BIP-able idea suggestion: Secure IP Transactions

[Emilstud]

Hello Bitcoin Community,
a long time ago there was a feature called ip transactions.

It worked like this:
1. You enter the IP-address of a recipient
2. A node which used this IP created a new address and informed the sending node about this address.

It has been removed in version v0.8 due to a lack of security.
The main key parts because it was removed were that it was very insecure because of Man-in-the-Middle attacks.

I thought that it would be really cool if you could send Bitcoins to donate.example.com.

The secure way would go through SSL.
For example:
If you enter an IP-Address/Domain it would send a SSL/TLS request to the IP-Address (I will call it server by now).
The server responds with a new generated address.
During this process SSL/TLS will be used to verify authenticity.

After the user clicked send, a message box will popup with the public key of the certificate. The user then can verify if this public key truly belongs to the owner of the IP-Address (For example if the owner provides the ssl pubkey on his website) and then confirms the transaction.

Additionally this can also be implemented in the bitcoin uri scheme:
bitcoin:donate.example.com?amount=1&sslpubkey=9A:62:5E:8B:53:D9:B0:74:10:FC:D5:6B:0F:D5:9B:3B:D9:71:4A:82
please execuse me if this URL is malformed, was too lazy to do url encoding.

Then the SSL fingerprint would be verified automatically.
Would be nice for donation receivers who want a new address for every transaction I will go onto this later.

Another big advantage is that every time someone wants to send Bitcoins to an IP-Address a new Bitcoin address is being generated.
This is really nice for people who want to use a new address for every incoming transaction.
I know it is also possible with today's methods but this would be much easier.
I see lots of sites using static Bitcoin addresses for donations. This is good for transparency but not as good as a new address when it comes to privacy.
Also very nice for only shops who want to protect their customers.

What do you think about my idea?

[darosior]

Hi,

I'm not sure it should be a BIP it could just be used by some wallets.

Cons : https://bitcointalk.org/index.php?topic=9334.0 (or why it has been removed)
Pros :

Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156.  The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address".  Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending.  If there's a better name for the switch, we can change it again.

Incidentally, for this DNS have custom-built records SRV. Theese records for Kerberos, for example:


$ dig _kerberos._tcp.host.com srv

;; QUESTION SECTION:
;_kerberos._tcp.host.com.   IN   SRV

;; ANSWER SECTION:
_kerberos._tcp.host.com. 3550 IN   SRV   10 10 88 kerberos.host.com.


Requesting for any DNS-name SRV-record in this format, you can find the address of Kerberos-server for this domain. Similarly, we can do for Bitcoin by queryng about: "_bitcoin._tcp.host.com" or something.

All this is done covertly, human sees only the right part of the name: host.com

And for domain names with sub-domains Kerberos using TXT records to enable the customer to understand what realm it belongs to:


$ dig _kerberos.grid.host.com txt

;; QUESTION SECTION:
;_kerberos.grid.host.com.   IN   TXT

;; ANSWER SECTION:
_kerberos.grid.host.com. 3587 IN   TXT   "HOST.COM"


Bitcoin can use this for subdomains like www:

_bitcoin.www.host.com. 3587 IN   TXT   "HOST.COM"

i.e., human can send bitcoin to www.host.com, bitcoin client check TXT _bitcoin.www.host.com for DNS-name of bitcoin "realm", than check SRV _bitcoin._tcp.host.com and, finally, sends bitcoins to IP, specified by this SRV-record.

This scheme is really a part of Kerberos standart and used, I think, more than 15 years.

And this DNS trick will be usable in Tor's .onion network

[achow101]

There is already work on an idea similar to this that is called Pay to Endpoint (P2EP).

[Emilstud]

@darosior
The Bitcoin wallet can also sign the cert on it's own.
My idea was to use SSL certificates just for the fingerprints to avoid fakers by DNS spoofs and Man-in-the-Middle attacks.
SSL is the solution for probably all cons on the list.

@achow101
Thank you, I will take a look at it

[pooya87]

However I don't think this should be a BIP as it doesn't need to be in the reference implementation,

a BIP is a "bitcoin" improvement protocol not "bitcoin core" improvement protocol. in other words they don't have to be in reference implementation (bitcoin core) to become a BIP. for example there are BIPs that aren't in it or even anywhere else for that matter. example: BIP178 which is a versioned WIF proposal which isn't used by any wallet. or BIP39 which is mnemonic code (generating a seed phrase part) is not used by bitcoin core.

[KingZee]

This is a decent idea but there are a few caveats :

Wouldnt the receiver IP need to be online 24/7? If the server is down for some reason then I guess you need to implement some sort of fallback or it wont go through...

Man in the middle is awfully scary too, especially if you're relying on a server rsponse to send your coins. You havve to worry not only if you're the receiver but also the sender. There are a lot of attack vectors that you need to proof against, with SSL mentioned by satoshi above being just a small part of it..

People will be a lot more tempted to compromise servers. You cant fake a btc addresss or claim it unless you have the privkey, but you can definitely hack servers, the damage would be massive compared to just a single compromised address.. Same goes for clientside, you can use SSL to encrypt your requests, but what about before the request goes out? I know very little about networking and the dumbest idea I can come up with would be to just fuck with your hosts file and simply redirect all your requests from someexchange.com to mywebsite.hack..

If there is something like this in the works Im sure they're all beating the idea to death in order to avoid/minimize issues like these. Just see how cryptography has very little human factor involved and yet we still see people lose their keys. If you open up a door like this imo the benefits are minimal compared to how much more room there will be for human error.

[Emilstud]

This is a decent idea but there are a few caveats :

Wouldnt the receiver IP need to be online 24/7? If the server is down for some reason then I guess you need to implement some sort of fallback or it wont go through...

Man in the middle is awfully scary too, especially if you're relying on a server rsponse to send your coins. You havve to worry not only if you're the receiver but also the sender. There are a lot of attack vectors that you need to proof against, with SSL mentioned by satoshi above being just a small part of it..

People will be a lot more tempted to compromise servers. You cant fake a btc addresss or claim it unless you have the privkey, but you can definitely hack servers, the damage would be massive compared to just a single compromised address.. Same goes for clientside, you can use SSL to encrypt your requests, but what about before the request goes out? I know very little about networking and the dumbest idea I can come up with would be to just fuck with your hosts file and simply redirect all your requests from someexchange.com to mywebsite.hack..

If there is something like this in the works Im sure they're all beating the idea to death in order to avoid/minimize issues like these. Just see how cryptography has very little human factor involved and yet we still see people lose their keys. If you open up a door like this imo the benefits are minimal compared to how much more room there will be for human error.

According to your hosts file tweak.
This would be impossible with SSL.
The SSL certificate is unqiue. It cannot be tampered unless you have the private keys.
My idea was if you send a transaction, a confirm dialog will pop-up with the public key of the fetched SSL cert. The author of the website should put his SSL pubkey onto his website so users can verify it with the popped up private key.

[Emilstud]

However I don't think this should be a BIP as it doesn't need to be in the reference implementation,

a BIP is a "bitcoin" improvement protocol not "bitcoin core" improvement protocol. in other words they don't have to be in reference implementation (bitcoin core) to become a BIP. for example there are BIPs that aren't in it or even anywhere else for that matter. example: BIP178 which is a versioned WIF proposal which isn't used by any wallet. or BIP39 which is mnemonic code (generating a seed phrase part) is not used by bitcoin core.

I know but to standardize it (which is my plan) it needs to specified somehow.