path: root/b5/eb98d9b079dd309abb36b19ea93659a731b765

Return-Path: <john@synonym.to>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E15E7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Oct 2022 04:08:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B5A73404F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Oct 2022 04:08:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B5A73404F6
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
 header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=XZR2S5gv
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8yW4RhN6QYOe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Oct 2022 04:08:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4841B40116
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com
 [IPv6:2607:f8b0:4864:20::736])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4841B40116
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Oct 2022 04:08:28 +0000 (UTC)
Received: by mail-qk1-x736.google.com with SMTP id b25so3720500qkk.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Oct 2022 21:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=synonym-to.20210112.gappssmtp.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=uOC1u8ulFYZurSIEbVBiPNS/S2RFSCvSk3VVsLazays=;
 b=XZR2S5gvR0sRTtBnfAAT75kkLk0KNbPMH37QnPQfesD/NN0mGeOD78kA8oI6dFOqDu
 lGdRiKC1aVkNNMAKH8T7yzzOubJXLPYPAEHktBdVLg9wpu1evo24Xs4cNb/dQgR52jq3
 es5fpTEEVuV5kzqvwFO0xCIybD6ZsAcD5GJEaYqEL6DsB5+vsjMG2WH20jpBS3J5xRyZ
 NuA1xbB3y0NY2q3HoRMpI175A1H7FgMz2CEL2mgfm2TrHV4zcj1OUVTjxxbv2KWa1eN9
 XPTy5bpbAVsLXPoCwR8bj7P2A+X7VTOaGDe/b+DnobQ5Udb3UzJKr3J2AZS5V91cOMBp
 OeRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=uOC1u8ulFYZurSIEbVBiPNS/S2RFSCvSk3VVsLazays=;
 b=3RrvGos963IHNp0gc2G/zrdBS3c4/mabPsKz9oQAY0AXlBQ9ZiycXQJUz+SK1CXaR+
 009XEsnq2i93uJ/6yohZ2ZjSTBe1zv6XmHMemK0fppPSQE3NldsZxGYMSo7RZHPVM9x+
 kpt64vSqAEs9CAfOOalNuCIoWGSLnRDZgxFrCOeRvbM4eZN5bTW9V3yhEbS0CbcAArZc
 Fth5PuFWjcjIqPPjc9YJ6l4Lwqs4FLN2HurBOSStS2vMNeorFW67YME3NLV3/bpk7McG
 sqMd2+6n1v2cRhqSVbzeN3XGpjRu19XCzHBE9ZkQxLZTIfHZggEnqknfBRj6QKQAlSdY
 5rGQ==
X-Gm-Message-State: ACrzQf0lftiACpKw96Nb1nluXGVcrSqdIlbeswO7QNeuq3FurylmZPa5
 f0GihSa8FU9bF1N/zFB0JV+oCUquXAj77eOEXiKNpZGYe/9FGg==
X-Google-Smtp-Source: AMsMyM44ygzPNWteIodNs0n+7X2cQDNsqmOZX3Ba59rKb5bvQ+ZH+lDINmlDu6wOJwcXWe7EdLJfvHwJEXzsXwx5UIg=
X-Received: by 2002:a37:658b:0:b0:6ee:7998:d694 with SMTP id
 z133-20020a37658b000000b006ee7998d694mr685694qkb.777.1665806906680; Fri, 14
 Oct 2022 21:08:26 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92x8-20SjMRs=+vbtvbvocSUM9gVEmHkhuifXeApANFXfg@mail.gmail.com>
 <Y0l6mN5Qw20HSmg6@petertodd.org>
 <CAJowKg+xLFyLPXBHp4tTvceFMO8TG-O=Wq0hbpXKbqCYhZhtNg@mail.gmail.com>
In-Reply-To: <CAJowKg+xLFyLPXBHp4tTvceFMO8TG-O=Wq0hbpXKbqCYhZhtNg@mail.gmail.com>
From: John Carvalho <john@synonym.to>
Date: Sat, 15 Oct 2022 06:08:15 +0200
Message-ID: <CAHTn92y_tJg592R5cg6rxkJXvw0rRdXyrcVP9nO4T0iBbK3qzg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="000000000000effe8105eb0ae432"
X-Mailman-Approved-At: Sat, 15 Oct 2022 04:12:18 +0000
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
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: Sat, 15 Oct 2022 04:08:31 -0000

--000000000000effe8105eb0ae432
Content-Type: text/plain; charset="UTF-8"

Erik, I am fully aware of Lightning and have a been a proponent and builder
of it since it was launched, including getting Bitfinex to support LN,
building a RN LDK implementation in our upcoming app, etc, but frankly LN
has nowhere near the adoption of onchain payments for commerce, and LN
complexity, reliability, maintenance and overhead are real obstacles for
merchants.

One of your links is to Muun, who started this thread!

There is no practicality in a merchant saying they accept bitcoin, but not
onchain, or in having many checkout and customer service versions for many
bitcoin payment methods.

Merchants accepting base layer bitcoin is one if the most important types
of adoption there is.

-John

On Fri, Oct 14, 2022 at 6:29 PM Erik Aronesty <erik@q32.com> wrote:

> Also, lightning works fine and is readily available in convenient mobile
> apps used by millions of people, or in .   So the need for a 0conf has been
> mitigated by other solutions for fast payments with no need for a trust
> relationship.  And for people that don't like mobile risks, core lightning
> and other solutions are now easily installed and configured for use in fast
> payments.
>
> some references:
>
> https://muun.com/ (easy!)
> https://github.com/ElementsProject/lightning (reference, works well with
> core)
> https://lightning.network/ (more info)
>
>
> On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
>> wrote:
>> > 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 way merchants try to manage 0conf risk is quite harmful to Bitcoin.
>> Connecting to large numbers of nodes to try to risk-manage propagation
>> _is_ an
>> attack, albeit a mild one. Everyone doing that is very harmful; only a few
>> merchants being able to do it is very unfair/centralized.
>>
>> ...and of course, in the past this has lead to merchants trying to make
>> deals
>> with miners directly, even going as far as to suggest reorging out
>> double-spends. I don't need to explain why that is obviously extremely
>> harmful.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog

--000000000000effe8105eb0ae432
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Erik, I am fully aware of Lightning and have a been a pro=
ponent and builder of it since it was launched, including getting Bitfinex =
to support LN, building a RN LDK implementation in our upcoming app, etc, b=
ut frankly LN has nowhere near the adoption of onchain payments for commerc=
e, and LN complexity, reliability, maintenance and overhead are real obstac=
les for merchants. =C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">One of your links is to Muun, who started this thread!</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">There is no practicality in a merchant say=
ing they accept bitcoin, but not onchain, or in having many checkout and cu=
stomer service versions for many bitcoin payment methods.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Merchants accepting base layer bitcoin is=
 one if the most important types of adoption there is.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">-John</div><div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 14, 2022 at 6:29 PM Er=
ik Aronesty &lt;<a href=3D"mailto:erik@q32.com">erik@q32.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-le=
ft-color:rgb(204,204,204)"><div dir=3D"ltr">Also, lightning works fine and =
is readily available in convenient=C2=A0mobile apps used by millions of peo=
ple, or in .=C2=A0 =C2=A0So the need for a 0conf has been mitigated by othe=
r solutions for fast payments with no need for a trust relationship.=C2=A0 =
And for people that don&#39;t like mobile risks, core lightning and other s=
olutions are now easily installed and configured for use in fast payments.<=
br><br>some references:<div><br></div><div><div><a href=3D"https://muun.com=
/" target=3D"_blank">https://muun.com/</a> (easy!)</div></div><div><a href=
=3D"https://github.com/ElementsProject/lightning" target=3D"_blank">https:/=
/github.com/ElementsProject/lightning</a> (reference, works well with core)=
<div><a href=3D"https://lightning.network/" target=3D"_blank">https://light=
ning.network/</a> (more info)</div></div><div><br></div></div><br><div clas=
s=3D"gmail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div></div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-lef=
t:1ex;border-left-color:rgb(204,204,204)"></blockquote></div><div class=3D"=
gmail_quote"><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)">On Fri, Oct 14, 2022 at 12:03:21PM +0200, Joh=
n Carvalho via bitcoin-dev wrote:<br>
&gt; In support of Dario&#39;s concern, I feel like there is a degree of ga=
slighting<br>
&gt; happening with the advancement of RBF somehow being okay, while mercha=
nts<br>
&gt; wanting to manage their own 0conf risk better being not okay.<br>
<br>
The way merchants try to manage 0conf risk is quite harmful to Bitcoin.<br>
Connecting to large numbers of nodes to try to risk-manage propagation _is_=
 an<br>
attack, albeit a mild one. Everyone doing that is very harmful; only a few<=
br>
merchants being able to do it is very unfair/centralized.<br>
<br>
...and of course, in the past this has lead to merchants trying to make dea=
ls<br>
with miners directly, even going as far as to suggest reorging out<br>
double-spends. I don&#39;t need to explain why that is obviously extremely =
harmful.<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></d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;paddin=
g-left:1ex;border-left-color:rgb(204,204,204)">
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rg=
b(34,34,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" st=
yle=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D=
"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204=
)" target=3D"_blank">Synonym.to</a><br><div><font size=3D"1"><br>Schedule:=
=C2=A0<a href=3D"https://calendly.com/bitcoinerrorlog" style=3D"color:rgb(1=
7,85,204)" target=3D"_blank">https://calendly.com/bitcoinerrorlog</a><br></=
font></div><div><font size=3D"1">Chat:=C2=A0<a href=3D"https://t.me/bitcoin=
errorlog" style=3D"color:rgb(17,85,204)" target=3D"_blank">https://t.me/bit=
coinerrorlog</a></font></div><div><font size=3D"1">Social:=C2=A0<a href=3D"=
https://twitter.com/bitcoinerrorlog" style=3D"color:rgb(17,85,204)" target=
=3D"_blank">https://twitter.com/bitcoinerrorlog</a></font></div></div></div=
></div></div>

--000000000000effe8105eb0ae432--