Bitcoin Forum
December 10, 2016, 03:12:52 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Potential vulnerabilities: dependency on IRC and transaction priority  (Read 1768 times)
theboos
Member
**
Offline Offline

Activity: 87


View Profile
March 03, 2011, 03:32:30 AM
 #1

These may have been discussed elsewhere but I couldn't find anything related with the search.

From what I understand of BitCoin, it receives IP addresses of peers from a single server (irc.lfnet.org). Unless the server is backed by elastic computing resources (EC2 or similar), isn't the entire network vulnerable to a relatively weak DDOS attack? Also, doesn't bootstrapping through a single, central, server undermine the openness and independence of BitCoin?

Another thought: what is to stop an attacker from sending hundreds of microtransactions to clog up the network? He could either send transactions of .0000001 BTC and pay the .01 BTC transaction fee (would this increase transaction priority beyond that of a free .01 BTC transaction?) or send transactions of .01 BTC (free per transaction, plus he can keep this up indefinitely by reusing the coins that he receives on each transaction). I estimate from the numbers on the blockexplorer.com front page that the average number of transactions per block is 20. Assuming it takes a maximum of 24 hours for a transaction to get into a block (for reuse by the attacker), an attacker could cause other transactions of equal priority to be delayed by a factor of two with the second approach for less than 30 BTC (6 blocks per hour, 24 hours, 20 transactions per block, .01 BTC per transaction) in capital.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481339572
Hero Member
*
Offline Offline

Posts: 1481339572

View Profile Personal Message (Offline)

Ignore
1481339572
Reply with quote  #2

1481339572
Report to moderator
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
March 03, 2011, 03:39:45 AM
 #2

I don't think already connected peers would have any problem if IRC went down. And I believe that there are some hardcoded backup peers to get new clients in the loop.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
JesusTheCaffeine
Jr. Member
*
Offline Offline

Activity: 35


View Profile
March 03, 2011, 03:40:58 AM
 #3

Something like dht would be nice to implement into the client though.
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
March 03, 2011, 03:51:37 AM
 #4

Something like dht would be nice to implement into the client though.

Do you mean the ability to manually enter a peer to connect to? I think you can do it, just not in the GUI. I never have though, others can tell more.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
mndrix
Michael Hendricks
VIP
Sr. Member
*
Offline Offline

Activity: 447


View Profile
March 03, 2011, 03:53:36 AM
 #5

From what I understand of BitCoin, it receives IP addresses of peers from a single server (irc.lfnet.org). Unless the server is backed by elastic computing resources (EC2 or similar), isn't the entire network vulnerable to a relatively weak DDOS attack? Also, doesn't bootstrapping through a single, central, server undermine the openness and independence of BitCoin?

As FreeMoney mentions, there are hardcoded seed nodes for those wishing to bootstrap without IRC.  You can run the client with the undocumented "-noirc" flag to test this.

Alternatively, if you can find the IP address of one node in the network, you can bootstrap by running the client with "-connect $ip" and then peer exchange will find plenty of nodes for you.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 03, 2011, 04:11:58 AM
 #6

As FreeMoney mentions, there are hardcoded seed nodes for those wishing to bootstrap without IRC.  You can run the client with the undocumented "-noirc" flag to test this.

Alternatively, if you can find the IP address of one node in the network, you can bootstrap by running the client with "-connect $ip" and then peer exchange will find plenty of nodes for you.

All quite true...  though I have been thinking that it would be nice to include a set of DNS bootstrapping nodes built into the bitcoin client.

Long-time community members with long-uptime nodes could include their DNS hostnames in this list.  Inventive programmers could mine bitcoin's addr.dat for addresses, and return those as DNS A records.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Cusipzzz
Sr. Member
****
Offline Offline

Activity: 300


View Profile
March 03, 2011, 03:24:06 PM
 #7


All quite true...  though I have been thinking that it would be nice to include a set of DNS bootstrapping nodes built into the bitcoin client.

Long-time community members with long-uptime nodes could include their DNS hostnames in this list.  Inventive programmers could mine bitcoin's addr.dat for addresses, and return those as DNS A records.



Agree...A natural choice would be the list of e-wallet providers / exchanges which should be up 24/7 by definition.

https://en.bitcoin.it/wiki/Category:EWallets


http://BTCSportsBet.com - The most complete bitcoin Sportsbook - All games from pro and college sports, Champions League, E-Sports, and reduced juice as well!
theboos
Member
**
Offline Offline

Activity: 87


View Profile
March 03, 2011, 04:39:30 PM
 #8

What of the second attack? There isn't any way (that I'm aware of) to discern a legitimate transaction from transaction spam. The cost of an attack of that type is proportional to normal transaction volume, average delay of transaction integration (any data on this?), and the desired factor of increase of average delay.
theboos
Member
**
Offline Offline

Activity: 87


View Profile
March 04, 2011, 12:03:46 AM
 #9

What about a proof-of-work factor in the transaction priority calculation? Clients would have the option of voluntarily increasing the difficulty of their hash to get their transaction into a block faster (though this somewhat undermines the purely economic benefits of generating blocks with high transaction fees), but also be required to include a proof-of-work for processing at all.

The immediate problem I see with that is the widely different hashing capabilities of various hardware: many clients have gigahash-scale clusters while others (particularly mobile clients) might have less than 1 Mhash/s . That's a factor of 1000 so it may be impossible to find a difficulty that will make it sufficiently costly to send waves of spam transactions while allowing low-end clients to complete single transactions in a short amount of time. Not to mention the fact that there are many legitimate large-scale transactions (mining pools) that would under sufficient difficulty take days or longer to clear.

What, then, if the burden of the proof-of-work was shifted to the receiving end of the transaction? Generally Bitcoins are received in few large transactions and sent in many. Retailers that would receive smaller Bitcoin transactions in large numbers (mtgox and other exchanges, bidding sites, e-wallets, etc.) are also probably established enough to have sufficient computing power to accept them. This would also prevent money from exiting the economy by going to nonexistent or lost addresses.

This is just one idea to counteract the issue; has this problem already been considered or dealt with?
Garrett Burgwardt
Sr. Member
****
Offline Offline

Activity: 350



View Profile
March 04, 2011, 12:11:20 AM
 #10

What about a proof-of-work factor in the transaction priority calculation? Clients would have the option of voluntarily increasing the difficulty of their hash to get their transaction into a block faster (though this somewhat undermines the purely economic benefits of generating blocks with high transaction fees), but also be required to include a proof-of-work for processing at all.

The immediate problem I see with that is the widely different hashing capabilities of various hardware: many clients have gigahash-scale clusters while others (particularly mobile clients) might have less than 1 Mhash/s . That's a factor of 1000 so it may be impossible to find a difficulty that will make it sufficiently costly to send waves of spam transactions while allowing low-end clients to complete single transactions in a short amount of time. Not to mention the fact that there are many legitimate large-scale transactions (mining pools) that would under sufficient difficulty take days or longer to clear.

What, then, if the burden of the proof-of-work was shifted to the receiving end of the transaction? Generally Bitcoins are received in few large transactions and sent in many. Retailers that would receive smaller Bitcoin transactions in large numbers (mtgox and other exchanges, bidding sites, e-wallets, etc.) are also probably established enough to have sufficient computing power to accept them. This would also prevent money from exiting the economy by going to nonexistent or lost addresses.

This is just one idea to counteract the issue; has this problem already been considered or dealt with?

You do not understand how bitcoin works.
theboos
Member
**
Offline Offline

Activity: 87


View Profile
March 04, 2011, 01:04:31 AM
 #11

You do not understand how bitcoin works.

Perhaps; I'm fairly new. Could you or someone else explain to me why this is not a potential problem?
mndrix
Michael Hendricks
VIP
Sr. Member
*
Offline Offline

Activity: 447


View Profile
March 04, 2011, 02:43:03 AM
 #12

As I understand transaction priority, transactions involving coins with more confirmations have higher priority.  In the situation you describe, the attacker's coins (being cycled back and forth) will have low priority and won't delay processing of legitimate transactions that pay the same transaction fee.

It seems like the net effect of this attack would be to require urgent transactions to pay a transaction fee, but the network would continue processing transactions just fine.
Garrett Burgwardt
Sr. Member
****
Offline Offline

Activity: 350



View Profile
March 04, 2011, 11:03:33 AM
 #13

You do not understand how bitcoin works.

Perhaps; I'm fairly new. Could you or someone else explain to me why this is not a potential problem?

There's no way to put the burden of mining on people who want to accept transactions. Transactions are simply broadcast throughout the network and whoever generates a block with that transaction gives it a confirmation. After 6 confirmations, it is considered confirmed.
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
March 04, 2011, 07:27:10 PM
 #14


You do not understand how bitcoin works.

I guess he doesn't, but he's on to something anyway. Usually there is no proof of work attached to a transaction. Attaching a fee denominated in bitcoins is like attaching a proof of work. And that is the ultimate solution to the priority issue.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!