Summary
Your bitcoins are safe if you received them in transactions confirmed before 2015-07-04 15:00 UTC.
However, there has been a problem with a planned upgrade. For bitcoins received later than the time above, confirmation scores are significantly less reliable then they usually are for users of certain software:
- Lightweight (SPV) wallet users should wait an additional 30 confirmations more than you would normally wait.
- Bitcoin Core 0.9.4 or earlier users should wait an additional 30 confirmations more than you would normally wait or upgrade to Bitcoin Core 0.10.2.
- Web wallet users should wait an additional 30 confirmations more than you would normally wait, unless you know for sure that your wallet is secured by Bitcoin Core 0.9.5 or later.
- Bitcoin Core 0.9.5 or later users are unaffected. (Note: upgrade to 0.10.2 is recommended due to denial-of-service vulnerabilities unrelated to this alert.)
[More after the break.]
The incident status page describes the cause of the problem:
For several months, an increasing amount of mining hash rate has been signaling its intent to begin enforcing BIP66 strict DER signatures. As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks.
Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block.
It further describes the impact of this on Bitcoin users:
All software that assumes blocks are valid (because invalid blocks cost miners money) is at risk of showing transactions as confirmed when they really aren't. This particularly affects lightweight (SPV) wallets and software such as old versions of Bitcoin Core which have been downgraded to SPV-level security by the new BIP66 consensus rules
There has already been lost revenue as a result of this incident, with the status page stating "several large miners have lost over $50,000 dollars worth of mining income so far." The status page will be updated as this situation unfolds. There is currently a big red warning message at the top of their status page that prominently states: "many wallets currently vulnerable to double-spending of confirmed transactions."
[Update: corrected links to 0.10.2 - Ed.]
(Score: 4, Informative) by Anonymous Coward on Sunday July 05 2015, @01:43PM
That's how it was supposed to be. The problem is that a large percentage of the miners who generate v3 blocks don't actually enforce the v2 rejection, so the 95% v3 creation threshold was reached, but much more than 5% of the miners still accept v2 blocks. That leads to more and longer than expected blockchain fragments being created which have invalid blocks in them. Eventually these chains are rejected, but it can take a while due to the large number of miners that don't follow the protocol, hence the recommendation to wait for more confirmations. If you see a transaction on an invalid blockchain and your client does not itself reject the chain, then you might be inclined to trust that it actually happened. The transaction can then be "repeated" (actually performed) on a/the valid blockchain. This creates an opportunity for double spending.
Blockchain splits happen all the time as a normal effect of the distributed race to solve the next block. That's why you need to wait for several confirmations (i.e. until your transaction has enough computations piled on top of it) to be reasonably sure that you're on the right chain. Due to a large scale implementation weakness, the amount of computation needed to be sure that you're on the right chain is currently larger than normal, if you're using a client which doesn't strictly verify the blockchain.
(Score: 2) by cosurgi on Monday July 06 2015, @08:43AM
Thanks, I didn't know this part.
#
#\ @ ? [adom.de] Colonize Mars [kozicki.pl]
#