Auto-setting min relay fee + RBF possible attack vector in 0.12

[dive]

Reading the release notes for 0.12 RC I was wondering of a possible attack vector introduced there so would like to check the scenario here before doing further review of the code (yeap - sometimes asking saves a lot of time) and testing it out.

- PR #6722 adds an automatic update of the min relay fee when mempool is full
- New version enables RBF

Possible scenario:
1. Flood the network with a chained TXs with high fee to use most of the standard mempool size space, bump out others txs and set a high minimum fee
2. Change through RBF the first TX with a higher fee to invalidate the entire chain
3. Long time for the entire blockchain to recover and possible disruption of services that don't rebroadcast their txs

- Cost of running the attack would be VERY low if RBF invalidates the entire chain before its added to a block.
- Making a chain of very large transactions (multiples txins and txouts) would allow for quickly fill up mempool with lower risk of propagation delay of the RBF transaction.

Ways to avoid the impact:
- RBF can only be issued if it changes entire tx chain
- RBF recalculates min relay fee based on mempool size (anticipates the half life of fee decay)

Is this scenario a possible attack vector?

[achow101]

Reading the release notes for 0.12 RC I was wondering of a possible attack vector introduced there so would like to check the scenario here before doing further review of the code (yeap - sometimes asking saves a lot of time) and testing it out.

- PR #6722 adds an automatic update of the min relay fee when mempool is full
- New version enables RBF

Possible scenario:
1. Flood the network with a chained TXs with high fee to use most of the standard mempool size space, bump out others txs and set a high minimum fee
2. Change through RBF the first TX with a higher fee to invalidate the entire chain
3. Long time for the entire blockchain to recover and possible disruption of services that don't rebroadcast their txs

- Cost of running the attack would be VERY low if RBF invalidates the entire chain before its added to a block.
- Making a chain of very large transactions (multiples txins and txouts) would allow for quickly fill up mempool with lower risk of propagation delay of the RBF transaction.

Ways to avoid the impact:
- RBF can only be issued if it changes entire tx chain
- RBF recalculates min relay fee based on mempool size (anticipates the half life of fee decay)

Is this scenario a possible attack vector?

IIRC nodes only store up to 25 transactions in an unconfirmed transaction chain in their mempools. Anything more than that will not be kept in the mempool and will simply be rejected.

Also, I think since changing that transaction would invalidate the entire chain, the chain would also be discarded.

[dive]

IIRC nodes only store up to 25 transactions in an unconfirmed transaction chain in their mempools. Anything more than that will not be kept in the mempool and will simply be rejected.

You are right. 25tx or 100Kb.
So considering that maxmempool default is 300MB, and maximum chain size is 100kb, you'd need 3000 chains to clog the mempool.
To bump the minimum fee from 1000 satoshi/kb to 10000 satoshi/kb would only cost 0.3BTC

Also, I think since changing that transaction would invalidate the entire chain, the chain would also be discarded.

Yes - the chain is discarded but I don't think the minimum fee is updated when this happens.