[PULL] Send payments to emails, urls and domains in GUI

[khal]

Chapters
1. Description
2. Technical explanation
3. Usages examples
4. How to add this to your website
5. You have an email and don't own the domain

Pull request on git : http://github.com/bitcoin/bitcoin/pull/174

1. Description

This patch allows you to send payments to email address, domain names and url from the bitcoin GUI.
Valid examples of inputs :

• wikipedia.org
• http://xkcd.com
• yourpseudo@bitcoin-contact.org
• http://bitcoin-contact.org/q/getaddress/myaccount@gmail.com

2. Technical explanation

Input url/address is translated to an http request sent to the corresponding domain (ip addresses are not translated for backward compatilibty).
A valid response is a text formatted in json, containing a bitcoin address with an optional label :

Code:

{
    "error" : "",
    "label" : "Bitcoin Contact",
    "address" : "1NMxHnpAE38P9HN9pzRSqAFMCv1WcXZC1N"
}

GUI will propose you to add the returned address in your address book.

KISS !


3. Usages examples

I've taken my own domain (bitcoin-contact.org) for the examples, because i need some working examples. To see how to add this in your website, see next part.
"Pay To" is the user input written in the "Pay To" field of the "Send Coins" GUI.

Domain name :
Pay To : bitcoin-contact.org
Request : http://bitcoin-contact.org/bitcoin-address.txt
Request result :

Code:

{
    "error" : "",
    "label" : "Bitcoin Contact",
    "address" : "1NMxHnpAE38P9HN9pzRSqAFMCv1WcXZC1N"
}

Payment sent to : 1NMxHnpAE38P9HN9pzRSqAFMCv1WcXZC1N

Domain root url :
Pay To : http://bitcoin-contact.org
Request : http://bitcoin-contact.org/bitcoin-address.txt
Request result :

Code:

{
    "error" : "",
    "label" : "Bitcoin Contact",
    "address" : "1NMxHnpAE38P9HN9pzRSqAFMCv1WcXZC1N"
}

Payment sent to : 1NMxHnpAE38P9HN9pzRSqAFMCv1WcXZC1N

Email :
Pay To : khal@bitcoin-contact.org
Request : http://bitcoin-contact.org/bitcoin-address-khal.txt
Request result :

Code:

{
    "error" : "",
    "label" : "Khalahan",
    "address" : "1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG"
}

Payment sent to : 1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG

Pay To : user@bitcoin-contact.org
Request : http://bitcoin-contact.org/bitcoin-address-user.txt
Request result :

Code:

{
    "error" : "Not a public address."
}

Payment sent to : If error field is not empty, bitcoin displays standard error "Invalid address".

Any other URL :
Pay To : http://bitcoin-contact.org/q/getaddress/khal@bitcoin-contact.org
Request : http://bitcoin-contact.org/q/getaddress/khal@bitcoin-contact.org
Request result :

Code:

{
    "error" : "",
    "label" : "Khalahan",
    "address" : "1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG"
}

Payment sent to : 1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG
You can give any url as long as it returns those json lines.


4. How to add this to your website

Default address for your own domain
Create a file named "bitcoin-address.txt" at the root of your domain and remplace 111... chars with your address :

Code:

{
    "error" : "",
    "label" : "Label of your website, or email address for example",
    "address" : "1111111111111111111111111111111111"
}

Email address for your own domain
Example : mymail1@mydomain.com
Create a file named "bitcoin-address-mymail1.txt" at the root of your domain and remplace 111... chars with your bitcoin address :

Code:

{
    "error" : "",
    "label" : "Your email address or a label",
    "address" : "1111111111111111111111111111111111"
}

Example : mymail2@mydomain.com
Create a file named "bitcoin-address-mymail2.txt" at the root of your domain and remplace 222... chars with your bitcoin address :

Code:

{
    "error" : "",
    "label" : "mymail2@mydomain.com",
    "address" : "2222222222222222222222222222222222"
}

5. You have an email and don't own the domain
Example : mypseudo@gmail.com & address 11111111111111111111111111111
Register your email and bitcoin addresses to http://bitcoin-contact.org/?account and set them public.
Then, give this url to your contacts :
http://bitcoin-contact.org/q/getaddress/mypseudo@gmail.com

You can also register a pseudo on bitcoin-contact and use this directly : mypseudo@bitcoin-contact.org
Note : you can also set the label to "mypseudo@gmail.com" and people who use "mypseudo@bitcoin-contact.org" will receive a contact like that :
- label : mypseudo@gmail.com
- address : 11111111111111111111111111111

[1713559082]

1713559082

[1713559082]

1713559082

[1713559082]

1713559082

[1713559082]

1713559082

[error]

What if some site wants to give different receiving addresses to different users? I don't see any provision here for that.

[khal]

The Json code returned by http://bitcoin-contact.org/bitcoin-address-admin.txt can be static or dynamic.

If you want dynamic addresses, do it with a rewrite rule in apache to redirect the static file to a php script :

Code:

RewriteRule      ^bitcoin-address-(.*).txt$             /myscript.php?q=$1               [L,NC]

Once in the php script, you can do what you want :
- connect to you own node and get new address
- return a random address from a predefined pool

Don't forget this system is for bitcoin public address discovery, not for managing addresses from a merchant website.
Is there a use case i miss or misunderstood ?

[jav]

Hey! Great to see you are working on a "Bitcoin address discovery system". That would definitely be cool to have!

I was thinking about that myself and am still unsure, if I would not prefer this to be its on daemon. So let's say you would connect to the domain in question on some well-known port (say 8334) and be connected to a simple daemon which you can then query for those things. Somehow that seems like a good thing to do to me, considering "separation of concerns" and all that.

I guess you went with this route in order to make it much simpler to deploy? That's definitely a big advantage, I agree. So maybe that's the pragmatic thing to do to actually see some adoption of it and some point. If we marry it to the webserver, I would prefer these changes though:

1. Use .json instead of .txt as the file ending
2. Move all the user lookups (user@example.org) to a folder, as to not "clutter up" the root folder too much

So that would mean:

/bitcoin-address.json (instead of /bitcoin-address.txt)
/bitcoin-address/user.json (instead of /bitcoin-address-user.txt)

[genjix]

I think my patch is better, http://bitcointalk.org/index.php?topic=5938.0 

[khal]

Your solution looks over complicated and don't allow :
- a simple user to configure their address on their own domain without installing all the required stuffs.
- using any url and domain names

Mine is best, of course

[khal]

Hey! Great to see you are working on a "Bitcoin address discovery system". That would definitely be cool to have!

I was thinking about that myself and am still unsure, if I would not prefer this to be its on daemon. So let's say you would connect to the domain in question on some well-known port (say 8334) and be connected to a simple daemon which you can then query for those things. Somehow that seems like a good thing to do to me, considering "separation of concerns" and all that.

I guess you went with this route in order to make it much simpler to deploy? That's definitely a big advantage, I agree. So maybe that's the pragmatic thing to do to actually see some adoption of it and some point. If we marry it to the webserver, I would prefer these changes though:

1. Use .json instead of .txt as the file ending
2. Move all the user lookups (user@example.org) to a folder, as to not "clutter up" the root folder too much

So that would mean:

/bitcoin-address.json (instead of /bitcoin-address.txt)
/bitcoin-address/user.json (instead of /bitcoin-address-user.txt)

Good idea for the directory. People who do not want to use php and want a simple solution to use their own domain may also need several addresses. I like things to be at the "right" place :p

For .json or .txt, why not (i was hesitating too).

[Matt Corallo]

Which ever one is better, neither should ever use HTTP even as a fallback.  SSL should ALWAYS be on and enforced no matter what the user wants.  Sites which allow users to register an account which will be then pushed out via SSL shouldn't be too hard to find (hopefully as a part of online wallet services) but never should and kind of unencrypted/unsigned addresses be used.

[khal]

Which ever one is better, neither should ever use HTTP even as a fallback.  SSL should ALWAYS be on and enforced no matter what the user wants.  Sites which allow users to register an account which will be then pushed out via SSL shouldn't be too hard to find (hopefully as a part of online wallet services) but never should and kind of unencrypted/unsigned addresses be used.

So, you wan't to restrict this function to account providers only and geeks ?
All people that wan't to publish their address on http://myblog.blogproviderwithoutssl.com can't use http://myblog.blogproviderwithoutssl.com/bitcoin.txt as shortcut ?

It's not a problem for me because i know how to do it and i've control over my servers (i've a default self signed certificate on https://bitcoin-contact.org for example), but i'm not representative of all people...

Here's my response on github about that problem:

A bitcoin user is vulnerable to a MITM attack because of DNS resolution not using DNSSEC (irc connections, dnsseed and dyndns) and TCP connections to ip not using SSL verifiable certificates. Once he controls all connections...
Possibilities for the attacker are :
- make the user believe he has been paid by sending a transaction from already spent coins on the real nodes
- generate fake blocks for confirmations and fake transactions
So, you can't really trust 100% what is displayed by your bitcoin client ?

By fetching addresses in http, it adds an additional risk :
- a user can send coins directly to the attacker
I admit it is a big risk, but it should not block the possibility to fetch an address even if the connection is not secured. However, the user should be warn in this case and decide what to do with a manual action (you won't send 500BTC that way do you ?).

A way to do it securely would be to send the fetch request to connected first level nodes and compare results (or shasum to shorten the message). But, bitcoin network is not ready/designed for trusted nodes.

Another solution is to have a centralized site for address fetching. If a think a centralized solution was good i would already have linked my patch with my domain :p. Maybe, I could fetch both from a direct request to the website and make a second request to one of the trusted ip (declared like bitseed ips) ?

What do you think about the alternatives ?

[Matt Corallo]

Which ever one is better, neither should ever use HTTP even as a fallback.  SSL should ALWAYS be on and enforced no matter what the user wants.  Sites which allow users to register an account which will be then pushed out via SSL shouldn't be too hard to find (hopefully as a part of online wallet services) but never should and kind of unencrypted/unsigned addresses be used.

So, you wan't to restrict this function to account providers only and geeks ?
All people that wan't to publish their address on http://myblog.blogproviderwithoutssl.com can't use http://myblog.blogproviderwithoutssl.com/bitcoin.txt as shortcut ?

It's not a problem for me because i know how to do it and i've control over my servers (i've a default self signed certificate on https://bitcoin-contact.org for example), but i'm not representative of all people...

No, not at all.  But at this point, no one has any excuse for not having ssl on any site which has a login of any kind (stupid users insist on using the same password for all their sites) and especially not one that is used for financial transactions.  Anyone can just use startssl and get a valid certificate.  (I'm looking at you bitcoin.org)  I don't really mind if the client allows non-SSL connections, but we should take after modern browsers and put red lights up everywhere, clearly explain the risks and make the user click Yes about 20 times before they can send to a non-SSL address.  Also, if the user does get an address without SSL, it should not be stored in their address book permanently. 

A bitcoin user is vulnerable to a MITM attack because of DNS resolution not using DNSSEC (irc connections, dnsseed and dyndns) and TCP connections to ip not using SSL verifiable certificates. Once he controls all connections...
Possibilities for the attacker are :
- make the user believe he has been paid by sending a transaction from already spent coins on the real nodes
- generate fake blocks for confirmations and fake transactions
So, you can't really trust 100% what is displayed by your bitcoin client ?

To an extent, yes you are absolutely right, if someone is pulling off a MITM attack, they can do all kinds of nasty things to bitcoin nodes.  What they can't do, however, if convince the user to pay the attacker, ie make money off their victim.  With this, an attacker can easily make quite a bit of money off their victim.

A way to do it securely would be to send the fetch request to connected first level nodes and compare results (or shasum to shorten the message). But, bitcoin network is not ready/designed for trusted nodes.

Again, if someone is doing a MITM attack, they control all the connections.  You can thus not trust anything who's identity is not trusted and verified.

Another solution is to have a centralized site for address fetching. If a think a centralized solution was good i would already have linked my patch with my domain :p. Maybe, I could fetch both from a direct request to the website and make a second request to one of the trusted ip (declared like bitseed ips) ?

I agree, a centralized solution is not the way to go on this.  Especially for financial stuff like this.  What happens if our central repo is compromised?

[khal]

My last proposal is inspired by the new bitseed bootstrap of the bitcoin client.
2 domains are declared in bitcoin :
- bitseed.xf2.org
bitseed.xf2.org has address 109.75.176.193
bitseed.xf2.org has address 142.58.248.28
bitseed.xf2.org has address 173.242.112.53
bitseed.xf2.org has address 174.120.185.74
bitseed.xf2.org has address 178.18.90.41
bitseed.xf2.org has address 178.63.15.200
bitseed.xf2.org has address 178.63.62.15
bitseed.xf2.org has address 217.157.1.202
bitseed.xf2.org has address 69.163.132.101
bitseed.xf2.org has address 69.164.218.197
bitseed.xf2.org has address 91.85.220.84

- bitseed.bitcoin.org.uk
They both return a list of ip nodes to bootstrap to.

We can do the same with :
- bitfetch.xxxxxx.yyy => a list of ip
- bitfetch.yyyyyy.zzz => a list of ip
- more
That would return a list of servers ip, with ssl enabled, that accepts to do requests for you.

Example 1 :
Input : khalahan@sky-animes.com
Domain sky-animes.com has ssl ! :p
request 1 : https://sky-animes.com/boitcoin-address/khalahan.json

Example 2 :
Input : khalahan@tartuffxxyy.com
Domain tartuffxxyy.com has no ssl
request 1 : http://tartuffxxyy.com/boitcoin-address/khalahan.json
request 2 : https://bitfetch.yyyyyy.zzz/fetchaddress/tartuffxxyy.com/boitcoin-address/khalahan.json
=> 2 results are compared.

That way it is half centralized, but a bit complicated though.

So, next step is to add SSL support in requests :p


ps : web browsers don't complain when the certificated has changed, but complain for a self signed certificate. Where is the security here ? (there's a ff plugin to check this, i don't remember the name)

[Matt Corallo]

My last proposal is inspired by the new bitseed bootstrap of the bitcoin client.

That seems much too complicated and not worth it.  I think your current protocol works just fine, I just wanted to say that you need to be 100% sure that it is secure for the average, stupid, user.  That means force SSL unless the user wants to jump through hoops.

[khal]

- Patch has been updated to support HTTPS only for secured requests (thanks BlueMatt, it must be like that).
- file naming has moved to jav proposal (thanks jav) :
/bitcoin-address.json (instead of /bitcoin-address.txt)
/bitcoin-address/user.json (instead of /bitcoin-address-user.txt)

[khal]

A small mistake, it's :
/bitcoin-address-domain.json (instead of /bitcoin-address.txt)

Here are examples of user input and the corresponding request sent :

input : sky-animes.com
query : https://sky-animes.com/bitcoin-address-domain.json

input : http://sky-animes.com
query : https://sky-animes.com/bitcoin-address-domain.json

input : khalahan@sky-animes.com
query : https://sky-animes.com/bitcoin-address/khalahan.json

input : http://sky-animes.com/bitcoin-address/khalahan.json
query : https://sky-animes.com/bitcoin-address/khalahan.json

input : http://bitcoin-contact.org
query : https://bitcoin-contact.org/bitcoin-address-domain.json

input : sipa@bitcoin-contact.org
query : https://bitcoin-contact.org/bitcoin-address/sipa.json

input : http://bitcoin-contact.org/q/getaddress/mypseudo@gmail.com
query : https://bitcoin-contact.org/q/getaddress/mypseudo@gmail.com

[Maged]

So, you wan't to restrict this function to account providers only and geeks ?
All people that wan't to publish their address on http://myblog.blogproviderwithoutssl.com can't use http://myblog.blogproviderwithoutssl.com/bitcoin.txt as shortcut ?

It's not a problem for me because i know how to do it and i've control over my servers (i've a default self signed certificate on https://bitcoin-contact.org for example), but i'm not representative of all people...

Why not, as a fallback, we have a central secure site that stores a public key for a domain/email, and then the user just signs the file with their private key and uploads it to their own unsecure site? Of course, to get on this central secure site, you'd need to verify that you control the location when the file would be on your server (Or maybe just the email address for emails?).