public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  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