Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E252C002D for ; Tue, 13 Dec 2022 21:58:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2131381EDD for ; Tue, 13 Dec 2022 21:58:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2131381EDD Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=pwDD69FC X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae8AB4RFxIY3 for ; Tue, 13 Dec 2022 21:58:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C41FB81EDA Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by smtp1.osuosl.org (Postfix) with ESMTPS id C41FB81EDA for ; Tue, 13 Dec 2022 21:58:43 +0000 (UTC) Received: by mail-io1-xd34.google.com with SMTP id p6so2462108iod.13 for ; Tue, 13 Dec 2022 13:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fDw0jLK3DjO0nMJcZpUbDhH/MBWHVr1Qq+w3vnKOaX4=; b=pwDD69FCZda7BjGA0doPEYKn4s/vHykBY1g0S18DzMuCQ65fV/wsTOzQbN1viCxkwV pkWLAxPfP3feT5cRhrcHDpatEc/14F611zttoEPyXhj6HlWghZ3zMQdbEslMfCKNEP+B lpyVE24B7RA+fwDMPML8QnPbvPFajIvtFF3HshSkvHgHb4ztEygvMyByTbGj9E7jX+AC hEW7HL5dklgWbJX8vkKliFflAXGVYoPxVZssvlrVkS5sRjgxCEPScEoT1o9S8qca3IeI nyh1e2y9yvTDknseYmhBWq+fNtedYgv/+IyujI16VkpDQvz9OiNyB/ZnTkskqgfLltJe pCeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fDw0jLK3DjO0nMJcZpUbDhH/MBWHVr1Qq+w3vnKOaX4=; b=FVofnsqI/kDgc9rGTjGo7Cs17+w/2xhauf0dsro64Heo+L18RirJ11Mz0WiDW9TCVV Rmf2tD37JYuL8G5gTu1kp1floA80Td87cAOsGasO9JjK01tr1n6mRmxrYIRnSUUm6MLt NeI2J6s8/kEejLuQnexJZYJdUP96kcV8gfgO5G2Kpen1yI6rqleWfhlW+9zXFvk4Cyc1 ACoNx/heN/L9I8Pnt74cYeh+QXDya1fc4gNVju4w5YSc0prba2xgRLy1aTAXs18SXL4h zgV7Vy1xwGOjwKp45BmG33JkAwBUJirie4FpD8MfAiOTQT0s0x5J9CyEjI8fG+Hf9aWu qUOg== X-Gm-Message-State: ANoB5pn0six6/o9DJTeew6hwiWDSQgNiHZzRHCg6Z0HTt0hUGvd/P8Uk Rth+Plux9wj9tGAN6z8YVCIn9FtjBAAuAjUmTV5MKarRKee9uA== X-Google-Smtp-Source: AA0mqf4mObGDR1DkMJ9eZoY8LPvxJEFiGXHDE2xo1Enk+nVxrP649RmSPfXq3CKFkFF4TRf8iEvZzl+reXEYB9ksU/g= X-Received: by 2002:a5e:db04:0:b0:6e2:c1b3:d74f with SMTP id q4-20020a5edb04000000b006e2c1b3d74fmr4207901iop.90.1670968722600; Tue, 13 Dec 2022 13:58:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Tue, 13 Dec 2022 23:58:31 +0200 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="0000000000002447d005efbcb937" X-Mailman-Approved-At: Tue, 13 Dec 2022 23:17:57 +0000 Cc: bitcoin-dev , John Carvalho Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2022 21:58:45 -0000 --0000000000002447d005efbcb937 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 13 Dec 2022 at 23:41 Peter Todd 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 a= s > > 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 exis= ts > > 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=C2=B9, which has a significant, negative, privacy imp= act=C2=B2. > 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 servic= es > 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=E2=80=99t 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 an= d > expand your business with other chians, such as BSV=C2=B3. The fact is so= me > hashing > power is already beginning to run with full-rbf=E2=81=B4, and I fully exp= ect that > % to > increase over time. > > 1) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021= 144.html > 2) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021= 250.html > 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/ > 4) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021= 260.html > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --=20 ________________________________ Daniel Lipshitz GAP600 www.Gap600.com --0000000000002447d005efbcb937 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 13 Dec 2022 at 23:41 Peter Todd <pete@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 reaso= n 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
>
>=C2=A0 Those reasons do not seem pertinent here - given OptinRBF alread= y 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-spe= nds
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 mitigat= ed today if Full RBF is not in place ?
<= br>
Nothing less than full-rbf without restritions on outputs works for this use-case. The only compromise possible is Antoine Riard's spent-nVersio= n
signalling proposal=C2=B9, which has a significant, negative, privacy impac= t=C2=B2. It
also increases costs and time in many cases, as you often have to create ne= w
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 lar= ger
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=E2=80=99t think this has anything to do with block size debate or d= ecentralisation just looking to protect a significant use case that has bee= n 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.=C2=A0



Anyway, my advice to you is to either change your business model to make us= e of
scalable instant payment tech such as Lightning. Or give up on Bitcoin and<= br> expand your business with other chians, such as BSV=C2=B3. The fact is some= hashing
power is already beginning to run with full-rbf=E2=81=B4, and I fully expec= t that % to
increase over time.

1) https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
2) https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html
3) https://www.gap600.com/bitcoin/gap600-supports= -bsv/
4) https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--
________________________________
Dani= el Lipshitz
GAP600
www.Gap600.com


--0000000000002447d005efbcb937--