[ZIP 401] Addressing mempool denial-of-service

[daira]

Signed-off-by: Daira Hopwood daira@jacaranda.org

Done Criteria:

• ZIP and implementation are checked for consistency.

[gtank]

Consider expanding this explanation.

[lindanlee]

I've reviewed this proposal, with the purpose of whether there's anything that the draft could do differently to give users more confidence they know what's happening in the case of network conditions where mempools are full.

I think that this proposal is good!

I don't think that users need to know precisely why the mempool is full (I.e. if there is legitimate transaction volume, or if there is a denial of service attack). My rationale for this is that either of these cases would necessitate that the user take the same course of action--whether that would be sending the transaction again, or to send it with a higher fee. If they would benefit from a different strategy (i.e. if they should not try sending it again if there is a DoS but should try again if it's just full), then the difference should be made to the user.

If my understanding is correct, since the dropped transactions are weighted towards ones with lower fees but randomly selected, a person can try sending the same transaction with no change in fee and have a reasonable chance of not having the transaction dropped again.

I really like the fact that this randomness allows the user to send their transaction by trying the transaction again with the same fee, instead of one that deterministically drops the lowest, which will result in a user trying the transaction again and again with no chance of succeeding. My assumption here is that many users will be using a light wallet that sets the fee for them, or that they do not know how to change the fee.

This proposal also allows for simple automated recovery--i.e. a wallet could try sending a dropped transaction again after a period of time. It's also true that you can automatically retry transactions with a fee increase, but that'd be a bit more difficult to get correctly and require some knowledge of the average fee in the mempool, would require consent from/notice to the user to spend more of their money, and would be hard to get it implemented consistently (which ultimately results in different experiences in different platforms, which is confusing).

[geffenz]

It should be noted when transactions get dropped that will put an additional burden on nodes/wallets/exchanges to validate and respond, but the COST logic-structure will help enforce the standard fee.

My main UX concerns are around communication. An automated system like Linda mentioned would be a great next step, but communicating both network status and transaction droppage to a user is also a necessary requirement moving forward.

Since those concerns are outside this ZIP's goal, I approve!

Please re-review after changes. Note that I'm on vacation and won't be updating this zip, so please also reassign as necessary.

Please re-review after changes.

[Eirik0]

ACK

[Eirik0]

Force pushed because make was not working correctly for me. It would delete index.html rather than rewrite it. I am running ubuntu under WSL, so this issue may be specific to that platform.

[daira]

ACK