Feedback-ID: i525146e8:Fastmail
Date: Thu, 23 Jun 2022 15:13:47 -0400
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Message-ID: <YrS7a0E7xLswLD92@petertodd.org>
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
 <YrEHo+3XLDNgIOnz@petertodd.org>
 <CALZpt+EL=k_6iE5B950oz3EdLaQbRvgCNYZ8Lko4fcONcACvfw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="cXOSnUuvuZ5Dhv6I"
Content-Disposition: inline
In-Reply-To: <CALZpt+EL=k_6iE5B950oz3EdLaQbRvgCNYZ8Lko4fcONcACvfw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
 security
Precedence: list


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

On Tue, Jun 21, 2022 at 07:45:48PM -0400, Antoine Riard wrote:
> > BTW I changed one of my OTS calendars to issue fee-bumping txs without =
the
> > opt-in RBF flag set as an experiment. I also made sure txs would
> propagate to
> > the above node. As of right now, it's up to 32 replacements (once per
> block),
> > without any of them mined; the calendars use the strategy of starting at
> the
> > minimum possible fee, and bumping the fee up every time a new block
> arrives
> > without the tx getting mined. So that's evidence we don't have much
> full-rbf
> > hash power at this moment.
> >
> > You can see the current status at:
> https://alice.btc.calendar.opentimestamps.org/
>=20
> That's interesting. I'm not sure if we can conclude of the absence of
> full-rbf hash power at this moment, as it could also be a lack of full-rbf
> propagation path towards such potential hash power. I think the day we see
> an opt-out replacement transaction mined, it would constitute a good hint
> of full-rbf hash power (assuming the tx-relay topology stays relatively
> stable across the transaction issuance...)

Fees are relatively low right now, so there could be 1% or so of full-rbf h=
ash
power and I wouldn't notice with this particular technique as the initial tx
gets mined within 10-20 blocks; a few years back similar experiments were
finding a few percentage points of hashing power running full-rbf.

> Anyway, if/when the `fullrbf` patch lands in Bitcoin Core, including
> automatic outbound connections to few `NODE_REPLACE_BY_FEE` peers, I'm
> thinking of reaching out to a few mining node operators to advocate them
> with the new policy setting.

I'd suggest doing that right now, without waiting for the patch to get merg=
ed,
as it improves the politics of getting the patch merged. Miners tend to run
customized bitcoind's anyway.

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

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

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

iQEzBAEBCgAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAmK0u2cACgkQJIFAPaXw
kftZVQf/eestR6ixVBzFqTWEobrwwfT8S1t3ttLhAk0kiQFstfKicgsJ3vcU8RQ6
nVRt0T3KW9rz8fxNORg9We6gkMOOERSxoItl/+C8DPTrhJRdWgmzXLFddn6Knd+g
+djMgzmRmwGW87xtB1vnHxoqC8sJoONPsjKmDjS/kvAjilB5pijWqltWr825/I8r
bG1EyDcBBi0dz4nM16dOgbBHwVOwQCWm8ft73yBoyKAOmnzai5oh1y8cVLSHQAcv
wt58C378VMROLPufzriJgXIeO8e8lS4m1tI7PEL0o5BI6UmbmScgF4/3ZEhKKjXB
OLSKS8XcrcToLcCBXLrJGBuHekNGEw==
=0UtU
-----END PGP SIGNATURE-----

--cXOSnUuvuZ5Dhv6I--