Draft BUIP BAIP - DNS Based Address resolution

[Azarov Andrey]

Did not know where to post this so as not to multiply threads I'm posting in general dev discussion.
Comments and criticism is welcome.

This method allows paying to DNS defined domain (or subdomain) from within the client.

Title: DNS Based Address resolution
Author: Azarov Andrey
Status: Draft

Summary

In the first releases of Bitcoin payment to IP has been introduced. Unfortunately, such method would have left the network exposed to malicious activities.

With the original proposed addressing scheme Bitcoin addresses are extremely difficult to remember (obviously due to their random nature of not easily relatable mix of alphanumeric characters). This downside is also accompanied by security issues - when the addresses are copy-pasted to the client or when only the beginning and the end of the address is checked for similarity it leaves it open to very easy replacement attacks or just plain mistakes from the user. In a financial system with non-refundable tokens, such issue can be a grave mistake.

There were attempts to create an easy to remember naming scheme but it required using an alternative coin (Namecoin) to perform security of the name and thus was not feasible without direct exchange of tokens.

I propose a method using currently implemented worldwide naming system - DNS - to define unique bitcoin addresses for the clients to pay to. The security of DNS record can be provided by DNSSEC which would prevent government and other third-parties possible intervention and hijacking. DNSSEC is already used to secure authenticity of CERT, SSHF, IPSECKEY and TLSA records.

For simplicity sake, we ignore NAPTR and other fringe record types and use universally supported and accepted TXT record.

Motivation

Instead of paying to 1LbjEXE3idnyoBFdXrXpvmc9LcQyn9L7Ug or 1C26Erb8FzFUFq5goPnFWtKxLCf4Qz23R8 we will pay to example.com or user.example.com or subuser.user.example.com or invoice.74965.example.com . Extensions could be provided for browsers to display address for the visiting user.

Specification

In a DNS server a public address can be specified using the following TXT record:
```bind9
; example.com zone file fragment
$TTL 2d
@ IN A 127.0.0.1
www IN A 127.0.0.1
_bitcoin 1 IN TXT "1LbjEXE3idnyoBFdXrXpvmc9LcQyn9L7Ug"
...
```
Which when resolved would be the same as using URI bitcoin:1LbjEXE3idnyoBFdXrXpvmc9LcQyn9L7Ug

After successful payment, the address can be iterated with the usual widely available DNS server commands to update the record to a new address.
With TTL = 1 second (5 is the minimum but some applications will take it) it will update to a new address.
Already some of the DNS servers can be programmed to provide auto-generated addresses per each request or per different IP either from a pre-populated database or a genaddress script directly. This can still be cached for some period for each IP. The TTL record can be modified then to provide a TTL of 1 day or 1 week or more.
Another approach is to provide something like:
```bind9
; example.com zone file fragment
$TTL 2d
@ IN A 127.0.0.1
www IN A 127.0.0.1
_bitcoin.invoice.74856 10m IN TXT "1LbjEXE3idnyoBFdXrXpvmc9LcQyn9L7Ug"
_bitcoin.invoice.74836 10m IN TXT "1C26Erb8FzFUFq5goPnFWtKxLCf4Qz23R8"
...

```
And remove the record after TTL expired.

Of course, TXT response should be checked and verified as a valid Bitcoin address by the client to prevent unfortunate Proof of Burn.

Deployment

This improvement can be applied client-side only and doesn't require modifying protocol.
Client functions have to be implemented with DNS resolution over dnssec supporting libraries due to not many OS's supporting DNSSEC natively.

Benefits

1. Bitcoin will gain a lot of ease of use as well as become more attractive for eCommerce.
2. DNS servers are much easier to protect than HTTP server dynamic pages. Usually, DNS is the last bastion which hacker can access. In case of a third party supporting DNS you also have resilience (i.e. website is taken down by DDoS and Bitcoin address is not visible).
3. It would become much easier to provide addresses for direct payments than generating keys directly on the HTTP daemon server which has more possibilities of malicious hacking than slightly more limited DNS server.


Risks


1. Possible confusion of users between bitcoin and domain-based addresses. Can be mitigated by visualized difference.
2. Scam artists might try using similar domain names - however, domain names have far smaller possibility of error and scam domains are suspended fast nowadays. A warning screen with disclaimer and timeout can be implemented a la "you are sending to a newly discovered domain-sourced address, please re-enter the sum". After that, the DNSSEC key should be saved in a database to prevent possible MITM and malice.
3. Of course, DNS server could be hacked and the DNS entries might get rewritten. There is no way to protect against that as well as no way to protect against websites having their addresses rewritten by a hacker. However, this is out of scope of Bitcoin and should be taken as a possible loss. Users paying large sums (percent-wise off their wallet) should receive some disclaimer no matter where they pay
4. Exposure of IP address is possible in case of 'unique address <- DNS request <- HTTP request' logging chain, but then again it is also possible via HTTP requests to the website so I would classify this risk as negligible.

 

[Christoph Bergmann]

I'm all for taking this route, but can you paste in your proposal without the special format? It's annoying to scroll in two directions, at least on my system ...

 

[Azarov Andrey]

Updated

 

[Christoph Bergmann]

Thank you! I recommened to move this topic to the Bitcoin Unlimited subforum, where the discussion of BUIPs usually happens. @Bloomie

I really like to see something like this to happen. Pay to IP and other kind of payment protocoll applications are a seriously neglected area of development and have the potential to heaviliy improve user experience. So I'm all for exploring and be willing to vote for funding such venture for Bitcoin Unlimited.

I can't contribute to the technical discussion, but hope that some members of BU have enough experience in network technology to do. Here I only can contribute some background information, which might help to shape the concept (eventually, at least I hope).

Somehow the successor of P2IP was the payment protocoll, introduced in 2013. Mike Hearn hoped it would become the new standard for transactions. Despite being a great idea, it was not so much developed further and never fulfill its potential. In 2017, on the Arnhem Future of Bitcoin conference, both Craig Wright (nChain) and Tom from bitcrust revived the idea of payment protocols.

If I understand it right - and I could be very wrong here - the basic idea is this: You open a channel between sender and receiver, and the sender gives the receiver the incredients to build a transaction. So instead of the sender, the receiver can pay the proper fee and propagate the transaction to his favorite mining nodes, effectively eliminating the attempts for standard double spends and making zero-conf for small purchases secure.

Something similar is done by CashShuffle. Senders give their individual transactional incredients to a server, which builds a multi-party transasctions with it, which increases privacy of a bitcoin transaction, at least a bit. Not too different from this is the idea of TumbleBit, which uses hash based riddles to make untraceable offchain utxo exchanges.

All these concepts have in common that they need some kind of channel between two or more parties before building Bitcoin transactions. The same goes for Reusable Payment Codes as deployed by Stash. If you want to just make the client resolve a DNS to a Bitcoin adress, you should get in contract with the guys from Stash, because just linking an address to a DNS is not really the future, privacy like. Better to make such a channel to - this is just a rough guess from somebody not understanding it properly - exchange a certain path for deterministic keys.

Again, the most important thing to get those things done should be the channel. If there is a channel infrastracture to exchange transactional incredients, be it for payment protocoll or coinshuffle, and secrets, riddles or key generation paths, it would be a huge enabler for a lot of innovation. However, it is important, that there is a standard for those channels, so the different teams working on channel based concepts should cooperate.

 

[Bloomie]

Moved to Bitcoin Unlimited.

 

[Azarov Andrey]

I really like to see something like this to happen. Pay to IP and other kind of payment protocoll applications are a seriously neglected area of development and have the potential to heaviliy improve user experience. So I'm all for exploring and be willing to vote for funding such venture for Bitcoin Unlimited.

I can't contribute to the technical discussion, but hope that some members of BU have enough experience in network technology to do. Here I only can contribute some background information, which might help to shape the concept (eventually, at least I hope).

Somehow the successor of P2IP was the payment protocoll, introduced in 2013. Mike Hearn hoped it would become the new standard for transactions. Despite being a great idea, it was not so much developed further and never fulfill its potential. In 2017, on the Arnhem Future of Bitcoin conference, both Craig Wright (nChain) and Tom from bitcrust revived the idea of payment protocols.

I know why payment protocol has not gained any popularity. It is rubbish. There's a reason why text protocols won over binary. Text protocols are much easier to debug and implement. There were more elegant and easier ways to implement this, say through JSON-RPC or YAML-RPC or simple HTTP post but they decided to go with big company (Google) open-source tech (protobufs). First of all choosing a non-neutral technology made it less attractive for Google's competitors. Second of all Google has that death-of-projects following it. I know it because I implemented one of their promoted tech and now it is completely forgotten and 0 support exists for it, it's just garbage and ex-devs ask to fork it if you want it alive.

If I understand it right - and I could be very wrong here - the basic idea is this: You open a channel between sender and receiver, and the sender gives the receiver the incredients to build a transaction. So instead of the sender, the receiver can pay the proper fee and propagate the transaction to his favorite mining nodes, effectively eliminating the attempts for standard double spends and making zero-conf for small purchases secure.

Something similar is done by CashShuffle. Senders give their individual transactional incredients to a server, which builds a multi-party transasctions with it, which increases privacy of a bitcoin transaction, at least a bit. Not too different from this is the idea of TumbleBit, which uses hash based riddles to make untraceable offchain utxo exchanges.

All these concepts have in common that they need some kind of channel between two or more parties before building Bitcoin transactions. The same goes for Reusable Payment Codes as deployed by Stash. If you want to just make the client resolve a DNS to a Bitcoin adress, you should get in contract with the guys from Stash, because just linking an address to a DNS is not really the future, privacy like. Better to make such a channel to - this is just a rough guess from somebody not understanding it properly - exchange a certain path for deterministic keys.

Ok channels are just a locktimeverify transaction. I accidentally reinvented that wheel and was writing a BUIP about that as well (it's named Backtabs ) but dropped the idea when discovered that similar channels have already been discovered before me. In fact there are multiple implementations available. But no, my BUIP is not about payment channels. My BUIP is about user friendliness. About security: Bitcoin transactions are not really secure at the moment. Any ISP can listen to node traffic and decypher the initial sending point of transaction. Unless Bitcoin starts using SSL and SSLs are government-decryptable (assuming collaboration of SSL centers and governments) so it leaves us with Blockchain based SSLs but those are not really reliable. So there's that.

DNS is perfect for merchant adoption and use. It's easy to implement on the merchant's side and easy to implement in a client. Security with DNSSEC will be enough for transactions. I mean if we trust HTTP server with page display - we already by default trust DNS! So any merchant adoption will only win from DNS address resolution.

Picture this, now to provide a client with payment you need to authorize the customer every time using HTTP then to generate and provide the address. By using pay-to-dns you don't need to authorize the customer or display any page in 90% of the usage. Just registering a customer account with particular subdomain name would be enough to topup his account. He doesn't even need to visit the website ever to actually do anything. In fact we can even provide payforward type of provisioning - when customer sends the payment forward first and then signs the message on the website to authorize the spending.
This gives more possibilities with virtually almost 0 changes to the client (DNS client is already in for node discovery).

Again, the most important thing to get those things done should be the channel. If there is a channel infrastracture to exchange transactional incredients, be it for payment protocoll or coinshuffle, and secrets, riddles or key generation paths, it would be a huge enabler for a lot of innovation. However, it is important, that there is a standard for those channels, so the different teams working on channel based concepts should cooperate.

As I mentioned above, channels are not that sophisticated and difficult to implement. But they are kludges. Band-aids to a more severe problem.

 

[Christoph Bergmann]

Ok, I see, you confirm what I said about my technical knowledge ... nice to see that you know well about the payment protocol. You say it failed because it had the wrong data structure? Do you think it is worth a try to rebuilt it in json / html?

I think with channels our point of view doesn't match. What I meant with channels had nothing to do with transaction or blockchains, but just a channel to exchange information prior to creating a transaction. But it might be that I missed some information about the role of checktimelockverify.

Now, to come to the most important part: You P2IP concept. If I get it right - and this is again a big IF - you want the merchant to link an IP with a Bitcoin address, and the client to contact with the IP and get the address? And when I order a Pizza, the merchant can create a new site, maybe pizza.de/salami-4-christoph.htm, my client routes to the side and gets an address? Or, as the site knows me, it can just be pizza.de/christoph, right?

Edit: You might notice, that I'm a layman in this issue. I hope other BU members can provide more sophisticated feedback.

Maybe it will be worth a try to talk with payment processors about this. For example, rocketr or keys4coins could be good options to talk with.

 

[Azarov Andrey]

Ehh... no, I didn't provide a P2IP concept. I provided P2Domain system. You misunderstood it a bit but it's not a big problem. I'm working on additional information about it, maybe will try a pull request to implement changes.

You don't need a HTTP server for getting addresses, just DNS.