mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
- 873: Dev Docs: Remove Outdated Info From Payment Processing Section - 948: Allow Use Of Markdown For Alerts
This commit is contained in:
David A. Harding
commit
de46853640
4 changed files with 152 additions and 169 deletions
|
|
@ -1,156 +0,0 @@
|
|||
---
|
||||
title: "Some Miners Generating Invalid Blocks"
|
||||
alias: "spv-mining"
|
||||
active: true
|
||||
banner: "WARNING: many wallets currently vulnerable to double-spending of confirmed transactions (click here to read)"
|
||||
bannerclass: "alert"
|
||||
---
|
||||
{% capture markdown %}
|
||||
<p><em>This document is being updated as new information arrives. Last
|
||||
update: 2015-07-06 02:00. All times are UTC.</em></p>
|
||||
|
||||
**Note: this alert is on-going: the situation has not yet been
|
||||
resolved. ([Update #1](#update-1))**
|
||||
|
||||
{% assign confs="30" %}
|
||||
|
||||
<h2 id="summary">Summary</h2>
|
||||
|
||||
<p>Your bitcoins are safe if you received them in transactions confirmed before 2015-07-06 00:00 UTC.</p>
|
||||
|
||||
<p>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:</p>
|
||||
|
||||
<ul>
|
||||
<li markdown="span"><b>Lightweight (<a href="http://bitcoin.stackexchange.com/questions/4649/what-is-an-spv-client">SPV</a>) wallet users</b> should wait an additional {{confs}}
|
||||
confirmations more than you would normally wait. Electrum users,
|
||||
please see [this note][electrum note].</li>
|
||||
|
||||
<li><b>Bitcoin Core 0.9.4 or earlier users</b> should wait an
|
||||
additional {{confs}} confirmations more than you would normally
|
||||
wait or upgrade to <a href="/en/download">Bitcoin Core 0.10.2</a>.</li>
|
||||
|
||||
<li><b>Web wallet users</b> 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.</li>
|
||||
|
||||
<li><b>Bitcoin Core 0.9.5 or later users are unaffected.</b> (Note:
|
||||
<a href="/en/download">upgrade to 0.10.2</a> is recommended due to
|
||||
denial-of-service vulnerabilities unrelated to this alert.)</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="miners">Miners</h2>
|
||||
|
||||
<p>If you pool mine, please switch to a pool that properly validates
|
||||
blocks. The Wiki Mining Pool Comparison page currently contains a list of <a
|
||||
href="https://en.bitcoin.it/wiki/Comparison_of_mining_pools#SPV_Mining_.2F_Old_Bitcoin_Core">known (or
|
||||
suspected) good and bad pools.</a></p>
|
||||
|
||||
<p>If you solo mine, please switch to Bitcoin Core 0.10.2.</p>
|
||||
|
||||
<h2 id="solution">When Will Things Go Back To Normal?</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<ul>
|
||||
<li><b>Bitcoin Core 0.9.5 and later</b> never had any problems because
|
||||
it could detect which blocks were invalid.</li>
|
||||
|
||||
<li><b>Bitcoin Core 0.9.4 and earlier</b> will never provide as much
|
||||
security as later versions of Bitcoin Core because it doesn't know
|
||||
about the additional <a
|
||||
href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">BIP66</a>
|
||||
consensus rules. <a href="/en/download">Upgrade</a> is recommended
|
||||
to return to full node security.</li>
|
||||
|
||||
<li><b>Lightweight (SPV) wallets</b> are not safe for less than
|
||||
{{confs}} confirmations until all the major pools switch to full
|
||||
validation.</li>
|
||||
|
||||
<li><b>Web wallets</b> 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.</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="cause">What's Happening</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
So far, the following forks of two or more blocks have occurred:
|
||||
|
||||
{% assign Blocks='Blocks <sup><a href="#invalid-blocks">[1]</a></sup>' %}
|
||||
|
||||
<a name="list-of-forks" />
|
||||
|
||||
| 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.
|
||||
|
||||
<p>For several months, an increasing amount of mining hash rate has been
|
||||
signaling its intent to begin enforcing <a
|
||||
href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">BIP66</a>
|
||||
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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
## Updates
|
||||
|
||||
1. **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](#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.
|
||||
|
||||
<!--
|
||||
<div style="text-align:right">
|
||||
<i>This notice last updated: 2015-07-04 06:00 UTC</i>
|
||||
</div>
|
||||
-->
|
||||
|
||||
[electrum note]: https://en.bitcoin.it/wiki/July_2015_Forks#Electrum
|
||||
[invalid block hashes]: https://en.bitcoin.it/wiki/July_2015_Forks#Invalid_Block_Hashes
|
||||
{% endcapture %}
|
||||
{{ markdown | markdownify }}
|
||||
144
_alerts/2015-07-04-spv-mining.md
Normal file
144
_alerts/2015-07-04-spv-mining.md
Normal file
|
|
@ -0,0 +1,144 @@
|
|||
---
|
||||
title: "Some Miners Generating Invalid Blocks"
|
||||
alias: "spv-mining"
|
||||
active: true
|
||||
banner: "WARNING: many wallets currently vulnerable to double-spending of confirmed transactions (click here to read)"
|
||||
bannerclass: "alert"
|
||||
---
|
||||
*This document is being updated as new information arrives. Last
|
||||
update: 2015-07-06 02:00. All times are UTC.*
|
||||
|
||||
**Note: this alert is on-going: the situation has not yet been
|
||||
resolved. ([Update #1](#update-1))**
|
||||
|
||||
{% assign confs="30" %}
|
||||
|
||||
##Summary
|
||||
|
||||
Your bitcoins are safe if you received them in transactions confirmed before 2015-07-06 00: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][SPV]) wallet users** should wait an additional {{confs}}
|
||||
confirmations more than you would normally wait. Electrum users,
|
||||
please see [this note][electrum 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][bitcoin core].
|
||||
- **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][bitcoin core] 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][pool list].
|
||||
|
||||
If you solo mine, please switch to Bitcoin Core 0.10.2.
|
||||
|
||||
<h2 id="solution">When Will Things Go Back To Normal?</h2>
|
||||
|
||||
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][BIP66]
|
||||
consensus rules. [Upgrade][bitcoin core] 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.
|
||||
|
||||
<h2 id="cause">What's Happening</h2>
|
||||
|
||||
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 <sup><a href="#invalid-blocks">[1]</a></sup>' %}
|
||||
|
||||
<a name="list-of-forks" />
|
||||
|
||||
| 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][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
|
||||
|
||||
1. **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](#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.
|
||||
|
||||
<!--
|
||||
<div style="text-align:right">
|
||||
<i>This notice last updated: 2015-07-04 06:00 UTC</i>
|
||||
</div>
|
||||
-->
|
||||
|
||||
[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
|
||||
[pool list]: https://en.bitcoin.it/wiki/Comparison_of_mining_pools#SPV_Mining_.2F_Old_Bitcoin_Core
|
||||
[bitcoin core]: /en/download
|
||||
[SPV]: http://bitcoin.stackexchange.com/questions/4649/what-is-an-spv-client
|
||||
[electrum note]: https://en.bitcoin.it/wiki/July_2015_Forks#Electrum
|
||||
[invalid block hashes]: https://en.bitcoin.it/wiki/July_2015_Forks#Invalid_Block_Hashes
|
||||
|
|
@ -17,10 +17,6 @@ can, respectively, request and make payments using Bitcoin---and how
|
|||
they can deal with complications such as refunds and recurrent
|
||||
rebilling.
|
||||
|
||||
Bitcoin payment processing is being actively developed at the moment, so
|
||||
each subsection below attempts to describe what's widely deployed now,
|
||||
what's new, and what might be coming before the end of 2014.
|
||||
|
||||
|
||||
|
||||
The figure above illustrates payment processing using Bitcoin from a
|
||||
|
|
@ -410,10 +406,7 @@ otherwise-proven information.
|
|||
Bob was paid the specified number of satoshis.
|
||||
|
||||
If a refund needs to be issued, Bob's server can safely pay the
|
||||
refund-to pubkey script provided by Charlie. (Note: a proposal has been
|
||||
discussed to give refund-to addresses an implicit expiration date so
|
||||
users and software don't need to worry about payments being sent to
|
||||
addresses which are no longer monitored.) See the Refunds section below
|
||||
refund-to pubkey script provided by Charlie. See the Refunds section below
|
||||
for more details.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
|
@ -549,10 +542,11 @@ This leaves receivers only two correct ways to issue refunds:
|
|||
* If the payment protocol was used, send the refund to the output
|
||||
listed in the `refund_to` field of the Payment message.
|
||||
|
||||
As discussed in the Payment section, `refund_to` addresses may come with
|
||||
implicit expiration dates, so you may need to revert to contacting the
|
||||
Note: it would be wise to contact the
|
||||
spender directly if the refund is being issued a long time after the
|
||||
original payment was made.
|
||||
This allows you to ensure the user still has access to the key or keys
|
||||
for the `refund_to` address.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ module Jekyll
|
|||
@base = base
|
||||
@dir = '/'+dstdir
|
||||
@name = dst
|
||||
extension = dst.split('.')[-1]
|
||||
self.process(dst)
|
||||
self.read_yaml(File.join(base, srcdir), src)
|
||||
self.data['lang'] = lang
|
||||
|
|
@ -38,7 +39,7 @@ module Jekyll
|
|||
self.data['category'] = 'alert'
|
||||
if self.data.has_key?('banner') and !self.data['banner'].nil? and self.data['banner'].length>0
|
||||
site.config['ALERT']=self.data['banner']
|
||||
site.config['ALERTURL']='/'+dstdir+'/'+dst.gsub('.html','')
|
||||
site.config['ALERTURL']='/'+dstdir+'/'+dst.gsub('.html','').gsub('.md','')
|
||||
if self.data.has_key?('bannerclass') and !self.data['bannerclass'].nil? and self.data['bannerclass'].length>0
|
||||
site.config['ALERTCLASS'] = self.data['bannerclass']
|
||||
end
|
||||
|
|
@ -47,8 +48,8 @@ module Jekyll
|
|||
site.config['STATUS'] = 1
|
||||
end
|
||||
if self.data.has_key?('alias')
|
||||
site.pages << AlertPage.new(site, base, lang, srcdir, src, '', self.data['alias']+'.html', date)
|
||||
site.pages << AlertPage.new(site, base, lang, srcdir, src, '', self.data['alias']+'/index.html', date)
|
||||
site.pages << AlertPage.new(site, base, lang, srcdir, src, '', self.data['alias']+'.'+extension, date)
|
||||
site.pages << AlertPage.new(site, base, lang, srcdir, src, '', self.data['alias']+'/index.'+extension, date)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue