path: root/a4/f7ba201fbf356f3681c310c2a0d79cacaf6ef7

Return-Path: <daniel@gap600.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4E252C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 13 Dec 2022 21:58:43 +0000 (UTC)
Received: by mail-io1-xd34.google.com with SMTP id p6so2462108iod.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com>
 <CAAQdECAspoRJRz7j1ubAe=Cen==AVF5bm-Q2=0TiKc7NtbU65A@mail.gmail.com>
 <CACkWPs_4pjTo50=S86KPEznBs0PU7rd30rBGHq2Q5=6n6hYMgQ@mail.gmail.com>
 <CAHTn92wH17Z+p5cFOLpzsVUuTf4-nZc7tOjQr+_xjSU5groa0Q@mail.gmail.com>
 <CACkWPs9VawCYt7maiNqzafkFnHTiGJQkXMT4VXQQcG-rE2TTNw@mail.gmail.com>
 <Y5jxmItJIpIUVY+x@petertodd.org>
In-Reply-To: <Y5jxmItJIpIUVY+x@petertodd.org>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Tue, 13 Dec 2022 23:58:31 +0200
Message-ID: <CACkWPs_jSLDg3seON0uu=ri6iR9cytXo2MEPJ5PVeap+iDreeQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="0000000000002447d005efbcb937"
X-Mailman-Approved-At: Tue, 13 Dec 2022 23:17:57 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 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

<div><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, 13 Dec 2022 at 23:41 Peter Todd &lt;<a href=3D"mail=
to:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,20=
4,204)">On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:<br=
>
&gt; I dont think there was anything technical with the implementation and =
as<br>
&gt; far as I can tell this is well developed and ready.<br>
<br>
There are lots of problems with my first-seen-safe proposal. The only reaso=
n I<br>
proposed it in 2015 was as a political compromise.<br>
<br>
&gt; The reasons I can find for not being adopted are listed here -<br>
&gt; <a href=3D"https://bitcoincore.org/en/faq/optin_rbf/" rel=3D"noreferre=
r" target=3D"_blank">https://bitcoincore.org/en/faq/optin_rbf/</a> under - =
Why not First-seen-safe<br>
&gt; Replace-by-fee<br>
&gt; <br>
&gt;=C2=A0 Those reasons do not seem pertinent here - given OptinRBF alread=
y exists<br>
&gt; as an option and the added benefit of continuing to be able to support=
<br>
&gt; 0-conf.<br>
<br>
First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was<b=
r>
merged into Bitcoin Core: multi-party transactions.<br>
<br>
With multi-party transactions such as coinjoins and multi-party lightning<b=
r>
channels, we want full-rbf behavior because it avoids accidental double-spe=
nds<br>
holding up progress in these protocols. </blockquote><div dir=3D"auto">what=
 is meant by accidental double spends ? And do you have any data as to how =
often these occur and would cause harm?</div><div dir=3D"auto"><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb=
(204,204,204)" dir=3D"auto">Second, for intentional DoS attacks, it<br>
makes those attacks much more expensive by forcing the attacker to use<br>
tx-pinning.</blockquote><div dir=3D"auto">how are these Dos attacks mitigat=
ed today if Full RBF is not in place ?</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir=3D"auto"><=
br>
<br>
Nothing less than full-rbf without restritions on outputs works for this<br=
>
use-case. The only compromise possible is Antoine Riard&#39;s spent-nVersio=
n<br>
signalling proposal=C2=B9, which has a significant, negative, privacy impac=
t=C2=B2. It<br>
also increases costs and time in many cases, as you often have to create ne=
w<br>
outputs to flag full-rbf.<br>
<br>
Thus we have a political tradeoff between a handful of centralized services=
<br>
such as yours that benefit from the first-seen status quo, and the much lar=
ger<br>
group of users that use Lightning and coinjoins. </blockquote><div dir=3D"a=
uto">How many users are currently using Lightning and coinjoins today ?</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color=
:rgb(204,204,204)" dir=3D"auto">We&#39;ve already been through<br>
such a political tradeoff before with the blocksize debate - again, the<br>
centralized payment providers lost the debate.</blockquote><div dir=3D"auto=
">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</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,=
204)" dir=3D"auto"><br>
<br>
<br>
Anyway, my advice to you is to either change your business model to make us=
e of<br>
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<br>
power is already beginning to run with full-rbf=E2=81=B4, and I fully expec=
t that % to<br>
increase over time.<br>
<br>
1) <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
November/021144.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html</a><br>
2) <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
December/021250.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html</a><br>
3) <a href=3D"https://www.gap600.com/bitcoin/gap600-supports-bsv/" rel=3D"n=
oreferrer" target=3D"_blank">https://www.gap600.com/bitcoin/gap600-supports=
-bsv/</a><br>
4) <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
December/021260.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html</a><br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature">________________________________<br>Dani=
el Lipshitz<br>GAP600<br><a href=3D"http://www.Gap600.com">www.Gap600.com</=
a><br><br><br></div>

--0000000000002447d005efbcb937--