DOS prevention: mempool handling of ZCE replacements

[bitjson]

Tier Nolan brought up a possible denial-of-service preventing rule:

The overall system does make memory pool handling harder. One of the big advantages of the first seen rule is that you don’t have to handle removal of long chains of transactions. The only exception been once per block received.

It may be worth adding a rule that miners shouldn’t build on ZCE outputs (other than the reclaim transaction).

Some notes:

It’s worth noting that ZCE replacement is reasonably limited by 1) if there is any replacement, miners will be able to claim the largest ZCE of the available replacements, 2) replacements must take place within 5 seconds (this , and 3) replacements are ignored unless the ZCE grows by at least the replacements’ transaction fee (so the processing of replacements always costs a DOSer as much in additional ZCE “fees” as it would cost to create an equivalent-sized transaction).

So with all of that, if replacements ever happen, they pay the network for the trouble.

Even with those limitations, if there is still concern about DOS strategies based on replacing long transaction chains, we can simply disallow the use of ZCE reclaim transaction outputs for the 5 second lock-in period. (There’s no value beyond 5 seconds, since no honest nodes will accept replacements after that time.)

I’m not sure if it’s enough of a concern to justify adding that sort of additional logic, but 5 seconds of delay in the network accepting a transaction re-spending the ZCE output value probably won’t even be noticeable by users. (Especially since escrowed funds themselves already require a confirmation before they can be used by later ZCEs.)

I don’t have a strong preference either way; I would love to hear developers from the various node implementations weigh in.

So the question for node developers is: how expensive is mempool handling of ZCE replacements if attackers build long chains of transactions for each replacement? (Each replacement costs the attacker its minimum transaction fee, since the ZCE must be larger by at least that value.)

Do we need to prevent further transactions from building on ZCE transactions until the 5 second replacement window is over?

[bitjson]

I'm now leaning toward "yes" for this, since the cost is quite low for a solution which provides complete protection (even for particularly naive node implementations).

[bitjson]

Actually, that would still be insufficient:

Attacker sends a chain of transactions.

A → B → C → … → Z

The attacker then sends B’ which is a ZCE transaction with a low escrow amount (e.g double the tx fees for the whole chain) and also C’ which is the reclaim transaction.

The replacement means that B and C are replaced by B’ and C’. This requires removing B to Z from the memory pool.

[...]

I think there are probably some reasonable solutions though. Maybe something that takes advantage of the 5 second lock-in period? (Reminder: 5 seconds is ~2x the expected time it takes for the entire network to hear a transaction, so all commercial ZCE activity can be expected to happen within this time. ZCEs which attempt to e.g. replace a transaction from 1 minute ago would never be accepted by a merchant, and are almost certainly malicious/DOS attempts.) How crazy would it be for node implementations to keep the last 5 seconds of mempool updates in some sort of pre-commit log? After 5 seconds, the “rollback instructions” can be safely thrown away.

I’ll have to think about it more. I’d love to hear from node implementation devs on this topic!

[bitjson]

I should note: unfortunately, we can't just require that the ZCE payment be higher than the total fees of the replaced chain of transactions.

First, this introduces some timing-based non-determinism (different sections of the network might not hear enough of the chain before the ZCE replacement transaction, causing part of the network to complete the replacement and part of the network to ignore it).

Second, this would break the security for merchants. An attacker could broadcast an absurdly long chain of unconfirmed transactions, and if the merchant doesn't receive the transaction which competes with their payment before they accept the payment, the rest of the network might not accept the ZCE replacement. The merchant is back to waiting for acknowledgement of acceptance from other network nodes.

---

One other note: the BCH ecosystem has endeavored to offer a good experience for chains of small, low-risk, unconfirmed payments (e.g. gifts, tips, donations, social networking-related payments, etc.), and recently enabled support for practically unlimited chains of unconfirmed transactions. This DOS issue is a result of that BCH feature; at the previous limit of 50 unconfirmed transactions, DOS prevention would likely be unnecessary.

Regardless, an ideal solution would allow BCH to continue supporting unlimited chains of unconfirmed transactions without risking DOS attacks via ZCE replacement.