Question about BTG’s Rolling Checkpoint Finalization (RCF):
Seems kind of dangerous; wouldn’t the fixed fork limits make it easy to cause a permanent chain split?
It’s true, having a rolling checkpoint or rolling finalization opens up the theoretical possibility of a network split, which means it opens the possibility of a chain split. However, doing this is neither easy nor permanent.
There’s a full description of the new methodology in the release notes, but it’s critical to understanding our current question, so I’ll repeat the core of it here:
Rolling Checkpoint Finalization
Default Block Eligibility Requirements:
- depth >= 9 blocks
- age >= 4800 seconds (based on the receiving node’s timestamp.)
Finalization effects:
- A node receiving a conflicting chain of blocks from the network will not roll back further than the most recently finalized block, preventing deep chain reorganizations.
- Manual changes to the blockchain (via
invalidateblockandreconsiderblock) can still cause rollbacks beyond the finalized block. - Finalization is not persistent between node restarts, meaning a newly restarted node will have no finalized block for at least 4800 seconds.
Now, back to our question:
wouldn’t the fixed fork limits make it easy to cause a permanent chain split?
First, on the permanence:
This implementation of RCF is not persistent across node reboots. This means that if a node does get isolated because of an attack that bifurcates the network, a simple reboot will allow it to rejoin the majority network. When a node starts up, it will not mark any block as finalized for 4800 seconds - 80 minutes - which is plenty of time to establish 8 random outbound connections (or more, and likely multiple inbound connections, as well), from which the node is very likely find at least one node providing information on the majority chain.
Moreover, a node does not have to be rebooted if the operator knows it has been split off from mainnet - a manual invalidateblock can roll back the chain past any recent finalization, and the node will then be free to accept blocks from the majority chain as new peers connect.
Clearly, we’re not talking about true finalization in the sense that it is permanent - we’re talking about relative local finalization. This is why we take pains to call it Rolling Checkpoint Finalization, not True Finalization. This level of rollback-resistance is, however, enough to prevent deep-chain reversions of the type that we’ve seen people using in attempts to perform double-spend attacks against exchanges.
Next, on the ease:
At first glance with a bitcoin mindset, it may appear simple to potentially cause a network split: simply mine blocks in secret, and release them immediately after the honest pools mine those same blockheights. If some nodes accept your secret block instead of the honest public block, you’ve split the network. If you release the secret block less than 1 second after seeing the honest block released, this is theoretically possible - and if you can keep this up until the 9th block, each side of the fork will finalize to one side or the other, leading to a chain split.
However, we need to bear in mind that the bitcoin protocol does not actually really on chain height (block count.) Instead, it relies on accumulated work, which is a function of the difficulty when each block is mined. And while bitcoin only adjusts difficulty once every 2016 blocks, BTG adjust difficulty after every single block!
This means that the first duplicate block mined in secret by an attacker will have the same accumulated work as the honest public block, because they both get their difficulty from the same previous block’s timestamp. However, the second block mined for each side of a fork on BTG will very likely have a unique difficulty, because the timestamps in the block headers have very little chance of being the same. Even the slightest time difference will lead a different difficulty, which means the second block will contain a different amount of accumulated work. With different amounts of accumulated work, there is no longer a race or a split: the second block will immediately resolve the fork to one side or the other for the entire network.
An attacker might try to avoid this problem by attempting to hold back nie blocks and release them all at once after the honest pools publish a 9th block… but that runs into the problem that a while chain of blocks takes much longer to propagate through the network than a single block. You see, nodes don’t relay a block to their peers until validating it - and validating a whole chain of blocks and rolling back the mainchain to set those new block as the active chaintip generally takes much longer than validating a single block on the current tip and passing it on. Consequently, an attack has to release after the mainchain publishes the honest block (so it’s already behind), and then it has to deal with a big disadvantage in propagation time. This gives it a high chance of failure - but every attempt comes with the full cost of buying illicit power to mine all those blocks. In fact, they have to overpay to attract enough power to mine those blocks faster than the mainchain. These failures cost a lot of money, and every time the honest chain wins, all that money is lost.
Plus, whenever these 9 blocks happen in less than 80 minutes (which is not that rare), there’s no finalization/bifurcation problem at all, simply a 9-block fork that resolves immediately. While a 9-block fork will take some rewards away from honest miners, it will fail to power a double-spend against an exchange! In fact, not only will it fail against an exchange, the reversal of those deposit funds will indelibly mark that attacker’s account as having attempted fraud, surely leading the exchange to lock the account down.
An attack like this fails to power a double-spend against an exchange, and most of the time it fails to grab any block rewards at all - this is a very unprofitable thing to try.
And counterattacks!
On top of this, there are a host of other factors at play which make an attack even less likely to succeed, including the fact of counterattacks. There are BTG pool(s) who watch the chain & the hashpower markets for signs of secret mining, and who do counterattack. “Secret” attacks in progress are not invisible - the hashpower market activity makes them very obvious, and the pools have shown themselves to be quite capable of counterattacking to prevent such theft of rewards. Indeed, they’ve successfully counterattacked about half a dozen times during the past six months (as of August, 2020).
This means that if an attacker does manage to completely secretly mine a 9-block fork and release all those blocks at the last moment and still somehow get their chain propagated to many of the nodes faster than the single honest block, successfully causing a split… those newly seen blocks aren’t eligible for finalization for 80 minutes - which is plenty of time for a counterattack to grab the tip back to the honest chain, preserving the honest pools’ rewards.