In the Dogecoin Tricks
book the other day, I added
a trick to look up a wallet address associated with a domain name. I wrote a
little bit of code (try it at DogeDNS) to
turn a Dogecoin wallet address provided in a DNS TXT record to a QR code and
a link that will open an associated Dogecoin wallet.
None of this is magic. It builds on well-understood ideas like DNS, TXT records (used for things like SPF and DMARC), and BIP-21.
It’s nice when we can arrange existing things to do new things.
It’s important to understand what and why we’re doing that though.
The Problem Statement(s)
Why might someone want to associate an address with a web page or domain name?
Let’s say you’re running a blog site (like this one) and you don’t want advertisements on it (like I don’t). People repeatedly ask (okay, now we’re getting hypothetical) how they can support your work. I’m too lazy to set up Paypal or a Patreon or another third-party system, but I can publish a wallet address.
How do you know it’s mine?
You need some trusted mechanism of getting an address associated with my identity.
If you know that I run this domain of blog.ifdogethenwow.com or
ifdogethenwow.com, and if you know that you can retrieve something from this
domain with a wallet address under my control, then you can be pretty sure that
I can accept tips to that address.
Suppose alternately I sell something from this address, like PDF copies of the Dogecoin Tricks book (not yet but someday) or access to a private section of the blog with even smarter posts than this or time-limited articles. How do you know what’s what?
Set aside the problem that once I’ve associated a wallet address with my identity I’ve given up some anonymity, because you can watch that address and see what happens with those koinu.
How do you know that wallet address is really mine?
I can think of a few ways.
Multi-Step Verification
If this information is stored in DNS, we can take advantage of the fact that there’s one person authorized to make changes to my DNS records, and that’s me. When I update records, countless computers around the world get those new records and store them, so anyone who wants to spoof them has to seek out and get all of those records updated somehow.
Of course, if you’re in a hotel or at a conference and someone else controls all DNS, they can spoof my records unless I have DNSSEC enabled, which I do now, thanks to @RichDevX reminding me I kept meaning to enable it. Now there’s a cryptographically-secure mechanism to give us both confidence that my DNS records are what they are because I set them that way.
You don’t even have to look at my website at all to know what I intended.
Similarly, if I added a <meta> tag to the HTML on my homepage or any web
page, I could put a BIP-21 address in that tag, and you could be pretty sure
that the contents of that tag is something I added, if I have HTTPS enabled
on the site (which I do).
Again, that’s a cryptographically secure way of ensuring that someone who isn’t me didn’t manipulate the site between the time I edited it and you saw it.
Finally, if I added some file in some format at a well-known or publicized
location on my server, like a
robots.txt file, you could verify
that you fetched it over HTTPS and have the same confidence that you did when
looking at a <meta> tag embedded in HTML.
Three options, all of which have cryptographically secure mechanisms of verifying that the contents have not been tampered with in transit. One mechanism benefits from globally distributed caching and a side channel besides delivery over HTTP.
Which do we choose?
Pros and Cons of Not Yet Standards
It’s easy to say we should stick with the BIP-21 standard, which already has support in various operating systems and devices. For example, if you scan a BIP-21 QR code or click on a BIP-21 link on a mobile device and if you have a Dogecoin wallet installed correctly, your operating system should pop up that wallet and ask if you want to make a transaction.
Like I wrote earlier, it’s nice when things already exist.
The DNS Approach
What’s good about this approach? It doesn’t require a web site or HTML parsing. All you need is a domain name. You can use any DNS client to get the information.
What’s not so good about this approach? You’re more likely to have a web browser than a DNS client under your control. This is only secure if you have DNSSEC enabled.
Another pro is that you can associate an address with the domain as a whole or
any subdomain; I can have a separate BIP-21 address for ifdogethenwow.com
versus blog.ifdogethenwow.com. If I had users alice, bob, and charlie
who each had their own subdomain, they could each have a DNS entry for their
subdomain.
Discoverability is a bit of a problem, though. You can’t know there’s an address associated with a domain or subdomain without fetching DNS.
Also the TXT format is pretty limited. It’s a string of text. If we want
anything more complicated than a BIP-21 address, we’ll have to describe an
unambiguous parsing mechanism for semi-structured data (and I am not a fan of
introducing semi-structured
data).
The <meta> Tag Approach
The nice part about the <meta> tag is that the <meta> tag already has a
good
specification.
In fact, there’s already a bitcoin
MetaExtension proposal with the WHATWG
Extensions.
If we went with this approach, we could have a separate address associated with each page, with no need to edit DNS. (I assume updating a website is easier than updating DNS, because you’re more likely to have the ability to update HTML for any given page than you are to modify an entire domain, but I could be wrong.)
The content you can put in this tag is about the same as the content you can
put in a TXT record; basically a BIP-21 address or (ugh) semi-structured text
we’d have to parse.
I already mentioned that we can only trust this if we fetch the site over HTTPS and the certificates validate.
This is a pretty good option, not the least because a well-written browser extension doesn’t have to do anything special to fetch the page. This tag is either there or it isn’t.
There’s a lot to like about this approach.
If I were to propose this from the start to WHATWG, I’d replace <meta name="bitcoin" content="... bip-21 address ..."> with something a little more
general, such as <meta name="bip21" content="... bip-21 address ..."> so that
any cryptocurrency which has BIP-21 support could use the same tag. That way we
can avoid the proliferation of multiple nearly identical tags.
The Well-Understood File Format and Location Approach
The final approach is defining a file location and format, something like
robots.txt or the Atom syndication
format would be useful.
(Side note: Ben Trott, one of the minds behind Atom, was once a friendly
“rival” in the earliest days of PerlMonks. It’s good to have friendly
competition with good people.)
This format has both the advantage and disadvantage that it doesn’t exist yet.
Both the DNS and <meta> tag approaches have the advantage that they fit in
existing mechanisms but only let you associate a BIP-21 address with a
particular page or (sub-)domain.
With a new format and a new file, the sky is the limit.
Suppose a robots.txt or Sitemap
standard that could associate a URI path on the server with an address, or an
address and behavior. The use case where blog.ifdogethenwow.com/supporters
had metadata associated that said “for access to this, you must send 10 Doge to
address $A with label $L” could be machine-readable and a browser extension or
command line tool could parse that and prompt you to do something interesting
with it.
There are two problems to figure out.
First, how in the world do you verify that a client has sent that payment unless you generate a unique address, label, identifier, or something for each unique client? Or do you go through a redirector that uses an OAuth-style handoff? I don’t know. This requires some thought. Let’s not think about that now.
Second, what format should this file use? Does it go line-based text, like
robots.txt or XML like Atom (easy to parse, but it seems like people don’t
love parsing XML these days) or JSON (easy to parse especially in JavaScript
and mostly human readable)?
What’s in the standard and what’s out?
Is this file discoverable because another <meta> tag points to it? Or do we
arbitrarily pick a root-level path like bip21.txt or bip21.json or
bip21.xml and force the world to go along? If it’s any of those files, do we
want a new
MIME-type to
represent the format?
I admit, I start to feel tired when I think about defining a file format.
Next Steps
What should we do?
@inevetable360 and I agreed to talk about use cases the other day, so we should do that.
I think we need to discuss this on /r/dogecoindev as well. Comments welcome
on Defining a Standard for Dogecoin Domain/Website Tip
Discovery.
