MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 19 Oct 2022 10:45:44 -0400
Message-ID: <CAJowKg+Lp6NBm-H9_Gr6Zoj=-NCFVwpGZoqVOWhAkkw5TDwjYA@mail.gmail.com>
To: Sergej Kotliar <sergej@bitrefill.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002bbd9e05eb644434"
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

--0000000000002bbd9e05eb644434
Content-Type: text/plain; charset="UTF-8"

> Currently Lightning is somewhere around 15% of our total bitcoin
payments. This is very much not nothing, and all of us here want Lightning
to grow, but I think it warrants a serious discussion on whether we want
Lightning adoption to go to 100% by means of disabling on-chain commerce.

Is this about disabling "on-chain instant commerce"?

 - Waiting for confirmation on-chain before shipping a product won't
change, normally it's 15 minutes or so.  This doesn't change that.

 - An easy way to cancel/rbf a transaction doesn't exist - like you said,
there's no UX for this now, and I don't anticipate one being broadly used
except by inter-exchange transfers, etc.

So what does this change?

 - In the rare event that an RBF transaction is received where the fee
level means confirmation times will be slow a merchant will have to wait
very long for at least 1 confirmation, the merchant should alert the user
that the transaction may take longer than the BTC FX rate guarantee window,
and may require additional funds if FX rates change.

 - Users with wallets that support RBF can now be encouraged to accelerate
the tx, with help and advice depending on their wallet, in order to lock in
the FX rates

 - 0 conf is still viable strategy for releasing an order, as long as fees
are very high, and it's very likely to be included in the next block.
 More fee analysis is needed to validate 0 conf and mitigate risks, but now
it is, at least, more "honest" to the true risks.

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

<div dir=3D"ltr">&gt; Currently Lightning is somewhere around 15% of our to=
tal bitcoin payments. This is very much not nothing, and all of us here wan=
t Lightning to grow, but I think it warrants a serious discussion on whethe=
r we want Lightning adoption to go to 100% by means of disabling on-chain c=
ommerce.<br><div><br></div><div>Is this about disabling &quot;on-chain inst=
ant commerce&quot;?<br><br>=C2=A0- Waiting for confirmation on-chain before=
=C2=A0shipping a product won&#39;t change, normally it&#39;s 15 minutes or =
so.=C2=A0 This doesn&#39;t change that.</div><div><br></div><div>=C2=A0- An=
 easy way to cancel/rbf a transaction doesn&#39;t exist - like you said, th=
ere&#39;s no UX for this now, and I don&#39;t anticipate one being broadly =
used except=C2=A0by inter-exchange transfers, etc.</div><div><br></div><div=
>So what does this change?</div><div><br></div><div>=C2=A0- In the rare eve=
nt that an RBF transaction is received where the fee level means confirmati=
on times will be slow a merchant will have to wait very long for at least 1=
 confirmation, the merchant should alert the user that the transaction=C2=
=A0may take longer than the BTC FX rate guarantee window, and may require a=
dditional funds if FX rates change.</div><div><br></div><div>=C2=A0- Users =
with wallets that support RBF can now be encouraged to accelerate the tx, w=
ith help and advice depending on their wallet, in order to lock in the FX r=
ates</div><div><br></div><div>=C2=A0- 0 conf is still viable strategy for r=
eleasing an order, as long as fees are very high, and it&#39;s very likely =
to be included in the next block.=C2=A0 =C2=A0More fee analysis is needed t=
o validate 0 conf and mitigate risks, but now it is, at least, more &quot;h=
onest&quot; to the true risks.</div><div><br></div></div>

--0000000000002bbd9e05eb644434--