That is my understanding too, and it works well to protect bitcoin from attacks from individuals or small organizations bouncing small amounts of bitcoins between different addresses. However, for a large well funded attacker it would not be that expensive to create large amounts of transactions that would be very hard to differentiate from legitimate transactions from the point of view of a miner. With drastically larger fees for every transaction this problem would be smaller, but the usefulness of the bitcoin system would decrease as well.

/noa

Since I've first heard of bitcoin I've been facinated by the idea and the project. One of the most appealing qualities is it's potential both the long and short term. If all it is ever going to be is a way for hackers to tip their favorite cartoonist, that's great. If it turns out to be a large scale tool to protect the privacy of individuals against totalitarian governments and other large organizations, it is great. If it turns out to be a workaround to cope with central banks massively devaluing their currency, that would be wonderful.

However, as the utility of the bitcoin system grows, I am certain that the attacks against it will show up as well. If bitcoin were to be used for billions of USD of tax evasion for example, then it seems probable at least to my mind that the NSA would spend at least some of it's vast computing resources and analytical skills to try to break the system. I think that enumerating the attack vectors and start thinking about how to protect against them is a good strategy to prepare. This is what I've come up with in the last few days:

# A vulnerability in the bitcoin software (such as a buffer overflow in the networking code) that lets an attacker learn the secrets of each user's wallet and steal available bitcoins. I think the reference implementation is complex bordering on obfuscated and since it's a monolithic piece of software a vulnerability anywhere would make the important secrets accessible. As an added bonus, the p2p autodiscovery makes finding nodes to attack trivial.

To mitigate this, splitting wallet management from the p2p parts and only connect the two when needed would be a good step. Also, working on alternative implementations of bitcoin would lessen the impact of specific attacks.

# Malware unrelated to bitcoin could extract the relevant contents of wallet.dat and steal the money. Protecting the wallet with a good symmetric crypto would manage some of this risk, but I think that it would be advisable to have wallets with nontrivial amounts of bitcoins associated with them on removable media such as USB drives.

# Having a nontrivial number of evilnodes in the p2p network. Imagine a few thousand nodes behaving nicely for a few weeks, then suddenly start discarding some transactions, spam fellow nodes with block requests, alter the lists of nodes that gets passed around to make it difficult to connect to nonevil nodes.

I believe this scenario is hard to defend against. Carefully tuned rate limiting and disconnect on abuse will help a bit. Perhaps some sort of scheme where nodes identified themselves with a public key and earned trust from their peers in proportion to the amount of good behavior that they exhibit.

# Lots of transactions. That would make the cost of running a node capable of validating new transactions expensive. Gone would be the days when your laptop had the capacity to check a transaction for double spending. Also, it would take a long while for your transaction go get into a block if there were thousands of new transactions each second flooding the network. If you combine that with large mining operations that would build blocks out of just a small subset of the available transactions and win most of the races for the next block, that would mean that making your legitimate payment could take a long time and the system would feel unreliable to it's users.

Scary stuff, but if we manage to navigate around those threats I think that the bitcoin system is a world changer.

/noa

Oh, if it's just a buggy version of the mainline client that triggers this it's probably not needed to modify bitcoinj to work around it.

bitcoinj doesn't re-connect currently. The I/O thread dies and the main thread continues indefinitely waiting for the blockchain to be downloaded.

/noa

I took bitcoinj on a test drive today. Firstly, I would like to say that I'm really happy about the project. I think that having a second independent bitcoin protocol implementation is really valuable, especially since reference implementation code base have a quite steep learning curve.

However, when trying to start up the included PingService it fails to download the initial block chain from the bitcoin peer running on localhost. When i start up the PingService it starts to try to download the blocks from that it has gotten previously. After a few tens of blocks received the peer on localhost:8333 closes the TCP connection, and writes something along the lines of:

socket send flood control disconnect (1380543 bytes)

in the it's debug.log.

I'll look into working around this tomorrow, but thought I should bring this up here first.

What would be the reasonable thing for a client to do to not be seen as flooding by the bitcoin peer? The method I'm thinking about is to split the list of block hashes returned as a response to the getblocks message in several chunks and send a few separate getdata requests with a delay timer.

cheers
noa

Version info:
bitcoin client 0.3.20.1 BETA, OSX, no special settings
bitcoinj r51