📅 Original date posted:2022-12-13
📝 Original message:On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> I dont think there was anything technical with the implementation and as
> far as I can tell this is well developed and ready.
There are lots of problems with my first-seen-safe proposal. The only reason I
proposed it in 2015 was as a political compromise.
> The reasons I can find for not being adopted are listed here -
> https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe
> Replace-by-fee
>
> Those reasons do not seem pertinent here - given OptinRBF already exists
> as an option and the added benefit of continuing to be able to support
> 0-conf.
First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was
merged into Bitcoin Core: multi-party transactions.
With multi-party transactions such as coinjoins and multi-party lightning
channels, we want full-rbf behavior because it avoids accidental double-spends
holding up progress in these protocols. Second, for intentional DoS attacks, it
makes those attacks much more expensive by forcing the attacker to use
tx-pinning.
Nothing less than full-rbf without restritions on outputs works for this
use-case. The only compromise possible is Antoine Riard's spent-nVersion
signalling proposal¹, which has a significant, negative, privacy impact². It
also increases costs and time in many cases, as you often have to create new
outputs to flag full-rbf.
Thus we have a political tradeoff between a handful of centralized services
such as yours that benefit from the first-seen status quo, and the much larger
group of users that use Lightning and coinjoins. We've already been through
such a political tradeoff before with the blocksize debate - again, the
centralized payment providers lost the debate.
Anyway, my advice to you is to either change your business model to make use of
scalable instant payment tech such as Lightning. Or give up on Bitcoin and
expand your business with other chians, such as BSV³. The fact is some hashing
power is already beginning to run with full-rbf⁴, and I fully expect that % to
increase over time.
1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html
3) https://www.gap600.com/bitcoin/gap600-supports-bsv/
4) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/0da664f7/attachment-0001.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 23:17:44
in reply to nevent1q…rra9
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:17:44Event JSON
{
"id": "f326cefca0852476c26b40819f06712489a494c85e80b334dc709062a64d937d",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179864,
"kind": 1,
"tags": [
[
"e",
"25f605421c4fbd232e596dae47a53ef1bea24a0bb884796971a01a9714ed6f81",
"",
"root"
],
[
"e",
"6e2644ef2af1b2b4bfce481ac6d80981c424319fc28e3d029eb7021374479aad",
"",
"reply"
],
[
"p",
"597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6"
]
],
"content": "📅 Original date posted:2022-12-13\n📝 Original message:On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:\n\u003e I dont think there was anything technical with the implementation and as\n\u003e far as I can tell this is well developed and ready.\n\nThere are lots of problems with my first-seen-safe proposal. The only reason I\nproposed it in 2015 was as a political compromise.\n\n\u003e The reasons I can find for not being adopted are listed here -\n\u003e https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe\n\u003e Replace-by-fee\n\u003e \n\u003e Those reasons do not seem pertinent here - given OptinRBF already exists\n\u003e as an option and the added benefit of continuing to be able to support\n\u003e 0-conf.\n\nFirst-seen-safe is incompatible with the #1 reason why mempoolfullrbf was\nmerged into Bitcoin Core: multi-party transactions.\n\nWith multi-party transactions such as coinjoins and multi-party lightning\nchannels, we want full-rbf behavior because it avoids accidental double-spends\nholding up progress in these protocols. Second, for intentional DoS attacks, it\nmakes those attacks much more expensive by forcing the attacker to use\ntx-pinning.\n\nNothing less than full-rbf without restritions on outputs works for this\nuse-case. The only compromise possible is Antoine Riard's spent-nVersion\nsignalling proposal¹, which has a significant, negative, privacy impact². It\nalso increases costs and time in many cases, as you often have to create new\noutputs to flag full-rbf.\n\nThus we have a political tradeoff between a handful of centralized services\nsuch as yours that benefit from the first-seen status quo, and the much larger\ngroup of users that use Lightning and coinjoins. We've already been through\nsuch a political tradeoff before with the blocksize debate - again, the\ncentralized payment providers lost the debate.\n\n\nAnyway, my advice to you is to either change your business model to make use of\nscalable instant payment tech such as Lightning. Or give up on Bitcoin and\nexpand your business with other chians, such as BSV³. The fact is some hashing\npower is already beginning to run with full-rbf⁴, and I fully expect that % to\nincrease over time.\n\n1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html\n2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html\n3) https://www.gap600.com/bitcoin/gap600-supports-bsv/\n4) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/0da664f7/attachment-0001.sig\u003e",
"sig": "74ce2c03259f9120ff6a3990bbf8e0e97aac23a9f631d88efd90dbdd66573bc7f5aa35b2a40a0c0fdd5dd8b68347a6b6d00f527a5544105e2ac2330430dc40f9"
}