The Blockchain Problem Space – When to Use Blockchain? | Hacker News Reader

The Blockchain Problem Space – When to Use Blockchain?

blog.ironbay.digital

127 pointsZGF458 comments

All: We've banned this site and this account for using a spam service to buy upvotes. Obviously that is a capital offense on HN. There's no issue on which the community feels more strongly.

I wish everyone would realize that when they do this, they leave obvious trails in the data and so it is not worth the risk.

The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see everything" are not the end user, whereas, in Blockchain because the nodes are untrusted, one must assume that the end user can see the entire Blockchain state.

This limits the number of use-cases tremendously to those where "everyone-can-see-everything" is an acceptable tradeoff.

There are several ways around this.

1) Zero Knowledge Proofs. But these are highly specialized and resource intensive. To my knowledge we don't have these for generalized Smart Contracts.

2) Split the overall state into Channels, Subledgers etc. with narrower "viewing rights". But again this typically involves an application compromise.

3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts.

4) Use frameworks like Microsoft's recently released CoCo Framework which relies on Hardware Trusted Execution Environments (TEE). The issue here is that a compromise of a single TEE negates the whole scheme.

In my opinion the privacy characteristics of Blockchain are a critical factor that needs to be taken into account while deciding on the suitability of Blockchai for an application.

Can you clarify the disadvantages of the application compromises required for option 2?

I'm currently looking at Hyperledger Fabric and it falls into that category.

Sure. Hyperledger Fabric 1.0 has the option of "Channels" to limit viewership rights. In particular it restricts rights to a subset of the community. For example, you may have a 1000 parties in the community, but a particular channel may have only three (say A, B and C).

Now, if one takes a Supply Chain example (a domain I'm quite familiar with), most transactions cannot be restricted to just parties A, B and C. Some will involve A, B and D and some will involve B, C and F etc. So, it is difficult to come up with a suitable Channel membership model.

Even if the transaction is between A, B and C often the view rights are not symmetric. For example in a drop ship case where A is the Buyer, B is the seller and C is the fulfiller, the price attribute may need to be visible between A and B but not C. This is not possible with the Channel approach.

So this particular type of hard partitioning only works for the simplest Supply Chain examples.

Another type of hard partition is to partition by Transaction. But this involves issues such as synchronization between transactions. This becomes an off-chain concern with major consistency issues.

Hope this helps.

Thank you that was a very helpful answer

> 3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts.

This will change once homomorphic encryption is feasible.

He mentioned zero knowledge proofs in point (1) - that includes homomorphic encryption if I'm not mistaken.

We're working on 5), a privacy option for public blockchains using secure multi party computation. Few application trade-offs (mostly around availability logic and additional cost), no private or trusted chains.

My recent work focused on applying sMPC.

Garbled circuits don't scale.

You know what is a great database with all those properties?

Your folder with git. There is nothing that you cant do with git that you can do with blockchains as a database.

About the BFT part, it fails the mention the very important part that it doesnt work without proof-of-work.

---

So then when should we use p-o-w blockchains?

When you want to decentralize control - both, distribution & conflict resolution.

Git has a history and UTXO does not store history only keeps with the latest commit

git has shallow clones `--depth N`

TL/DR: "If Byzantine Fault Tolerance [0] does not create a huge advantage for your use-case, it is unlikely blockchain makes sense to consider over a traditional database."

[0] https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

Unless you want to totally eliminate counter party risk or execute an unstoppable transaction. Most use cases do not require these benefits.

Unstoppable transaction is not a benefit.

Unless you want your transactions to be unstoppable, that is..

It really depends on the use case. In general, in the commercial world, we want to be able to have transactions/contracts that can't just be voided without consequence because one of the parties thought it was a good deal at the time but it turned out not to be. On the other hand, most legal systems aren't going to enforce contracts that have ruinous effects on someone because of a simple mistake or event that no one could have foreseen.

What if I don't want my transactions to be stopped?

Sure, the powers of the world that want to engage in financial censorship probably don't think of unstoppable transactions as benefit.

But the people that oppose censorship certainly do think of it as a benefit.

The continuing existence of Bitcoin disproves this. What do you base your point on?

And that is wrong AFAICT. PoW is what achieves Byzantine fault tolerance, not the blockchain.

What blockchain achieves is proof of history given only the latest block's hash. This might or might not have a PoW on top of it to achieve BFT.

Practical example:

An authoritative server which responds only with the latest block's hash (this is cheap, think microcontroller cheap) is another way to make a blockchain useful with no BFT. This way blockchain distribution can be offloaded to untrusted peers while the actual agreement is not distributed (and thus no DFT is involved).

EDIT:

Off the top of my head I can see a few applications of such an scheme: imagine a very low-power device taking mission-critical measurements. This device would periodically distribute a message consisting of (current block of measurements + previous message's hash) to untrusted high-power-large-storage clients. In case of any client desynchronizing it can request from its peers the measurement chain, and only has to receive the latest message from the low-power device to ensure the chain he got has not been tampered with.

That is not BFT because the source of truth is just an authoritative server. There is no distributed consensus even if there is distributed storage.

This is just semantics. "Blockchain" in the sense it's usually used means proof-of-work; hashing that incorporates the history tree predates blockchain and exists in things we wouldn't usually consider "blockchain", e.g. git.

It's unsurprising that discussig what a term means is just semantics ;)

Git is not a blockchain (it's a DAG) but that misses the point: I think the term could perfectly be retrofitted if it was the case. Things predating a term don't invalidate the new term convering them.

Either way I disagree with your opinion and there's nothing to argue further that would change either of our minds.

Though many new "blockchain" systems do achieve BFT (perhaps most notably Tendermint, which seems to be passing aphyr's Jepsen tests with flying colors), it's important to keep in mind Bitcoin falls short of achieving it:

https://eprint.iacr.org/2014/765.pdf

"Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by 1/3."

One important difference between how a truly BFT system behaves versus Bitcoin is how Bitcoin handles network partitions, or rather, how it doesn't handle them.

Specifically, when Bitcoin goes split-brain, i.e. in the event of a network partition, Bitcoin will "reorg" into two new chains, both of which will happily accept writes from both sides. When the partition is healed, one chain will win, and the writes to the other chain will be clobbered. Ideally these transactions will wind up in the mempool again and be accepted into the new chain, but that isn't a guarantee, more of a band-aid, and doesn't change the fact the system ostensibly acknowledged a write it then lost.

On the CAP triangle, Bitcoin has chosen to sacrifice partition tolerance (i.e. Bitcoin is NOT partition tolerant), and this is bad: https://codahale.com/you-cant-sacrifice-partition-tolerance/

There are ways to turn Bitcoin into a truly BFT system. The main one I like is decoupling proof-of-work from transaction processing, turning it into a leader election system for a more traditional BFT algorithm, such as ByzCoin:

https://arxiv.org/abs/1602.06997

With ByzCoin, if you can't reach quorum, you can't make progress, so in the event of a network partition the system will simply stop accepting writes if it can't reach quorum, as opposed to accepting writes which will go on to be clobbered by a future reorg.

> With ByzCoin, if you can't reach quorum, you can't make progress [...]

This may be a stupid questions, but how does such a system prevent me from adding new nodes, only to remove them all at once if I want to prevent the system from progressing?

The participants in the consensus group are selected via PoW. You would need to control > 1/3rd of them (i.e. 1/3rd of the nodes that have recently won the PoW leader election race/lottery) to cause Byzantine faults.

Not a bandaid at all. Unconfirmed transactions in the "lost" chain are bringing fees with them, so it is the exact same incentive of every other transaction.

Besides , how many times in history a continental network partition of the internet has happened?

And it would only take a single node connected to both sides (land and satellite?), to undo all the work of the would be attacker.

> how many times in history a continental network partition of the internet has happened?

Continental? No. Country-wide? Many, many times.

Imagine being in Egypt during the Arab Spring revolution when the government shut off Internet access. Imagine selling product to people for Bitcoin, seeing your client software accept the transaction because "enough time has passed", and then a few days/weeks later, when Internet access is restored, seeing your wallet balance get clobbered by the much-longer global chain.

/shudder

This is no different than, say, watching MongoDB for if it loses your writes, and if it does, replaying them.

This is definitely a band-aid: a good database doesn't lose writes it acknowledged.

So spin up a lot of nodes, stop writes, short the coin, and profit?

That's...surprisingly simple. As it happens I was just today lamenting to a colleague that for all the blockchain hype, I have yet to hear about any other relevant use case than those which have an ideological agenda to require decentralization at their very core.

Reading this it seems like the author comes pretty much to the same conclusion.

Is it really that simple? I feel like I must be missing something, because the hype is so real.

> Blockchain, however, handles conflict resolution in quite a different way. If there is a net-split between Europe and the USA and two versions of the database emerge, it simply decides on re-connection to keep the entirety of the version that has received more traffic during the disruption (aka the longer chain). This means if the USA version wins, all of the modifications in the European version, even if there aren’t conflicts, are discarded. To reiterate, this means even if most of the interactions in Europe were just with other users in Europe and not in conflict with the USA version, all of those writes are thrown away regardless.

Is this really possible? I can't see why not. If so could a DoS on a specific region of nodes that's large enough to sustain it's own sub chain for a short period be possible? This would be extremely dangerous if transactions were confirmed by the network on a chain that is eventually ignored.

I think it's unlikely you'd have a fully split chain, although this is actually an interesting attack against bitcoin, considering China could theoretically cause a China / rest of the world blockchain partition.

The article isn't correct in that "the version that has received more traffic during the disruption" wins. The amount of transactions that are in a bitcoin block play no role in determining the longest chain. It's solely about solving the most SHA256 proof of work solutions in the shortest amount of time.

So you could say that the connected component of the netsplit graph with the highest hashrate will win with the highest probability.

Simple economics dictates when to use space on the Bitcoin blockchain: When your use case can afford it. This is because transactions require a fee to get confirmed in Bitcoin. And the fees are currently low enough that it supports most use cases; pretty much everything except microtransaction payments. With Lightning Network coming, even that may become economically feasible.

Is "blockchain" singular, plural, or some kind of lowercase Proper Noun?

> Blockchains fall

Okay, blockchain is singular, so it always refers to a single object.

There is a universe U of objects, and "Blockchain" is a predicate on U. So for any given x in U, "Blockchain(x)" is a proposition. In other words, we can ask whether something is a blockchain or not.

> Step one is to figure out a framework for analyzing blockchain

Here it's being used as a plural, like you might study a herd of blockchain. That's okay in principle - some words are their own plurals, like "sheep" or "fish". But above, it had an "s" at the end, so it can't be plural.

Another possibility is that "blockchain" is the name of some specific object. "Fred went to the store" -> "I asked blockchain for some money".

That's no problem: Your name can be "Archer" and you can study Archery.

There is a constant c in U such that Blockchain(c). Something somewhere is named "blockchain".

> blockchain does not have the capability to support

> For everything Blockchain does worse than other databases

More evidence that he's talking about some specific blockchain. Christians capitalize God in every sentence to show reverence, while Atheists tend to leave it as a lowercase god.

Is something similar happening here? Which blockchain are people even talking about?

I probably should not be capitalizing it ever and using it as singular everywhere. Thanks for pointing that out

Blockchain should be singular - "blockchains" should be used when referring to the technology in general. Getting this wrong is the #1 indicator that an article on blockchains isn't worth reading.

I'm not sure if it should be plural when referring to the technology in general. "Powered by blockchains technology" doesn't seem correct to me.

I do hope you'll read the article regardless!

The word "blockchain" works just like the word "computer". You can have a blockchain or multiple blockchains, just as you can have a computer or multiple computers. And you'd refer to "blockchain technology" just as you'd refer to "computer technology."

I think Steem is pretty interesting from a developer perspective. Since all data lives on the blockchain it's like having unlimited and unrestricted API access. It's very different from having to submit to whatever restrictions and rules centralised social networks usually put on their APIs, if they have one at all.

You really need a blockchain for ONE THING:

To timestamp transactions in a distributed way.

Transactions can be signed, proving authorship.

At signing time, you can prove the transaction happened AFTER something else.

The only thing missing is PROVING THE TRANSACTION HAPPENED BEFORE SOMETHING ELSE.

For that, you need an incentive structure to keep each transaction be accepted by someone, somewhere, in a growing merkle tree.

That's the blockchain.

However we don't need proof of work to elect the next miner for every block. It leads to an incredibly wasteful arms race.

In fact we don't even need every transaction to be verified by a miner. Only the merkle tree that happened before the block signing time.

Proof of work does not elect the next miner.

Proof of work means that the lucky random miner has invested energy on a previous valid block, and is lucky enough to find another valid block.

If you take that away, you could as well use a database and a trusted timestamp server.

No, that's a false dichotomy. And also the "lucky" is relative to the whole scheme. The value to the miner of finding a hash to make another block has gone down and will continue to go down, that's partly why transaction fees are so high.

In any case, that's like saying someone is "lucky" to win a video game in Dave and Buster's. That's not the only way to incentivize validators to timestamp transactions. All you really need is a consensus protocol.

Ripple for example has a consensus protocol that can be run by an entire LOCAL community and can fund itself and the resources it uses. Without requiring a global blockchain. And Bitcoin validation is effectively centralized in the hands of a few miners.

Who defines the LOCAL community?

People who deal in that local currency.

The PoW isn't meant to elect the next miner. It's meant to ensure the integrity of the chain and maintain a lead in the work cost for the honest chain.

Transactions are already signed and can't be forged. The only reason for the chain to exist is so that everyone knows about every transaction, to eliminate the double spend problem.

I have a use case for a new blockchain/cryptocurrency that I think is cool. Feel free to take the idea from me and implement it for an ICO :)

I propose "whatcoin", a cryptocurrency designed to create a market for peer to peer media sharing based on the upload/download ratio model used by what.cd and other private torrent trackers to incentive seeding and penalize leeching.

The whatcoin "blockchain" has a catalogue of all currently available music on the platform, so it doubles as the tracker and transaction ledger. The catalogue can have multiple copies of albums sorted by the specific release and the quality (lossless FLAC, lossy 320kbps, etc).

So let's say you want to download a FLAC formatted 1988 MFSL release of Pink Floyd's Dark Side of the Moon album. You'll pay a specific amount of whatcoin from your own wallet based on the size of the files being downloaded, which will be distributed to the seeders you peer with. You'll also pay a network transaction cost.

The network transaction costs fund the "miners", or those who upload new, verified releases that are not on the whatcoin network yet. Those who upload the music are also strongly incentivized to continue seeding it, because they will be paid whatcoin inversely proportional to the number of other available seeders for the same files whenever someone chooses to download them. So the more exclusive the media is, the more lucrative it will be to host it.

Seeders will be paid for uploading media and leechers will pay for downloading media; leechers can then earn more whatcoin by continuing to seed the media they've just downloaded. Each upload/download transaction is recorded on the whatcoin network, and the greatest economic opportunity is available to those who can upload popular new media and then seed it very early on.

This proposal is similar to Filecoin, but you're paying to download new media instead of to store your own and retrieve it later. It also adds the extremely high fidelity media cataloguing that some private trackers have achieved. You could market it to the MPAA or RIAA as an "enterprise blockchain" the way banks are currently investigating it. The studios would be paid for new media they bring onto the platform, and indie artists could be paid for bringing their media onto the network instead of, say, SoundCloud or Bandcamp. If the media is popular enough then the original uploaders are heavily compensated and their hosting costs decrease over time, because there will be other seeders to maintain the media.

If large media firms didn't go for this immediately, you could try and take this concept and ICO with it. Then start competing with Bandcamp and SoundCloud to capture the indie market. With the ICO funding and notoriety in that space, try to take on the RIAA.

> Each upload/download transaction is recorded on the whatcoin network

Hmmm. Under this scenario, though, wouldn't the major labels be losing out when others host their files? They may have an incentive to place music on the chain, but if I read you right, when others host the same files, the labels' share of whatcoin for those files declines.

I has similar idea around 3 months ago. The problem is that to participate in this network you need to pay and in normal networks today you don't need to pay anything.

There are a lot of technical problems in this what you wrote, it's only good in theory. You write that each upload/download transaction is recorded but you don't define what is a upload/download transaction. If you will use protocol like bittorrent you have chunks that are downloaded from many peers that are divided into blocks, having all those transactions in blockchain will not scale, it's just too much data. Another problem, How can you ensure that someone will not cheat in network? I can spoof that I have certain data, you will send me coins and I will not send you the data or if you confirm in source it's even more easy to cheat I will just send information that I got corrupted data even it's ok. There is a lot more other problems with this idea.

How do "miners" fit into this ?

Agreed. But also, it's become very hard to get anything to get noticed organically.

It is not about quality. The same exact story submitted by different people or at different times may get 1 upvote and gets buried, or hits over 100 points on the front page. See this for example!

https://news.ycombinator.com/item?id=14929067

I suspect most frontpage people ask their friends to upvote a story in the first few minutes.

Check out my own list of submissions for some examples. The vast majority is 1-2 points. Including SHOW HN stuff I worked hard on such as this:

https://news.ycombinator.com/item?id=13474714

Ironically, I got more upvotes on a comment I made, regarding this phenomenon.

You've posted several of these off-topic complaints in off-topic places, but doing it in response to a comment about people buying spam upvotes on HN takes the cake.

There's no right to "get anything to get noticed" on HN. There is, however, a duty not to defraud the community. If people defraud the community then obviously we're going to ban them many times over.

We detached this subthread from https://news.ycombinator.com/item?id=15010431 and marked it off-topic.

I posted it a couple times since I have no idea if you saw it. If you responded (as you did) I would not post it again. HN is not like Facebook, no one gets notified of follow-up comments, so I don't know if someone actually saw my comment in response to theirs.

I totally agree that the community should protect itself from being defrauded. I actually support the measures you are taking on that front. I just wanted to bring to your attention, as a pretty active and interested user of HN, that it has changed and the system pushes people to do this kind of stuff. It's fostering competition to do it, because that's what it takes to get to the front page. I suspect that this happens in most cases. Look, I could be wrong - you have way more data than me - but using just what's available to me suggests that "asking friends to give you a couple upvotes in the crucial first few minutes" happens a lot. Heck, I did it in the past once or twice and it worked. The problem is that this mentality causes the element to become necessary. That, or clickbait.

We don't want this in the community, I agree, but it's like punishing X in individual cases while the system almost requires X to get to the front page in the first place. It is not about a "right" to get anything noticed on HN. It's about the incentive structure that develops over time as the system grows and changes.

Bitcoin started out to be decentralized and now is in the hands of several miners, and fees have gone up. Saying that there is "no right to have a transaction be recorded in the ledger" doesn't mean there isn't an incentive problem with a root. The root of that problem is the escalating proof-of-work arms race.

Authorities in the drug war thought if only they got low level dealers to rat out their suppliers there would be no more drugs on the street, but the incentive structure of money to be made on drugs caused a problem. The root of that problem is an escalating arms race between the feds and the cartels caused the drug gangs become more ruthless and publicly execute the families of those who ratted people out, greatly increasing violence.

The root of this problem is an escalating arms race to get noticed as HN has grown. But perhaps there is no problem. If there is, however, this is NOT OFF-TOPIC. The topic is gaming the system. And I am saying this as someone who wants to see less of it, but recognizes that the system now encourages it more than in the past.

Ok since you detached the threas I'm going to guess the downvote is yours, with no response so you think there is no problem. And this is off-topic.

Well, I've brought it to your attention, no reason to mention it anymore. Good day sir! :-)

If you want to talk to the mods, you can just email them instead of posting your complaint repeatedly in random threads and hoping someone notices.

I didn't downvote you—no one, including mods, can downvote direct replies. But if you have concerns about HN quality or moderation you really ought to send them to hn@ycombinator.com, as the site guidelines ask (https://news.ycombinator.com/newsguidelines.html).

Thanks! I don't know what you mean by "direct replies" but the thing above got downvoted to 0. Anyway, it doesn't matter.

Yeah, I will send an email to hn@ycombinator.com next time it's something I think the admins should know, this time it just seemed relevant to mention this.

Anyway, Good Day! :)

Reply on news.ycombinator.com