From: Murch <murch@murch•one>
To: Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
Date: Mon, 22 Jan 2024 13:12:45 -0500 [thread overview]
Message-ID: <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one> (raw)
In-Reply-To: <Zalsq+Nq7RRr/CAR@petertodd.org>
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
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.
Among those five transactions, the only transaction attractive for block
inclusion would be the small RBFr transaction with a
bottom-of-the-next-block feerate. Today, if it were mined it would
amount to fees of around 4000 sats every few blocks to make the entire
network relay transactions of more than 205,000 vB every few seconds.
Given that my example is minimal, it should be possible to further
increase bandwidth cost.
Assuming that I did not make a mistake, i.e. all the replacements are
viable and my scenario is compatible with your proposal, the described
One-Shot Replace-By-Fee-Rate proposal would not be safe for deployment
on the network.
Best,
Murch
next prev parent reply other threads:[~2024-01-22 18:19 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 [this message]
2024-01-22 22:52 ` Peter Todd
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=9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one \
--to=murch@murch$(echo .)one \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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