Topic: Should IP address transactions be depreciated entirely? (Read 1608 times)

You use hostnames? There's nothing wrong with the idea, if it just needs encryption. As-is it's not safe to use.

The biggest thing it needs is mandatory encryption... Providing the public key hash of the server, this way, you can't preform a MitM attack, and there is no need for a third party (even if mutually trusted) to verify and sign the certificate. Instead of using a host, you would use hash@host like "[email protected]"

I never understood the IP address transactions either -- apart from privacy issues, half of the internet is behind NAT or similar routing structures, IP is a very bad identifier.

I don't see this as an argument to keep this particular set of code as it current exists.  While the concepts as used with the IP address authentication might be useful so far as helping with thin client transactions, that sounds like a significant protocol extension that goes beyond how it is currently implemented at the moment.  A good base, but something that needs significant upgrading and may even have to be completely rethought and reworked.

Essentially, it would be depreciating these messages to be something completely different.  Maybe I'm missing something else here that I'm not seeing.  I don't see the need for backward compatibility to maintain the unauthenticated raw IP address method of requesting the Bitcoin address information.  Keeping that backward compatibility even introduces a potential attack vector which would be nice to close.

No. Ultra-lightweight clients that don't even download the block chain except headers ("standard" lightweight clients download the chain and then discard most of it) need to receive full transactions from the sender. I think this will be the standard way of doing transactions in the future. IP transactions make a good base for this: we just need authentication. Authentication is even designed: people will provide static Bitcoin-address-like public keys along with IP addresses.

Agreed.  Not as many users will be as intelligent or aware of such security issues with using IP addresses.  It is best to not have that option at all.


The bitcoin project is entirely open source.  The older source code versions are all freely available and backed up.  If people want to use ip addresses, they can dig up the old code, and release a forked version for only those people that would want to use ip addresses.  But best thing is that ip addresses are not included in any official versions.  Security trumps usability and extra options.

There are currently three messages in the Bitcoin protocol directly related to conducting IP address transactions:

- checkorder
- submitorder
- reply

The only use for these messages is to conduct transactions over an IP address (unless somebody gives me a better excuse).  I get that backward compatibility with earlier clients might make it useful to keep these messages for a time, but at this point the entire notion of sending transactions to an IP address is almost completely refuted as a really bad idea.  Other alternatives such as "accounts" and perhaps other systems could be developed through the network itself that I don't understand even the need to maintain these data structures and messages at all.

Is anybody still using IP address transactions?  If you want to keep them in the current client on the philosophy "if it ain't broke, don't fix it", perhaps it isn't doing any harm, but it seems like generally a bad thing to encourage other alternate implementations to create this backdoor that isn't really being used.  I'm glad that the default situation is to simply prohibit people from using this from within the GUI interface, but my question is mainly if they should be formally marked as depreciated messages that are not going to get additional attention in the future?

Certainly if you are re-implementing a bitcoin client with the protocol, there is no need that I can see to putting these messages into that client.  Perhaps I'm missing something as to their importance in the protocol, if so, please enlighten me.