Feedback-ID: i525146e8:Fastmail
Date: Sat, 10 Dec 2022 13:07:18 -0500
From: Peter Todd <pete@petertodd.org>
To: 0xB10C <b10c@b10c.me>
Message-ID: <Y5TK1kaWtBnz6NqX@petertodd.org>
References: <Y2I3w8O5X55sD/3C@petertodd.org> <Y2qc7Ubc5xtJhxGw@petertodd.org>
 <Y3MlSE7AWkBgiCyr@erisian.com.au>
 <f146ca66-a611-f129-ae11-6907a7333d10@b10c.me>
 <Y5OlpAi3wHPKxxkx@petertodd.org>
 <ff27975a-78b0-f697-8e88-0d0e5e5dddb6@b10c.me>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="F+8hPIjXyNesmUwe"
Content-Disposition: inline
In-Reply-To: <ff27975a-78b0-f697-8e88-0d0e5e5dddb6@b10c.me>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Precedence: list


--F+8hPIjXyNesmUwe
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 10, 2022 at 12:59:05PM +0100, 0xB10C wrote:
> On 12/9/22 22:16, Peter Todd wrote:
> >> For further monitoring, I've set-up a mempoolfullrbf=3D1 node and are
> >> logging replacement events with [0]. I filter the full-RBF replacements
> >> and list the replaced and replacement transactions here:
> > Question: are you taking any special steps to peer that node with other
> > full-rbf nodes? I see you are in fact getting all the replacements I'd =
expect
> > you to get, so you must have good peering. I'm curious what it took (if
> > anything) to achieve that. Also, is that node accepting incoming connec=
tions?
> No special steps like #25600 preferential peering or similar. I suspect
> I was lucky to have a full-RBF peer (or more than one) from the start or
> there are more mempoolfullrbf=3D1 nodes than I'd think on the network. The
> node accepts incoming connections on a non-default port and currently
> has 45 inbound slots filled up. Mostly buy v23.0 and v24.0 nodes though,
> as older Bitcoin Core version usually don't connect to non-default port
> peers.

Interesting! I'm running a full-rbf node that is (manually) connected to a =
few
hundred v24.0 nodes to ensure good propagation. But I'm only connected to
standard ports (I'm reusing the DNS seed list). So you must have a full-rbf
peer purely by luck.

Could you please grep your logs for which peer(s) are sending you replaceme=
nts?
I don't want to know the IP addresses. I'm just curious if you have exactly=
 one
full-rbf peer or more.

BTW I have Antoine's preferential peering patch ported to v24.0, along with=
 a
few other minor fixes:

https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0

I think it'd be reasonable for you to run that, as what's more interesting =
is
the replacements, not whether or not propagation happens to work out of the
box.

> > https://blockstream.info also enabled full-rbf a few days ago. But curr=
ently
> > propagation to their nodes is spotty, so replacements don't always show=
 up.
>=20
> Since my last post, five full-RBF replacements have been mined in two
> blocks:
>=20
> 766733 by Luxor:
>=20
> =A0=A0=A0 41d497d64bfa71390408ddb65c478a5400c721c71336fa51509929f19a5c8aa=
5 1x
> P2WPKH in -> 1x P2WPKH out (12.50 sat/vByte)
> =A0=A0=A0 3061eec0b57346c01419db091ce3af16094e796db91f4f3eb9b7ad42ce8f6e25
> OpenTimestamps Alice ~170 USD bounty (6424.72 sat/vByte)
> =A0=A0=A0 9000f73e818af9019d26b2edde6e8e11f67d6d6f35916dabd808bbdd314ce80=
7 1x
> P2WPKH in -> 1x P2WPKH out=A0 (22.73 sat/vByte)
> =A0=A0=A0 3843e93a0ec5cf09d757fd497fdda8f15f5094c64b149624c5d343b24e675093
> OpenTimestamps Bob (108.25 sat/vByte)
>=20
> It seems like Luxor (5.5 EH/s or 2.11% network hashrate in the last 7
> days)[0] might have mempoolfullrbf=3D1 enabled.
>=20
> 766736 by AntPool:
>=20
> =A0=A0 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1
> OpenTimestamps Bob (4.25 sat/vByte)
>=20
> I'm not too sure if AntPool has full RBF enabled based on this one
> transaction. 3c96fe.. is the first replacement of
> 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (1.19
> sat/vByte) which they might not have seen (?). They have nearly 20% of
> the network hashrate [0], so if the have mempoolfullrbf=3D1 set, we should
> see them include more full-RBF replacements soonish. There was also
> 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f which
> bumped 3c96fe.. by 1.53 sat/vByte, but was only broadcast shortly before
> AntPool found the block. The might not have seen it yet.

So according to my logs the replacement that AntPool mined, 3c96fe813, was =
the
third replacement in a row of four replacements:

2022-12-10T07:46:09Z [mempool] AcceptToMemoryPool: peer=3D<snip>: accepted =
903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (poolsz 63=
20 txn, 90818 kB)
2022-12-10T07:47:14Z [mempool] replacing tx 903f03b16e69f9f3fc6bb8d008338da=
37efc3f235fc5091ca767baae96834d95 with f8bef985457f9e5bbf5b583e33cca43d515a=
3a73e1bb6a2c5a11646632123aa2 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:01:09Z [mempool] replacing tx f8bef985457f9e5bbf5b583e33cca43=
d515a3a73e1bb6a2c5a11646632123aa2 with 3c96fe8136de98a91d0add7e51fcacef8130=
71d43feccc51987dc8378f6913e1 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:06:06Z [mempool] replacing tx 3c96fe8136de98a91d0add7e51fcace=
f813071d43feccc51987dc8378f6913e1 with 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e=
164f0dd87525c72e921d7a27ab1f for 0.00000234 additional fees, 0 delta bytes

There's significant time between tx #2 and tx #3, and the block was found s=
oon
after #4 reached my node, so it's quite possible that AntPool was in fact
running full-rbf and they simply didn't see #4 in time.

Big pools tend to run many different nodes at once, splitting up hash rate
between them, so they could be simply running full-rbf on a subset of their
hashing power to test it out. I noticed F2Pool mined a few full-rbf
replacements a few weeks ago too (they also mined a replacement that appear=
ed
to be due to them starting a new node, with an empty mempool).

Similarly, note how Luxor has mined a few blocks since #766733, without min=
ing
full-rbf replacements.


I'll also note that Foundry USA mined a doublespend,
fab4df6b9b51dcfe94b366f17bccca50430f4ceb274a87f948a5493cd31a8551, which your
site shows. In that case according to my logs the two transactions were sent
essentially simultaneously, so likely just an accident of propagation. But =
it's
good to remind people that such double-spends are easy. :)

> I've also updated the site to allow only showing the replacements that
> were mined.

Thanks! That's very useful.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--F+8hPIjXyNesmUwe
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmOUytMACgkQLly11TVR
Lzf4+BAAkffwivq85q2F0pCBXy8876V0VPfH9RjBXcwybT/6JqSc3FfY8NXe89Id
B2w36JOPhg6RAmGyKEZNV3fJxDG2zBkDFVBtyYtuWy20EbJHIWbDF54ndhyhMDDk
PZ7544WxmtbJUWvye9IpH1/eZvAqFTCYewl30ifbICLR4keGRuu1x+UPooe5F1hc
taND/yv3tCcifwAt/wPLXnfbO+wTpUJiIfA2tT+VBQzZD0KSwSwQMFDANzDoP/8V
Pd0LNcQ8xrt71ISd7b8yZlHQ2kRD17jS0Mxn+1nzyMRzRFSKj8iFpbqZIyQpNGBo
B0ZLyVXk/50jb0NIgXOOAMarYCnifboKBexeYl8nbj1uOWgRepgg2ufr+HZrCkPS
lWluimoVZTGL74VrTU1nXwNGGkY+B9K07X/Et9NRKAKyoO3w3sWyUCzFrVKRhIpn
xfEFW79PlSJqTQcUmPVbvc5cHNaO4oUmfDtJVML3mIBPMVXECvxjPD1dh1T2y+Wd
/b/6OV+sOVvXXPraMhJ62wJP45NMeC/1+5iphnIyBc22YzxDHWQnMQpcsV/T22Cr
z6aUWlazCsXynpA3zH1M7B4ZXE3KtiIqu4oueBx9RF3P8Jv8MUCmdDWkHh8yu9/T
lPQxknV5K9GfO0npsn4RSwgh0BEATB5QxRb7gwgmH6pcyIRL5iY=
=e+/p
-----END PGP SIGNATURE-----

--F+8hPIjXyNesmUwe--