John Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-17 📝 Original message:Simply, 0conf acceptance ...

📅 Original date posted:2022-10-17
📝 Original message: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/>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/9685b7ad/attachment.html>;