📅 Original date posted:2022-10-23
📝 Original message: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
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-07 23:15:01
in reply to nevent1q…ty46
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:15:01Event JSON
{
"id": "a362113ceed511bddcb40fe5186b5d6581d623d38a57b2f923e904c239aa5af4",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179701,
"kind": 1,
"tags": [
[
"e",
"946b9a8231803f73c278c08ca74b58bc34d6ba681eae8ff2a82e75b78f2e09ab",
"",
"root"
],
[
"e",
"53e039b298cbcba02444405de1388e8dc0082b5657c78b74d9f0af3054e8aef4",
"",
"reply"
],
[
"p",
"6c4821c93cad469f3b37d8304ecd7384018a56f69f660bc5a92913288098623c"
]
],
"content": "📅 Original date posted:2022-10-23\n📝 Original message:On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:\n\u003e The biggest risk\n\u003e in accepting bitcoin payments is in fact not zeroconf risk (it's\n\u003e actually quite easily managed), it's FX risk as the merchant must\n\u003e commit to a certain BTCUSD rate ahead of time for a purchase. Over\n\u003e time some transactions lose money to FX and others earn money - that\n\u003e evens out in the end. But if there is an _easily accessible in the\n\u003e wallet_ feature to \"cancel transaction\" that means it will eventually\n\u003e get systematically abused.\n\nOne way to address this risk is by turning it into a certainty. If the \nprice of BTC increases between when the invoice is generated and when a \ntransaction is included in a block, give the customer a future purchase \ncredit equal in value to the difference between the price they paid and \nthe value of the purchase at confirmation time. Now there's no benefit \nto the customer from canceling their transaction.\n\nOf course, this means that the merchant will always either break even or \nlose money on the exchange rate part of the transaction and will need to \nraise their prices accordingly. I can see how that would be unappealing \nto implement, but it seems better to me to address the incentive \nincompatibility you've raised rather than hope no large miners ever \nstart performing full RBF. Plus, maybe the future credit feature is \nsomething customers would like: I know I've been sad several times when \nthe exchange rate changed significantly while I was waiting for one of \nmy transactions to confirm.\n\nThe above mitigation is also compatible with LN payments. For example, \na merchant today might issue an LN invoice that expires in 10 minutes. \nThe customer can wait for most of that time to elapse to see how the \nexchange rate changes before deciding to pay, obtaining the same \nAmerican call option. If they are instead offered a future purchase \ncredit for any gains, the customer doesn't suffer any opportunity cost \nby paying immediately. (With LN, it might be possible to have a better \nUX for this by either refunding any excess or (if using something like \nOriginal AMP or PTLCs) not claiming any parts of the payment which are \nin excess.)\n\n-Dave",
"sig": "23166e6c2476dfe2a15f0b5f95f61cb88fa4b9dcebedb6bb7a32d306b884d315c79a980d8be343cd13546ff95e418b1d4204209b2785c9afd0831d441fa827b5"
}