Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E15E7C002D for ; 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 ; 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 ; 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 ; Sat, 15 Oct 2022 04:08:28 +0000 (UTC) Received: by mail-qk1-x736.google.com with SMTP id b25so3720500qkk.7 for ; 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: In-Reply-To: From: John Carvalho Date: Sat, 15 Oct 2022 06:08:15 +0200 Message-ID: To: Bitcoin Protocol Discussion , Erik Aronesty 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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

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

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.

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 Er= ik Aronesty <erik@q32.com> wrote:=
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't like mobile risks, core lightning and other s= olutions are now easily installed and configured for use in fast payments.<= br>
some references:



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, Joh= n Carvalho via bitcoin-dev wrote:
> In support of Dario's concern, I feel like there is a degree of ga= slighting
> happening with the advancement of RBF somehow being okay, while mercha= nts
> 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<= br> merchants being able to do it is very unfair/centralized.

...and of course, in the past this has lead to merchants trying to make dea= ls
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.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--
--000000000000effe8105eb0ae432--