The solution to the secret chain attack is simple and was described and researched by Vitalik and ETH years ago. No checkpoints needed.

Everyone is worried about what happens when BCH's hashrate returns to the saturation point (1.00 DARI on fork.lol) and if BSV/Ayre/CSW decide to attempt a reorg 51% attack to double-spend against exchanges.

This is a legitimate fear, and fortunately there's an easy solution. Each individual node simply needs to make it more difficult for a sudden long-chain reorg to overtake an established public chain.

Specifically, these rules:

  1. If the current "best" chain is 6-12 blocks from the reorg height, require that the new "best" chain have twice as much accumulated POW.
  2. If the current "best" chain is 12-48 blocks from the reorg height, require that the new "best" chain have three times as much accumulated POW.
  3. If the current "best" chain is 48-144 blocks from the reorg height, require that the new "best" chain have four times as much accumulated POW.

And if desired, 5x as much past 144, etc. This rule doesn't apply if a user manually uses invalidateblock on either branch.

This is effectively a quick and easy version of Vitalik's weak subjective scoring that prevents divergent chains in POS: https://blog.ethereum.org/wp-content/uploads/2014/10/ess1.png (Source here). Moreover, Gavin Andresen described a similar idea to me about 4 years ago.

This immediately provides complete protection for exchanges to accept any BCH transactions at 12 confirms, and provides a lot more confidence against a reorg attack in general, under all situations. It also puts the hashpower required to destructively reorg the BCH chain out of reach for CSW/SV/Ayre.

Meanwhile, it prevents users from getting stuck if there is a bug that requires a reorg - Like what happened in March 2013 when the BDB bug split the Bitcoin chain. Users who do nothing will eventually get reorg correctly even if they don't invalidateblock, and exchanges/miners who are time-sensitive can use invalidateblock to stay on track.

This approach also doesn't require active checkpoints from developers or frequent upgrades from users.

Edit: I forgot to mention, but as this rule is a consensus change, it is easy to add a sunset to the rule 15 months from now when it is unlikely for there to be any threat of an attack from SV/Ayre/CSW. Sunsets are good, assuming we don't want the rule permanently for all future situations.

submitted by /u/JustSomeBadAdvice
[link] [comments]

source https://www.reddit.com/r/btc/comments/9xo7eq/the_solution_to_the_secret_chain_attack_is_simple/

Comments