📅 Original date posted:2022-12-13
📝 Original message:On Tue, 13 Dec 2022 at 23:41 Peter Todd <pete at petertodd.org> wrote:
> 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.
what is meant by accidental double spends ? And do you have any data as to
how often these occur and would cause harm?
Second, for intentional DoS attacks, it
> makes those attacks much more expensive by forcing the attacker to use
> tx-pinning.
how are these Dos attacks mitigated today if Full RBF is not in place ?
>
>
> 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.
How many users are currently using Lightning and coinjoins today ?
> We've already been through
> such a political tradeoff before with the blocksize debate - again, the
> centralized payment providers lost the debate.
I don’t think this has anything to do with block size debate or
decentralisation just looking to protect a significant use case that has
been in place - GAP600 is by no means the only service provider is this
place there are many merchants who do 0-conf on there own.
>
>
>
> 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
>
--
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/5169f876/attachment.html>;
Daniel Lipshitz [ARCHIVE] /
npub1t9…fg2yy
2023-06-07 23:17:44
in reply to nevent1q…uqc5
Author Public Key
npub1t97ak5ltnq0v72nv4jssnhw0fr09axwqvc20623jfdnvrajae7nqufg2yyPublished at
2023-06-07 23:17:44Event JSON
{
"id": "260ccfe6a67d799ea345a20a92aa2278e89acea556b740e15be3e9cbfabc1cfb",
"pubkey": "597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6",
"created_at": 1686179864,
"kind": 1,
"tags": [
[
"e",
"25f605421c4fbd232e596dae47a53ef1bea24a0bb884796971a01a9714ed6f81",
"",
"root"
],
[
"e",
"f326cefca0852476c26b40819f06712489a494c85e80b334dc709062a64d937d",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-12-13\n📝 Original message:On Tue, 13 Dec 2022 at 23:41 Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:\n\u003e \u003e I dont think there was anything technical with the implementation and as\n\u003e \u003e far as I can tell this is well developed and ready.\n\u003e\n\u003e There are lots of problems with my first-seen-safe proposal. The only\n\u003e reason I\n\u003e proposed it in 2015 was as a political compromise.\n\u003e\n\u003e \u003e The reasons I can find for not being adopted are listed here -\n\u003e \u003e https://bitcoincore.org/en/faq/optin_rbf/ under - Why not\n\u003e First-seen-safe\n\u003e \u003e Replace-by-fee\n\u003e \u003e\n\u003e \u003e Those reasons do not seem pertinent here - given OptinRBF already exists\n\u003e \u003e as an option and the added benefit of continuing to be able to support\n\u003e \u003e 0-conf.\n\u003e\n\u003e First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was\n\u003e merged into Bitcoin Core: multi-party transactions.\n\u003e\n\u003e With multi-party transactions such as coinjoins and multi-party lightning\n\u003e channels, we want full-rbf behavior because it avoids accidental\n\u003e double-spends\n\u003e holding up progress in these protocols.\n\nwhat is meant by accidental double spends ? And do you have any data as to\nhow often these occur and would cause harm?\n\nSecond, for intentional DoS attacks, it\n\u003e makes those attacks much more expensive by forcing the attacker to use\n\u003e tx-pinning.\n\nhow are these Dos attacks mitigated today if Full RBF is not in place ?\n\n\u003e\n\u003e\n\u003e Nothing less than full-rbf without restritions on outputs works for this\n\u003e use-case. The only compromise possible is Antoine Riard's spent-nVersion\n\u003e signalling proposal¹, which has a significant, negative, privacy impact².\n\u003e It\n\u003e also increases costs and time in many cases, as you often have to create\n\u003e new\n\u003e outputs to flag full-rbf.\n\u003e\n\u003e Thus we have a political tradeoff between a handful of centralized services\n\u003e such as yours that benefit from the first-seen status quo, and the much\n\u003e larger\n\u003e group of users that use Lightning and coinjoins.\n\nHow many users are currently using Lightning and coinjoins today ?\n\n\u003e We've already been through\n\u003e such a political tradeoff before with the blocksize debate - again, the\n\u003e centralized payment providers lost the debate.\n\nI don’t think this has anything to do with block size debate or\ndecentralisation just looking to protect a significant use case that has\nbeen in place - GAP600 is by no means the only service provider is this\nplace there are many merchants who do 0-conf on there own.\n\n\u003e\n\u003e\n\u003e\n\u003e Anyway, my advice to you is to either change your business model to make\n\u003e use of\n\u003e scalable instant payment tech such as Lightning. Or give up on Bitcoin and\n\u003e expand your business with other chians, such as BSV³. The fact is some\n\u003e hashing\n\u003e power is already beginning to run with full-rbf⁴, and I fully expect that\n\u003e % to\n\u003e increase over time.\n\u003e\n\u003e 1)\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html\n\u003e 2)\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html\n\u003e 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/\n\u003e 4)\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n-- \n________________________________\nDaniel Lipshitz\nGAP600\nwww.Gap600.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/5169f876/attachment.html\u003e",
"sig": "65d2925da9cea3129ca3d53a56754b406db15384f5a898e82cf2aed10f1b2b169a03de25376243bb9e1ad6747c5b6b91ae533b48241d32270dc71620c9eb550b"
}