Talk:Weaknesses: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Giszmo (talk | contribs)
→‎Pools: new section
Sgornick (talk | contribs)
Move speculation from the article to here.
Line 4: Line 4:


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.
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.
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. - [[User:Sgornick|Sgornick]] ([[User talk:Sgornick|talk]]) 06:39, 29 September 2012 (GMT)
=== Illegal Content In the Blockchain ===
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 ==
== Pools ==

Revision as of 06:39, 29 September 2012

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)

Wallet Vulnerable To Loss

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.

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)

Illegal Content In the Blockchain

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.