Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I halfway disagree:

There is a huge scientific merit of the algorithms for reaching a distributed consensus when not all participants can be trusted (including the fact that the Bitcoin paper uses game theory to give evidence why malicious entities attempting to create another fork will by the mere design of the algorithms have a hard time).

What is, of course, social consensus are some aspects about what it "socially" means that there exists this concrete consensus in the blockchain. By the design of the protocol and its data structures, there do exist boundaries concerning possible "social interpretations" of this consensus, but a lot of aspects are up to different interpretations.



> There is a huge scientific merit of the algorithms for reaching a distributed consensus when not all participants can be trusted

Not quite. Distributed consensus had been solved in the 1980's theoretically and the 1990's practically, even in the presence of byzantine nodes. What Nakamoto consensus was first in was to extend this to the permissionless setting (at enormous expense & inefficiency, and with no benefits, in my view; though enabling large scale rule breaking or "censorship resistance", which some see as a benefit).


> Not quite. Distributed consensus had been solved in the 1980's theoretically and the 1990's practically, even in the presence of byzantine nodes.

Could you give me some literature references on this topic, because I guess this is something new to me?


I highly recommend Tim Roughgarden's lecture series Foundation's of Blockchain. It covers it all:

https://www.youtube.com/watch?v=KNJGPI0fuFA&list=PLEGCF-WLh2...


Thank you.



Thank you.


Nakamoto Consensus didn’t solved a secure scalable PBFT (Practical Byzantine Fault Tolerant) Consensus.

Bitcoin didn’t solved a forkability and finality problems. Blockchain (or more properly hashchain) is a linked list of hashpointers, and since anyone can create a hashpointer pointing to the head of the hashchain - it means anyone can fork it. And indeed Bitcoin was forked multiple times, and the solution to forks was almost always either centralized and/or social.

IMO PBFT consensus algos have a niche applications anyway, and not required for Electronic Cash implementation, only for decentralized and/or disintermediated Systems-of-Record, but that’s a complete opposite of bearer instruments like electronic cash.


Bitcoin is the OG Birkin Handbag. Valuable for the story. People compete to own a bit of it for that. You can create your own Bitcoin clone and own all of it! But no story, no value.


> You can create your own Bitcoin clone and own all of it!

That is what I wrote:

> What is, of course, social consensus are some aspects about what it "socially" means that there exists this concrete consensus in the blockchain.

In your private Bitcoin clone, such a consensus has a "socially much more boring" interpretation.


I'm not disagreeing though. Just adding.


> There is a huge scientific merit of the algorithms for reaching a distributed consensus when not all participants can be trusted

Yes, they existed a long time ago and aren't wasteful as a way to generate "value".


> Yes, they existed a long time ago and aren't wasteful as a way to generate "value".

Can you give me a literature reference for such a result, because this claim surprises me.

Of course Merkle trees existed long before - but they are just "cryptographically signed data structures", and thus don't solve the distributed consensus problem.

Of course eCash existed long before - but it depended on some central authority.

Of course distributed consensus algorithms existed long before - but they depended on the fact that all participants are trustable.

Thus, in my opinion Satoshi Nakamoto indeed made a really important scientific contribution for a quite specific algorithmic problem.


> Of course distributed consensus algorithms existed long before - but they depended on the fact that all participants are trustable.

No. They depended on the fact that all participants were known (in other words, the permissioned setting). Among those known ones, some (less than n/3) could go bonkers, all the way byzantine, and the honest nodes would still be guaranteed to find consensus (with consistency and availability).


I'm pretty sure there's no guarantee to find consensus. Even if all nodes are functional.


Depending on the networking assumptions, of course there is. That's the whole point of SMR: under certain assumptions, you can attain availability and consistency.


No. Paxos does not guarantee consensus.


The basic results of SMR theory are as follows, where "sync", "async" and "partially sync" refer to specific network models; PKI is public key infrastructure (that is, each node knows all the other nodes and has their public keys); "f" is the number of failed/dishonest/byzantine nodes (out of n total nodes); and only deterministic protocols are considered.

1) Permissioned, Sync, PKI: SMR possible, any f (!), Dolev-Strong (1983, [-5])

2) Permissioned, Sync, no PKI: SMR impossible if f >= n/3, PSL (1980), FLM (1985) (the hexagon proof, [-4])

3) Permissioned, Async: SMR impossible even with f=1 (!), FLP (1985) ("endless bivalent", [-3])

4) Permissioned, partially sync: SMR with "eventual availability" impossible if f >= n/3 [-2], possible otherwise (eg Tendermint [-1], Byzantine Paxos, PBFT)

In setting 4), PBFT-type protocols such as Tendermint guarantee consistency (among the "honest" nodes following the protocol as intended - you can't make any guarantees wrt to faulty or byzantine nodes) and eventual availability (that is, all requests sent by clients will "sooner or later" be dealt with) once network functionality is resumed.

That is consensus, for all intents and purposes, given that more consensus isn't really possible due to 2), 3). And arguably better consensus than Nakamoto consensus, which improves the boundary in 4) to n/2 (without selfish mining) at the cost of being stochastic, not deterministic, but replaces "consistency always, availability eventually" with "consistency eventually, availability always", arguably the wrong choice for financial applications.

[-5] https://timroughgarden.github.io/fob21/l/l2.pdf

[-4] https://timroughgarden.github.io/fob21/l/l3.pdf

[-3] https://www.youtube.com/watch?v=vJhm9uhd34E&list=PLEGCF-WLh2...

[-2] https://timroughgarden.github.io/fob21/l/l6.pdf

[-1] https://timroughgarden.github.io/fob21/l/l7.pdf




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: