Time for a threat down?

[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

[1714049040]

1714049040

[1714049040]

1714049040

[1714049040]

1714049040

[1714049040]

1714049040

[alkor]

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

From my limited understanding of the bitcoin protocol, the transaction fees are designed to solve exactly the above problem. When the volume of transactions becomes problematic, then miners will be free to choose which transactions they include in their newly discovered block, and the prioritization will be done based on the fee included with each transaction. In this way transactions with no fees can be treated as spam and ignored (or will take very long time to confirm), and only transactions with sufficiently high fees will be included.

Regarding your other points, I wholeheartedly agree, especially with regard to modularizing the code with clearly defined security boundaries between each module. Having a gigantic monolithic piece of code where a single vulnerability may bring down the whole thing is bad software design.

[Nefario]

This reminds me of the Tanenbaum–Torvalds flame war about whether Linux should be monolithic.

[noa]

From my limited understanding of the bitcoin protocol, the transaction fees are designed to solve exactly the above problem. When the volume of transactions becomes problematic, then miners will be free to choose which transactions they include in their newly discovered block, and the prioritization will be done based on the fee included with each transaction. In this way transactions with no fees can be treated as spam and ignored (or will take very long time to confirm), and only transactions with sufficiently high fees will be included.

Regarding your other points, I wholeheartedly agree, especially with regard to modularizing the code with clearly defined security boundaries between each module. Having a gigantic monolithic piece of code where a single vulnerability may bring down the whole thing is bad software design.

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

[em3rgentOrdr]

(Adding thread to my watch list)

Id be interested in a simulation of such an attack.  Maybe try you attack on the test netwoekand report back results?

[Rena]

Increasing the transaction fee helps your transaction go through during a spam attack yes, but how does John Q Public know what would be a good value to use at the moment? I imagine most will just leave it at the default setting of zero; some will set it to 0.01 and forget about it. It'd help if the client could automatically suggest a fee amount for each transaction that will probably get it handled reasonably fast.
As well, if high-budget spammers are flooding the network with transactions with large fees, one would need to out-fee them to defeat the spam, no? People would start to get annoyed if they had to pay a $1 fee on every transaction. And if said spammers are also major miners, wouldn't they even be able to reclaim a lot of their own fees, thus keeping the attack going?

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

On this point: from what I've seen, your wallet has to be in ~/.bitcoin/wallet.dat as long as the client is running. That makes using a removable device not very convenient. This could be improved with some minor tweaks to the client:

• Allow entering paths to where one or more additional wallets may reside. (These would be on removable media, so wouldn't necessarily be present all the time.)
• If one of these files suddenly comes into existence (i.e. the media containing the file was inserted), automatically import the address list from it. Keep the file closed most of the time; open it only when needing to access it.
• If one of these files suddenly disappears (i.e. the media was removed), automatically remove those addresses again.
• The user can use Truecrypt or whatever other mechanism they like to encrypt the media.
• Be able to automatically transfer funds from ~/.bitcoin/wallet.dat to any wallet stored on external media whenever the media is connected. This turns the local wallet file into basically just a buffer holding any received funds that haven't been saved to external media, so there's little risk of it being stolen. (In theory we could run without a local wallet file and keep the transactions in memory until media is present, but that risks losing them if the machine crashes.)

It's pretty much guaranteed that the more popular Bitcoin becomes, the more malware will be out there specifically to steal wallets, and also do things like hijack the Bitcoin process itself to automatically send transactions to some spammer. Encrypting the wallet won't stop a program from just reading the decryption keys out of memory. Eventually - at very least, when the user wants to send money - everything necessary for a trojan to steal the wallet and/or make some transactions of its own will be available. The best way to prevent this is removable media - no malware can access memory that isn't physically connected - so it makes a lot of sense to make it as convenient as possible to use removable media.

Related: easy importing/exporting of bitcoins/wallets to/from files, so that one can distribute them by putting them on cheap removable media and passing it to someone. For the non-technically-inclined to use this, it should as simple as "export 10BTC to a file" and "drag file into your Bitcoin client window". (Maybe even pop up a window with a coin icon and the instructions "drag this icon to a folder to save the coins to a file".)

(and while we're at it, can we move ~/.bitcoin to ~/.config/bitcoin to avoid cluttering the home directory? >.>)

[theymos]

(and while we're at it, can we move ~/.bitcoin to ~/.config/bitcoin to avoid cluttering the home directory? >.>)

You can change the location by running Bitcoin with -datadir=~/.config/bitcoin or whatever.

[marcus_of_augustus]

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.

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

/noa

Securing the wallets on local machine ... yep, it needs some serious looking at ... 'deleted' copies of wallets and fragments are probably being left lying around all over the place. It will take some really tight low-level file/memory management to make it bullet-proof, probably be quite high commercial demand for some top-shelf wallet management s/ware also.