7 ms·

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 traditiona

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 https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

Rmilb 9y ago
Unless you want to totally eliminate counter party risk or execute an unstoppable transaction. Most use cases do not require these benefits.
- metroidfan832 9y ago
  Unstoppable transaction is not a benefit.
  - kaffeemitsahne 9y ago
    Unless you want your transactions to be unstoppable, that is..
  - ghaff 9y ago
    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.
  - stale2002 9y ago
    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.
  - Rmilb 9y ago
    The continuing existence of Bitcoin disproves this. What do you base your point on?
kaoD 9y ago
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.
- lmm 9y ago
  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.
  - kaoD 9y ago
    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.
bascule 9y ago
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 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/ 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 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.
- dividuum 9y ago
  > 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?
  - bascule 9y ago
    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.

Rmilb 9y ago

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

metroidfan832 9y ago
Unstoppable transaction is not a benefit.
- kaffeemitsahne 9y ago
  Unless you want your transactions to be unstoppable, that is..
- ghaff 9y ago
  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.
- stale2002 9y ago
  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.
- Rmilb 9y ago
  The continuing existence of Bitcoin disproves this. What do you base your point on?

kaoD 9y ago

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.

lmm 9y ago
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.
- kaoD 9y ago
  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.

bascule 9y ago

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 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/ 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 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.

dividuum 9y ago
> 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?
- bascule 9y ago
  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.