On Mon, Oct 17, 2022 at 08:23:20AM +0200, John Carvalho via bitcoin-dev wrote: > 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.
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. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
