<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 26 feb. 2017 20:39 skrev "Henry Baker" <<a href="mailto:hbaker1@pipeline.com">hbaker1@pipeline.com</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This approach cryptographically selects ---in a way that is provably immune from manipulations, unpredictable until the last minute, but ultimately universally clear--- a set of verifiers in charge of constructing a block of valid transactions.  This approach applies to any way of implementing a shared ledger via a tamper-proof sequence of blocks, including traditional blockchains. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">This isn't the first attempt to do this. The arguments against it are old.</div><div dir="auto"><br></div><div dir="auto">Here's a good article on why everything that isn't centralized degrades to proof of work when there's an incentive to influence the globally shared output;</div><div dir="auto"><br></div><div dir="auto"><a href="http://www.truthcoin.info/blog/pow-cheapest/">http://www.truthcoin.info/blog/pow-cheapest/</a><br></div><div dir="auto"><br></div><div dir="auto">Some examples of why this is flawed;</div><div dir="auto"><br></div><div dir="auto">1: Sybil attacks. We could just stop here, but... </div><div dir="auto"><br></div><div dir="auto">2: NSA (or any other entity with similar technical capabilities) can just hack the current leader nodes. They're just a bunch of random nodes in the first place, so they're unlikely to be highly secure. </div><div dir="auto"><br></div><div dir="auto">Then they can try a million inputs until all further blocks appoints themselves only as future leaders. This is a huge weakness with using elected central master nodes in networks without any central gatekeeper. This system is just a distributed gatekeeper that you can hijack. A full takeover is unrecoverable with technological measures and needs a social effort to revert.</div><div dir="auto"><br></div><div dir="auto">If there actually existed any automated method capable of restoring normal trusted behavior after a takeover, then this method would by itself be able to replace the standard concensus system. </div><div dir="auto"><br></div><div dir="auto">3: There's no way their proof will be meaningful in any way, because it implicitly assumes that all nodes are secure and it assumes a perfect network. "Unpredictable until the last minute" means nothing even if they're doing their randomized node selection with hash commitments. </div><div dir="auto"><br></div><div dir="auto">This is both because of the above mentioned Sybil attack, and because if you've got a large number of nodes participating then you can always delay publishing commitments until everybody else has published theirs, and opt to publish OR not publish committed values as desired to influence selection (giving you as many "bits worth" of effective bruteforce as you've got participating nodes) - and of course also because of the following problem;</div><div dir="auto"><br></div><div dir="auto">4: Netsplits. Or worse, induced netsplits and direct network level censorship by somebody capable of spying directly on the internet connections of the individual nodes. </div><div dir="auto"><br></div><div dir="auto">Since a protocol like this must be tolerant to node failures, NSA can just delay the responses of everybody and chose the set to allow through that gives their own nodes more control (amplifying the effect of the selective publishing attack in #3). </div><div dir="auto"><br></div><div dir="auto">5: The classical nothing-at-stake problem. There was a valid block A at time B (in the past) from set of leaders C.  </div><div dir="auto"><br></div><div dir="auto">Then network troubles happened and most nodes fell away, and a new leaders were appointed from the candidates. </div><div dir="auto"><br></div><div dir="auto">Except not, the "real" chain is a different one, but your fresh node doesn't know that. And it has no way to know. </div><div dir="auto"><br></div><div dir="auto">Nothing enforces that this blockchain truly is append-only for anybody not well connected. What's worse is that if your node later finds the real chain, your node has no object way to know which is real, while it does have internal state that is incompatible with the current chain (the set of appointed leader nodes). </div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">There's not even any useful heuristics to detect an attack, because any sign of a forgery attack in the blockchain is indistinguishable from an actual real world event (and can be induced in the real chain). And any strong heuristics would lead to a looks-least-fake fork competition with ugly play = another modified proof of work scheme. </span></div><div class="gmail_extra" dir="auto"><br></div></div>