7d98f798ab
Gemfile:
- Upgrade to Jekyll 3.x (3.0.1 tested). This brings several new
features I want to use, most notably *collections* which allows us
to add blog-like collections. I've converted the `_releases` and
`_alerts` pages into collections, although their plugins are
maintained to handle the Download and Active Alert features.
- Upgrade to latest Kramdown.
- Lock Less at 2.4.0. This prevents breaking our Less plugin. Jekyll
3.x provides native support for SCSS, so we may want to switch to
that in time.
- Lock HTML Proofer at 2.1.0. The most recent version was taking
forever to check our pages (I never actually got it to complete).
I'll look into it when I get more time.
Makefile:
- New `make clean` command. Jekyll 3.x by default attempts to do
incremental rebuilds. The new `jekyll clean` command cleans up the
metadata necessary for than so that a full build is performed, and
this new `make clean` command is a wrapper around it so that we
automatically do full rebuilds in the relevant cases. Note: our
plugins aren't fully compatible with the incremental rebuilds, but
I'd like to fix that in the future.
- Remove WEBrick hack to enable previewing with default URL paths (/
instead of /index.html).
- Filter out compliants from Rouge
README.md:
- Now that Alerts (_alerts) are part of a collection, the file names
are no longer parsed for dates, so instructions on adding the date
to the YAML metadata have been added.
_alerts/*:
- Now that alerts are part of a collection, the file names are no
longer parsed to provide dates, so a `date:` field has been added to
the YAML metadata.
_config.yml:
- Some variables renamed per upgrade instructions.
- Switched from old default syntax highlighter Pygments to new default
Rouge. I tried to use Rouge options to keep new output as similar
to old output as possible to making diffing easy, but Rouge adds
extra CSS class info.
- Move `_alerts` and `_releases` into Jekyll 3.x "collections", which
provide the organizational features we were using plugins to
manange. I haven't removed the old plugins because we still use
some of their features (alerts.rb provides active issue and banner
features; releases.rb provides info to Download page)
- _layouts/* can no longer provide default global metadata; that is now
provided in the new `defaults:` section in _config.yml.
_layouts/*:
- Default metadata can no longer be provided in the layout files for
collections, so I've removed it and left a message to see
_config.yml.
_plugins/*:
- Remove filter_for.rb. It's completely broken on Jekyll 3.x because
of changes to Liquid which prevent adding new arguments to the
inherited Liquid::For class. Existing uses of filter_for have been
migrated to built-in for loops prefaced by sorts.
- Remove remove-html-extension.rb: at it said in the comments, this
was a temporary hack to get us to Jekyll 3.0.
_releases/*:
- Rename all the files: prefix a v to the file name so the output html
(e.g. v10.0.0.html) is the same as the source filename (e.g.
v10.0.0.md). This is necessary to migrate them to a Jekyll collection.
- Remove %v from titles: we have to explicitly set the title, like we
used to. Again required for migration to collections.
_templates/events.html & en/rss/events.rss:
- Sort events by date and then loop with regular for loop rather than
filter_for
en/alerts.html & en/rss/alerts.rss:
- Sort alerts by date and then loop with regular for loop rather than
filter_for
en/bitcoin-core/index.md & en/version-history.html & en/rss/releases.rss:
- Sort alerts by date and then loop with regular for loop rather than
filter_for
6.2 KiB
| title | shorturl | active | date | bannerclass |
|---|---|---|---|---|
| Some Miners Generating Invalid Blocks | spv-mining | false | 2015-07-04 | alert |
This document is being updated as new information arrives. Last update: 2015-07-15 13:00. All times are UTC.
Note: this situation has not been fully resolved, and it does not appear that it will be fully resolved anytime soon. Users of the affected wallets listed below are still advised to wait additional confirmations or to switch to a safer wallet.
{% assign confs="30" %}
##Summary
Your bitcoins are safe if you received them in transactions confirmed before 2015-07-15 12: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 {{confs}} confirmations more than you would normally wait. Electrum users, please see this note.
- Bitcoin Core 0.9.4 or earlier users should wait an additional {{confs}} confirmations more than you would normally wait or upgrade to Bitcoin Core 0.10.2.
- Web wallet users should wait an additional {{confs}} 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.)
##Miners
If you pool mine, please switch to a pool that properly validates blocks. The Wiki Mining Pool Comparison page currently contains a list of known (or suspected) good and bad pools.
If you solo mine, please switch to Bitcoin Core 0.10.2.
When Will Things Go Back To Normal?
The problem is miners creating invalid blocks. Some software can detect that those blocks are invalid and reject them; other software can't detect that blocks are invalid, so they show confirmations that aren't real.
- Bitcoin Core 0.9.5 and later never had any problems because it could detect which blocks were invalid.
- Bitcoin Core 0.9.4 and earlier will never provide as much security as later versions of Bitcoin Core because it doesn't know about the additional BIP66 consensus rules. Upgrade is recommended to return to full node security.
- Lightweight (SPV) wallets are not safe for less than {{confs}} confirmations until all the major pools switch to full validation.
- Web wallets are very diverse in what infrastructure they run and how they handle double spends, so unless you know for sure that they use Bitcoin Core 0.9.5 or later for full validation, you should assume they have the same security as the lightweight wallets described above.
What's Happening
Summary: Some miners are currently generating invalid blocks. Almost all software (besides Bitcoin Core 0.9.5 and later) will accept these invalid blocks under certain conditions.
So far, the following forks of two or more blocks have occurred:
{% assign Blocks='Blocks [1]' %}
| Start date | End time | {{Blocks}} | Double Spends |
|---|---|---|---|
| 4 July @ 02:10 | 03:50 | 6 | 0 |
| 5 July @ 21:50 | 23:40 | 3 | Not yet known |
The paragraphs that follow explain the cause more throughly.
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 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.
Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far.
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.
The recommended fix, which was attempted, was to get all miners off of SPV mining and back to full validation (at least temporarily). If this happens, Bitcoin.org will reduce its current recommendation of waiting {{confs}} extra confirmations to a lower number.
Updates
- 6 July 04:00:{:#update-1} A new fork occurred starting 5 July at 21:30 with three blocks before the valid chain again became the strongest chain. See the recently-added list of forks. Reports that the situation has passed are not correct. Please continue to wait {{confs}} more confirmations than you usually would wait before accepting a transaction.
Invalid Blocks
Please see the list of invalid block hashes on the Bitcoin Wiki.