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.
Topic: [pull] Remove send to IP address and IP transactions support (Read 5034 times)
No reason to keep it: we've already seen that "server based Bitcoin transactions" can be automated, and work just fine without it.
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..."
IP transaction support has been disabled by default for a while now.
Considering that, deletion does not seem to be a priority.
Cleaning out the UI is always worth doing I think.
IP transaction support has been disabled by default for a while now.
Considering that, deletion does not seem to be a priority.
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
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
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. 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.
Satoshi's proposal doesn't make that much sense either. If you use
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.
yep, this stuff should be removed.
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.
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.
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.
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.
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
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.
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:
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4hdomain.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.
The future plan for sending to an IP is to make it a bitcoin address plus IP, like:
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h
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.
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?
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.
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.
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.
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.
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
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
Jump to: