From: Peter Todd <pete@petertodd•org>
To: Murch <murch@murch•one>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
Date: Mon, 22 Jan 2024 22:52:01 +0000 [thread overview]
Message-ID: <Za7xkUsoeACMv6Fw@petertodd.org> (raw)
In-Reply-To: <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-22 22:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 18:23 Peter Todd
2024-01-22 18:12 ` Murch
2024-01-22 22:52 ` Peter Todd [this message]
2024-01-24 4:44 ` Peter Todd
2024-01-25 21:25 ` Murch
2024-01-27 7:19 ` Peter Todd
2024-01-28 17:27 ` Murch
2024-01-31 8:40 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Za7xkUsoeACMv6Fw@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=murch@murch$(echo .)one \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox