Feedback-ID: i525146e8:Fastmail
Date: Sat, 27 Jan 2024 07:19:22 +0000
From: Peter Todd <pete@petertodd.org>
To: Murch <murch@murch.one>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZbSueoReTvEmm1s9@petertodd.org>
References: <Zalsq+Nq7RRr/CAR@petertodd.org>
 <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="+FlKIbswhidnlpem"
Content-Disposition: inline
In-Reply-To: <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
Precedence: list


--+FlKIbswhidnlpem
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 22, 2024 at 01:12:45PM -0500, Murch via bitcoin-dev wrote:
> Hi Peter,
>=20
> 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
>=20
> 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 t=
he
> same five transactions repeatedly:
>=20
> https://stacker.news/items/393182
>=20
> 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 repla=
ce
> its low-feerate parent, then use the RBFr transaction again to reduce the
> absolute feerate. Due to the asymmetric replacements, the same transactio=
ns
> can replace each other in that order in every cycle. Please refer to the
> linked write-up for details, I=E2=80=99ve included weights, fees, and a t=
ransaction
> graph to make my example comprehensible.
>=20
> 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=E2=80=AFvB every few seconds. Given tha=
t my
> example is minimal, it should be possible to further increase bandwidth
> cost.
>=20
> Assuming that I did not make a mistake, i.e. all the replacements are via=
ble
> 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.

I actually tried this attack out, and it fails at step #4 due to the Rule #=
6,
PaysMoreThanConflicts, check.

While on stacker.news you stated that:

    tx_HS has 5000 vB and pays 21 s/vB, but since it spends an output from a
    low-feerate parent, it=E2=80=99s mining score is only 1.95=E2=80=AFs/vB.

and

    You RBF tx_LL and tx_HS with tx_LM that has 100,000 vB and pays 3.05=E2=
=80=AFs/vB (fee:
    305,000 s) by spending the outputs C1 and C2. This is permitted, since =
only
    tx_LL is a direct conflict, so the feerate of tx_HS does not have to be=
 beat
    directly.

tx_HS _is_ considered to be a direct conflict, and its raw fee-rate _does_ =
have
to be beat directly. While ts_HS does spend an unconfirmed output, it appea=
rs
that the fee-rate PaysMoreThanConflicts uses to calculate if ts_HS can be
beaten is ts_HS's raw fee-rate. So looks like your understanding was incorr=
ect
on these two points.

FYI here is the actual test script I used to test this attack. You can run =
it
using Bitcoin v26.0 with the -acceptnonstdtxn -mempoolfullrbf=3D1 command l=
ine
arguments, with python-bitcoinlib v0.12.2 installed.

#!/usr/bin/env python3

import bitcoin
bitcoin.SelectParams('regtest')

import bitcoin.rpc
import sys

=66rom bitcoin.core import *
=66rom bitcoin.core.script import *
=66rom bitcoin.wallet import *

proxy =3D bitcoin.rpc.Proxy()

my_addr =3D proxy.getnewaddress().to_scriptPubKey()

coins =3D proxy.listunspent(1)

print(coins[0:2])

txo1 =3D coins[0]['outpoint']
txo1_amount =3D coins[0]['amount']
txo2 =3D coins[1]['outpoint']
txo2_amount =3D coins[1]['amount']

print(txo1)
print(txo2)

for i in range(0, 1):
    # Step 2
    tx_ll =3D CTransaction(
        [CTxIn(txo1)],
        [CTxOut(txo1_amount - 100000, my_addr),
         CTxOut(0, CScript([OP_RETURN, b'x' * 90000]))])

    r =3D proxy.signrawtransactionwithwallet(tx_ll)
    assert(r['complete'])
    tx_ll_signed =3D r['tx']

    print('tx_ll =3D %s' % b2lx(proxy.sendrawtransaction(tx_ll_signed)))

    tx_ls =3D CTransaction(
        [CTxIn(COutPoint(tx_ll.GetTxid(), 0))],
        [CTxOut(txo1_amount - 100000 - 300, my_addr)])
    r =3D proxy.signrawtransactionwithwallet(tx_ls)
    assert(r['complete'])
    tx_ls_signed =3D r['tx']

    print('tx_ls =3D %s' % b2lx(proxy.sendrawtransaction(tx_ls_signed)))

    # Step 3
    tx_hs =3D CTransaction(
        [CTxIn(COutPoint(tx_ll.GetTxid(), 0)),
         CTxIn(txo2)],
        [CTxOut((txo1_amount - 100000) + txo2_amount - 4000, my_addr)])

    r =3D proxy.signrawtransactionwithwallet(tx_hs)
    assert(r['complete'])
    tx_hs_signed =3D r['tx']

    print('tx_hs =3D %s ' % b2lx(proxy.sendrawtransaction(tx_hs_signed)))


    # Step 4
    tx_lm =3D CTransaction(
        [CTxIn(txo1),
         CTxIn(txo2)],
        [CTxOut(txo1_amount + txo2_amount - 300000, my_addr),
         CTxOut(0, CScript([OP_RETURN, b'x' * 90000]))])

    r =3D proxy.signrawtransactionwithwallet(tx_lm)
    assert(r['complete'])
    tx_lm_signed =3D r['tx']

    print('tx_lm =3D %s' % b2lx(proxy.sendrawtransaction(tx_lm_signed)))

--+FlKIbswhidnlpem
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmW0rnkACgkQLly11TVR
LzdVzg/+KPUkIvZNF9cqBmRx32tfxehFlqaLZoBqAS2YGEhKbX1QoCFwM8R7F2VM
pP/16pJeZszRDrbo8dk3/X5r4qpDQfpv2Q748+DbxtYMTBngkXJgdaYX1Vi2RtzA
7lGrN930Grw7IqHGGD1yp5S7rqk/tggP6Kux/mvsS0/Ntg7SQeVTqbfSFLEfLBVj
lr65B3IUb3m8PsBm4xdLVjZIVYnJqTCBmBDgm6tnw9hiEOCbkZhn7hIBrLJ0NJLR
xpUUW7XFx/+wvtntZphVBeKo89z7RohP5acRsFY5hFw+hCt7AlCNVH5Rd9n3yvj8
uRR9y8znMC/sw/1DR7fWV1mC0y338IaN4fuABnocLyMtk2mcVAmATB5xhiIFO9f4
LxYjqi10ybcgcE/6zGH/IcMEE0chUKH/2ySM+hu2RnkCuWx+1pnUeqoE+7Ij4H8u
LvVixbqabTRlAKAunoRzLjdUZ4XHRguoplwxLLZIGUicaMjQBVFMd4x0mPhuryJQ
11GOhQ3Nu7xtuEZDjlrTZYLZ8JinlSeP0pIO2LZgqsX6FO0LQduuajGxTeHdm/IQ
eQMrr7lsTKKBbjSgODGUS9uhP5dCAIM1nawW3ScOnBXiNYp97S5wWdcNiUrxmM4i
QLYPtKMG5kF86lky5ayuzfL1Wwbbcfzy2rJ4WognZf/fF4SLld4=
=ygyc
-----END PGP SIGNATURE-----

--+FlKIbswhidnlpem--