[pull] Remove send to IP address and IP transactions support

[wumpus]

Remove send to IP transaction support, as it is insecure and would confuse users when used.

An IP is a terrible identifier as it does not identify a person or organization. Furthermore, man-in-the-middle attacks are trivial as the internet has no "proof that you have ip XXX" API. In the future address shortening services based on "user@domain" would be useful, but these will likely be based on third party APIs and not on this code.

• Removes server logic to accept transfers by IP [checkorder, submitorder] (was already behind a barely-known setting)
• Removes UI logic to send transfers by IP (CSendingDialog). Entering an IP in the send box will always result in an error.

Less transaction-handling code to maintain and audit is always better.

I have obviously kept in the code to handle and show old by-IP transactions, as they will remain part of history.

https://github.com/bitcoin/bitcoin/pull/253

[theymos]

Why not implement the secure IP transfers that Satoshi talked about instead of removing it? I've always thought that IP transfers would be very useful if made secure.

[wumpus]

1) I don't believe that secure IP-based transactions are possible. The internet has no API to confirm that you are the real owner of an IP address. This would need to involve your ISP.

2) We already have bitcoin addresses, why would you complicate it by having mulitple kinds of addresses? What inherent advantages do IP transactions have that hash-based transactions don't have?

3) Also if you really want IP based transactions (or other forms of address shortening) they could be implemented as a secondary service apart from the P2P protocol. I see no advantage to having this as part of the main protocol.

[Pieter Wuille]

Why not implement the secure IP transfers that Satoshi talked about instead of removing it? I've always thought that IP transfers would be very useful if made secure.

Care to give a pointer?

[theymos]

1) I don't believe that secure IP-based transactions are possible. The internet has no API to confirm that you are the real owner of an IP address. This would need to involve your ISP.

You publish a public key along with your IP address.

2) We already have bitcoin addresses, why would you complicate it by having mulitple kinds of addresses? What inherent advantages do IP transactions have that hash-based transactions don't have?

You can send a message without putting data in the block chain.

IP transactions are also more size-efficient, and they might be used as a base for "user@domain"-style transfers.

3) Also if you really want IP based transactions (or other forms of address shortening) they could be implemented as a secondary service apart from the P2P protocol. I see no advantage to having this as part of the main protocol.

It basically is a separate protocol now. It's not required to implement IP transaction functionality if you're making a client.

Care to give a pointer?

The current sending by IP is not very useful: it connects to the IP, so you'd like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled.

The future plan for sending to an IP is to make it a bitcoin address plus IP, like:

1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com

I need suggestions for the separator character.  ":" is a candidate, but IPv6 has : in it and that might get confusing.  Something that's allowed in url parameters would be nice.

I want to use SSL for the connection, using the bitcoin address' public key as the cert.  You would be certain you're connected to who you thought, and safely encrypted.  The bitcoin address would not be used for the transaction, only for authentication.  A new generated bitcoin address would be sent through the SSL connection.

Since it's authenticated, it would then be safe to allow the IP address to be a domain name.  Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup.

[wumpus]

You publish a public key along with your IP address.

So what is the advantage beyond simply publishing your public key? Which is already an address?

Satoshi's proposal doesn't make that much sense either. If you use <key>.<IP> the entire shortening advantage goes away.

And IPs can change if you move providers, or if your provider moves IP ranges, so they're also not useful as long-term address to publish.

[Mike Hearn]

Agree it should be removed for now. The functionality can go back in at some later point with a new protocol if somebody wants to write one.

It's really to our advantage to simplify the clients UI at this point, because lots of new users are coming on board who may not be very tech savvy. Simplicity is the key and deleting effectively dead features is the easiest way to start. There are some other simple UI improvements that could be made later as well.

If direct sends support gets resurrected, it'd be more convenient to have it run over HTTPS. For all its faults HTTP supports things like multi-plexing multiple independent sites onto the same IP addresses and lots of companies already have sophisticated load balancing and traffic routing setups that handle it.

[wumpus]

Good point about https. Domain-based makes sense, IP-based doesn't. And as added bonus, it would have trust control with certificates. "Transaction messages" could evenso be added as part of this API, and will be encrypted over the line unlike now.

On the modern internet, hardly anyone is basing protocols on static fixed IP addresses anymore, for many reasons; among them, IPv4 is running out of addresses so people have to multiplex.  For IPv6 the shortening advantage will be lost. Remembering a IPv6 address is as hard as remembering a bitcoin address.

[Vladimir]

yep, this stuff should be removed.

[theymos]

So what is the advantage beyond simply publishing your public key? Which is already an address?

Satoshi's proposal doesn't make that much sense either. If you use <key>.<IP> the entire shortening advantage goes away.

And IPs can change if you move providers, or if your provider moves IP ranges, so they're also not useful as long-term address to publish.

Addresses are not public keys. Addresses are public key hashes, which necessitates a larger transaction (24 bytes extra per output).

As I said before, the main benefit is sending messages out-of-band. I never even mentioned shortening as a benefit...

You should be able to use domain names instead of IPs. (I know you can't right now.)

IP transactions is one of those things, like script, that will probably have some interesting uses later. Unlike address transactions, the recipient can refuse a transaction before it's even made (if the input is wrong, for example). This would solve the refund problem that some merchants have had. It's also one way that lightweight clients might receive transactions without checking the block chain.

I'm fine with hiding it from the "send bitcoins" UI for now.

[wumpus]

Theymos, that's mostly theory and would-be-nice.  The proposed https-based protocol can do this all in a more secure way.

Also the code will remain in github's history, so anyone that wants to use it to make a useful system in the future can easily resurrect it. Plase don't keep code around because it might come in useful in the future some day, it's not an attic

[xf2_org]

IP transaction support has been disabled by default for a while now.

Considering that, deletion does not seem to be a priority.

[Mike Hearn]

Cleaning out the UI is always worth doing I think.

[wumpus]

IP transaction support has been disabled by default for a while now.

Considering that, deletion does not seem to be a priority.

Then why only go half the way, and disable it but not delete it? The patch is completely straightforward.

[Gavin Andresen]

I vote for removing dead code; less code means less bugs, and less chance of security issues.  The source control system is the right place for code that we "might need again someday..."

[gigitrix]

No reason to keep it: we've already seen that "server based Bitcoin transactions" can be automated, and work just fine without it.

[Stephen Gornick]

Sorry for necrothread, but to bookend this thread:

As-of v0.8.0, the Bitcoin-Qt/bitcoind client no longer includes the code for IP transactions.