Re: [Lightning-dev] Mandatory "d" or "h" UX issues
What about this? https://github.com/btcontract/lnurl-rfc/blob/master/spec.md#2-withdrawing-funds-from-a-service On Monday, January 21, 2019, Rusty Russell wrote: > Francis Pouliot writes: >> 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. > > Yes, there's a missing "give me an invoice" API for this kind of push > payment. yalls.org has the same problem: there's a clumsy API where you > give them an invoice and it pays it if you have that much. > > lninv: URL? Description, min and max amounts, submission URL? Ideally > the browser would reach out to the wallet to get an invoice and do the > submission itself (preserving sessions, cookies, etc) but I'm not sure > how that part of the stack works? > > There was talk of something similar in Adelaide, but I hadn't > appreciated the concrete problem at the time :( > > Cheers, > Rusty. > ___ > 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
Re: [Lightning-dev] Mandatory "d" or "h" UX issues
Francis Pouliot writes: > 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. Yes, there's a missing "give me an invoice" API for this kind of push payment. yalls.org has the same problem: there's a clumsy API where you give them an invoice and it pays it if you have that much. lninv: URL? Description, min and max amounts, submission URL? Ideally the browser would reach out to the wallet to get an invoice and do the submission itself (preserving sessions, cookies, etc) but I'm not sure how that part of the stack works? There was talk of something similar in Adelaide, but I hadn't appreciated the concrete problem at the time :( Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Mandatory "d" or "h" UX issues
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, 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 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
Re: [Lightning-dev] Mandatory "d" or "h" UX issues
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 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
