Topic: Potential vulnerabilities: dependency on IRC and transaction priority (Read 2037 times)

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.

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.

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.

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

You do not understand how bitcoin works.

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?

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.

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

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.

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.

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.

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

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.

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.