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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
