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 <fran...@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 > Lightningfirstname.lastname@example.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev