|
aceat64 (OP)
|
 |
September 16, 2010, 02:57:43 AM |
|
Sending transactions to IP addresses should be removed or at least disabled by default.
As has been stated by many members of the community, it is in no way secure. I also believe that it may actually allow an attacker to determine the identify of an operator of a bitcoin node. Example, I send 0.01 BTC to various IPs on the network and record the IP and bitcoin address (a bitcoin address is autogenerated). If I run or have access to the information at one of the Bitcoin exchanges (or run a store/service that accepts bitcoins) I can then tie that IP address to the user of that site/service. In the case of an exchange I could tie that IP to a person's PayPal or bank account!
Another possible attack is to connect to a target node and initiate an IP transaction. The target will generate a new address, at which point you disconnect and start again. This might be useful as a denial of service attack.
|
|
|
|
|
|
|
|
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
LZ
Legendary
 Offline
Activity: 1722
Merit: 1072
P2P Cryptocurrency
|
|
September 16, 2010, 03:31:50 AM
Last edit: September 16, 2010, 08:00:20 PM by lzsaver |
|
So may be IP transactions should be enabled only for IP addresses ranges reserved for private networks?
What about forced transaction fees for other IP ranges? (Payee will accept only transactions with fees.)
|
My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
|
|
|
|
nanotube
|
|
September 16, 2010, 03:40:22 AM |
|
It's not the sending that should be disabled by default, but the receiving, I think.
If the receiving end refuses to accept IP transactions, unless explicitly enabled, all the problems go away.
Right?
|
|
|
|
|
em3rgentOrdr
|
|
September 16, 2010, 03:43:39 AM |
|
It's not the sending that should be disabled by default, but the receiving, I think.
If the receiving end refuses to accept IP transactions, unless explicitly enabled, all the problems go away.
Right?
Right. Good point! Don't throw the baby out with the bathwater! |
"We will not find a solution to political problems in cryptography, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks, but pure P2P networks are holding their own."
|
|
|
|
aceat64 (OP)
|
|
September 16, 2010, 06:47:34 PM |
|
Sorry, I guess I wasn't very clear in the original post. I would like for receiving of transactions by IP to be disabled by default.
|
|
|
|
|
LZ
Legendary
Offline
Activity: 1722
Merit: 1072
P2P Cryptocurrency
|
|
September 16, 2010, 08:43:59 PM
Last edit: September 16, 2010, 09:00:43 PM by lzsaver |
|
Seems that it would increase the security without decreasing the ease of use. So I like it.  |
My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
|
|
|
|
|
|
|
satoshi
Founder
Sr. Member
Offline
Activity: 364
Merit: 6723
|
|
September 19, 2010, 09:49:30 PM |
|
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.
|
|
|
|
|
|
