Message-ID: <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
Date: Mon, 22 Jan 2024 13:12:45 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <Zalsq+Nq7RRr/CAR@petertodd.org>
From: Murch <murch@murch.one>
In-Reply-To: <Zalsq+Nq7RRr/CAR@petertodd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
Precedence: list

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