Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BFB9C002D for ; Sun, 23 Oct 2022 19:20:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 422804010E for ; Sun, 23 Oct 2022 19:20:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 422804010E X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L77cpFkrBdJ for ; Sun, 23 Oct 2022 19:20:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2960540104 Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2960540104 for ; Sun, 23 Oct 2022 19:20:43 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 9C7E3280087F; Sun, 23 Oct 2022 12:20:41 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Sun, 23 Oct 2022 12:20:41 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 23 Oct 2022 09:20:41 -1000 From: "David A. Harding" To: Sergej Kotliar , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: <63801f7f26f10f6d04cf8e4afe3c8ca1@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 29cb.63559409.30cb6.0 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 19:20:45 -0000 On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote: > 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. 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. 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. 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.) -Dave