Francis Pouliot [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-11 📝 Original message: I'm currently in the ...
📅 Original date posted:2019-01-11
📝 Original message:
I'm currently in the process of building the Lightning Network payout
feature which will allow users to purchase bitcoins with fiat and have the
coins sent to the via LN rather than on-chain. The main issue I'm facing is
ensuring that recipients generate the correct Bolt11 invoice.
Having the "d" and "h" fields mandatory creates a UX issue for Bitcoin
services that are performing payouts/withdrawals (in the absence of a
widely adopted payment protocol).
It seems to me that the design of Bolt11 may have been biased towards
merchants, because normally merchants, as recipients, decide on what the
invoice is going to be and the sender doesn't have a choice but to conform
(since the recipient is the service provider).
But for LN payouts (e.g. withdrawal from an exchange or a poker site), the
Sender is the services provider, and it is the Sender who will be creating
(most likely programatically) the terms of the payment. However, this means
that the Sender must be able to communicate to his end-user exactly what
type of Bolt11 invoice he wants the user to create. This means, in most
cases, that the user will have to manually enter some fields in his wallet.
And if the content doesnt match, there will be a payment failure.
Here is how I picture the ux issues taking place.
1. User goes on my app to buy Bitcoin with fiat, and opts to be paid out
via LN rather than on-chain BTC.
2. My app will tell him: "make an invoice with the following: msatoshi,
description.
3. He will go in his wallet and type msatoshi, description.
4. It's likey he won't pay too much attention, make a typo in
description, leave it blank, write his own description, etc.
5. When my app tries to pay, we of course have to decode his bolt11
first.
6. We have to have some logic that will compare the "h" or "d" that we
instructed him to create and the "h" or "d" that we got from the decoded
bolt 11 (which is an extra hassle for devs)
7. In the cases there they are not the same, we need to instruct the
user to create a new bolt 11 invoice because the one he created was not
correct.
What this ends up doing is create a situation where the service provider
depends on his user to create a correct invoice before sending him the
funds, and creates an added (unecessary) requirement for communication, and
lower payment success rates, and likely higher abandonment rate.
Question: what is the logic behind making "d" and "h" mandatory? I think
business logic should be left to Bitcoin businesses.
Can we simply not make "d" or "h" mandatory without breaking anything?
TL;DR users already have troube entering the correct amount of BTC when
paying invoices that aren't BIP21, so I am afraid that there will be tons
of issues with them writing down the correct description.
P.s. I'm using c-lightning right now and would like to not have to switch
P.s.s. this will likely be fixed with a standardised payment protocol but
addressing this issue seems a lower hanging fruit.
Issue: https://github.com/lightningnetwork/lightning-rfc/issues/541
Thanks is for your time,
Francis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190111/2cd3eae9/attachment.html>;
📝 Original message:
I'm currently in the process of building the Lightning Network payout
feature which will allow users to purchase bitcoins with fiat and have the
coins sent to the via LN rather than on-chain. The main issue I'm facing is
ensuring that recipients generate the correct Bolt11 invoice.
Having the "d" and "h" fields mandatory creates a UX issue for Bitcoin
services that are performing payouts/withdrawals (in the absence of a
widely adopted payment protocol).
It seems to me that the design of Bolt11 may have been biased towards
merchants, because normally merchants, as recipients, decide on what the
invoice is going to be and the sender doesn't have a choice but to conform
(since the recipient is the service provider).
But for LN payouts (e.g. withdrawal from an exchange or a poker site), the
Sender is the services provider, and it is the Sender who will be creating
(most likely programatically) the terms of the payment. However, this means
that the Sender must be able to communicate to his end-user exactly what
type of Bolt11 invoice he wants the user to create. This means, in most
cases, that the user will have to manually enter some fields in his wallet.
And if the content doesnt match, there will be a payment failure.
Here is how I picture the ux issues taking place.
1. User goes on my app to buy Bitcoin with fiat, and opts to be paid out
via LN rather than on-chain BTC.
2. My app will tell him: "make an invoice with the following: msatoshi,
description.
3. He will go in his wallet and type msatoshi, description.
4. It's likey he won't pay too much attention, make a typo in
description, leave it blank, write his own description, etc.
5. When my app tries to pay, we of course have to decode his bolt11
first.
6. We have to have some logic that will compare the "h" or "d" that we
instructed him to create and the "h" or "d" that we got from the decoded
bolt 11 (which is an extra hassle for devs)
7. In the cases there they are not the same, we need to instruct the
user to create a new bolt 11 invoice because the one he created was not
correct.
What this ends up doing is create a situation where the service provider
depends on his user to create a correct invoice before sending him the
funds, and creates an added (unecessary) requirement for communication, and
lower payment success rates, and likely higher abandonment rate.
Question: what is the logic behind making "d" and "h" mandatory? I think
business logic should be left to Bitcoin businesses.
Can we simply not make "d" or "h" mandatory without breaking anything?
TL;DR users already have troube entering the correct amount of BTC when
paying invoices that aren't BIP21, so I am afraid that there will be tons
of issues with them writing down the correct description.
P.s. I'm using c-lightning right now and would like to not have to switch
P.s.s. this will likely be fixed with a standardised payment protocol but
addressing this issue seems a lower hanging fruit.
Issue: https://github.com/lightningnetwork/lightning-rfc/issues/541
Thanks is for your time,
Francis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190111/2cd3eae9/attachment.html>;