MIME-Version: 1.0
References: <mailman.34559.1665948998.956.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.34559.1665948998.956.bitcoin-dev@lists.linuxfoundation.org>
From: John Carvalho <john@synonym.to>
Date: Mon, 17 Oct 2022 08:23:20 +0200
Message-ID: <CAHTn92zSBHQAf=i--+dwhWHEX3U9pQPN5uc5ryGkbEb3R3H8Gw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ed3ab905eb350385"
Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority
 or a rational one? (re rbf) (Jeremy Rubin)
Precedence: list

--000000000000ed3ab905eb350385
Content-Type: text/plain; charset="UTF-8"

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.

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.

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.

Now RBF just kinda haunts us as the establishment keeps baking it deeper
and deeper into Bitcoin, despite almost no one using it, and despite it
having negative consequences on more popular use cases.

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?


--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

--000000000000ed3ab905eb350385
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Simply, 0conf acceptance can be monitored and enforce=
d by the merchant and exposure to doublespends can be both mitigated and li=
mited in size per block. It is less expensive to be double-spent occasional=
ly than to have a delayed checkout experience. Responsible 0conf acceptance=
 is both rational and trusting.=C2=A0</div><div><br></div><div>RBF assuranc=
es are optionally enforced by miners, and can be assisted by node=C2=A0memp=
ool policies. It is not reliable to expect replaceable payments to be enfor=
ced in a system designed to enforce integrity of payments. RBF is both irra=
tional and trusting.</div><div><br></div><div>RBF is a whim of a feature wh=
ere engineers made the mistake of thinking a hack that basically incentiviz=
es 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-balli=
ng rates until txns get in.=C2=A0</div><div><br></div><div>Now RBF just kin=
da haunts us as the=C2=A0establishment keeps baking it deeper and deeper in=
to Bitcoin, despite almost no one using it, and despite it having negative =
consequences on more popular use cases.=C2=A0</div><div><br></div><div>Mine=
rs serve full nodes. What is more likely, a node set that prefers blocks wi=
th replaced txns, or a node set that rejects blocks with replaced txns?=C2=
=A0</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br clear=3D"all"><div=
><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><span style=3D=
"color:rgb(34,34,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=
=3D"ltr" style=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div>=
<div dir=3D"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rg=
b(17,85,204)" target=3D"_blank">Synonym.to</a></div></div></div></div></div=
></div></div>

--000000000000ed3ab905eb350385--