Adds new page about human readable addresses #1082
Conversation
This is something we've discussed for a few weeks in the UX channel in Discord and turns the findings into a page. I think there's more work to do in cross-linking this from all the right places. I updated a few spots, but there's probably more. The UI mock-ups are more directional than implementation-ready, which I think is fine. But we could flesh this out further in a revision at a later point.
GBKS
added
Copy
✅ Deploy Preview for bitcoin-design-site ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hi, Chris! Looks great so far, but I have a few issues:
|
Co-authored-by: Johns Beharry <johns@peakshift.com>
|
Thank you for the super-fast feedback.
Thanks for pointing that out. I just pushed a commit updating the sample domains. I had checked whether there are official .btc domains, but was not aware of this "other" use.
There was a lot of discussion around the Also, did you just mention using a sat symbol? 😉
True, it is pretty dismissive. But PayNyms is basically a single database, while the other proposals do their best to decentralize, but are bound by the "basic infrastructure of the internet". Ver different ends of the spectrum to me. But if it is too dismissive, then it should be revised.
Agree, this needs more fleshing out. I mention in the page that the UI mocks are conceptual, and I'd like to take more time to discuss and sort this out. I still have some open questions, but also wanted to get this page out. How do you think this will play out? Dedicated bitcoin address services like we have in Nostr for NIP-05 identifiers? Thanks again for the feedback. |
|
With Paynyms, I'm a bit too ignorant, but I'm skeptical they are any more centralized than DNS. All namespaces require an authoritative list to exist somewhere. And anyone can host a new list, or query any existing list they want to. Centralized/decentralized isn't really the correct paradigm for namespaces. Regarding how I think this will all play out, well, I think it is all moot tbh, and that such things are a fad born of ignorance. No one needs nicknames at a protocol level, they are app-level concerns and thus should be rendered in contact list UX. Domain names are a scam, and thus pay-names follow in kind. This is my, likely unpopular, opinion, so it could also be wrong :) Think of DNS more like a list of phone numbers. I can either make a list myself, or trust someone else to provide a list (like a phone book/directory), but the difference is all about there being a trusted authority, thus solutions that do not require such an authority are more interesting, or, solutions that aggregate many lists, etc. If a user wants to pay "Mom" they should be able to just tap on Mom's face, not type in her fake email address into some novel UX. |
|
I don't see the value in using the B symbol (which I frankly don't even know how to make with my keyboard). Can somebody educate me on the dangers of mixing up an email address and a bitcoin payment identifier? |
Co-authored-by: Johns Beharry <johns@peakshift.com>
Co-authored-by: Johns Beharry <johns@peakshift.com>
To be clear, the keyboard issue shouldn't be an issue - it should be displayed and in a copy (if wallets allow copying the human-readable names directly, though generally they should prefer to copy the underlying payment instructions for noncustodial wallets), but users shouldn't need to type it. The reason its there is because payment instructions are a different namespace from email. We've already seen at least one case where a company uses their domain for emails and also to provide users with lnaddresses, with someone having the lnaddress who doesn't work for the company and doesn't have the corresponding email. @moneyball thought we should have some suggestions to cache name -> (reusable) payment instructions mappings. Sadly, in some protocols (at least DNS) we have pretty tight timeouts for the data itself (eg the domain might expire tomorrow!), so it'd need to be a cache with a notice on changes rather than not doing further lookups. Can happen separately, but something to think about. |
|
The "B" symbol is a recipe for frustration, and setting up normies for failure.
Why limit the design space of what users can, and can't do?
That's fine - add some other way instead of an impossible to type "B" symbol. There's "human readable", and there should be, in my view, "human typable". These are the most basic human machine interface requirements. Normies will not memorize the special character shortcut for "B". We don't have "B" on keyboards today. Really, anything else on the keyboard, or perhaps even on the more difficult to access emoji keyboard reduces user friction. The designers I'm sure can come up with something better. Examples: BTC.name@domain |
To keep things a bit orderly, I'd like to ask for criticism of the proposal to be posted on the original proposal pull request. This new page in the guide is a reflection of the logic in that proposal. I'll also add this note to the PR description. Proposal criticism is not really something that can be resolved in comments here.
Totally. The page mentions "read, memorize, pronounce, understand, and type". |
- Added note about the DNS proposal still being in discussion - Updated general how it works image to use [prefix] instead of ₿ - Added note about PayNym directory not being open-source, and removed note about not using it due to centralization (should be clear from reading the text whether to use it or not)
There was a problem hiding this comment.
IMHO, this is a little creepy looking. The smile is too happy and the art style is very "uncanny valley". Maybe a different art style for this Jordan character?
|
|
||
| Every approach requires at least one intermediary that is being contacted to serve the payment information. | ||
|
|
||
| This brings up important questions around privacy and security. Intermediaries can potentially serve up different payment information than a user specified. Or they can track requests and metadata to build profiles of users and user behavior. If these intermediate hops are not fully controlled by the user, the address should be considered custodial (or at least semi-custodial). |
There was a problem hiding this comment.
If these intermediate hops are not fully controlled by the user, the address should be considered custodial (or at least semi-custodial).
I agree with this sentiment. However, it doesn't always mean custodial. In this case, I interpret custodial to mean that someone can take or spend funds without the user's consent. In the case of an LNURL server, this is custodial. In the case of DNS payment instructions, I don't think it's custodial, but there are other concerns: availability (will it always be online serving my payment instructions) and will they change the payment instructions on me (but that's not the same as custody to me).
Maybe I am nitting this too much?
There was a problem hiding this comment.
Maybe the problem is that we are so used to the term "custodial" being used for the funds themselves - who controls the key - and now we use it for addresses with very different context. Not sure how to resolve this other than using a different term. What do you think?
Generally, I find the paragraph clear as a whole, even if the specific term could be off.
|
|
||
| ### How it works | ||
|
|
||
| Users create DNS entries with payment information, which can be one or more addresses of different formats, combined to a [BIP 21 URIs](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki). Since address reuse is best avoided for privacy reasons, the included addresses should only be static payment codes (like [silent payment codes](https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8) and [BOLT12](https://bolt12.org/) offers). |
There was a problem hiding this comment.
Also, RE included addresses should only be BOLT12 and paynyms -- I think one draft of the spec I saw talks about putting onchain addresses, and how you can essentially refresh DNS records with new on-chain addresses to prevent re-use....but I agree, in general, its not the best use-case.
This is more of "well ackshyually" than an actionable comment
There was a problem hiding this comment.
I think I read that, and then someone else said that DNS propagation is not speedy and trustworthy enough to make it super reliable. No particular thoughts on this, other than recommending to stick with BOLT12 and silent payments.
🤷
|
|
||
| #### Setup | ||
|
|
||
| Hosting human-readable addresses carries legal and financial responsibility, so many non-custodial wallets are unlikely to offer this feature. However, they should still make it easy to copy payment information for setting up addresses on domains owned by the user or a third party of their choice. |
There was a problem hiding this comment.
Hosting human-readable addresses carries legal and financial responsibility...
I'm not a lawyer, but it seems to me that putting a BOLT 12 offer in an DNS record is just publishing a piece of information; the service placing the info in the DNS record does not have to be involved in any way with the actual payment.
Is there a discussion about the legality of this happening somewhere that I can find?
There was a problem hiding this comment.
I was thinking more about the service needing to run servers and databases to handle the user data, probably some form of login, etc. Not like Bitcoin Core, for example, where it's a standalone piece of software you run locally and don't get any other service. So the wallet provider would need to be a company and everything that comes with it. Does that make sense?
There was a problem hiding this comment.
Sure, it's something we consider are considering with TwelveCash (how do we best handle users editing data). However, I disagree with the statement "so many non-custodial wallets are unlikely to offer this feature".
You can facilitate pushing the user's offer to your DNS records without taking custody of the user's funds. That aspect is pretty trivial. In fact, it's arguable that many non-custodial wallets would want to use this as a selling point (that you can have a cool username and be self-custodial).
There was a problem hiding this comment.
So the wallet provider would need to be a company and everything that comes with it.
Being a company does not equal being custodial
There was a problem hiding this comment.
I am not thinking of custody of funds, just custody of the address.
Let's imagine you create your address with some anon service online. After an initial period where everything works well, they start occasionally swapping out your actual payment info with someone else's. Or maybe they sell the domain or service to someone else, who starts messing things up. Or maybe they beef up prices and threaten to just relay your payment info to your own if you don't pay up. Or they get hacked and someone replaces the info right before your monthly paycheck comes in and you don't find out until later. If the service simply stops working and addresses break, then it's not so bad. But other scenarios could also happen.
So I think there is a responsibility that comes with owning the relay of this one piece of information to another piece of information. This is not the case when you share your BOLT12 or silent payments addresses directly. Would Sparrow Wallet or a similar project want this responsibility? Without being a company and having the required legal protection?
In the progressive security sense, there are maybe two realities. In a "Nostr zap via Lightning Address" world of tiny payments and small amounts, maybe it's fine to just be more relaxed. But with meaningful funds and use, then it's a different story. Mo' money, mo' security, if you will.
There was a problem hiding this comment.
Also, TwelveCash looks cool.
There was a problem hiding this comment.
I love the way this is designed but I don't know that I agree with the actual content of the screens. Let me be specific:
Self-controlled domain
IMHO, this is not really tenable for a mobile app...or at least, maybe not as simply as defined in this screen. The DNS pay instruction spec requires the use of DNSSEC for signing the records. Not every DNS provider supports DNSSEC at the moment. So worst case scenario, we assume the user probably doesn't even use a DNS provider that uses DNSSEC.
BUT...you could also imagine that the "set up your domain" screen points this out. "step 1, you need to make sure you have DNSSEC turned on for your domain, step 2 you need to add this TXT record".
Keep these in mind
Bad idea: Post your address publicly online
Really? What's the actual point of this then?
Look, I get it, there's a privacy concern that you are tying a piece of bitcoin payment instruction to an identity. But simply not sharing the payment address isn't some kind of privacy guarantee. Even if you only share your payment identifier with people you know IRL, they could still share the information and it could leak out online. Once christoph@gbks.com has leaked onto the internet, that's it. Furthermore, somebody could write a Python script that does DNS lookups for {{insert_name_here}}.user._bitcoin-payment.{{insert-domain-here.com}} and just feed it an array of names and an array of domains.
If we're so concerned about privacy that you shouldn't share this online, then IMHO, it's not even a useful UX feature to begin with.
Having said all that...I believe the ultimate goal of this is that BOLT 12 offers use route blinding. This means we can cram an offer with several candidates for blinded paths inside an offer, then cram that offer in a DNS record. Meaning that even if I were to scrape your offer from a DNS record, I still don't know the pubkey of your node. I can make a payment without even knowing the sender.
tl;dr - there is no guarantee of privacy even if you don't share it online, it's not a super useful UX feature if you have to keep it that private, and route blinding fixes this™️
There was a problem hiding this comment.
Thanks for taking a close look at those. There's a separate issue for revising these setup screens here, since the ones in this PR are more conceptual, as the text indicates. I kept them conceptual, because it was just too much to handle in one PR and I just needed a bit more time and brain focus to push them further. Your feedback will definitely flow into that iteration, but I'd like prefer not to address them right here in this PR if that's OK.
I don't understand your second rationale. Just because someone else could leak my information or somehow find it by brute-force scraping guessing, does not mean I should not be careful about what I post publicly. Privacy practices are often about reducing the chance that others see something.
There was a problem hiding this comment.
While I personally like the idea of just hanging on to the offer, this seems to contradict this text from the BIP.
While clients MAY cache the payment instructions they receive from the DNS, clients MUST NOT cache the payment instructions received from the DNS for longer than the TTL provided by their DNS resolver, and further MUST NOT cache the payment instructions for longer than the lowest initial TTL (which is signed as a part of DNSSEC signatures) received in the full DNSSEC chain leading from the DNS root to the resolved TXT record.
So on a technical level, the client (wallet) can't cache the pay instructions for longer than the TTL. So it means it needs to recheck if the TTL is elapsed. In practice, I don't think you'd actually have the client re-checking every single person in the contact list everyday, just re-checking at time of payment.
Furthermore, I'm not sure how actionable it is -- you hit view changes, and then it shows you that it changed from one nasty looking lnobc1.... string to another nasty lnobc1... string.
Is this going to notify me every single time the DNS record changes? Or just when I try to pay Priya Lee and it has changed since last time?
Overall, I don't fully disagree with the "Update Contact" button, I just think the usage diverges from how it's phrased in the BIP.
When I see "Update Contact", that user story is that Stephen wants to pay Priya, so he types in her address and his wallet stores the offer, and then he pays the offer. But the BIP user story is more like, Stephen wants to pay Priya, so he types in her address and the wallet checks to figure out how to pay her, and whatever the wallet gets in response from the DNS servers we can reasonably trust because it has been signed by DNSSEC and if DNSSEC is broken then the internet is broken.
There was a problem hiding this comment.
Good points, will update.
Furthermore, I'm not sure how actionable it is -- you hit view changes, and then it shows you that it changed from one nasty looking lnobc1.... string to another nasty lnobc1... string.
Just knowing that something unexpectedly changed can be helpful, even if you can't interpret the change instantly and need to dig a little.
|
Adding in some birds eye view ideas as well. More on the overarching structure of the content, less about the copy itself. Reading through the content it forms 4 larger chunks:
|
Co-authored-by: Stephen DeLorme <stephen@d.elor.me>
This is something we've discussed for a few weeks in the this issue and the UX channel in Discord and turns the findings into a page.
Primary focus of the page is on the DNS-based payment information proposal, with an additional paragraph about Lightning Address and a small note about PayNyms.
The UI mock-ups are more directional than implementation-ready, which I think is fine. But we could flesh this out further in a revision at a later point.
I think there's more work to do in cross-linking this from all the right places. I updated a few spots, but there's probably more. The page is at a point where more review and public feedback would be helpful in identifying missing and incorrect bits.
If you have criticism of the DNS-based payment information proposal, please post it in that PR, and not here. This page is a reflection of the logic described in that PR.
🧐Check the preview🧐