path: root/8b/123346e744aaa7c28633ec4532652e750e9790

Return-Path: <alicexbt@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 81F3CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 Oct 2022 20:51:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 4555C813F4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 Oct 2022 20:51:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4555C813F4
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=dzJppR4M
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 5dKDqYZBDjAU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 Oct 2022 20:51:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 447DD813F0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 447DD813F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 Oct 2022 20:51:30 +0000 (UTC)
Date: Sun, 23 Oct 2022 20:51:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1666558287; x=1666817487;
 bh=bcT5/MBTuvfCa0oQ4eKFgaViIf2y4S/5USBGAQ8+G+w=;
 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=dzJppR4Mn/zvE4jkhqFHJ0p05Or3JHmcL+dYwBW6LAe5AisQYxas4AvdCQYp5qTWK
 sUDT6P74XDHC6zF6IuUX1aiCcwo5++bp/74dg+b6ZPfnJAdrzC/4+GgaFjpOIyDbBJ
 WyVEOTAs99sHfAbXIBA7v6wR+Pb9ED5VJ+sK6ueU8TW+cqJtuSxYXZkmofcHmQnIny
 ggPPFf97LUtnMRivMM43qaRbPvgEijgVsB0V8aKNKqR+hweSLZjatzjzYjh5tGr12f
 tH3tblkfmUFkbvLTQD3Oe+rZqf/quQcbs7zB/eT21v63zQwC/fp0j339IEY9yojdda
 Fu+NOrcmG7XVg==
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
X-Mailman-Approved-At: Sun, 23 Oct 2022 21:19:50 +0000
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
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: Sun, 23 Oct 2022 20:51:33 -0000

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