Treatment of labels and messages

[rabbitholiness]

We have had a couple of discussions about labels and messages in various contexts, mainly sending and receiving. There were questions as to what is visible to whom. The goal of this issue is to summarize the current state and to discuss how we want the Bitcoin Core App to work in the future.

Overview

If they are included in an invoice/payment request, both the label and the message are included in the URI and commonly stored by the spender’s wallet software. But they are never added to the actual transaction, so other Bitcoin users cannot see them.

Receiving:

1. If included in the payment request, the label is added to the URI and the label is visible to the sender.
2. If added to an incoming payment is not visible to the sender and can be used to organize payments/addresses internally. However, it seems that only one label can be added currently, which somewhat limits their usefulness as an organizational feature.
3. Messages can only be added as part of a payment request. They cannot be added to a payment later on.

Sending
Labels that are added to outgoing transactions, they are only visible to the sender.

Wallet support

I tested with a couple of wallets that I had available (BlueWallet,Sparrow, Blockstream Green, Muun, Bitkit, Phoenix and Bitkey). I did not have access to other apps like Ledger Live, Trezor Suite or the BitBox app.

Most wallets support labels, while only few of them support messages. Apart from Bitcoin Core, only Phoenix and Muun display messages. Bitkey and Bitkit displayed neither the label, nor the message.

Implications

Based on the above, there are a couple of implications that we should consider for the Bitcoin Core App:

• It should be indicated to users that if they add labels and/or messages to a payment request, both pieces of information are visible to the sender, if they use a wallet that support them.
• If users want to use labels for organizational/accounting reasons, the should add them after the fact.
• Users need to be aware that the sender might not see the label and/or message, because they might use a wallat that does not support them.

Possible future scope: tags and notes

Thinking beyond current functionality, it could be helpful to create a clear distinction between information that is shared with the sender as part of a payment request and information that is used internally to organize payments, e.g. for accounting reasons or to support coin control.

This could be achieved by introducing tags and notes. Tags are keywords that are defined by the user to group addresses and payments based on criteria that are relevant to them. Tags can also be used as filters on the activity screen. Notes are free form text that can be used to provide more context to an address, payment or contact.

Some wallets already allow creating tags and internal notes (sometimes also called “note to self”). Many banking applications also support such featues.

Tags and notes would need to be stored locally. Ideally, they are auto-saved and backed up each time the wallet detects a new entry or a change of existing ones.

[rabbitholiness]

Does anybody know what the rationale is for adding the address label to the URI, as is currently the case for QT? Why does the sender need to see the label that I give to my address?

Seems to me that, as a receiver, I want to use labels for myself to organize my receiving addresses. If I want to convey some information to the sender, I would add a message to the transaction.

[GBKS]

That is what we need to clarify. With the current logic, I think there are two ways users can use labels, neither of which are great.

1. I use the label to let the sender know my name. The sender can then correctly connect my name with my address in their contacts. Problem is that this label is also connected to my receive address in my app. Result is that all my addresses are labelled with my own name in my app.
2. I use the label to identify the sender. That way I can see which address I used for my transaction partners. But then the sender has their own name connected to my address and the transaction in their app.

The message is very simple, it explains what the transaction is about. That is helpful for both parties. If the label is shared, then it also has to serve both parties, and cannot be used by one party for their own purposes. That leaves us with three options:

1. Change the label info so that it serves both parties well, like including both names "Alice - Bob"
2. Do not share the label, so that the requester can use it for their own purposes. The sender can then add their own label
3. Create another label that is not shared. Rename label 1 to "From" and label 2 to "To". Then share "From" so the sender knows who is making the request, and keep the "To" attached to the receive address/transaction, so the requester knows who they transacted with. This would not need any under-the-hood technical changes.

Does that make sense?

[rabbitholiness]

I would go for options 2 or 3.

What I like about option 3 is that it reinforces the fact that it is a transaction between two people. It also implicitly guides users what they should enter in these fields. The term "label" is quite vague in that regard.

"From" and "To" might be a bit tricky, though. I think they work, but I would use them in the opposite way :-). As a user filling out a payment request I would associate the word "From" with the person who will pay me, and "to" with myself, as I'm the recipient of the payment. So, the basic structure of the form would be: Amount, From (Payer), To (Payee), Message. What about "Payer" and "Requester" (or something like that)? Could help make the roles more clear, but is also more formal.

[BenWestgate]

Is message the field to say what the payment is for? Then a nice default label in my wallet after they pay my payment request is Payer - Message or From Payer, for Message. People are familiar with Cash App adding “For” before a transaction label.

…

On Fri, Jul 19, 2024 at 00:29, Michael Haase ***@***.***(mailto:On Fri, Jul 19, 2024 at 00:29, Michael Haase <<a href=)> wrote: I would go for options 2 or 3. What I like about option 3 is that it reinforces the fact that it is a transaction between two people. It also implicitly guides users what they should enter in these fields. The term "label" is quite vague in that regard. "From" and "To" might be a bit tricky, though. I would use them in the opposite way :-). As a user filling out a payment request I would associate the word "From" with the person who will pay me, and "to" with myself, as I'm the recipient of the payment. What about "Payer" and "Requester" (or something like that)? Would make the roles more clear, I think. So, the basic structure of the form would be: Amount, From (Payer), To (Payee), Message. — Reply to this email directly, [view it on GitHub](#113 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ARQZ6F3RFM4YCAQRDMOCWI3ZNCP3DAVCNFSM6AAAAABLABBJOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZYGIZDSMBSGY). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[GBKS]

"From" and "To" might be a bit tricky

Yeah, that does not work too well... it's helpful to see it mocked up.

How about something like this?

First, I changed the title. The tab is already called "Receive", so having another title that also says "Receive" is not super helpful. "New payment request" is a better description of what the user is doing here.

The main part though are the two fields "Your name" and "Private note".

• "Your name" is what is appended to the BIP21 URI as the "label". The app can remember that across payment requests to the user does not have to type their name every time.
• "Private note" is what is attached to the address (and payment request) that is being generated.

"Your name" then is pre-filled in the senders transaction as the label description for the receive address. So it helps them have nicely labelled addresses.

How does that work for you? Is the usage intent clear?

[stackingsaunter]

If users want to use labels for organizational/accounting reasons, the should add them after the fact.

@rabbitholiness I don't get how did you end up with that conclusion? Why after the fact?

Option 3, treating "label" as a place to put your name seems strange to me. Mostly because I assume other wallets do not treat it like this, so when interacting with other wallets, there may be some confusion and very different usage of this field between different wallet users (confusion can arise then on both ends, Core user and other wallets users). I think no other wallet treats labels/messages like this.

Also, bitcoin wiki advices not to use person identifiers but payment identifiers:

Payment identifiers, not person identifiers
Current best practices are that a unique address should be used for every transaction. Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.

Although at the same time they use Luke Jr name as an example of Label.

For me, option 2 is the best and most simple and rational:

Do not share the label, so that the requester can use it for their own purposes. The sender can then add their own label this option

So we'd keep quite general description of the field "label", which is also what lots of current bitcoin users are used to. I think most users, and this is also confirmed partially in our user research, use it to manage UTXOs and thus identify the source of funds. Label then is not shared, making sure it's a private message for the owner of the wallet.

Only worry for me is for users who might want to have both Label and Message shared with the sender. Eg. Labeling it "Monthly Payment" and then putting invoice number in "Message".

Also I wonder If this won't break a bit how BIP21 is used and eg unified bitcoin QRs

[stackingsaunter]

On further thought, I wouldn't hide label, as I think it can break some UXes around transacting. If we want private note, then that could be additional thing as @GBKS pointed out. After some reading and playing with Core and the fact that Label is then used for "address book" seems like it really works well as "name", although I wonder If we can also accommodate different usage (naming rather transaction, than identifying ourselves):

Otherwise I like Christoph idea to just prefill that with last used Name

[rabbitholiness]

If users want to use labels for organizational/accounting reasons, the should add them after the fact.

@rabbitholiness I don't get how did you end up with that conclusion? Why after the fact?

Because, currently in Core, the label will be shared with the sender, if you include it in the payment request. So if you want to use a label privately for your own reference, then you need to add it after you have shared the payment request. That means if we keep the current behavior, users need to be aware of this. But I don't think this is very intuitive or convenient. That's why I don't think Option 1 is the one to go with.

Option 2 is fine for me as well and will work as expected for users that use, for example, Sparrow or other software. I think we can always fall back on this, if we can't make Option 3 work.

Only worry for me is for users who might want to have both Label and Message shared with the sender. Eg. Labeling it "Monthly Payment" and then putting invoice number in "Message".

This is why I think exploring option 3 is a worthwile exercise. It gives a bit more flexibility to the user. But I see your point that the wording should be consistent with other wallet applications. So keeping "label" or "address label" but not sharing it with the payer makes sense to me.

Something like in the screenshot, maybe? The term "subject" could be interesting, it can be my name or some other identifying piece of information. "Subject" plays well with "message" (like emails have a subject and a message). It also makes it clear that those two pieces of information will be shared with the payer, while the address label will stay private, as a tool for me to manage receiving addresses. The subject could be prefilled on the payer's side as @GBKS describes.

[GBKS]

I don't think we have to maintain the wording used elsewhere if it is confusing. We could always have a small tooltip to indicate how other wallets might use it.

[GBKS]

I updated the design docs for receiving with a note about how we are looking to clarify the use of labels. I think the design intent makes sense and our logic is sound, even if we tweak the actual label text a bit further.

[stackingsaunter]

Here's a table of current proposals by @rabbitholiness