I woke up today to see two threads flooded with discussion about ABCs new deep reorg protection. As I feel partially responsible for this, since I've suggested such a mechanism in a past thread, I'd like to make a comprehensive thread on the topic.
Terminology
Full Node: A full node (which is what miners, businesses, SVP wallets and full node wallets rely on) has a complete copy of the blockchain. The full node is also connected to its peers to receive and relay new blocks that are found.
Blockchain: Blocks always reference the block they are built on, hence forming a chain of blocks.
Consensus: A set of rules agreed upon by all network participants what constitutes block permissible to be included on the chain and which have to be orphaned because they are invalid as per consensus.
Orphan: If a miner receives a block but does not build on it for whatever reason (consensus violation or other metrics)
Fork: When two blocks appear that are referencing the same parent block
longer/shorter chain: Nodes select which is the canonical chain based on which valid chain (of several alternative forks that conform to consensus) has the most accumulated proof of work (for simplicities sake abreviated as "longer chain"). The shorter chain would be any with less accumulated proof of work.
Reorg: If there are several alternative chains and one that was previously behind overtakes the other, then a reorg happens where all transactions in the now shorter chain get invalidated by the now longer chain.
Deep reorg: If there is a reorg that goes unusually far back. For instance in the nearly 10 year history of the BCH chain, it only happened 2 in extraordinary circumstances that a 10 block deep reorg appeared (and both times in extraordinary circumstances that required manual intervention regardless).
Network partition: If there is an event which causes nodes on the network to mutually reject each others chain choices and side with one or the other side of a fork.
What is deep reorg protection?
This is a new rule introduced by the ABC implementation for full nodes, that will cause them to orphan a block if it builds on a chain whose fork origin lies back further than 10 blocks.
Why do we need it?
BCH being a relatively small chain it faces some issues with an attack where the attacker amasses enough hashing power to secretly build a longer chain than the chain everybody knows about. When the attacker broadcasts the blocks of this chain, they cause a reorg that goes back however long the attacker secretly mined (could be hours, days, weeks, months or years). CSW has threatened to do that.
The usual rule for when to accept a transaction as irreversible is 6 transactions (which is used by most exchanges and the like). Not only can the attacker with his reorg cause this to blow up (by not including those transactions), but he can also specially craft transactions to go into one block and say send coins to an exchange, but in the reorg exclude those transactions and include another transaction that he spends to his own wallet, and therefore execute a successful and damaging double spend (CSW has threatened to do that too).
Is this not a unilateral consensus change by ABC making BCH not Bitcoin?
No. This isn't a consensus change per se. Consensus is what can possibly constitute a valid chain as agreed upon by all network participants. It rules the visible history, the one that gets persisted forever. Miners can and do use a variety of "soft" rules to orphan blocks that technically conform to consensus (such as when they're to large, too expensive to validate, etc.)
Was it proper for ABC to introduce this change out of the blue?
I'm not terribly happy it got introduced as it was. I would've hoped there to be a robust debate and analysis of the measure by people way smarter than me, and I haven't seen any of that. That doesn't mean it's automatically a bad idea or change, but it may need some refinement, refinement that I hope every implementation, miner and full-node operator can get behind.
Will this not disrupt the usual functioning of the network?
No. 10-block deep reorgs only happened twice in the nearly 10 year history of the BCH chain and both times in extraordinary circumstances that required manual intervention regardless.
What if a 10-block deep reorg is not an attack?
This may happen in circumstances where the internet for a whole country (let's say China) is cut for a couple of hours. In that case there will be a more than 10-block deep fork of miners on either side of the internet (those within china and those outside). If this happens, a manual intervention will be required regardless if the deep reorg protection exists or not. Miners in China do not want to reorg the chain that users/businesses/exchanges outside of China accept as canonical. It is most likely that businesses/exchanges within China would suspend withdraw/deposit and wait for the network to be restored to pick up the chain when the network is restored.
Does this introduce a new attack vector?
I think it does create a new attack surface.
- Create a 10-block deep fork
- Broadcast 9 of the blocks (you may fake them arriving at organic intervals)
- Wait for the 10th block to be found on the other side of the fork and immediately broadcast your 10th block
- Let block propagation and node selection partition the network into two parts that mutually reject each others canonical chain as a 10-block deep reorg
Due to a concern-troll describing this attack in hundreds of replies on other posts I shall call this the zhell attack.
Can the zhell attack be mitigated?
I don't know. I think there may be mitigation strategies, but these will need a robust discussion and analysis to be developed, and I hope all developers/implementations/businesses will be part of that debate.
A suggestion/musing on how to determine a valid chain from several alternatives without PoW
The 10-block deep reorg protection circumvents PoW at the 10-block depth as the determinant of the "longest chain". Therefore any resolution strategy in a fork 10 or more blocks deep cannot rely on PoW. But if everybody can canonically agree on which side of the fork is the valid one whenever they get to see it (sooner or later), that does not matter as long as both sides of the fork are otherwise valid by consensus and everybody just picks one. The reorg attack can only succeed if it replaces the previously seen chain, so the goal is to make it improbably/hard to work out for an attacker to control which chain that is.
I'm not sure how to achieve this exactly, but it seems to me you could use block-hashes in some way to force a deterministic, non-controllable decision that would be hard to undo unless you want to rehash 10 blocks repeatedly until you found a chain that accidentially satisfies that criteria.
A naive (incomplete) implementation of that idea would be to compare the hash of the 10th block hash and pick whichever side of the fork as valid that has (numerically) the higher one. That idea is naive/incomplete because the attacker can repeatedly hash the 10th block until he found one that satisifies that criteria, and the probability of achieving it are 50% (not a very good mitigation). But if that principle could somehow be extended to all the 10 blocks (i.e. make the attacker waste much more work before he knows he's got a good 10-block reorg chain), it would make the attack extremely difficult as he would have to repeatedly hash 10 blocks over and over until he found a match.
In a larger context this is about an asymmetric/amplification defense. It has to be vastly more difficult to attack a chain than it is to maintain it. Malicious behavior has to be penalized so heavy in terms of difficulty/cost to pull it off, that even modest resources are sufficient to defend a chain. I know that this would seem to go againsts the grain of PoW, but I don't think it has to. PoW has to play an essential role in any defense, but it has to be used in a fashion to facilitate the amplification of attack cost, not make it more costly for the defenders to defend their chain from attack.
Another suggestion is some kind of advisory checkpoint system of the style that monero uses.
[link] [comments]
source https://www.reddit.com/r/btc/comments/9z1gjo/on_the_new_deep_reorg_protection/
No comments:
Post a Comment