Feedback-ID: i525146e8:Fastmail
Date: Thu, 4 Aug 2022 14:06:34 -0400
From: Peter Todd <pete@petertodd.org>
To: Michael Folkson <michaelfolkson@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YuwKqnfj0MyXhbE6@petertodd.org>
References: <zl3fWujFF4mSjfXz_d1gA73ALTnN_LaaGKyidRR6azX9toY2-j7cUkfVcU1ggIhJ0cjK9oA4q1jF5mDob6bdlDp4yaWHZKxxev-zjUQBqTk=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="IJwBPXtQQ3L997rR"
Content-Disposition: inline
In-Reply-To: <zl3fWujFF4mSjfXz_d1gA73ALTnN_LaaGKyidRR6azX9toY2-j7cUkfVcU1ggIhJ0cjK9oA4q1jF5mDob6bdlDp4yaWHZKxxev-zjUQBqTk=@protonmail.com>
Subject: Re: [bitcoin-dev] RBF rules,
 setting policy defaults in Bitcoin Core and the role of BIPs
Precedence: list


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

On Thu, Aug 04, 2022 at 02:54:54PM +0000, Michael Folkson via bitcoin-dev w=
rote:
> A short history of RBF and BIP125
>=20
> The history of BIP125 is as far as I=E2=80=99m aware this. RBF rules were=
 merged into Bitcoin Core in November 2015 [0]. Following that merge David =
Harding and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules t=
hat had been implemented in Bitcoin Core. The rationales for the rules in t=
he BIP was a bit lacking (in my opinion) but recall this is 2015 (7 years a=
go!) when L2 protocols were in their infancy. Certainly the research on the=
 security of L2 protocols has come a long way since and we have a much bett=
er idea of some of the possible attacks on L2 protocols that to some extent=
 are impacted by policy rules.
>=20
> In addition it was discovered [2] in May 2021 that the Bitcoin Core imple=
mentation of the RBF rules had never matched the RBF rules outlined in BIP1=
25. Clearly this isn=E2=80=99t ideal but mistakes happen and will continue =
to happen. I certainly do not intend any criticism whatsoever to any of the=
 individuals involved. Thankfully this discrepancy doesn=E2=80=99t seem to =
have resulted in any loss of funds or disruption. However, cross checking a=
 specification with an implementation presumably led to the discovery and a=
llowed for a post mortem on why the implementation didn=E2=80=99t match the=
 specification.
>=20
> There seems to be two views on what to do next given that the RBF rules n=
eed to be updated. One is to ditch the idea of a specification for RBF rule=
s and just document them in the Core repo instead. The other is to have a n=
ew specification for the RBF rules in Core and attempt to correct the mista=
kes made with BIP125 by having a BIP that does correctly outline the RBF ru=
les implemented in Core and includes detailed rationales for why those RBF =
rules have been implemented.
>=20
> Should anyone care about where things are documented?

They really shouldn't.

The nature of L2 punishment protocols is that transaction relay schemes are
additive security: every different way that a punishment tx could get broad=
cast
and mined is a different way that the punishment scheme could succeed. We
should be thinking about how to add diversity and robustness to this in the
form of different schemes, rather than trying to specify exactly how we exp=
ect
these txs to be broadcast. In particular, you have to accept that different
schemes will exist, and an adversary could use those schems.

For the near-term, an important part of this is to get package relay and
package replacements implemented, to avoid edge-cases in multiple-tx scheme=
s.
It'd also be good to specify something entirely different, like a hashcase
based broadcast scheme.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLsCqUACgkQLly11TVR
LzejCg//biIjXTUZmAyak5wdo7sOGke6bi7PADdOIlv8QYBGTt+03fIwhPwDbBP8
mNAouT60UmTkjQMSAMBmJn9taKwjQ6Nvs0HMh9lNOJFgj/wzv3HXQMjrUiOR4jG7
BG5BTxYcjHChWBYO1WAPqh3hkU3ra1a30bLkUnn7685yOyDlUM6tKhDm53xeojP7
7HTA3f6sb/EIQ/LvihSHIpyCsH0uCI4XF12zxLwElwxALky8SeKYt8Y4iIPLsWck
LSEU7NKdUfRu5Ecbdyq9Y4bSn4HmuKQcf0X+axj9AXqjmP/Zv1+G1Y5LfB/WR2kK
Eoo5TETff72Wj7s1nU2w4brfa273aU1XU4R0NE6PxM5JGb7/c0vLrFAnr4kQ001i
FOtdvxEMI1Bk5FGx1qNrOAQK9PNDnWdF8U77MhdeqZ/ZaojURMETGpWS3DcfF7V8
ArneZGdkJrorXvQME0gu/S/qFkD7yB3hleK2WrcaoL/gjVl85AhmpK55hvlGnMsX
3Uf1KJ2idJbwQuXP7CZiz/idnhjczqtYf33h5lFbm0pTX2FaNTTelOuOeFTFgZEQ
kbvabBOs3E2exU47giqhHqw3RbIptg0qA6mO8i7lEgk6FP3kKQcTBu1sy7Oe5C74
n/cUC7WId3xdFwqO4xoMTmQm4/JSsrmnZP50rBAcbdJ9xN1Ovvo=
=AHS+
-----END PGP SIGNATURE-----

--IJwBPXtQQ3L997rR--