-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOS prevention: mempool handling of ZCE replacements #12
Comments
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). |
Actually, that would still be insufficient:
[...]
|
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. |
Tier Nolan brought up a possible denial-of-service preventing rule:
Some notes:
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?
The text was updated successfully, but these errors were encountered: