Well Known directory for wallets address

[Falci]

No description provided.

[Falci]

Demo

[tynes]

This protocol needs to be versioned so that it is easy to upgrade from the way that the addresses are currently hardcoded. I could imagine in future versions, the client could need to provide a proof of identity before the server would return an address.
It would be possible to place the version in the path, as a query parameter or in the HTTP request header. I personally lean towards the path, so that it would look something like this:

GET foo.bar/.well-known/wallets/v0/btc

This makes the version explicit and forces the client to state the version that they are expecting a response from. If the version is a query parameter or in the HTTP header, they can get away without setting it. It also makes using a reverse proxy much easier, I could imagine setting up a reverse proxy based on the HTTP path that sends the request to a different server that is responsible for managing the wallet service. This could even be outsourced to a company who manages the keys, making it very easy for existing websites to add this functionality by only adding a rule into their proxy.

[sdtsui]

Ack.

Neat proposal.

I'm almost certain this is a silly question, but I'm going to ask it anyway for my own learning. I hope that's alright. :)

What is the difference between providing the address over HTTPS and simply publishing the address on-chain on a record, like TXT?

My thinking: 512 bytes is a lot to work with. While I'm aware of privacy concerns for the latter, I feel like ENS and others have gotten substantive adoption with solutions many HNS purists would consider flawed. If our wallet address standard can be designed to be extensible (not on-chain? okay, the wallet provider can make a request for the receive addr), I feel like we could start with something simple like on-chain records.

[brandondees]

@sdtsui there's been some telegram discussion about pros and cons of doing it in dns. the main factors I can recall:

• dns records are more troublesome to update or make dynamic for purposes like fresh wallet address per use (the recommended practice) -- this is way worse/slower for the on-chain data as opposed to nameserver level
• http(s) is more accessible natively to more applications, particularly including web apps
• generic wallet apps won't necessarily always have a handshake node to talk to, which complicates the security model for getting the dns info in a tamper-proof way. dnssec is there for us, but also not super commonplace or straightforward to support (yet).
• with https and a well known path, it's not handshake-exclusive, it can be used for any sort of wallet address, even fiat if banks provide a string that can be used safely for transfers, with no hard dependency on handshake dns resolution etc.
• IMHO 512 bytes is really not all that much to work with. as additional use cases for the chain data pile up, that limit can fill up extremely quickly, and folks will start having to pick and choose what extended TXT-based features their TLDs will support (or even just what short list of cryptocurrencies to accept). I think i'm already putting something like 200 bytes into most of my TLDs just for parking, not even getting into DNSSEC, TLSA, etc. which i hope we will start to normalize in the near future. delegating it off chain to the nameserver is fine but then we're back to the security modelling challenges

[ca98am79]

I like this. My only concern is that it requires HTTPS, whereas doing it on chain removes this dependency. I know it is a tradeoff wrt to privacy. But by having this dependency, there could be issues with resolving the address, or it could also be considered more insecure because it is more centralized (you need to have a web server running).

[pinheadmz]

Some additional thoughts:

Note that a cryptocurrency address-in-DNS system has been propsed: https://openalias.org/

It is in use in the Monero community. Monero uses "stealth addresses" which means that the address you get is never actually revealed on chain. Such addresses can be reused because the sender actually uses that address to encrypt a blob that goes in the transaction along with an ephemeral key (or something like that). BTC and HNS could also use stealth addresses but they are not standard: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

HNS users could easily just use openalias as well with a static address but it is considered bad practice.

There are other issues with using TXT in the root zone: it takes up to 6 hours to update for one.

I think the "referal only" root zone concept for HNS is a good guideline - we should be using HNS to point to authenticated servers and then use those servers for evreything else. Even if a user chooses to run openalias, they should do it from their authenticated name server, and then can still generate new addresses with each request.

The well-known standard is essentially equivalent to posting an address on a website. It is extremely user friendly and can still be authenticated with https

[brandondees]

i don't think managing dns and dnssec is easier to support on either end.

with the http option, this feature could be enabled by a lightweight wordpress plugin, or a wide range of low-barrier-to-entry alternatives opening it up for "everybody" relatively speaking. the population that has a website and wouldn't mind taking donations (if it were easy to do) is way larger than the population that can manage dns records safely (total non-starter for the vast majority).

i do understand preferring consensus data to server data, when possible, but i don't think the tradeoffs here make sense when we want to cycle addresses on use, and enable widespread adoption. if you're ok with relatively static reused addresses, then i think it makes sense to follow the existing openalias spec as mentioned, rather than adding yet another standard for the exact same function.

[pinheadmz]

@brandondees TXT in the root zone on HNS is the only way to do this without DNSSEC.

Using an authenticated nameserver to issue addresses requires DNSSEC

Using HTTPS on a handshake website requires DNSSEC + DANE

[brandondees]

@pinheadmz fair point, i guess i'm thinking just about the address rotation management aspect, which will have to be manual for most individuals' websites where they can't run their own dns server.

[Falci]

Just to keep track: this should be merged as HIP-0002