[Lightning-dev] Mandatory "d" or "h" UX issues

[Félix-Antoine Paradis]

Francis

I have seen you ask around for this. c or h are mandatory on a protocol
level but I would never enforce business decisions based on their content.

The same way as you would not ask a customer to plainly add his customer
number in a Bitcoin transaction... Instead, you give him a unique address
and base you decisions on this.

Once you know the amount you are going to owe to this customer, ask for the
payment_req and decode it to be sure it matches the amount owing. You can
lookup c or h and store it but I would never parse that.

Let me know if you come to Quebec city, we can have a lightning talk ;)

On Mon., Jan. 14, 2019, 19:08 Olaoluwa Osuntokun, <laolu32 at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/20190115/9038b978/attachment.html>