Topic: Introduce reorg limit for guaranteed settlement and attack resilience? (Read 1340 times)

TL;DR: Suggest limiting Bitcoin's ability to automatically reorg to 6-72 blocks, for non-technical reasons.

While it technically makes sense to re-org whatever it takes to switch to the fork with more POW, this ability if unconstrained is incompatible with the business need of a final settlement.

Think of a bank account statement mailed to you. Do you think any jusrisdiction would allow the bank to revise the statement today and re-mail it with yesterday's date? Nope. Especially not for an IT reason. If there are errors then adjustments could be made, but with today's date and clearly flagged as adjustment, not just through presenting a new backdated reality.

Current financial technology works with settlement cycles, usually a few per day. Funds that settled at the last cycle can not un-settle in the next for a reason unrelated to the parties involved. If an adjustment is requested by either party or for a technical reason, then they are flagged as such and are not processed with the same workflow, but often trigger human review and decision on the matter. This is not because technology in banks was bad, but because final settlement of claims is of value to the bank's customer, it simplifies their business process and is the primary reason they use a bank account to settle claims.

To deliver the same value to business, Bitcoin transactions have to be final after a time horizon comparable to settlement cycles, that is a few hours.

An implementation for final settlement would disallow automated reorgs longer than few hours' of blocks, that is 6-72.

Assuming a reorg limit of N was implemented, businesses could be certain that transactions with at least N confirmation are final and this would greatly simplify their business process. B2B systems would likely use only transacions with N confirmations and they would love the network for its simplicity and reliability.

What would happen if a reorg longer than N is justified by POW?

Following Gavin's thoughts at https://gist.github.com/gavinandresen/630d4a6c24ac6144482a this would be the result of either a long network split or an attack.

A network split should not come as a surprise, since previous significant drop in block frequency would indicate that something is fishy. IT would check connections and stand ready to accept a longer fork as connections are restored. Customer could be notified that settlement cycles are suspended until the problem is resolved. Once the network is reunited longest chain was accepted no matter how long it reorgs and some time later customer notified that business is again as usual.

An attack would rather look like sudden increase of hash rate. Should it reorg more than N, then the network would, by default, ignore it thereby making the attack even more expensive. Since IT teams would not stand ready to act as in the split case, the manual switch to the longer "attack" chain was delayed indefinitelly. More likely than action of the majority it was the rougue miner who would learn that playing by the rules (that is mining on the tip) is more profitable.

For above reasons I think Bitcoin would become more attractive for business use and be more resilient to "51%" attack if it had a limit to automatic reorg, and could only be overridden with a manual action.