Feedback-ID: i525146e8:Fastmail
Date: Tue, 15 Nov 2022 09:43:25 -0500
From: Peter Todd <pete@petertodd.org>
To: Anthony Towns <aj@erisian.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y3OljVGQbZ/Wj8T6@petertodd.org>
References: <Y2I3w8O5X55sD/3C@petertodd.org> <Y2qc7Ubc5xtJhxGw@petertodd.org>
 <Y3MlSE7AWkBgiCyr@erisian.com.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="YK6gRvqxzxwfznAz"
Content-Disposition: inline
In-Reply-To: <Y3MlSE7AWkBgiCyr@erisian.com.au>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Precedence: list


--YK6gRvqxzxwfznAz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev wro=
te:
> On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrot=
e:
> > FYI I've gotten a few hundred dollars worth of donations to this effort=
, and
> > have raised the reward to about 0.02 BTC, or $400 USD at current prices.
>=20
> Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):

I'm turning it back on when (if) the mempool settles down. I've got more th=
an
enough donations to give another run at it (the majority was donated privat=
ely
FWIW). There's a risk of the mempool filling up again of course; hard to av=
oid
that.

Right now of course it's really easy to double spend with the obvious
low-fee/high-fee method as the min relay fee keeps shifting.

> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc=
2be29d934d69138c
>=20
> The block it was claimed in seems to have been about an hour after the
> default mempool filled up:
>=20
> https://twitter.com/murchandamus/status/1592274621977477120
>=20
> That block actually seems to have included two
> alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
> (309sat/vb):
>=20
> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe=
7aa020ccfead07cf

The second is because I turned down the full-rbf reward to more normal fee
levels. There's also another full-rbf double-spend from the Bob calendar, a=
long
the same lines: 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008=
d2cd2

I double-spent the txin of the high fee tx that got mined. But I mistakenly=
 had
RBF enabled in that double-spend, so while it propagated initially, I belie=
ve
it was replaced when something (someone?) rebroadcast the high-fee 397dcb t=
x.

> Timeline (utc) to me looks like:
>=20
>  - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb
>  - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6=
e1
>            is announced and propogates widely (1.2sat/vb)
>  - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e09=
44
>            is announced and propogates widely (1.2sat/vb)
>  - 21:52 - ba967010 tx is announced and propogates widely, since
>            conflicting tx 746daab9 has been removed from default
> 	   mempools
>  - 21:53 - murch tweets about default mempool filling up
>  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>            conflicting tx f503868 has already been removed from default
> 	   mempools

Is that 22:03 time for 397 from your node's logs? It was originally announc=
ed
hours earlier. From one of my full-rbf nodes:

    2022-11-14T14:08:37Z [mempool] replacing tx 764867062b67fea61810c3858d5=
87da83a28290545e882935a32285028084317 with 397dcbe4e95ec40616e3dfc4ff8ffa15=
8d2e72020b7d11fc2be29d934d69138c for 0.00468 additional fees, -1 delta bytes

>  - 22:35 - block 763189 is mined
>  - 22:39 - block 763190 is mined
>  - 23:11 - block 763191 is mined
>  - 23:17 - block 763192 is mined including 397dcbe4
>=20
> miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
> first three blocks, and gives similar mempool ages for those txs to what
> my logs report:
>=20
>   https://miningpool.observer/template-and-block/0000000000000000000436ab=
a59d8430061e0e50592215f7f263bfb1073ccac7
>   https://miningpool.observer/template-and-block/000000000000000000056004=
04792bacfd8a164d2fe9843766afb2bfbd937309
>   https://miningpool.observer/template-and-block/00000000000000000004a307=
3f58c9eae40f251ea7aeaeac870daeac4b238fd1
>=20
> That presumably means those pools (AntPool twice and "unknown") are
> running with large mempools that didn't kept the earlier 1.2sat/vb txs.

To be clear, you think that AntPool and that other exchange is running with=
 a
larger than normal max mempool size limit? You mean those miners *did* keep=
 the
earlier 1.2sat/vb tx?

> The txs were mined by Foundry:
>=20
>   https://miningpool.observer/template-and-block/00000000000000000001382a=
226aedac822de80309cca2bf1253b35d4f8144f5
>=20
> This seems to be pretty good evidence that we currently don't have any
> significant hashrate mining with fullrbf policies (<0.5% if there was a
> high fee replacement available prior to every block having been mined),
> despite the bounty having been collected.

Oh, we can put much lower bounds on that. I've been running OTS calendars w=
ith
full-rbf replacements for a few months without clear evidence of a full-rbf
replacement.  While there was good reason to think some miners were mining
full-rbf before a few years back, they probably didn't bother to reapply th=
eir
patches each upgrade. `mempoolfullrbf=3D1` is much simpler to use.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNzpYoACgkQLly11TVR
Lzc0mQ//TdJZPvfORlRQ9inKeLlMrwDrXTiXXDCiYZjU931NYLLUbVDHWfRpCPez
ilNcEty7a0m34mQBYAcm/2cTF9YwpDd+h3ryYF/SlhptyqSsE1RZyyuptmt7FB6e
g8Sse1y1YWgVaQEkQ9aXMk5uelan5oTYpEFnRlQqKhVx0zDVlgm1d7xhbATfKtU0
BdPRk01a1J7nf1DPbNuvtPHPEodBwd7I+kirit1Z96oGnvCT3RLBcjniwCu7YRIN
Oh95ApHAoWamr2flhGuj1UuZ50+SxrjG9+6dPRUEnHkWKGHKSaMGog354gfPJ1Hz
srggX/1N+SOWrHemuVyREs4NY6h8sqjt7tuPdygCqgIW0cNrGb4Hl7Ju/AcXeOpB
ILFLET1CMcqsES4Rw3YxfSx0xZG0DMzXXShPbNbyETL7qSFRhZVPIEbAynpgh5Sx
12TOwNIUSQg1Wq+hbibKxKpgu7Vqg4Gj9bPOePwvij4XJRyexzrXeWGi7OJt3z2m
QdgeJPa8UKw9IqbEyMNfl4riihN2Fb3XrYZGkhxK2ve2HDbVx/dQIsa79OvdKSuv
SjThm1baaZ0AXdHP5zhoQDKnteG3yAE8y5WMc6/sosr/tM0tO5ueWukByEy+uSBP
Q8Iq2RcL+E2rgQ81ALRjm7zh7iOttzXMi4VJW1cmmIyDTsvYbpU=
=5pjI
-----END PGP SIGNATURE-----

--YK6gRvqxzxwfznAz--