[heptathorp]

>You know the transaction exists, and at some point (i.e. after a certain number of blocks), if the transaction isn't included in the chain, you can conclude with reasonable certainty that the transaction is being intentionally orphaned. This allows you to reject the chain that doesn't include the transaction as invalid, and choose the longest chain that does include it.

So you are going to reorg after many blocks (enough to be sure a transaction is being censored). This sounds extremely undesirable as it kills finality. Today you can very reasonably be sure that after say, 6 blocks, a transaction is irreversible. That's not the case with this new rule.

[kerkeslager]

It delays finality, but it doesn't kill it. Reorgs are already possible, this is why we currently wait for some number of confirmations (6 last time I checked) to say a transaction is complete. Adding the condition of requiring all transactions you've received to be included in a chain means that you need to wait for more confirmations to reach the same level of confidence that the chain is final, but it doesn't mean finality will never happen.

With a perfect network where everyone receives all transactions immediately, and where transactions are prioritizes for inclusion by transaction fee first, and order received second, we can conclude after ONE block whether a transaction with a high enough transaction fee is being excluded. But the network isn't perfect. There's some network analysis to be done here to gather probabilities, but for the sake of simplicity, let's say the network is reliable enough that we can reasonably conclude whether a transaction is being excluded in 5 blocks (I think the number is actually lower, but let's go with 5 to be safe).

So basically, what we're saying here is that if we reject the fifth block that doesn't contain a transaction after we see it, then we're forcing a reorg.

The attack you're describing happens when someone waits for China to start ignoring a transaction, then attempts to use the resulting reorg to execute a double spend.

Last time I checked, the recommendation was to wait for 6 confirmations to prevent double spends, because it would be unreasonable for an attacker to attempt to catch up to the main block chain when the main blockchain has a 6-block head start. But if China forces a reorg after 5 blocks, then the attacker attempting to execute the double spend only needs to catch up 1 block.

Trivially, all this means is that we have to wait for 5+6 = 11 confirmations to achieve the same level of confidence that we got from 6 confirmations when China couldn't force a reorg.

But wait: China actually can't force a reorg that quickly with 100% probability. In order to force this reorg, China has to mine 5 blocks in a row. China only has 66% of hashing power, so the probability of China mining a given block is P=0.66. The chances of China mining N blocks in a row is P=0.66^N. So the probability of China even being able to force this reorg is P=0.66^5=0.13.

That's not nothing, but that's a lot of effort for China to put in just for a 13% chance of delaying a transaction. Given China can't actually censor the transaction, only delay it, why would they spend all those hashing cycles to do this? The incentives don't line up.

[heptathorp]

Good points, thanks.

Followup question: how does a node coming online know not to trust China's (longer, censoring) chain? It wasn't online to have the transaction in its mempool, so it doesn't know to check for it in the longest chain.

I think it would need to check all candidate blocks with lower heights to see if their chains contain any transactions that aren't in a longer chain.

What happens if I mine off of a very old block and include my own transaction in it, and present it to you... how do you distinguish between what I just did vs the longer chain having censored the transaction this whole time?