public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt•org>
To: 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
Date: Sun, 23 Oct 2022 09:20:41 -1000	[thread overview]
Message-ID: <63801f7f26f10f6d04cf8e4afe3c8ca1@dtrt.org> (raw)
In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>

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


  parent reply	other threads:[~2022-10-23 19:20 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` Sergej Kotliar
2022-10-19 14:45   ` Erik Aronesty
2022-10-19 15:43   ` Jeremy Rubin
2022-10-19 15:51     ` Greg Sanders
2022-10-19 16:04     ` Sergej Kotliar
2022-10-19 16:08       ` Greg Sanders
2022-10-20  1:37   ` Antoine Riard
2022-10-20 14:11     ` Sergej Kotliar
2022-10-21  1:04       ` Antoine Riard
2022-10-20  4:05   ` Peter Todd
2022-10-21 19:35     ` Peter Todd
2022-10-20  7:22   ` Anthony Towns
2022-10-20 12:37     ` Sergej Kotliar
2022-10-20 14:14       ` Ruben Somsen
2022-10-20 14:17         ` Sergej Kotliar
2022-10-20 19:58       ` Anthony Towns
2022-10-20 21:05         ` David A. Harding
2022-10-20 21:07         ` Greg Sanders
2022-10-20 22:02           ` Eloy
2022-10-21 12:02           ` Sergej Kotliar
2022-10-21 14:01             ` Greg Sanders
2022-10-21 14:19               ` Sergej Kotliar
2022-10-21 14:47                 ` Greg Sanders
2022-10-21 19:43             ` Peter Todd
2022-10-24  7:55               ` Sergej Kotliar
2022-10-20 22:13         ` Peter Todd
2022-10-21  9:34           ` Sergej Kotliar
2022-10-21 19:33             ` Peter Todd
2022-10-24  7:45               ` Sergej Kotliar
2022-10-21 11:56         ` Sergej Kotliar
2022-10-23 19:20   ` David A. Harding [this message]
2022-10-23 20:51     ` alicexbt
     [not found] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz
2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
2022-12-02  6:34   ` Daniel Lipshitz
2022-12-02  1:52 ` Antoine Riard
2022-12-02  6:59   ` Daniel Lipshitz
2022-12-02  4:30 ` Peter Todd
2022-12-02  7:06   ` Daniel Lipshitz
2022-12-03  8:50     ` Peter Todd
2022-12-03 11:01       ` Daniel Lipshitz
2022-12-03 11:51         ` Daniel Lipshitz
2022-12-03 12:12         ` Peter Todd
2022-12-03 13:17           ` Daniel Lipshitz
2022-12-03 14:03             ` Daniel Lipshitz
2022-12-05 12:21               ` angus
     [not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` John Carvalho
2022-10-14 15:04   ` Peter Todd
2022-10-14 16:28     ` Erik Aronesty
2022-10-15  4:08       ` John Carvalho
2022-10-15  4:20     ` John Carvalho
  -- strict thread matches above, loose matches on Subject: below --
2022-10-07 16:20 Dario Sneidermanis
2022-10-07 17:21 ` David A. Harding
2022-10-07 17:28   ` Greg Sanders
2022-10-07 21:37   ` Dario Sneidermanis
2022-10-11 16:18     ` Pieter Wuille
2022-10-12  5:42     ` Anthony Towns
2022-10-12 16:11       ` Pieter Wuille
2022-10-12 21:44         ` Dario Sneidermanis
2022-10-13  4:35         ` Anthony Towns
2022-10-16  8:08           ` Anthony Towns
2022-10-17 14:25             ` Greg Sanders
2022-10-17 21:41             ` Antoine Riard
2022-10-18  7:00               ` Anthony Towns
2022-10-19  3:01                 ` Antoine Riard
2022-10-19  3:17                 ` alicexbt
2022-10-20 22:08                   ` Peter Todd
2022-11-02 15:04                     ` AdamISZ
2022-10-20 23:18                 ` Peter Todd
2022-11-09 13:19                 ` ArmchairCryptologist
2022-11-10  9:35                   ` ZmnSCPxj
2022-10-07 20:56 ` Luke Dashjr
2022-10-08 20:47 ` alicexbt
2022-10-13 16:07 ` linuxfoundation.cndm1
2022-10-14  2:44   ` alicexbt
2022-10-14 15:02     ` Peter Todd
2022-10-17 20:31 ` Antoine Riard
2022-10-17 22:14 ` Antoine Riard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63801f7f26f10f6d04cf8e4afe3c8ca1@dtrt.org \
    --to=dave@dtrt$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=sergej@bitrefill$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox