Date: Fri, 14 Oct 2022 02:44:04 +0000
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

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