📅 Original date posted:2019-01-14
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190114/09200bcf/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:53:57
in reply to nevent1q…8fex
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:53:57Event JSON
{
"id": "5b7d5876fddfcfbcf706ffe8c1f8bdc3c022ce1e211971d4af34abb1b3b988cb",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315237,
"kind": 1,
"tags": [
[
"e",
"519a7a8c86eac72a23dc644543eb562443536845963ecffa2a6e73592013b70b",
"",
"root"
],
[
"e",
"0325b024a95af576b9ce731a0ee4b2bf9fe1d42a51750a39abb65d3d95d5d939",
"",
"reply"
],
[
"p",
"fdda698ac52e9604f8416b2efb416dd6260a547f5127f90449a51a7d0fa26937"
]
],
"content": "📅 Original date posted:2019-01-14\n📝 Original message:\nIt isn't mandatory. It can be left blank, none of the existing wallets\nrequire users to input a description when they make an invoice.\n\nOn Mon, Jan 14, 2019, 3:28 PM Francis Pouliot \u003cfrancis at satoshiportal.com\nwrote:\n\n\u003e I'm currently in the process of building the Lightning Network payout\n\u003e feature which will allow users to purchase bitcoins with fiat and have the\n\u003e coins sent to the via LN rather than on-chain. The main issue I'm facing is\n\u003e ensuring that recipients generate the correct Bolt11 invoice.\n\u003e\n\u003e Having the \"d\" and \"h\" fields mandatory creates a UX issue for Bitcoin\n\u003e services that are performing payouts/withdrawals (in the absence of a\n\u003e widely adopted payment protocol).\n\u003e\n\u003e It seems to me that the design of Bolt11 may have been biased towards\n\u003e merchants, because normally merchants, as recipients, decide on what the\n\u003e invoice is going to be and the sender doesn't have a choice but to conform\n\u003e (since the recipient is the service provider).\n\u003e\n\u003e But for LN payouts (e.g. withdrawal from an exchange or a poker site), the\n\u003e Sender is the services provider, and it is the Sender who will be creating\n\u003e (most likely programatically) the terms of the payment. However, this means\n\u003e that the Sender must be able to communicate to his end-user exactly what\n\u003e type of Bolt11 invoice he wants the user to create. This means, in most\n\u003e cases, that the user will have to manually enter some fields in his wallet.\n\u003e And if the content doesnt match, there will be a payment failure.\n\u003e\n\u003e Here is how I picture the ux issues taking place.\n\u003e\n\u003e 1. User goes on my app to buy Bitcoin with fiat, and opts to be paid\n\u003e out via LN rather than on-chain BTC.\n\u003e 2. My app will tell him: \"make an invoice with the following:\n\u003e msatoshi, description.\n\u003e 3. He will go in his wallet and type msatoshi, description.\n\u003e 4. It's likey he won't pay too much attention, make a typo in\n\u003e description, leave it blank, write his own description, etc.\n\u003e 5. When my app tries to pay, we of course have to decode his bolt11\n\u003e first.\n\u003e 6. We have to have some logic that will compare the \"h\" or \"d\" that we\n\u003e instructed him to create and the \"h\" or \"d\" that we got from the decoded\n\u003e bolt 11 (which is an extra hassle for devs)\n\u003e 7. In the cases there they are not the same, we need to instruct the\n\u003e user to create a new bolt 11 invoice because the one he created was not\n\u003e correct.\n\u003e\n\u003e What this ends up doing is create a situation where the service provider\n\u003e depends on his user to create a correct invoice before sending him the\n\u003e funds, and creates an added (unecessary) requirement for communication, and\n\u003e lower payment success rates, and likely higher abandonment rate.\n\u003e\n\u003e Question: what is the logic behind making \"d\" and \"h\" mandatory? I think\n\u003e business logic should be left to Bitcoin businesses.\n\u003e\n\u003e Can we simply not make \"d\" or \"h\" mandatory without breaking anything?\n\u003e\n\u003e TL;DR users already have troube entering the correct amount of BTC when\n\u003e paying invoices that aren't BIP21, so I am afraid that there will be tons\n\u003e of issues with them writing down the correct description.\n\u003e\n\u003e P.s. I'm using c-lightning right now and would like to not have to switch\n\u003e\n\u003e P.s.s. this will likely be fixed with a standardised payment protocol but\n\u003e addressing this issue seems a lower hanging fruit.\n\u003e\n\u003e Issue: https://github.com/lightningnetwork/lightning-rfc/issues/541\n\u003e\n\u003e Thanks is for your time,\n\u003e\n\u003e Francis\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190114/09200bcf/attachment-0001.html\u003e",
"sig": "2a0eb2849d3f80adf5774f47c842a827b181ce0a33f61e5b8ff4cc909898f18bb3dcf9f9246fffc10d095b2fab03330f9ea4e1797fe8590b3260f26be06e533f"
}