Feedback-ID: i525146e8:Fastmail
Date: Thu, 20 Oct 2022 18:52:03 -0400
From: Peter Todd <pete@petertodd.org>
To: John Carvalho <john@synonym.to>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y1HRE5ybTrQZWg6F@petertodd.org>
References: <mailman.34559.1665948998.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92zSBHQAf=i--+dwhWHEX3U9pQPN5uc5ryGkbEb3R3H8Gw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="fji6oTZc/OXz86eb"
Content-Disposition: inline
In-Reply-To: <CAHTn92zSBHQAf=i--+dwhWHEX3U9pQPN5uc5ryGkbEb3R3H8Gw@mail.gmail.com>
Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority
 or a rational one? (re rbf) (Jeremy Rubin)
Precedence: list


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

On Mon, Oct 17, 2022 at 08:23:20AM +0200, John Carvalho via bitcoin-dev wro=
te:
> Simply, 0conf acceptance can be monitored and enforced by the merchant and
> exposure to doublespends can be both mitigated and limited in size per
> block. It is less expensive to be double-spent occasionally than to have a
> delayed checkout experience. Responsible 0conf acceptance is both rational
> and trusting.
>=20
> RBF assurances are optionally enforced by miners, and can be assisted by
> node mempool policies. It is not reliable to expect replaceable payments =
to
> be enforced in a system designed to enforce integrity of payments. RBF is
> both irrational and trusting.

My OpenTimestamps calendars all use RBF for optimal fee discovery. The fact=
 is,
about 95% of OTS transactions mined are replacements rather than originals.=
 I
also took a quick look, and found examples of replacements mined by Foundry
USA, AntPool, F2Pool, Binance Pool, ViaBTC, SlushPool, Luxor, MARA Pool, and
Poolin. That's at least 97.21% of all hashing power supporting opt-in RBF.

Are you claiming that almost all hashing power is irrational?

> RBF is a whim of a feature where engineers made the mistake of thinking a
> hack that basically incentivizes rollbacks and uncertainty might be useful
> because we can pretend Bitcoin has an undo button, and we can pretend to
> game the fee market by low-balling rates until txns get in.

Electrum *literally* has an undo button, implemented with RBF. I've used it=
 a
half dozen times, and it's worked every time.

> Miners serve full nodes. What is more likely, a node set that prefers
> blocks with replaced txns, or a node set that rejects blocks with replaced
> txns?

Has anyone _ever_ implemented a node that rejects blocks containing
double-spends? I don't believe the code to reject such blocks even exists. =
Note
that it should: that's a terrible idea that could lead to sever consensus
problems.

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

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

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

iQEzBAEBCgAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAmNR0Q4ACgkQJIFAPaXw
kfunNggAgLy2ksIrK1Lof1lLzFfn/j1lxx9JfreK6JtVwHs4cR39drNsxX0PPGvw
/ztO3o2EeBvILnnnR2JFp5kblDwBcUXH/u6mqPLIK3+YdNcH0Q2h62gCiRHBy+7b
nndo12LNXmMpnuO8Mwrj2OU56uhza/6JfZsj4NmTaIinlupJj5X3joLq5p9UuVqH
vmawLPPItGcbykrsl1lJB2G/I8Y62CALVt6q7o/014zxdmuEnxRliPH3YJJ4/P4p
AfAfo+LVfT5MaKOc6WI5b8Yd4b4IeCMnMVQi+zLjMnFl22FZINZIwjov5sLuYrCA
XAWK8Me8Cim3J7taxuZnCJ9nKDn60Q==
=X7lH
-----END PGP SIGNATURE-----

--fji6oTZc/OXz86eb--