Talk:Weaknesses

Wallet Vulnerable To Loss

I don't know if the vulnerable to loss from no backup is something that should fall under the category of being a "Bitcoin weakness". - Sgornick 05:36, 18 June 2011 (GMT)

If a computer problem such as a disk crash occurs or for whatever reason there is no longer access to the wallet, and backups are either unavailable or not current enough, loss of coins can result. Though backups are recommended, the client itself does not manage backups.

New wallets vulnerable with old passwords via backups

I'd like to add the above in as another wallet/backup vulnerability, this time through unexpected behaviour. While the following isn't a bitcoin protocol weakness, I do think it a weakness of how bitcoin clients interact both with users and the user's device.

An old copy of a wallet with its old password is often retrievable via an existing backup facility (particularly Apple Time-machine): draining that old wallet, with it's old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.

An initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause) the creation of new addresses, and the sending of existing sums to them. Backed-up copies of the wallet with the original password would then be empty, should they be compromised. On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and - intially at least - is no longer backed up. On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of the wallet in order to destroy them. Diary404 (talk) 23:41, 30 March 2013 (GMT)

Illegal Content In the Blockchain

This following appears to be speculation as to how a resolution to the problem might be arrived at. That has been moved here as speculation of potential solutions doesn't go in the Weaknesses article. - Sgornick (talk) 06:39, 29 September 2012 (GMT)

Unspent transactions can be safely forgotten if more than half of all users are forgetting those transactions. If a miner neglects to forget an unspent transaction and is in the minority, its blocks will be rejected by the majority if those transactions are subsequently spent. Probably users will not want to coordinate enough to forget illegal transactions, as it would require a high degree of centralization. Miners can safely refuse to accept illegal transactions, which may be enough to avoid legal problems, but this is basically impractical due to illegal content being extremely complex to detect.Transaction data can also be deleted with minimal risk if it can be proven that data will never be used. For example, if the standard template for a tx output is used, the only place you can put arbitrary data is the pubkey hash. If you set this to, say, English text or part of a JPEG, that tx output can be deleted because the chances of anyone finding a public key that hashes to that specific bit of meaningful data is very remote. However, someone could still encrypt the data so miners cannot detect it, and this carries the same liability for miners who neglect to drop it.

Pools

On the forum I have been discussing threats from pools and I would like to see those presented here. Sorry for not being bold enough to just add it. I just registered in the wiki so maybe it can be found elsewhere. My addition would be in the context of the 50%-attack a subsection on feasibility of obtaining the necessary computational power (20.000 PCs with several high end video cards each ...) and the ways to get that computational power for a small budget via a pool.

Imagine the following scenario:

• Pool (E)vil registers as a miner with Pool (G)ood.
• G assigns work to E as to any other miner.
• E assigns it on to its miners.
• The miners provide proof of work and found blocks.
• E hands on the proof of work part to G but not the found blocks.
• Other miners at G still find some blocks.
• G distributes the reward among all according to their proof of work.

This way G will be less profitable and even compensates part of E's effort to attack them. This way E could stay the biggest shark in the pool pool in the network once it got there by dedicating some miners to each pool with a potential to compete. With the biggest pool at more than 50% we are back at above described problem of one player being able to control what gets in to the chain and what not.

Spamming transactions

The maximum size of a block is stated as being 1MB. The current bitcoin.org client tops out a 0.5 MB, but that could be increased to 1 MB without requiring a hard fork, if I remember correctly.

Also, the part that reads "but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees" is unclear to me. That likely is referring to the old min fee (0.01, now 0.0005), but what does the spending transaction fees mean?