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/>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
