So the 51% attack has been a hot topic lately for obvious reasons. Not only that, I think it's THE topic on everyone's mind even if nobody is officially saying it. There is evidence here, here, here and I think even here...
The elephant nobody is acknowledging remains in the room. Accordingly I've been thinking of good defensive strategies a lot over these last days. The day before the fork I submitted an article outlining a new defense model:
https://www.reddit.com/r/btc/comments/9x5gmn/bitcoins_model_is_antiquated_moving_beyond/
For some reason it got zero upvotes (actually a downvote to zero) and no worthwhile discussion. Hopefully this submission fares better. I do think the defense I outlined is quite viable, but I acknowledge the costly move toward centralization. So I continued thinking of ways to further improve defense and I think I've got something that works without any added centralization pressure. It's surprisingly simple, with only two general changes being made.
First, there is a consensus rule change saying no node accepts a re-organization over 5 blocks long, at least, not without explicit manual override (useful in cases of unintentional chain splits). There shouldn't ever be a case where nodes suddenly learn of 6 or more blocks having valid rules and proper difficulty they were previously unaware of. The only situations where that would be expected is a bug creating a chain split, or an intentional hashpower attack to create disruption. As stated, an override can handle bugs, so the remaining issue should be edited out completely. This gives the ecosystem assurance that as often stated 6 confirmations means settlement certainty.
Astute observers will recognize an obvious problem: nodes attempting to sync won't ever be aware of rejected re-organizations since they would satisfy all chain requirements otherwise. This is easily resolved by having all nodes sync backwards. A node synchronizing from the highest block perceived from the network's perspective will include all rules of that network, including one rejecting lengthy real-time re-organizations.
So those are the only two changes to the way we currently do things, but 51% attacks are rendered impotent! As for where nodes get the highest block that's easy to accommodate. Nodes compatible with BIP 0064 (authored by Mike Hearn) already have access to 'chain height' and 'chain tip hash' when querying for UTXO lookups. Those return values coincide with the moment the result was calculated, though, so a better, explicitly most recent height and hash service might be preferable. Nodes then use the broadest consensus.
This does open the door slightly to Sybil attacks. However, an attacker would need to be working alongside the entity performing the broader re-org attack, and any harmful effects are limited to the effectively isolated and Sybil'd node(s). Since synchronization events are rare there might be a bootstrap 'sanity' list similar to the current DNS seed which is used to compare the information the node receives with IPs developers deem trustworthy (e.g. Bitcoin.com, BitPay etc), which would also defeat a Sybil attack.
The DoS portion of a 51% attack is also solvable with simple changes such as adding tx prority weighting (mentioned in my article) to determine the best chain.
No comments:
Post a Comment