Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-14 📝 Original message: It isn't mandatory. It ...
📅 Original date posted:2019-01-14
📝 Original message:
It isn't mandatory. It can be left blank, none of the existing wallets
require users to input a description when they make an invoice.
On Mon, Jan 14, 2019, 3:28 PM Francis Pouliot <francis at satoshiportal.com
wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190114/09200bcf/attachment-0001.html>;
📝 Original message:
It isn't mandatory. It can be left blank, none of the existing wallets
require users to input a description when they make an invoice.
On Mon, Jan 14, 2019, 3:28 PM Francis Pouliot <francis at satoshiportal.com
wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190114/09200bcf/attachment-0001.html>;