Bitcoin Forum
November 11, 2024, 10:10:00 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [pull] Remove send to IP address and IP transactions support  (Read 5034 times)
wumpus (OP)
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 22, 2011, 09:00:52 AM
Last edit: May 22, 2011, 09:25:44 AM by John Smith
Merited by ABCbits (2)
 #1

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


Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5376
Merit: 13407


View Profile
May 22, 2011, 09:25:43 AM
 #2

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
wumpus (OP)
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 22, 2011, 09:27:26 AM
Merited by ABCbits (2)
 #3

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1181


View Profile WWW
May 22, 2011, 09:52:38 AM
 #4

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?

I do Bitcoin stuff.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5376
Merit: 13407


View Profile
May 22, 2011, 09:59:51 AM
 #5

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
wumpus (OP)
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 22, 2011, 10:04:34 AM
 #6

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1134


View Profile
May 22, 2011, 10:09:34 AM
 #7

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 (OP)
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 22, 2011, 10:14:16 AM
 #8

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Vladimir
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1001


-


View Profile
May 22, 2011, 10:22:04 AM
 #9

yep, this stuff should be removed.

-
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5376
Merit: 13407


View Profile
May 22, 2011, 10:25:59 AM
 #10

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
wumpus (OP)
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 22, 2011, 11:19:18 AM
 #11

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 Smiley

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
xf2_org
Member
**
Offline Offline

Activity: 98
Merit: 13


View Profile
May 22, 2011, 04:45:10 PM
 #12


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

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

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1134


View Profile
May 22, 2011, 04:47:58 PM
 #13

Cleaning out the UI is always worth doing I think.
wumpus (OP)
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
May 22, 2011, 06:23:43 PM
 #14


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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2301


Chief Scientist


View Profile WWW
May 23, 2011, 02:37:44 PM
 #15

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..."

How often do you get the chance to work on a potentially world-changing project?
gigitrix
Hero Member
*****
Offline Offline

Activity: 630
Merit: 500



View Profile
May 23, 2011, 05:21:59 PM
 #16

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
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
May 15, 2013, 10:28:31 AM
 #17

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.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!