pull down to refresh
what’s the “free relay” attack vector you’ve spotted?
I wasted way too much time on this, but my second attempt works—I just needed a fifth transaction.
Arrow points from child to parent. Dotted line with ball and socket, the socket is on the side of the replacement.
You have two confirmed UTXOs C1 and C2. Let’s say 20 s/vB is the bottom of the first block.
- You create a large low-feerate transaction
tx_LLwith 100,000 vB at 1 s/vB (fee: 100,000 s). It spends the confirmed outputC1and has an outputtx_LL:0. - You attach a small low-feerate transaction
tx_LSas a child with 100 vB at 1 s/vB (fee: 100 s) by spendingtx_LL:0.
- You RBF
tx_LSwith a high-feerate transaction that spendsC2andtx_LL:0in a new transactiontx_HS.tx_HShas 5000 vB and pays 21 s/vB, but since it spends an output from a low-feerate parent, it’s mining score is only 1.95 s/vB.
- You RBF
tx_LLandtx_HSwithtx_LMthat has 100,000 vB and pays 3.05 s/vB (fee: 305,000 s) by spending the outputsC1andC2. This is permitted, since onlytx_LLis a direct conflict, so the feerate oftx_HSdoes not have to be beat directly.
- You use the new RBFr rules to replace
tx_LMwith a small high feerate transactiontx_RBFrwith 100 vB paying 20 s/vB (fee: 2000 s) that spendsC2and makes it into the top block of the mempool.tx_LMwas not going to be in the next block, andtx_RBFrpays more than 1.25× the feerate oftx_LM. So this is permitted under the new rules.
- You then rebroadcast
tx_LLandtx_LSbecauseC1is no longer being spent.
- You immediately replace both
tx_LSandtx_RBFrwithtx_HS.tx_HShas a feerate of 21 s/vB which is higher thantx_RBFr(20 s/vB) andtx_LS(1 s/vB), and pays more absolute fees than both (105,000 s vs 2000 s + 100 s). But since it’s a child oftx_LLit only has a mining score of 1.95 s/vB.
Repeat 4.–7. to make every node on the network cycle the same five transactions ad nauseam. Roll the locktimes or sequences to make the transaction have a new TXIDs in each iteration, while spending the same UTXOs. The only transaction that is ever in any danger of getting mined is tx_RBFr which costs you 2000 s. If it it does get included in a block, just start over with a new confirmed UTXO as your c2'.
deleted by author
I wrote an example with four transactions, but it doesn’t quite work. I’m fairly sure that you can construct a cycle where you can just publish the same transactions over and over again and in circle they each replace each other.
The two attack vectors provided in comparison are both less potent in some ways
What do you mean by "less potent" here? And what specific attack vectors are you referring to?
Affecting only listening nodes is less effective than affecting all nodes and broadcasting 205 kvB every few seconds at the cost of paying for 200 vB every few blocks is worse than broadcasting 404 kvB at a definitive price of paying for 50 vB.
Ok, so your comment was based on the assumption that the cycling problem isn't fixed.
If it is fixed, do you have further objections?
You're departing from how we've been treating unconfirmed transactions so far. While discounting the tail of the mempool for top transactions intuitively makes plausible, instead of treating every transaction at its face value, that generally introduces new potential attack vectors. I'd like to see a more substantial exploration of that before I'd be convinced that's not a problem
Mh, this doesn’t seem like a good idea to me. The two attack vectors provided in comparison are both less potent in some ways, and this proposal appears to introduce a free infinite relay attack vector.