Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOLT 11: add optional vendor field. #694

Open
wants to merge 1 commit into
base: master
from

Conversation

@rustyrussell
Copy link
Collaborator

rustyrussell commented Nov 5, 2019

It was pointed out to me at thelightningconference.com that it's often
a legal requirement to list the vendor on a receipt. It also makes
perfect sense.

It can be done in the description field, but that's really supposed to
be a description of the items. Dividing it also lets wallets have
much better UX.

Signed-off-by: Rusty Russell rusty@rustcorp.com.au

It was pointed out to me at thelightningconference.com that it's often
a legal requirement to list the vendor on a receipt.  It also makes
perfect sense.

It can be done in the description field, but that's really supposed to
be a description of the *items*.  Dividing it also lets wallets have
much better UX.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@yaslama

This comment has been minimized.

Copy link

yaslama commented Nov 5, 2019

@rustyrussell What do you think about adding a field containing data in an already standardized format like https://en.wikipedia.org/wiki/EDIFACT or https://en.wikipedia.org/wiki/Universal_Business_Language?
I feel that we are reinventing the wheel.

@BitcoinErrorLog

This comment has been minimized.

Copy link

BitcoinErrorLog commented Nov 5, 2019

Bitefill CFO says a vendor field would be very useful :)

@shesek

This comment has been minimized.

Copy link

shesek commented Nov 5, 2019

Isn't there a risk that showing an unauthenticated vendor name could give users the wrong impression that the vendor name is somehow verified?

If the vendor name is added as part of the description then its pretty clear that its just some free text added by the invoicer, but a special UI element showing the vendor name separately might make it appear like it is somehow verified, which could potentially be abused by scammers.

Edit: Regarding the legal aspect,

It was pointed out to me at thelightningconference.com that it's often a legal requirement to list the vendor on a receipt.

Wouldn't vendors typically also issue a standard tax receipt/invoice, in addition to the lightning invoice? Wouldn't it be legally sufficient to list the vendor name on the regular receipt (which can be sent as pdf over email, shown on a website, etc), without being listed on the lightning receipt too?

This is what we do with bitcoin invoices (aka addresses) today [0], there's no place for a vendor name or even a description field, which I think is probably not legally problematic? (edit: well, BIP21 does have labels actually, but bare bitcoin addresses are still very common and probably legally okay)

And like you mentioned, even if this is legally required as part of the lightning invoice itself, it should be sufficient to put it in the description. So its really more a matter of UI/UX than a legal one.

[0] ignoring the broken BIP70 which should just die already

@renepickhardt

This comment has been minimized.

Copy link
Contributor

renepickhardt commented Nov 5, 2019

To me it feels like this is a half baked solution. either go with a standard - like @yaslama suggested - in the invoice because you expect that lightning invoices will replace regular invoices or keep it the way it is. I would suggest to go the full path instead of just adding one field.

@hsjoberg

This comment has been minimized.

Copy link

hsjoberg commented Nov 5, 2019

@rustyrussell I do fully agree that we should have a field that is the name of the recipient, I am not sure about the field name vendor though, as the payment could be from person to person as well.

It can be done in the description field, but that's really supposed to
be a description of the items. Dividing it also lets wallets have
much better UX.

Yes, I have been working on a simple protocol for doing this in the description field, but separating them is a much better approach.

Isn't there a risk that showing an unauthenticated vendor name could give users the wrong impression that the vendor name is somehow verified?

@shesek This risk exists, the wallet should probably check if the name has already been used by another pubkey.

Wouldn't vendors typically also issue a standard tax receipt/invoice, in addition to the lightning invoice? Wouldn't it be legally sufficient to list the vendor name on the regular receipt (which can be sent as pdf over email, shown on a website, etc), without being listed on the lightning receipt too?

This is off-channel though and (from a UX standpoint) doesn't reflect nor improve the transaction log inside the wallet. I think it makes sense to improve and integrate information to the actual wallet as this essentially makes lightning network wallets more intuitive than using the current banking system.

In the future, perhaps even the receipt could be integrated to the wallet.

@BitcoinErrorLog

This comment has been minimized.

Copy link

BitcoinErrorLog commented Nov 5, 2019

Further comments from our team, mirror Rene's sentiments:

"Receipts usually have very complex data structures, basically everything an invoice of ours has, not just the vendor name. "
"If the goal is to fulfill all receipt needs then there’s a lot more that needs to be done, such as one line for each item in the basket, terms and conditions, etc. Queue the CVS long receipts meme."

The scope starts blowing out to a full accounting solution... but generally some threshold of comprehensiveness may need to be achieved to provide utility.

@hsjoberg

This comment has been minimized.

Copy link

hsjoberg commented Nov 5, 2019

I think the scope is very clear. Add a recipient field for BOLT11-invoices. An receipt protocol could be worked on later on, separately.

EDIT: To clarify, I do not think that this PR satisfies legal requirements of a receipt. I am mainly positive for this new field as a UX/UI improvement.

@esneider

This comment has been minimized.

Copy link
Contributor

esneider commented Nov 5, 2019

This would be very useful for wallet implementors to do things like this: https://twitter.com/MuunWallet/status/1186738141731983361

While doing research for this feature we found that there are many nodes being used for multiple lapps each, so this would be really useful, as we can't determine the lapp from just its node public key.

We should be careful as to how this field is used in applications though, since vendor impersonation is a real possibility, as @shesek points out.

@rustyrussell

This comment has been minimized.

Copy link
Collaborator Author

rustyrussell commented Nov 6, 2019

EDIT: To clarify, I do not think that this PR satisfies legal requirements of a receipt. I am mainly positive for this new field as a UX/UI improvement.

Well, it does in Australia (technically, a "proof of purchase", see https://www.business.gov.au/finance/payments-and-invoicing/receipts-and-proof-of-purchase).

While you can claim to be anyone, you can also claim that in the description, so I don't think this is much of an issue.

@Alex-CodeLab

This comment has been minimized.

Copy link

Alex-CodeLab commented Nov 6, 2019

@yaslama I've worked with EDIFACT for years, and all companies that use it implement their own version. It is a standard, but not a protocol, so there are many, many variations. (For example, think about how many address+zipcode variations there are and how they are different per country.)

A far easier solution would be that all this is handled on the wallet level: wallet creators could design their invoice document any way they want (with vendorname, address, goodslines, etc), and add a hash that matches a hash on the lightning invoice.

@fiatjaf

This comment has been minimized.

Copy link

fiatjaf commented Nov 6, 2019

In my opinion the protocol should be left as open and as generic as possible, without trying to include every possible current vendor requirement. We don't know what people may be using Lightning for in the future, and including a lot of fields with a very limited use-case creates complexity for all others.

Also, it's not as if big and law-abiding vendors are using Lightning today, anyway, and what if the law changes? What if the law requires other types of fields in other countries?

In Brazil, for example, a "valid receipt" must include numbers from our national IRS and many other quibbles. What happens is that small merchants don't give one unless explicitly requested and after a long waiting time, big merchants who have automated systems for everything do give, but still it's a separate receipt than the one provided by credit card machines and so on. As @shesek said.

@yaslama

This comment has been minimized.

Copy link

yaslama commented Nov 6, 2019

A far easier solution would be that all this is handled on the wallet level: wallet creators could design their invoice document any way they want (with vendorname, address, goodslines, etc), and add a hash that matches a hash on the lightning invoice.

But in this case, the ln invoice is not self-contained. This is the reason I proposed to add a field with an "opaque" blob which is supposed to follow a recognized and used standard, and each wallet will handle the content of this blob depending on the situation/country etc..

@esneider

This comment has been minimized.

Copy link
Contributor

esneider commented Nov 6, 2019

While using some comprehensive standard like UBL would be great for the application/wallet layer, I think the length of the invoice should also be taken into account. Invoices are already pretty long, which causes QR codes to be super dense.

Older phones have difficulties scanning these codes, due to having cameras with low(er) resolutions. It was common in the lightning conference to see people try to scan lightning invoices 4/5 times until the QRs were recognized.

It’d be great to keep the standard usable for non-last-gen phones.

@nayuta-ueno

This comment has been minimized.

Copy link
Contributor

nayuta-ueno commented Nov 7, 2019

If there is a vendor field in an invoice text, I would like to display vendor information (URL, icon, etc.) without decoding the vendor field.

@yaslama

This comment has been minimized.

Copy link

yaslama commented Nov 7, 2019

While using some comprehensive standard like UBL would be great for the application/wallet layer, I think the length of the invoice should also be taken into account. Invoices are already pretty long, which causes QR codes to be super dense.

Older phones have difficulties scanning these codes, due to having cameras with low(er) resolutions. It was common in the lightning conference to see people try to scan lightning invoices 4/5 times until the QRs were recognized.

It’d be great to keep the standard usable for non-last-gen phones.

A point is made here. But if/when BOLT 12 is implemented, the invoice will be retrieved using LN and only the "offer" will be QR encoded. And the offer is a lot shorter than the invoice.
cf https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002276.html about BOLT 12

@esneider

This comment has been minimized.

Copy link
Contributor

esneider commented Nov 8, 2019

A point is made here. But if/when BOLT 12 is implemented, the invoice will be retrieved using LN and only the "offer" will be QR encoded. And the offer is a lot shorter than the invoice.
cf https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002276.html about BOLT 12

Wouldn't we want to include the vendor info directly in the "offer" though?

  • As I user, knowing who I'm paying to is a key piece of information when deciding whether I want to share my address/phone number.
  • As a wallet, I want to be able to render the payment info before having to retrieve the final invoice, to avoid delays due to unreliable nodes in the communication path to the destination node.
  • A nice side effect of including the vendor in the offer is that it encodes the fact that the vendor cannot change for recurring payments, which would be pretty unintuitive for the user.

Finally, notice that lno... URIs aren't that much shorter than ln... URIs, and in fact might end up being longer.

@Alex-CodeLab

This comment has been minimized.

Copy link

Alex-CodeLab commented Nov 8, 2019

@esneider

  • As I user, knowing who I'm paying to is a key piece of information when deciding whether I want to share my address/phone number.

as @shesek pointed out, vendor names should not be trusted and are not unique identifiers. Keys and URI are used for authentication.

Wouldn't we want to include the vendor info directly in the "offer" though?

Would that mean broadcasting name/address info ?


I think this is all going in the wrong direction. It started with just the vendor name, but now it becomes some business application with (purchase) orders, crm, accounting, etc..
Once we go down that route, the options and requirements will be endless. I can guarantee it won't end with just adding a few fields.
(Trying to build SAP into LN is not the way to go.)

Imho, all personal details should be kept out of the LN network. It would be a goldmine for data-collection and surveillance.
While one group of developers is working on privacy, others are talking about adding address and phonenumbers, (tax-ID)... wth is going on??

@hsjoberg

This comment has been minimized.

Copy link

hsjoberg commented Nov 8, 2019

Wouldn't we want to include the vendor info directly in the "offer" though?

@esneider I don't see the harm of adding a optional field that will probably be around 10 characters or less. It will have a minimal effect on the invoice text length, while greatly improving UX.

Once we go down that route, the options and requirements will be endless. I can guarantee it won't end with just adding a few fields.

@Alex-CodeLab The PR is talking about an optional vendor field, not anything else.

Imho, all personal details should be kept out of the LN network. It would be a goldmine for data-collection and surveillance.
While one group of developers is working on privacy, others are talking about adding address and phonenumbers... wth is going on??

How would the data collection be done? The QR code is hopefully displayed on an HTTPS-secured site, only visible for the actual user buying something.

Adding phone numbers, address etc for a presumably known party, like an e-shop, does nothing to harm privacy.

If Lightning Network is supposed to be used for every day transactions. I don't understand why we wouldn't want to include common data that most payments would benefit on having.

@tkijewski

This comment has been minimized.

Copy link

tkijewski commented Nov 8, 2019

This addition to the spec seems out of place. Protocol layers are supposed to be as application agnostic as possible. This is an addition for a specific application: b2c payments. It is completely irrelevant for p2p payments.

Looking at the existing Tagged Fields, Optional name of vendor/supplier (UTF-8). really does not fit in

@Alex-CodeLab

This comment has been minimized.

Copy link

Alex-CodeLab commented Nov 8, 2019

@rustyrussell
What is the problem you're trying to solve here?

Some mention UX, others are talking about legal requirements, others about business requirements. So we're all talking about something else. I think a clear problem-statement would improve this conversation.

@hsjoberg

This comment has been minimized.

Copy link

hsjoberg commented Nov 8, 2019

This addition to the spec seems out of place. Protocol layers are supposed to be as application agnostic as possible. This is an addition for a specific application: b2c payments. It is completely irrelevant for p2p payments.

I suggested to change the name of the field to something more general than vendor, perhaps recipient.

It is very relevant to P2P payments, otherwise you cannot see very easily to whom you sent money to.

Looking at the existing Tagged Fields, Optional name of vendor/supplier (UTF-8). really does not fit in

It fits very well with the Description tag d.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.