path: root/14/d828b0f2b5f2a689e33bf24d3b2d8535675c82

Return-Path: <alicexbt@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D2AABC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Oct 2022 02:44:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A5E214097B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Oct 2022 02:44:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A5E214097B
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=HZ1FspGG
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2UJ_aGRNMqYy
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Oct 2022 02:44:16 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4A551408DD
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 4A551408DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Oct 2022 02:44:16 +0000 (UTC)
Date: Fri, 14 Oct 2022 02:44:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1665715453; x=1665974653;
 bh=dtvubm/WUy7izBhfuf1XCtmFyYOlqu+Ksb9/bRBq+tI=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=HZ1FspGGc+uWendhHax7Jfycrxm+OKOKswjwYsjHV4QgkS3wlpKX9cCAjR5ou0vnk
 fZ1hdtlRoZL5N4K0NtxllU4ib4lC14pHMImkRKW3mnv3PYad+bHI9eQx/0uM6WOh/l
 mAcz2MmQ0wlC26H0cmZwiJUjkRU9a+H0Sj4ZwSi3W34bwd8Ku/ghS6o5mY71FQHpIh
 3DlrUkyiX3EUVgQYnWFmfVO4MX/whXAt6s4qfvD7f5TFVsJ2TSOJj7M14f76Sc8Fvm
 jtGBeMfIw6zqN53sogHDS4464vRpkFk5x6OwPDyADE/5NOgAzXnk/YTT+yCUt5q2BU
 ugxTZuud0QWCw==
To: linuxfoundation.cndm1@dralias.com
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <4f73l5UZxQAv3BB6YIveAjJlp-YdQa7esPYMsiO-OnNX-G8psxzWSX70WDoLuHCv_FUoIkjY-HNQEkyZKQj88tHwOOIksXKn7qdMBxkbpm0=@protonmail.com>
In-Reply-To: <166567725305.12.6779598172515633768.68724733@dralias.com>
References: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
 <166567725305.12.6779598172515633768.68724733@dralias.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 14 Oct 2022 11:08:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 14 Oct 2022 02:44:18 -0000

Hi cndm1,

> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.

Lightning is only used for 4% payments compared to 32% on-chain payments ac=
cording to a [tweet][1] from Jan 2022 by Sergej Kotliar and stats are simil=
ar based on the slides shared in a [presentation][2] in Pizza Day Prague 20=
22.

By EUR:

onchain - 30%
lightning - 5%

By unique users:

onchain - 40%
lightning - 9%

> Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions.=20

I don't believe relay of fullrbf transactions works well right now. The mis=
sing piece you mentioned is important and a real need for all full node use=
rs to try fullrbf.

> While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.

Changing default at this moment does not make sense as v24.0 could give som=
e insights about usage of fullrbf and we could wait for a few months before=
 changing default for users that run latest version of bitcoin core.

I will quote Antoine Riard's comment from PR [#25353][3]:

"_I know I've advocated in the past to turn RBF support by default in the p=
ast. Though after gathering a lot of feedbacks, this approach of offering t=
he policy flexiblity to the interested users only and favoring a full-rbf g=
radual deployment sounds better to me. As a follow-up, if we add p2p logic =
to connect to few "full-rbf" service-bit signaling peers and recommend to t=
he ~17000 LN nodes operators, likely (hopefully!) running bitcoind as a bac=
kend, that should be okay to guarantee a good propagation to miners (and ye=
s reaching out to few mining pools ops to explain the income increase broug=
ht by full-rbf). Unless we observe a significant impact on compact blocks r=
econstruction, personally I'm really fine waiting another multi-years devel=
opment cycle before to propose a default change, or even let opt-in forever=
 the default as it is._"

"_Once again, the proposed change is only targeting educated users aiming t=
o deploy full RBF for their application specific needs. If the majority of =
Bitcoin users is not interested, that's okay. It's a policy rule, not a con=
sensus one._"

Although Antoine has opened another [pull request][4] to make fullrbf defau=
lt a few hours ago, so I am not sure what is the new motivation or discussi=
on that I am missing.

[1]: https://twitter.com/ziggamon/status/1481307334068641795
[2]: https://youtu.be/bkjEcSmZKfc?t=3D463
[3]: https://github.com/bitcoin/bitcoin/pull/25353
[4]: https://github.com/bitcoin/bitcoin/pull/26305

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, October 13th, 2022 at 9:37 PM, linuxfoundation.cndm1--- via bi=
tcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> > - Bitrefill's on-chain payments for gift cards and phone top-ups
>=20
>=20
> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.
>=20
> It would be interesting to know if there are any obstacles that
> Bitrefill and other services face, or if they don't agree that
> lightning is an improvement over accepting unconfirmed on-chain
> transactions from untrusted parties.
>=20
> > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at=
 least
>=20
>=20
> I haven't tried them yet, but I suspect they could benefit in a
> similar by showing lightning transfers more prominently. Moreover, any
> UX improvement they can offer to users that intentionally or
> accidentally selected RBF opt-in, will also benefit users once fullrbf
> is widespread. To give an example, ATMs could immediately give out a
> voucher for the cash amount that can be redeemed as soon as the
> transaction is confirmed on-chain, to allow (untrusted) users to leave
> the ATM and go for a walk in the meantime.
>=20
> > With full-RBF, wallets should make it extremely clear to users that unc=
onfirmed
> > funds are not theirs (yet). Otherwise, protocol-unaware users that are
> > transacting on-chain with untrusted parties can be easily scammed if th=
ey don't
> > know they have to wait for a confirmation. Eg. in Argentina, it's prett=
y common
> > to meet someone in person to buy bitcoin P2P for cash, even for newcome=
rs.
>=20
>=20
> This is easy to solve, because a wallet can simply display all
> unconfirmed transactions as if they signalled for RBF. Your suggested
> solution to "activate" fullrbf at a specific block height might be
> counter productive, because educating users that unconfirmed
> transactions are unsafe takes longer than a single block. So the
> earlier users are educated that unconfirmed transactions from
> untrusted parties are unsafe, the better.
>=20
> > # Impact at Muun
> >=20
> > Work to transition Muun from using zero-conf submarine swaps to using p=
ayment
> > channels is ongoing, but we are still several months away from being pr=
oduction
> > ready. This means we would have to turn off outgoing lightning payments=
 for
> > +100k monthly active users, which is a good chunk of all users making
> > non-custodial lightning payments today.
>=20
>=20
> It would be unfortunate for those users, but I think that the risk
> exists today. Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions. While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.
>=20
> Best,
> cndm1
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev