rich1.0npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4rhttps://nostr.ae/npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4rnjumphttps://nostr.ae📅 Original date posted:2022-10-14 📝 Original message:In support of Dario's concern, I feel like there is a degree of gaslighting happening with the advancement of RBF somehow being okay, while merchants wanting to manage their own 0conf risk better being not okay. The argument against 0conf acceptance seems to be "miners can facilitate doublespends anyway, and are incentivized to do so if the fees are higher" as this is just how Bitcoin works. But RBF proponents seem to be taking what is actually a much rarer, and less useful, use case of replacing txns that lowball feerates, or actually undoing/doublespending previously signed payments... and threaten the use case of onchain bitcoin being useful at the point-of-sale for merchants and consumers. I can tell you right now where this leads. It leads to miners, merchants and consumers creating alternative fee mechanisms and trusted/exclusive mempools where first-seen txns are respected. The truth is that doublespending is not a certain process, and in many commercial situations, too risky to attempt without real-world consequences. 0conf payment acceptance comes with highly *manageable* risks, which means that if best practices and methods are used by merchants, and *gasp* advanced by engineers with better tools and specs, that we can have fast and valuable commercial payments with merchants that meet user expectations. In fact, we may even be able to do so with less complexity than Lightning and with similar results and overhead... That said, we are (myself and a group of builders and merchants) moving forward with demonstrating, protecting, and advancing this use case, to contrast the trend of making the mempool less predictable and easier to replace. RBF causes more problems than it resolves, and if your argument is that 0conf was never safe, then mine is that RBF was never needed. We should not pretend that the mempool is enforceable for either cause, and should respect that incentives will always prevail eventually. To me, use cases for spending Bitcoin are more important to protect than features for pretending you can enforce mempool behaviors or pretending you can reliably provide replacement features. If anyone is interested in research, specs, and tools and assisting our group, you can contact me directly, or join the public chat at https://t.me/bitcoinandlightningspecs Thanks, -- John Carvalho CEO, Synonym.to <http://synonym.to/> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221014/d5ebbd52/attachment.html>