📅 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>;
John Carvalho [ARCHIVE] /
npub1qg…nqm4r
2023-06-07 23:14:31
in reply to nevent1q…n0ef
Author Public Key
npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4rPublished at
2023-06-07 23:14:31Event JSON
{
"id": "03def9885ed31aea42cfe4e2930b707dd5757873f9340a0adc99ed03a85d6ac9",
"pubkey": "02283afe5d7e6355ba7a0c2f5283e3149f651dab319cfb553d46a1d180234ed5",
"created_at": 1686179671,
"kind": 1,
"tags": [
[
"e",
"946b9a8231803f73c278c08ca74b58bc34d6ba681eae8ff2a82e75b78f2e09ab",
"",
"root"
],
[
"e",
"5b48899355ca4dbfa86938b276238bad46a0a45d8ed0dd43c424fea8bbd37f0d",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-10-14\n📝 Original message:In support of Dario's concern, I feel like there is a degree of gaslighting\nhappening with the advancement of RBF somehow being okay, while merchants\nwanting to manage their own 0conf risk better being not okay.\n\nThe argument against 0conf acceptance seems to be \"miners can facilitate\ndoublespends anyway, and are incentivized to do so if the fees are higher\"\nas this is just how Bitcoin works.\n\nBut RBF proponents seem to be taking what is actually a much rarer, and\nless useful, use case of replacing txns that lowball feerates, or actually\nundoing/doublespending previously signed payments... and threaten the use\ncase of onchain bitcoin being useful at the point-of-sale for merchants and\nconsumers.\n\nI can tell you right now where this leads. It leads to miners, merchants\nand consumers creating alternative fee mechanisms and trusted/exclusive\nmempools where first-seen txns are respected.\n\nThe truth is that doublespending is not a certain process, and in many\ncommercial situations, too risky to attempt without real-world consequences.\n\n0conf payment acceptance comes with highly *manageable* risks, which means\nthat if best practices and methods are used by merchants, and *gasp*\nadvanced by engineers with better tools and specs, that we can have fast\nand valuable commercial payments with merchants that meet user\nexpectations. In fact, we may even be able to do so with less complexity\nthan Lightning and with similar results and overhead...\n\nThat said, we are (myself and a group of builders and merchants) moving\nforward with demonstrating, protecting, and advancing this use case,\nto contrast the trend of making the mempool less predictable and easier to\nreplace.\n\nRBF causes more problems than it resolves, and if your argument is that\n0conf was never safe, then mine is that RBF was never needed. We should not\npretend that the mempool is enforceable for either cause, and should\nrespect that incentives will always prevail eventually.\n\nTo me, use cases for spending Bitcoin are more important to protect than\nfeatures for pretending you can enforce mempool behaviors or pretending you\ncan reliably provide replacement features.\n\nIf anyone is interested in research, specs, and tools and assisting our\ngroup, you can contact me directly, or join the public chat at\nhttps://t.me/bitcoinandlightningspecs\n\nThanks,\n\n--\nJohn Carvalho\nCEO, Synonym.to \u003chttp://synonym.to/\u003e\n\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221014/d5ebbd52/attachment.html\u003e",
"sig": "0f6bfc683addf564e411d05052b3e53f4a57aa8ceb8b8b0ce14d380f5799a61b38b265b9c70ae97a8d01f772de9f1e6b5b679540ddec74ae5b84db7205f107fa"
}