support for dns lookups

[anarchy]

Hi,

Does the bitcoin client support dns lookups instead of having to enter a complete address?
If yes, how does it deal with upper/lowercase?  Do A-records support that?

[jgarzik]

Does the bitcoin client support dns lookups instead of having to enter a complete address?
If yes, how does it deal with upper/lowercase?  Do A-records support that?

DNS lookups... for what?

You could store a bitcoin address in a TXT record, I suppose.

[bober182]

I assume he means the send to IP option. I'm not sure yet try it out with 0.01 bitcoin and your own domain.
Domains do not look at UPPERcase and lowercase, but the app might.

[anarchy]

No, I'm basically implying that it is easier for customers to send to bitcoin.shop.com instead of the full bitcoin address fE90eat445e5geagea15.  If the client would support you entering bitcoin.shop.com instead of that full bitcoin address, it would be really nice.  The bitcoin.shop.com would resolve to cname fE90eat445e5geagea15.shop.com so it knows which full bitcoin address to send to.

[jgarzik]

Perfect for a TXT record

[hugolp]

DNS lookup implies some kind of centralization, if I am not mistken. I think its easier to create some kind of plugin for the browser so it connects directly to the client and pays automatically.

[Gavin Andresen]

Bad idea until we have secure DNS (DNSSEC) everywhere.

And maybe even a bad idea then; one slip of the fingers and your bitcoins might go to amazone.com instead of amazon.com.

[bitcoinex]

No, I'm basically implying that it is easier for customers to send to bitcoin.shop.com instead of the full bitcoin address fE90eat445e5geagea15.  If the client would support you entering bitcoin.shop.com instead of that full bitcoin address, it would be really nice.  The bitcoin.shop.com would resolve to cname fE90eat445e5geagea15.shop.com so it knows which full bitcoin address to send to.

here I wrote ideas about it:
https://www.bitcoin.org/smf/index.php?topic=1042.msg13095#msg13095

but yeah, without DNSSEC it should not be used

[slush]

Why do not use something what openid or rss readers already does? link rel marks in html!

Is is:
* much easier to everybody to support (just add meta tag to you eshop and you are ready. no hacking DNS records for domains hosted somewhere)
* quite straighforward to use - just use eshop URL as wallet ID
* perfectly match with another activity on this forum - setting up URI for bitcoin wallet and create browser plugins which can manage that on page. In this case a plugin can detect that page use bitcoin and handle that in some way.

So something like

<link rel="bitcoin.walletr" href="bitcoin:1CFV3fjDzf9iCTD3TCfmhfgghgD3CbFS3K" />


Marek

[RHorning]

Why do not use something what openid or rss readers already does? link rel marks in html!

I'm sure that some kind of DNS-like system or "real world" naming system could be set up that could be put internal to Bitcoins, and it could be made as secure or perhaps even more secure than DNSSEC.  While a current system used by other network services could certainly be adopted, I would think to make it secure it would have to be a custom re-implementation specific to Bitcoins itself in some fashion.

What is being suggested here is a way to name addresses in something that is human compatible and memorable as opposed to a long bitcoin address.  On that point I think this is something worth discussing.

Some points worth noting:

• Name collisions would have to be dealt with in some fashion.  In other words, if two or more people claim shop.bitcoins as an "address", some method must be set up to deal with the collision, including potentially malicious attacks on the naming system.  This is why DNSSEC is mentioned, and even that isn't foolproof.
• Going onto the idea of name collisions, there is another vector of "attack" in terms of somebody looking at common mis-spellings and using that as a vector to intercept coin transfers.  You want to send some BTC to shop.bitcoins  but instead you typed in shop.bitcons as the address.  Don't count on the coins getting to your intended destination if that happens.  This should be addressed even if it is looked at and ignored.
• Some sort of culling process should be put into the naming system to keep the list from growing to uncontrollable levels.

You could of course simply have some way to collect addresses in some sort of notebook as a feature on the client app where you could manually assign a name to an address, so it would keep the naming relationship local, but I presume that the goal is to advertise in some way "If you want this cool T-shirt, send 5BTC to shop.bitcoins!"

On the whole this is a good idea, but one that needs some serious work to get it implemented.

[slush]

While a current system used by other network services could certainly be adopted, I would think to make it secure it would have to be a custom re-implementation specific to Bitcoins itself in some fashion.

I think that link rel is secure enough because you can of course show a warning in bitcoin client when site does not support HTTPS with valid certificate signed by some authority.

In case of signed https the link in page is far easiest way to implement *on side of services* and it may be very secure (well, secure enough for common use on Internet; typing bitcoin address is of course much more safer). Maybe implementation is not easy in client (HTTPS, certificates etc), but it definitely should not be a showstopper.

[Cdecker]

While this is certainly useful for a site accepting donations it'll not be a solution for Online Shops because the receiving end of the transaction has no way to distinguish payments, and where they came from. For this purpose it is solicited to generate a new address for each transaction, which in DNS and link-rel is not a given.

[Stephen Gornick]

So if I want to be able to identify the payor, what's the harm in having a single bitcoin address for each of my customers rather than for each transaction?

[slush]

While this is certainly useful for a site accepting donations it'll not be a solution for Online Shops because the receiving end of the transaction has no way to distinguish payments, and where they came from. For this purpose it is solicited to generate a new address for each transaction, which in DNS and link-rel is not a given.

Let's imagine that eshop will tell customer to pay to address https://great-eshop.com/customernickname where link-rel is unique for every customer nickname. It is just alias for any bitcoin address.

It is nice to remember for customer, extremely easy to implementation and safe enough.

[zipslack]

While this is certainly useful for a site accepting donations it'll not be a solution for Online Shops because the receiving end of the transaction has no way to distinguish payments, and where they came from. For this purpose it is solicited to generate a new address for each transaction, which in DNS and link-rel is not a given.

I think the problem of identifying senders should be solved by the bitcoin protocol. Suppose that Messages were supported when sending to a bitcoin address.

Suppose that the merchant generated a unique identifier and included it in the bitcoin link along with the address and payment size. The buyer clicks the link, which opens the bitcoin client and automatically opens the Send Coins dialog. The Pay To and Amount boxes are pre-populated with the information included with the link. The Message box is pre-populated with the unique identifier. All the buyer has to do is click Send. When the merchant receives the payment, the identifier tells him which buyer's account should be credited.

Now that I think about it you can do without the identifier if you generate a new address for each buyer. The trouble with that is that bitcoin addresses have to be stored forever by the merchant even after they are likely never to be used again, even if they've never been used, if there is any chance at all that they might be used in the future. The identifiers described above OTOH can be discarded after any time period the merchant chooses. Maybe that's less of a problem than I imagine it is.