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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
