diff options
| author | David A. Harding <dave@dtrt.org> | 2022-10-23 09:20:41 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-23 19:20:45 +0000 |
| commit | ae992b301218241161fcd8947a5b34c137003224 (patch) | |
| tree | 3b9a32132ef8b2d6b26fca541076af4aca1440fa | |
| parent | 5518ca3b5e6e4952b4ee272f7db7f2ce6acd67c8 (diff) | |
| download | pi-bitcoindev-ae992b301218241161fcd8947a5b34c137003224.tar.gz pi-bitcoindev-ae992b301218241161fcd8947a5b34c137003224.zip | |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
| -rw-r--r-- | a4/36b496a4a7ae6358e46225f921a40738a693c4 | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/a4/36b496a4a7ae6358e46225f921a40738a693c4 b/a4/36b496a4a7ae6358e46225f921a40738a693c4 new file mode 100644 index 000000000..62ada9b0f --- /dev/null +++ b/a4/36b496a4a7ae6358e46225f921a40738a693c4 @@ -0,0 +1,110 @@ +Return-Path: <dave@dtrt.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 7BFB9C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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" <dave@dtrt.org> +To: Sergej Kotliar <sergej@bitrefill.com>, Bitcoin Protocol Discussion + <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com> +References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com> + <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com> +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 <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 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 + |