Using DNS To Coordinate Bitcoin Payments \ stacker news ~bitcoin

Using DNS To Coordinate Bitcoin Payments bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments

3940 sats \ 14 comments \ @Rsync25 20 Feb bitcoin

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!

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 :)

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 !

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.

0 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/

0 sats \ 0 replies \ @stargut 21 Feb

doesnt a vpn hide your ip address from the receiver?

0 sats \ 0 replies \ @nout 20 Feb

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...

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.

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.

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?

0 sats \ 1 reply \ @TonyGiorgio 20 Feb

Human readability.

0 sats \ 0 replies \ @nerd2ninja 20 Feb

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.

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!