From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 81F3CC002D for ; 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 ; 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 ; 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 ; 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" From: alicexbt Message-ID: <0iUO9M0mp6DaXCBTs0j14kLLjpGSSDKcP1saKsmIThENXcf0uQCZ8XmOwpeaKoWaqWcOl3sn4Xg0iQJegqXCyhvxiGH7qE4bAWoodxFHxSA=@protonmail.com> In-Reply-To: <63801f7f26f10f6d04cf8e4afe3c8ca1@dtrt.org> References: <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 , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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= 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