Peter has a proposal for how to fix pinning, the bugbear of any tx based L2 protocol — allow feerate replacement
pull down to refresh
pull down to refresh
Peter has a proposal for how to fix pinning, the bugbear of any tx based L2 protocol — allow feerate replacement
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.
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
C1andC2. Let’s say 20 s/vB is the bottom of the first block.tx_LLwith 100,000 vB at 1 s/vB (fee: 100,000 s). It spends the confirmed outputC1and has an outputtx_LL:0.tx_LSas a child with 100 vB at 1 s/vB (fee: 100 s) by spendingtx_LL:0.https://m.stacker.news/13360
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.https://m.stacker.news/13361
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.https://m.stacker.news/13363
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.https://m.stacker.news/13366
tx_LLandtx_LSbecauseC1is no longer being spent.https://m.stacker.news/13367
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.https://m.stacker.news/13374
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_RBFrwhich costs you 2000 s. If it it does get included in a block, just start over with a new confirmed UTXO as yourc2'.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.
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