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, <laol...@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 <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 >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev