related posts
155 sats \ 3 replies \ @0368d36190 20 Feb
I think I saw a comment to this proposal somewhere to use /.well-known instead of dns and tend to agree to it. just looking at the list of use cases here just looking at this list of use cases here https://en.wikipedia.org/wiki/Well-known_URI there are similarities all over - keys, identifiers, etc
The overhead and friction that comes with managing dns records as well as retrieving information from it in your typical app is not to be underestimated, it's one thing in system requirements to ask to configure and launch and run a software, but to require domain name, to talk to some providers is somewhat different.
p.s. I should read more about lnurl and bolt12 and issues that remain there that this proposal addresses, it may become more evident, why it's better.
Good job by Matt, ever enthusiastic to improve bitcoin!
reply
100 sats \ 2 replies \ @bluematt 24 Feb
You may be interested in reading the BIP draft at https://github.com/bitcoin/bips/pull/1551 specifically the section which lists the drawbacks for HTTP-based solutions. Further, note that a large custodial provider wishing to accept payments for many users only needs a single (wildcard) entry in the lightning case, so it shouldn’t be too hard to handle :)
reply
0 sats \ 1 reply \ @0368d36190 25 Feb
Thanks Matt! I've read BIP along with comments in github issue. You're very concise about HTTP drawbacks in there - a, b, c. , you don't have to expand on that a lot in DNS-focused spec obviously..
I just recall from my working experience dns is typically far away from what application has to deal with and would like to have dependency on
To make changes. I need to go to another team in the company, engage external service provider if it's smb - this is a friction I was talking about.
To top this with all the memes that often go around tech industry- "it's always DNS to blame"
I wonder if bitcoin payment scenario is close to OpenID, e.g. how keys are distributed for instance here https://accounts.google.com/.well-known/openid-configuration and what this protocol does in terms of authentication, signing access tokens, etc
There are many software libraries for interoperability.
it's still plagued by token theft, but smart guys in IETF and OASIS couldn't come with anything better over the years.
I am sure there are benefits to DNS, wildcard sounds easy !
reply
0 sats \ 0 replies \ @bluematt 27 Feb
I would definitely agree with your point here, if it weren't for the wildcard option. While I think its a sad state of affairs that most devs don't know anything about how the DNS works (which is sad cause its wayyyy more simple than HTTP(s)), I agree that its often the case. That's the reason for the wildcard option! With it, large custodial services don't need to know much about DNS, they can add one wildcard record and handle the rest at the app layer. Anyone running a solo name resolver can similarly just add one record, so its all pretty easy.
I assume you saw what a, b, and c referred to :) They're pretty important properties.
reply
101 sats \ 0 replies \ @ca98am79 26 Feb
DNS is a security risk. Centralized, many people have access to your domain. That's why we made the Spaces Protocol (built on Bitcoin): https://spacesprotocol.org/
reply
0 sats \ 0 replies \ @stargut 21 Feb
doesnt a vpn hide your ip address from the receiver?
reply
0 sats \ 6 replies \ @nerd2ninja 20 Feb
First impression: Unless it is expected that the user hosts their own DNS server, this is a stupid stupid idea.
Okay so this is because of Bolt12 offers which at least makes it much more sane than what I thought it was. What was not presented, was how a user was supposed to create this DNS record without running their own DNS. Seems worth at least exploring.
reply
24 sats \ 5 replies \ @TonyGiorgio 20 Feb
It's strictly better in every way compared to the solution it is meant to replace, which is LNURL addresses.
reply
0 sats \ 2 replies \ @nerd2ninja 20 Feb
No wait, this is a stupid idea lmao. Bolt12 can replace LNURL addresses all on its own. Not having a reusable address was what LNURL was all about creating a bandaid for, so what is all of this for?
reply
0 sats \ 1 reply \ @TonyGiorgio 20 Feb
Human readability.
reply
0 sats \ 0 replies \ @nerd2ninja 20 Feb freebie
Bah humbug. Make an in wallet contact list like how we did with phone numbers.
0 sats \ 1 reply \ @nerd2ninja 20 Feb
Yeah you're just commenting on my first impression. A lot of assumptions in my first impression that didn't turn out to be the case.
reply
0 sats \ 0 replies \ @nerd2ninja 20 Feb
So first impression was the idea, edit was about it being used for Bolt12. To specify this is a dumb idea to apply to on-chain addresses.
Reading the BIP now:
"Thus, using TXT records to store Bitcoin payment instructions allows for human-readable Bitcoin payment destinations which can be trivially verified on hardware wallets and which can be resolved relatively privately."
Why would you verify this on a hardware wallet? Are you using an on-chain address? Don't do that!
reply
0 sats \ 0 replies \ @nout 20 Feb freebie
Interesting! Couple impressions:
The same could be used as NIP-05 on nostr. The reality though is that when you have a domain, you usually also have a server (but maybe this makes it worth getting a domain without server?)
Also changing DNS records with your registrar is often more pain than just updating a static file on the server.
And finally from client (e.g. mobile phone) perspective - isn't it sometimes harder to make DNS request compared to HTTP? And I think for backwards compatibility, the client will have to do both anyway - first try DNS and then LNURL http...