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.

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?

Majority Attack

The majority attack may not be limited to reversing transactions and double spend. With an increasing number of derivatives in circulation based on Bitcoin, those on the short side of the bet may have both significant funding, and significant interest in seeing bitcoin's value go down. It is therefore possible we may see a well funded attack against Bitcoin aimed at blocking transaction clearance. The cost of an attack would be between $1Bn - $4Bn as of writing. The effects of one of the more effective game plans could be mitigated to some degree by adopting a re-targeting algorithm like digishield V3. This should be adoptable relatively uncontroversially, before an attack occurs, since no good players in the market should be adversely affected by it. If this fails, we may need a totally different POW algorithm - in which case, miner's and user's interests will be at odds. Nickhill (talk) 15:23, 7 November 2017 (UTC)