On Mon, Jan 22, 2024 at 01:12:45PM -0500, Murch via bitcoin-dev wrote: > Hi Peter, > > On 1/18/24 13:23, Peter Todd via bitcoin-dev wrote: > > Reposting this blog post here for discussion: > > > > https://petertodd.org/2024/one-shot-replace-by-fee-rate > > I saw your proposal mentioned on Stacker News and read it with interest. In > response, I described a replacement cycle that can be used to broadcast the > same five transactions repeatedly: > > https://stacker.news/items/393182
So if this does in fact work - I haven't actually tested it - the root problem here is not replace-by-fee-rate, but rather our current replace-by-fee rules: in step 7 you've clearly replaced a more desirable, high fee-rate, transaction that will be mined soon with a low fee-rate transaction that will not be. That's obviously not incentive compatible for miners, for the same reason that replace-by-fee-rate generally is incentive compatible. I had incorrectly thought we had gotten rid of those cases... But looks like the definition of BIP-125 Rule #2, "The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions.", is not sufficient because you can combine unconfirmed inputs from two different replaced transactions, making a resulting transaction that is less valuable to miners than one of the replaced transactions. IIUC Suhas has a draft fix here that would solve this issue: https://github.com/bitcoin/bitcoin/pull/26451 An even simpler fix would be to just require that all unconfirmed inputs in a replacement come from the *same* replaced transaction. That would make certain rare, but economically viable, replacements infeasible. But it would definitely fix the issue. > The gist is that by using two confirmed inputs and five transactions, you > can use RBFr to reduce the absolute fee while raising the feerate to top > block levels, then immediately use the current RBF rules to introduce a > high-feerate transaction that beats the RBFr transaction but is hampered by > a low-feerate parent and not attractive for mining, then use RBF to replace > its low-feerate parent, then use the RBFr transaction again to reduce the > absolute feerate. Due to the asymmetric replacements, the same transactions > can replace each other in that order in every cycle. Please refer to the > linked write-up for details, I’ve included weights, fees, and a transaction > graph to make my example comprehensible. BTW do you mind if I reproduce those graphics, with credit, to explain the issue? I have a few places where I could make use of it, eg the replace-by-fee-rate post itself. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
