Date: Sun, 23 Oct 2022 20:51:16 +0000
To: "David A. Harding" <dave@dtrt.org>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <0iUO9M0mp6DaXCBTs0j14kLLjpGSSDKcP1saKsmIThENXcf0uQCZ8XmOwpeaKoWaqWcOl3sn4Xg0iQJegqXCyhvxiGH7qE4bAWoodxFHxSA=@protonmail.com>
In-Reply-To: <63801f7f26f10f6d04cf8e4afe3c8ca1@dtrt.org>
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
 <63801f7f26f10f6d04cf8e4afe3c8ca1@dtrt.org>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Sergej Kotliar <sergej@bitrefill.com>,
 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 Dave,

> One way to address this risk is by turning it into a certainty.  If the=
=20
price of BTC increases between when the invoice is generated and when a=20
transaction is included in a block, give the customer a future purchase=20
credit equal in value to the difference between the price they paid and=20
the value of the purchase at confirmation time.  Now there's no benefit=20
to the customer from canceling their transaction.

There are several methods to approach this issue, one of which is by using =
multiple exchanges from different countries as there are always possibiliti=
es for arbitrage. Example:

The user purchases a gift card on Bitrefill for 0.01 BTC, and then Bitrefil=
l cash it out at one of the three exchanges where the price of bitcoin is 1=
9000, 19100, or 19500. However, price used for gift card payment was averag=
e of all 3. This should never be solved at protocol level as speculation of=
 price is irrelevant when making RBF policy default in bitcoin core.

There are different types of businesses that accept bitcoin payments and it=
s good for bitcoin. However, everyone has their own way to deal with the is=
sues. Example:

In a website for booking flights, you may cancel a user's ticket if they co=
uldn't make a payment within a certain amount of time and confirmations. I'=
m not sure how gift cards operate, but they are used for carding, fraud etc=
. frequently.

Its important to give priority to bitcoin projects that could improve deman=
d for block space even if opening and closing channels. I would [quote][0] =
something from a pull request by Michael Folkson although I do not agree wi=
th everything he writes:

"I don't believe in added code (complexity) for issues that can be resolved=
 in alternative repos and through communication with the ecosystem."

Things that could help improve business for companies that accept bitcoin p=
ayments could be done in other ways. Zero conf is old school but we can try=
 new ways and do partnerships with more organizations (outside North Americ=
a and Europe). I work for an exchange as developer although CTO won't write=
 an email and CEO don't want to spam the mailing list with non technical th=
ings. I request on their behalf that we consider all businesses and some ar=
e not even aware of fullRBF. Example: Lolli or Gosats

TL;DR

Full RBF should be tried and if default is an issue, devs should convince s=
ome nodes and miners or agree on one of the pull requests. I prefer [AJ's p=
ull request][1] because it gives time for review and testing. It is importa=
nt to test as many websites, apps, projects etc. as possible before making =
something default and also consider the percent of usage.

[0]: https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280742475
[1]: https://github.com/bitcoin/bitcoin/pull/26323


/dev/fd0


Sent with Proton Mail secure email.

------- Original Message -------
On Monday, October 24th, 2022 at 12:50 AM, David A. Harding via bitcoin-dev=
 <bitcoin-dev@lists.linuxfoundation.org> wrote:


> On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
>=20
> > The biggest risk
> > in accepting bitcoin payments is in fact not zeroconf risk (it's
> > actually quite easily managed), it's FX risk as the merchant must
> > commit to a certain BTCUSD rate ahead of time for a purchase. Over
> > time some transactions lose money to FX and others earn money - that
> > evens out in the end. But if there is an easily accessible in the
> > wallet feature to "cancel transaction" that means it will eventually
> > get systematically abused.
>=20
>=20
> One way to address this risk is by turning it into a certainty. If the
> price of BTC increases between when the invoice is generated and when a
> transaction is included in a block, give the customer a future purchase
> credit equal in value to the difference between the price they paid and
> the value of the purchase at confirmation time. Now there's no benefit
> to the customer from canceling their transaction.
>=20
> Of course, this means that the merchant will always either break even or
> lose money on the exchange rate part of the transaction and will need to
> raise their prices accordingly. I can see how that would be unappealing
> to implement, but it seems better to me to address the incentive
> incompatibility you've raised rather than hope no large miners ever
> start performing full RBF. Plus, maybe the future credit feature is
> something customers would like: I know I've been sad several times when
> the exchange rate changed significantly while I was waiting for one of
> my transactions to confirm.
>=20
> The above mitigation is also compatible with LN payments. For example,
> a merchant today might issue an LN invoice that expires in 10 minutes.
> The customer can wait for most of that time to elapse to see how the
> exchange rate changes before deciding to pay, obtaining the same
> American call option. If they are instead offered a future purchase
> credit for any gains, the customer doesn't suffer any opportunity cost
> by paying immediately. (With LN, it might be possible to have a better
> UX for this by either refunding any excess or (if using something like
> Original AMP or PTLCs) not claiming any parts of the payment which are
> in excess.)
>=20
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev