Feedback-ID: i525146e8:Fastmail
Date: Thu, 2 Nov 2023 15:42:29 +0000
From: Peter Todd <pete@petertodd.org>
To: John Carvalho <john@synonym.to>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZUPDZTSbTBxDnlRa@petertodd.org>
References: <mailman.10748.1698911611.1202.lightning-dev@lists.linuxfoundation.org>
 <CAHTn92z9RhrHd=quYwfbj9y9gvA4aGX=JGNv9UggR4cWSZE9Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="+uncIoM9bJUI0yxk"
Content-Disposition: inline
In-Reply-To: <CAHTn92z9RhrHd=quYwfbj9y9gvA4aGX=JGNv9UggR4cWSZE9Xw@mail.gmail.com>
Subject: Re: [bitcoin-dev] The Pinning & Replacement Problem Set
Precedence: list


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

On Thu, Nov 02, 2023 at 08:58:36AM +0000, John Carvalho via bitcoin-dev wro=
te:
> Good morning,
>=20
> All layers and technologies "on" Bitcoin will fail in situations where
> miners misbehave or the blocks & mempool remain consistently, overly full.
> Consider this as a "law" of Bitcoin/blockchains.
>=20
> In hindsight (for you, not me) it was very unwise to start messing with
> mempool policies, like with RBF, mempoolfullrbf. First-seen policy brought
> a fragile harmony and utility to Bitcoin, which we were lucky to have for
> as long as we could.

Replacement cycling has nothing to do with full-rbf. You are being disingen=
uous
by bringing up your pet topic in relation to this exploit.

In fact, in the anchor channels case, it isn't even possible for the releva=
nt
transactions to turn BIP-125 RBF off, as the 1 block CSV delay forces RBF t=
o be
enabled.

Note that at the moment, the largest pool - AntPool - has full-RBF enabled.
Thus we have at least 40.1% of hash power mining with full-RBF:

AntPool: 28%
Binance Pool: 7.8%
Luxor: 2.5%
BTC.com: 1.8%


Obviously, the sane thing to do is design protocols that are made secure by
clear incentives, rather than vague hopes. Thats why I proposed OP_Expire, a
solution that does not rely on any particular mempool behavior. Indeed, it'=
s a
solution that unlike the current mitigations relying on mempools, has good
resistance to mempool sybil attacks.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmVDw2IACgkQLly11TVR
Lze7Lw//b/+Q746p3Me05N5vDiDo7338mZl7V+BplEGx3Js1/SrmKCZ5r3cYtUvk
7W7NeaEWABKFNu+p+ZH6/hXCPgaxfxiXCKckIFLsABPZRb2MXsmoAk2qTWzrF+85
KspRI39t2Kfk7leUQV+lTgtY8Y/nVl5BZyEItsilK8E5lYs1FQhjCXEawZETlVpb
mEW497xu/0jWoYtjEkOJ6JxF37pBUPnSqMCGogRbS5rKFF18IL2DqKf1fkJnHUdx
+ZWmYdKtPf+EuA3Db/vlSI9NekEcTXjoyjgCkpQOXjjPM5lUMe7qPMWey+t/IYBl
EEtNv70HELRRUVIWU5gMVRwbrDYfDUNxRi3CAdR7yBnX4GTOF7sdRbWUdO3HYc3R
PkXpH65HcP+D1G3+twIBFw4Q1+lCFstPfw8jPt6IimKMjXD503MKQ0eELYJemuKD
tUSx+6TsWXSP51NcpcrjYqEzzr2qhEPNShTCWwFDjLBKnIdHsaPGBnBFh4FQJpD6
Iwj5IdeT2qG6wt/Ey6Tj7Fi2Fx+XYD0Yawp81sx+u+1ZUD4ERX9sn1lRZpf0uWF3
D5skkrxSn9fYFZtDflfLLR2Hq2RXC1hLcavx50lTh7xpCLsRqC5eWpPLAa8BGjNZ
XlC6Zw8nJ37OVxM7aR6sZa/At/T0y1uPjOJZJM5rE5GNxyZjcM0=
=c4hE
-----END PGP SIGNATURE-----

--+uncIoM9bJUI0yxk--