mirror of
https://github.com/actions/setup-node.git
synced 2025-04-22 03:28:42 +00:00
4837 lines
462 KiB
XML
4837 lines
462 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
||
<channel>
|
||
<title>Bitcoin Core</title>
|
||
<description></description>
|
||
<link>https://bitcoincore.org</link>
|
||
<atom:link href="https://bitcoincore.org/en/rss.xml" rel="self" type="application/rss+xml" />
|
||
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.21.1 Released With Taproot Activation Code</title>
|
||
<description><p>Bitcoin Core version 0.21.1 is now available for <a href="/en/download">download</a>. As described in detail in the <a href="/en/releases/0.21.1/">release notes</a>, miner block
|
||
templates produced by this version of Bitcoin Core will signal readiness
|
||
to enforce taproot during the roughly three month period specified by
|
||
BIP341.</p>
|
||
|
||
<p>If, during that time, 90% of blocks within a 2,016 retarget period
|
||
signal readiness, taproot will be locked in and this version of Bitcoin
|
||
Core will begin enforcing the additional consensus rules specified in
|
||
BIPs 341 and 342 at block 709,632, which is expected in early or mid
|
||
November.</p>
|
||
|
||
<p>If miners don’t lock in taproot by the end of the three month signaling
|
||
period, a separate attempt to activate it using another mechanism is
|
||
expected to be tried. The activation mechanism has been designed so
|
||
that, by roughly mid August, it will either provide us with an assurance
|
||
that we’ll soon have taproot or immediately give us valuable information
|
||
that users and developers can use to make the next activation attempt
|
||
more likely to succeed.</p>
|
||
|
||
<p><strong>Note:</strong> due to a <a href="https://github.com/bitcoin-core/gui/issues/252#issuecomment-802591628">problem</a> with the certificate authority
|
||
that provides the code signing certificates for the Windows versions of
|
||
Bitcoin Core, users on Windows will need to click through an extra
|
||
prompt to install. It is also expected that there will be a 0.21.1.1
|
||
release with an updated certificate when the problem is fixed. If you
|
||
are planning to upgrade anyway, there’s no reason to delay using 0.21.1
|
||
because of this problem.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/#bitcoin">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Sat, 01 May 2021 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2021/05/01/release-0.21.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2021/05/01/release-0.21.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.21.0 Released</title>
|
||
<description><p>Bitcoin Core version 0.21.0 is now available for <a href="/en/download">download</a>. For a complete list of changes in this new major version release,
|
||
please see the <a href="/en/releases/0.21.0/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/#bitcoin">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Thu, 14 Jan 2021 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2021/01/14/release-0.21.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2021/01/14/release-0.21.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.20.1 Released</title>
|
||
<description><p>Bitcoin Core version 0.20.1 is now available for <a href="/en/download">download</a>. For a complete list of changes in this new major version release,
|
||
please see the <a href="/en/releases/0.20.1/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/#bitcoin">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Sat, 01 Aug 2020 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2020/08/01/release-0.20.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2020/08/01/release-0.20.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.20.0 Released</title>
|
||
<description><p>Bitcoin Core version 0.20.0 is now available for <a href="/en/download">download</a>. For a complete list of changes in this new major version release,
|
||
please see the <a href="/en/releases/0.20.0/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/#bitcoin">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Wed, 03 Jun 2020 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2020/06/03/release-0.20.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2020/06/03/release-0.20.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>bitcoincore.org hidden service</title>
|
||
<description><p>After frequent requests, this site is now reachable as a Tor hidden service
|
||
through an onion address:</p>
|
||
|
||
<p><a href="http://6hasakffvppilxgehrswmffqurlcjjjhd76jgvaqmsg6ul25s7t3rzyd.onion/">http://6hasakffvppilxgehrswmffqurlcjjjhd76jgvaqmsg6ul25s7t3rzyd.onion/</a></p>
|
||
|
||
<p>As well as adding another means of censorship resistance, a hidden
|
||
service gives an alternative trust path that doesn’t rely on certificate
|
||
authorities nor DNS infrastructure.</p>
|
||
</description>
|
||
<pubDate>Fri, 27 Mar 2020 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2020/03/27/hidden-service/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2020/03/27/hidden-service/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.19.1 Released</title>
|
||
<description><p>Bitcoin Core version 0.19.1 is now available for <a href="/en/download">download</a>. For a complete list of changes in this maintenance release,
|
||
please see the <a href="/en/releases/0.19.1/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/?channels=bitcoin&amp;uio=d4">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Mon, 09 Mar 2020 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2020/03/09/release-0.19.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2020/03/09/release-0.19.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.19.0 Released</title>
|
||
<description><p>Bitcoin Core version 0.19.0 is now available for <a href="/en/download">download</a> containing multiple improvements and bug fixes For a complete list
|
||
of changes in this maintenance release, please see the <a href="/en/releases/0.19.0.1/">release
|
||
notes</a>. Due to an issue that only came to light just after
|
||
the rc process, the download is for 0.19.0.1 instead of 0.19.0.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/?channels=bitcoin&amp;uio=d4">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Sun, 24 Nov 2019 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2019/11/24/release-0.19.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2019/11/24/release-0.19.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>CVE-2017-18350 Disclosure</title>
|
||
<description><p>Disclosure of the details of CVE-2017-18350, a fix for which was released on November 6th, 2017 in Bitcoin Core version 0.15.1.</p>
|
||
|
||
<h1 id="technical-details">Technical Details</h1>
|
||
<p>CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed <code class="highlighter-rouge">char</code> type (including common 32-bit and 64-bit x86 PCs).</p>
|
||
|
||
<p>The vulnerability was introduced in <a href="https://github.com/bitcoin/bitcoin/commit/60a87bce873ce1f76a80b7b8546e83a0cd4e07a5">60a87bce873 (SOCKS5 support)</a> and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27. A fix was hidden in <a href="https://github.com/bitcoin/bitcoin/commit/d90a00eabed0f3f1acea4834ad489484d0012372">d90a00eabed (“Improve and document SOCKS code”)</a> released in v0.15.1, 2017 Nov 6.</p>
|
||
|
||
<p>To be vulnerable, the node must be configured to use such a malicious proxy in the first place. Note that using <em>any</em> proxy over an insecure network (such as the Internet) is potentially a vulnerability since the connection could be intercepted for such a purpose.</p>
|
||
|
||
<p>Upon a connection request from the node, the malicious proxy would respond with an acknowledgement of a different target domain name than the one requested. Normally this acknowledgement is entirely ignored, but if the length uses the high bit (ie, a length 128-255 inclusive), it will be interpreted by vulnerable versions as a negative number instead. When the negative number is passed to the recv() system call to read the domain name, it is converted back to an unsigned/positive number, but at a much wider size (typically 32-bit), resulting in an effectively infinite read into and beyond the 256-byte dummy stack buffer.</p>
|
||
|
||
<p>To fix this vulnerability, the dummy buffer was changed to an explicitly unsigned data type, avoiding the conversion to/from a negative number.</p>
|
||
|
||
<h1 id="attribution">Attribution</h1>
|
||
<p>Credit goes to <a href="https://twitter.com/practicalswift">practicalswift</a> for discovering and providing the initial fix for the vulnerability, and Wladimir J. van der Laan for a disguised version of the fix as well as general cleanup to the at-risk code.</p>
|
||
|
||
<h1 id="timeline">Timeline</h1>
|
||
|
||
<ul>
|
||
<li>2012-04-01: Vulnerability introduced in PR #1141.</li>
|
||
<li>2012-05-08: Vulnerability merged to master git repository.</li>
|
||
<li>2012-08-27: Vulnerability published in v0.7.0rc1.</li>
|
||
<li>2012-09-17: Vulnerability released in v0.7.0.</li>
|
||
<li>…</li>
|
||
<li>2017-09-21: practicalswift discloses vulnerability to security team.</li>
|
||
<li>2017-09-23: Wladimir opens PR #11397 to quietly fix vulnerability.</li>
|
||
<li>2017-09-27: Fix merged to master git repository.</li>
|
||
<li>2017-10-18: Fix merged to 0.15 git repository.</li>
|
||
<li>2017-11-04: Fix published in v0.15.1rc1.</li>
|
||
<li>2017-11-09: Fix released in v0.15.1.</li>
|
||
<li>…</li>
|
||
<li>2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.</li>
|
||
<li>2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.</li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Fri, 08 Nov 2019 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2019/11/08/CVE-2017-18350/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2019/11/08/CVE-2017-18350/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.18.1 Released</title>
|
||
<description><p>Bitcoin Core version 0.18.1 is now available for <a href="/en/download">download</a> containing several bug fixes and other improvements. For a
|
||
complete list of changes in this maintenance release, please see the
|
||
<a href="/en/releases/0.18.1/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/?channels=bitcoin&amp;uio=d4">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Fri, 09 Aug 2019 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2019/08/09/release-0.18.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2019/08/09/release-0.18.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.18.0 Released</title>
|
||
<description><p>Bitcoin Core version 0.18.0 is now available for <a href="/en/download">download</a> containing several bug fixes and minor improvements. For a
|
||
complete list of changes, please see the <a href="/en/releases/0.18.0/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by the #bitcoin IRC chatroom
|
||
(<a href="irc://irc.freenode.net/bitcoin">IRC</a>, <a href="https://webchat.freenode.net/?channels=bitcoin&amp;uio=d4">web</a>) and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Thu, 02 May 2019 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2019/05/02/release-0.18.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2019/05/02/release-0.18.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.17.1 Released</title>
|
||
<description><p>Bitcoin Core version 0.17.1 is now available for <a href="/en/download">download</a> containing several bug fixes and minor improvements. For a
|
||
complete list of changes, please see the <a href="/en/releases/0.17.1/">release notes</a>.</p>
|
||
|
||
<p>If have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC chatroom</a> and we’ll
|
||
do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 25 Dec 2018 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/12/25/release-0.17.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/12/25/release-0.17.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.17.0 Released</title>
|
||
<description><p>Bitcoin Core version 0.17.0 is now available for <a href="/en/download">download</a> containing many new features as well as bug fixes and other
|
||
improvements. For a complete list of changes, please see the <a href="/en/releases/0.17.0/">release
|
||
notes</a>.</p>
|
||
|
||
<p>This release is not vulnerable to the <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17144">CVE-2018-17144</a> duplicate
|
||
inputs bug.</p>
|
||
|
||
<p>If have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC chatroom</a> and we’ll
|
||
do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 02 Oct 2018 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/10/02/release-0.17.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/10/02/release-0.17.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>CVE-2018-17144 Full Disclosure</title>
|
||
<description><h1 id="full-disclosure">Full disclosure</h1>
|
||
<p>CVE-2018-17144, a fix for which was released on September 18th in Bitcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of Service component and a critical inflation vulnerability. It was originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited on September 17th as a Denial of Service bug only, however we quickly determined that the issue was also an inflation vulnerability with the same root cause and fix.</p>
|
||
|
||
<p>In order to encourage rapid upgrades, the decision was made to immediately patch and disclose the less serious Denial of Service vulnerability, concurrently with reaching out to miners, businesses, and other affected systems while delaying publication of the full issue to give times for systems to upgrade. On September 20th a post in a public forum reported the full impact and although it was quickly retracted the claim was further circulated.</p>
|
||
|
||
<p>At this time we believe over half of the Bitcoin hashrate has upgraded to patched nodes. We are unaware of any attempts to exploit this vulnerability.</p>
|
||
|
||
<p>However, it still remains critical that affected users upgrade and apply the latest patches to ensure no possibility of large reorganizations, mining of invalid blocks, or acceptance of invalid transactions occurs.</p>
|
||
|
||
<h1 id="technical-details">Technical Details</h1>
|
||
|
||
<p>In Bitcoin Core 0.14, an optimization was added (Bitcoin Core PR #9049) which avoided a costly check during initial pre-relay block validation that multiple inputs within a single transaction did not spend the same input twice which was added in 2012 (PR #443). While the UTXO-updating logic has sufficient knowledge to check that such a condition is not violated in 0.14 it only did so in a sanity check assertion and not with full error handling (it did, however, fully handle this case twice in prior to 0.8).</p>
|
||
|
||
<p>Thus, in Bitcoin Core 0.14.X, any attempts to double-spend a transaction output within a single transaction inside of a block will result in an assertion failure and a crash, as was originally reported.</p>
|
||
|
||
<p>In Bitcoin Core 0.15, as a part of a larger redesign to simplify unspent transaction output tracking and correct a resource exhaustion attack the assertion was changed subtly. Instead of asserting that the output being marked spent was previously unspent, it only asserts that it exists.</p>
|
||
|
||
<p>Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur (as exists in the test case which was included in the 0.16.3 patch). However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion. This could allow a miner to inflate the supply of Bitcoin as they would be then able to claim the value being spent twice.</p>
|
||
|
||
<h1 id="timeline">Timeline</h1>
|
||
|
||
<p>Timeline for September 17, 2018: (all times UTC)</p>
|
||
|
||
<ul>
|
||
<li>14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg Maxwell, Wladimir Van Der Laan of Bitcoin Core, deadalnix of Bitcoin ABC, and sickpig of Bitcoin Unlimited.</li>
|
||
<li>15:15 Greg Maxwell shares the original report with Cory Fields, Suhas Daftuar, Alex Morcos and Matt Corallo</li>
|
||
<li>17:47 Matt Corallo identifies inflation bug</li>
|
||
<li>19:15 Matt Corallo first tries to reach slushpool CEO to have a line of communication open to apply a patch quickly</li>
|
||
<li>19:29 Greg Maxwell timestamps the hash of a test-case which demonstrates the inflation vulnerability (a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350)</li>
|
||
<li>20:15 John Newbery and James O’Beirne are informed of the vulnerability so they can assist in alerting companies to a pending patch for a DoS vulnerability</li>
|
||
<li>20:30 Matt Corallo speaks with slushpool CTO and CEO and shares patch with disclosure of the Denial of Service</li>
|
||
<li>20:48 slushpool confirmed upgraded</li>
|
||
<li>21:08 Alert was sent to Bitcoin ABC that a patch will be posted publicly by 22:00</li>
|
||
<li>21:30 (approx) Responded to original reporter with an acknowledgment</li>
|
||
<li>21:57 Bitcoin Core PR 14247 published with patch and test demonstrating the Denial of Service bug</li>
|
||
<li>21:58 Bitcoin ABC publishes their patch</li>
|
||
<li>22:07 Advisory email with link to Bitcoin Core PR and patch goes out to Optech members, among others</li>
|
||
<li>23:21 Bitcoin Core version 0.17.0rc4 tagged</li>
|
||
</ul>
|
||
|
||
<p>September 18, 2018:</p>
|
||
|
||
<ul>
|
||
<li>00:24 Bitcoin Core version 0.16.3 tagged</li>
|
||
<li>20:44 Bitcoin Core release binaries and release announcements were available</li>
|
||
<li>21:47 Bitcointalk and reddit have public banners urging people to upgrade</li>
|
||
</ul>
|
||
|
||
<p>September 19, 2018:</p>
|
||
|
||
<ul>
|
||
<li>14:06 The mailing list distributes an additional message urging people to upgrade by Pieter Wuille</li>
|
||
</ul>
|
||
|
||
<p>September 20, 2018:</p>
|
||
|
||
<ul>
|
||
<li>19:50 David Jaenson independently discovered the vulnerability, and it was reported to the Bitcoin Core security contact email.</li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Thu, 20 Sep 2018 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/09/20/notice/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/09/20/notice/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.16.3 Released</title>
|
||
<description><p>Bitcoin Core version 0.16.3 is now available for <a href="/en/download">download</a> with a fix for a denial-of-service vulnerability introduced in
|
||
Bitcoin Core 0.14.0 and affecting all subsequent versions though to
|
||
0.16.2. We highly recommend users of all affected versions immediately
|
||
upgrade to 0.16.3.</p>
|
||
|
||
<p>Security issue <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17144">CVE-2018-17144</a>: it was discovered that older versions of Bitcoin Core
|
||
will crash if they try to process a block containing a transaction that
|
||
attempts to spend the same input twice. Such blocks are invalid, so
|
||
they can only be created by a miner willing to sacrifice their allowed
|
||
income for creating a block of at least 12.5 BTC (about $80,000 USD as
|
||
of this writing). This release eliminates the crash, allowing the
|
||
software to quietly reject such invalid blocks.</p>
|
||
|
||
<p>For a complete list of changes, please see the <a href="/en/releases/0.16.3/">release notes</a>. If
|
||
have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC chatroom</a> and we’ll do
|
||
our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 18 Sep 2018 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/09/18/release-0.16.3/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/09/18/release-0.16.3/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.16.2 Released</title>
|
||
<description><p>Bitcoin Core version 0.16.2 is now available for <a href="/en/download">download</a>. All users are encouraged to upgrade to this <a href="/en/lifecycle/#maintenance-releases">maintenance
|
||
release</a> that fixes several bugs and provides backports of new minor
|
||
features, such as:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>The <a href="/en/doc/0.16.2/rpc/blockchain/verifytxoutproof/">verifytxoutproof RPC</a> is no longer
|
||
vulnerable to a particular <a href="https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/">expensive attack</a>
|
||
against SPV proofs publicly disclosed in early June. The attack was
|
||
considered unlikely given that much cheaper attacks of roughly equal
|
||
effectiveness are well known. Similarly, the <a href="/en/doc/0.16.2/rpc/blockchain/getblock/">getblock RPC</a> also now returns extra information that can be used to
|
||
defeat this attack even if the requested block has been pruned. None
|
||
of this mitigates the attack for actual SPV clients.</p>
|
||
</li>
|
||
<li>
|
||
<p>The <a href="/en/doc/0.16.2/rpc/wallet/abandontransaction/">abandontransaction RPC</a> has been fixed
|
||
to abandon all descendant transactions, not just children. As before,
|
||
you can call this RPC when you no longer want your wallet to
|
||
re-broadcast an old unconfirmed transaction. Note that the RPC can not
|
||
force miners or other nodes to forget about the transaction.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>For a complete list of changes, please see the <a href="/en/releases/0.16.2/">release notes</a>. If
|
||
have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC chatroom</a> and we’ll do
|
||
our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Sun, 29 Jul 2018 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/07/29/release-0.16.2/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/07/29/release-0.16.2/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.16.1 Released</title>
|
||
<description><p>Bitcoin Core version 0.16.1 is now available for <a href="/en/download">download</a>. All users are encouraged to upgrade to this <a href="/en/lifecycle/#maintenance-releases">maintenance
|
||
release</a> that fixes several bugs and provides backports of new minor
|
||
features, such as:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Mitigating a vector for denial-of-service attacks. This attack required
|
||
compromising particular services and would’ve probably been most
|
||
effective against nodes that were started for the first time (rather
|
||
than nodes that had already been connected to the network for more
|
||
than a few hours).</p>
|
||
</li>
|
||
<li>
|
||
<p>Fixing a bug that could’ve potentially caused miners to lose revenue if
|
||
they produced two blocks in very rapid succession.</p>
|
||
</li>
|
||
<li>
|
||
<p>Ceasing relay of transactions using the rarely-seen <code class="highlighter-rouge">OP_CODESEPARATOR</code> opcode for legacy
|
||
(non-segwit) signature scripts. The presence of this opcode makes it
|
||
difficult for nodes to estimate how much computational work will be
|
||
required to validate a legacy signature script. Because of that, it
|
||
blocks the deployment of solutions to prevent attackers from creating
|
||
blocks that require a long time to validate. By itself, this change
|
||
to relay policy doesn’t fix the problem itself, but it does make it
|
||
easier and safer to deploy proposed solutions in the future should
|
||
users consent to adopt them.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>For a complete list of changes, please see the <a href="/en/releases/0.16.1/">release notes</a>. If
|
||
have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC chatroom</a> and we’ll do
|
||
our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Fri, 15 Jun 2018 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/06/15/release-0.16.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/06/15/release-0.16.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.16.0 Released</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#segwit-wallet" id="markdown-toc-segwit-wallet">Segwit Wallet</a></li>
|
||
<li><a href="#bip173-bech32-address-support-bc1-addresses" id="markdown-toc-bip173-bech32-address-support-bc1-addresses">BIP173 (Bech32) Address support (“bc1…” addresses)</a></li>
|
||
<li><a href="#hd-wallets-by-default" id="markdown-toc-hd-wallets-by-default">HD-wallets by default</a></li>
|
||
<li><a href="#replace-by-fee-by-default-in-gui" id="markdown-toc-replace-by-fee-by-default-in-gui">Replace-By-Fee by default in GUI</a></li>
|
||
<li><a href="#wallets-directory-configuration" id="markdown-toc-wallets-directory-configuration">Wallets directory configuration</a></li>
|
||
<li><a href="#support-for-signalling-pruned-nodes-bip159" id="markdown-toc-support-for-signalling-pruned-nodes-bip159">Support for signalling pruned nodes (BIP159)</a></li>
|
||
<li><a href="#performance-sha256-assembly-enabled-by-default" id="markdown-toc-performance-sha256-assembly-enabled-by-default">Performance: SHA256 assembly enabled by default</a></li>
|
||
<li><a href="#gui-changes" id="markdown-toc-gui-changes">GUI changes</a></li>
|
||
<li><a href="#new-rescanblockchain-rpc" id="markdown-toc-new-rescanblockchain-rpc">New rescanblockchain RPC</a></li>
|
||
<li><a href="#new-savemempool-rpc" id="markdown-toc-new-savemempool-rpc">New savemempool RPC</a></li>
|
||
<li><a href="#safe-mode-disabled-by-default" id="markdown-toc-safe-mode-disabled-by-default">Safe mode disabled by default</a></li>
|
||
<li><a href="#renamed-script-for-creating-json-rpc-credentials" id="markdown-toc-renamed-script-for-creating-json-rpc-credentials">Renamed script for creating JSON-RPC credentials</a></li>
|
||
<li><a href="#validateaddress-improvements" id="markdown-toc-validateaddress-improvements">Validateaddress improvements</a></li>
|
||
<li><a href="#low-level-changes" id="markdown-toc-low-level-changes">Low-level changes</a></li>
|
||
<li><a href="#other-changed-command-line-options" id="markdown-toc-other-changed-command-line-options">Other changed command-line options</a></li>
|
||
<li><a href="#testing-changes" id="markdown-toc-testing-changes">Testing changes</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We are pleased to announce the release of Bitcoin Core 0.16.0, the first
|
||
version of Bitcoin Core to include default wallet support for segregated
|
||
witness (segwit). The release also contains several other improvements
|
||
and bug fixes as described below.</p>
|
||
|
||
<p>The latest release is available for download from the <a href="/en/download">Download
|
||
Page</a></p>
|
||
|
||
<p>The following sections describe the most significant changes in this
|
||
release. For full details, please see the <a href="/en/releases/0.16.0/">Release Notes</a>.</p>
|
||
|
||
<h3 id="segwit-wallet">Segwit Wallet</h3>
|
||
|
||
<p>Bitcoin Core 0.16.0 introduces full support for segwit in the wallet and user interfaces. A new <code class="highlighter-rouge">-addresstype</code> argument has been added, which supports <code class="highlighter-rouge">legacy</code>, <code class="highlighter-rouge">p2sh-segwit</code> (default), and <code class="highlighter-rouge">bech32</code> addresses. It controls what kind of addresses are produced by <code class="highlighter-rouge">getnewaddress</code>, <code class="highlighter-rouge">getaccountaddress</code>, and <code class="highlighter-rouge">createmultisigaddress</code>. A <code class="highlighter-rouge">-changetype</code> argument has also been added, with the same options, and by default equal to <code class="highlighter-rouge">-addresstype</code>, to control which kind of change is used.</p>
|
||
|
||
<p>A new <code class="highlighter-rouge">address_type</code> parameter has been added to the <code class="highlighter-rouge">getnewaddress</code> and <code class="highlighter-rouge">addmultisigaddress</code> RPCs to specify which type of address to generate.
|
||
A <code class="highlighter-rouge">change_type</code> argument has been added to the <code class="highlighter-rouge">fundrawtransaction</code> RPC to override the <code class="highlighter-rouge">-changetype</code> argument for specific transactions.</p>
|
||
|
||
<ul>
|
||
<li>All segwit addresses created through <code class="highlighter-rouge">getnewaddress</code> or <code class="highlighter-rouge">*multisig</code> RPCs explicitly get their redeemscripts added to the wallet file. This means that downgrading after creating a segwit address will work, as long as the wallet file is up to date.</li>
|
||
<li>All segwit keys in the wallet get an implicit redeemscript added, without it being written to the file. This means recovery of an old backup will work, as long as you use new software.</li>
|
||
<li>All keypool keys that are seen used in transactions explicitly get their redeemscripts added to the wallet files. This means that downgrading after recovering from a backup that includes a segwit address will work</li>
|
||
</ul>
|
||
|
||
<p>Note that some RPCs do not yet support segwit addresses. Notably, <code class="highlighter-rouge">signmessage</code>/<code class="highlighter-rouge">verifymessage</code> doesn’t support segwit addresses, nor does <code class="highlighter-rouge">importmulti</code> at this time. Support for segwit in those RPCs will continue to be added in future versions.</p>
|
||
|
||
<p>P2WPKH change outputs are now used by default if any destination in the transaction is a P2WPKH or P2WSH output. This is done to ensure the change output is as indistinguishable from the other outputs as possible in either case.</p>
|
||
|
||
<h3 id="bip173-bech32-address-support-bc1-addresses">BIP173 (Bech32) Address support (“bc1…” addresses)</h3>
|
||
|
||
<p>Full support for native segwit addresses (BIP173 / Bech32) has now been added.
|
||
This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these
|
||
addresses (including as default new addresses, see above).</p>
|
||
|
||
<p>A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with <code class="highlighter-rouge">-addresstype=bech32</code> it is checked by default. When launched with <code class="highlighter-rouge">-addresstype=legacy</code> it is unchecked and disabled.</p>
|
||
|
||
<h3 id="hd-wallets-by-default">HD-wallets by default</h3>
|
||
|
||
<p>Due to a backward-incompatible change in the wallet database, wallets created
|
||
with version 0.16.0 will be rejected by previous versions. Also, version 0.16.0
|
||
will only create hierarchical deterministic (HD) wallets. Note that this only applies
|
||
to new wallets; wallets made with previous versions will not be upgraded to be HD.</p>
|
||
|
||
<h3 id="replace-by-fee-by-default-in-gui">Replace-By-Fee by default in GUI</h3>
|
||
|
||
<p>The send screen now uses BIP125 RBF by default, regardless of <code class="highlighter-rouge">-walletrbf</code>.
|
||
There is a checkbox to mark the transaction as final.</p>
|
||
|
||
<p>The RPC default remains unchanged: to use RBF, launch with <code class="highlighter-rouge">-walletrbf=1</code> or
|
||
use the <code class="highlighter-rouge">replaceable</code> argument for individual transactions.</p>
|
||
|
||
<h3 id="wallets-directory-configuration">Wallets directory configuration</h3>
|
||
|
||
<p>Bitcoin Core now has more flexibility in where the wallets directory can be
|
||
located. Previously wallet database files were stored at the top level of the
|
||
bitcoin data directory. The behavior is now:</p>
|
||
|
||
<ul>
|
||
<li>For new installations (where the data directory doesn’t already exist),
|
||
wallets will now be stored in a new <code class="highlighter-rouge">wallets/</code> subdirectory inside the data
|
||
directory by default.</li>
|
||
<li>For existing nodes (where the data directory already exists), wallets will be
|
||
stored in the data directory root by default. If a <code class="highlighter-rouge">wallets/</code> subdirectory
|
||
already exists in the data directory root, then wallets will be stored in the
|
||
<code class="highlighter-rouge">wallets/</code> subdirectory by default.</li>
|
||
<li>The location of the wallets directory can be overridden by specifying a
|
||
<code class="highlighter-rouge">-walletdir=&lt;path&gt;</code> option where <code class="highlighter-rouge">&lt;path&gt;</code> can be an absolute path to a
|
||
directory or directory symlink.</li>
|
||
</ul>
|
||
|
||
<p>Care should be taken when choosing the wallets directory location, as if it
|
||
becomes unavailable during operation, funds may be lost.</p>
|
||
|
||
<h3 id="support-for-signalling-pruned-nodes-bip159">Support for signalling pruned nodes (BIP159)</h3>
|
||
|
||
<p>Pruned nodes can now signal BIP159’s NODE_NETWORK_LIMITED using service bits, in preparation for
|
||
full BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers.</p>
|
||
|
||
<h3 id="performance-sha256-assembly-enabled-by-default">Performance: SHA256 assembly enabled by default</h3>
|
||
|
||
<p>The SHA256 hashing optimizations for architectures supporting SSE4, which lead to ~50% speedups in SHA256 on supported hardware (~5% faster synchronization and block validation), have now been enabled by default. In previous versions they were enabled using the <code class="highlighter-rouge">--enable-experimental-asm</code> flag when building, but are now the default and no longer deemed experimental.</p>
|
||
|
||
<h3 id="gui-changes">GUI changes</h3>
|
||
|
||
<ul>
|
||
<li>Uses of “µBTC” in the GUI now also show the more colloquial term “bits”, specified in BIP176.</li>
|
||
<li>The option to reuse a previous address has now been removed. This was justified by the need to “resend” an invoice, but now that we have the request history, that need should be gone.</li>
|
||
<li>Support for searching by TXID has been added, rather than just address and label.</li>
|
||
<li>A “Use available balance” option has been added to the send coins dialog, to add the remaining available wallet balance to a transaction output.</li>
|
||
<li>A toggle for unblinding the password fields on the password dialog has been added.</li>
|
||
</ul>
|
||
|
||
<h3 id="new-rescanblockchain-rpc">New rescanblockchain RPC</h3>
|
||
|
||
<p>A new RPC <code class="highlighter-rouge">rescanblockchain</code> has been added to manually invoke a blockchain rescan.
|
||
The RPC supports start and end-height arguments for the rescan, and can be used in a
|
||
multiwallet environment to rescan the blockchain at runtime.</p>
|
||
|
||
<h3 id="new-savemempool-rpc">New savemempool RPC</h3>
|
||
|
||
<p>A new <code class="highlighter-rouge">savemempool</code> RPC has been added which allows the current mempool to be saved to
|
||
disk at any time to avoid it being lost due to crashes / power loss.</p>
|
||
|
||
<h3 id="safe-mode-disabled-by-default">Safe mode disabled by default</h3>
|
||
|
||
<p>Safe mode is now disabled by default and must be manually enabled (with <code class="highlighter-rouge">-disablesafemode=0</code>) if you wish to use it. Safe mode is a feature that disables a subset of RPC calls - mostly related to the wallet and sending - automatically in case certain problem conditions with the network are detected. However, developers have come to regard these checks as not reliable enough to act on automatically. Even with safe mode disabled, they will still cause warnings in the <code class="highlighter-rouge">warnings</code> field of the <code class="highlighter-rouge">getneworkinfo</code> RPC and launch the <code class="highlighter-rouge">-alertnotify</code> command.</p>
|
||
|
||
<h3 id="renamed-script-for-creating-json-rpc-credentials">Renamed script for creating JSON-RPC credentials</h3>
|
||
|
||
<p>The <code class="highlighter-rouge">share/rpcuser/rpcuser.py</code> script was renamed to <code class="highlighter-rouge">share/rpcauth/rpcauth.py</code>. This script can be
|
||
used to create <code class="highlighter-rouge">rpcauth</code> credentials for a JSON-RPC user.</p>
|
||
|
||
<h3 id="validateaddress-improvements">Validateaddress improvements</h3>
|
||
|
||
<p>The <code class="highlighter-rouge">validateaddress</code> RPC output has been extended with a few new fields, and support for segwit addresses (both P2SH and Bech32). Specifically:</p>
|
||
<ul>
|
||
<li>A new field <code class="highlighter-rouge">iswitness</code> is True for P2WPKH and P2WSH addresses (“bc1…” addresses), but not for P2SH-wrapped segwit addresses (see below).</li>
|
||
<li>The existing field <code class="highlighter-rouge">isscript</code> will now also report True for P2WSH addresses.</li>
|
||
<li>A new field <code class="highlighter-rouge">embedded</code> is present for all script addresses where the script is known and matches something that can be interpreted as a known address. This is particularly true for P2SH-P2WPKH and P2SH-P2WSH addresses. The value for <code class="highlighter-rouge">embedded</code> includes much of the information <code class="highlighter-rouge">validateaddress</code> would report if invoked directly on the embedded address.</li>
|
||
<li>For multisig scripts a new <code class="highlighter-rouge">pubkeys</code> field was added that reports the full public keys involved in the script (if known). This is a replacement for the existing <code class="highlighter-rouge">addresses</code> field (which reports the same information but encoded as P2PKH addresses), represented in a more useful and less confusing way. The <code class="highlighter-rouge">addresses</code> field remains present for non-segwit addresses for backward compatibility.</li>
|
||
<li>For all single-key addresses with known key (even when wrapped in P2SH or P2WSH), the <code class="highlighter-rouge">pubkey</code> field will be present. In particular, this means that invoking <code class="highlighter-rouge">validateaddress</code> on the output of <code class="highlighter-rouge">getnewaddress</code> will always report the <code class="highlighter-rouge">pubkey</code>, even when the address type is P2SH-P2WPKH.</li>
|
||
</ul>
|
||
|
||
<h3 id="low-level-changes">Low-level changes</h3>
|
||
|
||
<ul>
|
||
<li>The deprecated RPC <code class="highlighter-rouge">getinfo</code> was removed. It is recommended that the more specific RPCs are used:
|
||
<ul>
|
||
<li><code class="highlighter-rouge">getblockchaininfo</code></li>
|
||
<li><code class="highlighter-rouge">getnetworkinfo</code></li>
|
||
<li><code class="highlighter-rouge">getwalletinfo</code></li>
|
||
<li><code class="highlighter-rouge">getmininginfo</code></li>
|
||
</ul>
|
||
</li>
|
||
<li>The wallet RPC <code class="highlighter-rouge">getreceivedbyaddress</code> will return an error if called with an address not in the wallet.</li>
|
||
<li>The wallet RPC <code class="highlighter-rouge">addwitnessaddress</code> was deprecated and will be removed in version 0.17,
|
||
set the <code class="highlighter-rouge">address_type</code> argument of <code class="highlighter-rouge">getnewaddress</code>, or option <code class="highlighter-rouge">-addresstype=[bech32|p2sh-segwit]</code> instead.</li>
|
||
<li><code class="highlighter-rouge">dumpwallet</code> now includes hex-encoded scripts from the wallet in the dumpfile, and
|
||
<code class="highlighter-rouge">importwallet</code> now imports these scripts, but corresponding addresses may not be added
|
||
correctly or a manual rescan may be required to find relevant transactions.</li>
|
||
<li>The RPC <code class="highlighter-rouge">getblockchaininfo</code> now includes an <code class="highlighter-rouge">errors</code> field.</li>
|
||
<li>A new <code class="highlighter-rouge">blockhash</code> parameter has been added to the <code class="highlighter-rouge">getrawtransaction</code> RPC which allows for a raw transaction to be fetched from a specific block if known, even without <code class="highlighter-rouge">-txindex</code> enabled.</li>
|
||
<li>The <code class="highlighter-rouge">decoderawtransaction</code> and <code class="highlighter-rouge">fundrawtransaction</code> RPCs now have optional <code class="highlighter-rouge">iswitness</code> parameters to override the
|
||
heuristic witness checks if necessary.</li>
|
||
<li>The <code class="highlighter-rouge">walletpassphrase</code> timeout is now clamped to 2^30 seconds.</li>
|
||
<li>Using addresses with the <code class="highlighter-rouge">createmultisig</code> RPC is now deprecated, and will be removed in a later version. Public keys should be used instead.</li>
|
||
<li>Blockchain rescans now no longer lock the wallet for the entire rescan process, so other RPCs can now be used at the same time (although results of balances / transactions may be incorrect or incomplete until the rescan is complete).</li>
|
||
<li>The <code class="highlighter-rouge">logging</code> RPC has now been made public rather than hidden.</li>
|
||
<li>An <code class="highlighter-rouge">initialblockdownload</code> boolean has been added to the <code class="highlighter-rouge">getblockchaininfo</code> RPC to indicate whether the node is currently in IBD or not.</li>
|
||
<li><code class="highlighter-rouge">minrelaytxfee</code> is now included in the output of <code class="highlighter-rouge">getmempoolinfo</code></li>
|
||
</ul>
|
||
|
||
<h3 id="other-changed-command-line-options">Other changed command-line options</h3>
|
||
|
||
<ul>
|
||
<li><code class="highlighter-rouge">-debuglogfile=&lt;file&gt;</code> can be used to specify an alternative debug logging file.</li>
|
||
<li>bitcoin-cli now has an <code class="highlighter-rouge">-stdinrpcpass</code> option to allow the RPC password to be read from standard input.</li>
|
||
<li>The <code class="highlighter-rouge">-usehd</code> option has been removed.</li>
|
||
<li>bitcoin-cli now supports a new <code class="highlighter-rouge">-getinfo</code> flag which returns an output like that of the now-removed <code class="highlighter-rouge">getinfo</code> RPC.</li>
|
||
</ul>
|
||
|
||
<h3 id="testing-changes">Testing changes</h3>
|
||
|
||
<ul>
|
||
<li>The default regtest JSON-RPC port has been changed to 18443 to avoid conflict with testnet’s default of 18332.</li>
|
||
<li>Segwit is now always active in regtest mode by default. Thus, if you upgrade a regtest node you will need to either -reindex or use the old rules by adding <code class="highlighter-rouge">vbparams=segwit:0:999999999999</code> to your regtest bitcoin.conf. Failure to do this will result in a CheckBlockIndex() assertion failure that will look like: Assertion `(pindexFirstNeverProcessed != nullptr) == (pindex-&gt;nChainTx == 0)’ failed.</li>
|
||
</ul>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">f51392e0cbf7940627944602a64890ed65cf44838fc4795d493cf12aafe37012 bitcoin-0.16.0-aarch64-linux-gnu.tar.gz
|
||
59f95da96f40b3a9acfeda9085e6389f2075ee40ef1fe7f023031f86c946c3ea bitcoin-0.16.0-arm-linux-gnueabihf.tar.gz
|
||
d7c173e2921e39df3631b7cd652ae7330c2735b0b221f9dc8f7c899887b4fb59 bitcoin-0.16.0-i686-pc-linux-gnu.tar.gz
|
||
ade85a8e39de8c36a134721c3da9853a80f29a8625048e0c2a5295ca8b23a88c bitcoin-0.16.0-osx64.tar.gz
|
||
df0036bae9f40536095908c9944ed66c0946f178ae8ef07639caf25a390b2ee7 bitcoin-0.16.0-osx.dmg
|
||
8cbec0397d932cab7297a8c23c918392f6eebd410646b4b954787de9f4a3ee40 bitcoin-0.16.0.tar.gz
|
||
7558249b04527d7d0bf2663f9cfe76d6c5f83ae90e513241f94fda6151396a29 bitcoin-0.16.0-win32-setup.exe
|
||
60d65d6e57f42164e1c04bb5bb65156d87f0433825a1c1f1f5f6aebf5c8df424 bitcoin-0.16.0-win32.zip
|
||
6d93ba3b9c3e34f74ccfaeacc79f968755ba0da1e2d75ce654cf276feb2aa16d bitcoin-0.16.0-win64-setup.exe
|
||
42706da1a95b2db8c5808529f73c2063a0dd770f71e0c8506bfa86dc0f3403ef bitcoin-0.16.0-win64.zip
|
||
e6322c69bcc974a29e6a715e0ecb8799d2d21691d683eeb8fef65fc5f6a66477 bitcoin-0.16.0-x86_64-linux-gnu.tar.gz</code></pre></figure>
|
||
|
||
</description>
|
||
<pubDate>Mon, 26 Feb 2018 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2018/02/26/release-0.16.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2018/02/26/release-0.16.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.15.1 Released</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#notable-changes" id="markdown-toc-notable-changes">Notable changes</a> <ul>
|
||
<li><a href="#network-fork-safety-enhancements" id="markdown-toc-network-fork-safety-enhancements">Network fork safety enhancements</a></li>
|
||
<li><a href="#rpc-changes" id="markdown-toc-rpc-changes">RPC changes</a></li>
|
||
<li><a href="#miner-block-size-limiting-deprecated" id="markdown-toc-miner-block-size-limiting-deprecated">Miner block size limiting deprecated</a></li>
|
||
<li><a href="#gui-settings-backed-up-on-reset" id="markdown-toc-gui-settings-backed-up-on-reset">GUI settings backed up on reset</a></li>
|
||
<li><a href="#duplicate-wallets-disallowed" id="markdown-toc-duplicate-wallets-disallowed">Duplicate wallets disallowed</a></li>
|
||
<li><a href="#debug--minimumchainwork-argument-added" id="markdown-toc-debug--minimumchainwork-argument-added">Debug <code class="highlighter-rouge">-minimumchainwork</code> argument added</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#conclusion" id="markdown-toc-conclusion">Conclusion</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We are pleased to announce the release of Bitcoin Core 0.15.1.</p>
|
||
|
||
<p>This release focuses on the safety of the P2P network as a precaution against potential future network forks, as well as bringing bug fixes, optimisations and improvements to the 0.15.x series.</p>
|
||
|
||
<h2 id="notable-changes">Notable changes</h2>
|
||
|
||
<h3 id="network-fork-safety-enhancements">Network fork safety enhancements</h3>
|
||
|
||
<p>A number of changes to the way Bitcoin Core deals with peer connections and invalid blocks
|
||
have been made, as a safety precaution against blockchain forks and misbehaving peers.</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Unrequested blocks with less work than the minimum-chain-work are now no longer processed even
|
||
if they have more work than the tip (a potential issue during IBD where the tip may have low-work).
|
||
This prevents peers wasting the resources of a node.</p>
|
||
</li>
|
||
<li>
|
||
<p>Peers which provide a chain with less work than the minimum-chain-work during IBD will now be disconnected.</p>
|
||
</li>
|
||
<li>
|
||
<p>For a given outbound peer, we now check whether their best known block has at least as much work as our tip. If it
|
||
doesn’t, and if we still haven’t heard about a block with sufficient work after a 20 minute timeout, then we send
|
||
a single getheaders message, and wait 2 more minutes. If after two minutes their best known block has insufficient
|
||
work, we disconnect that peer. We protect 4 of our outbound peers from being disconnected by this logic to prevent
|
||
excessive network topology changes as a result of this algorithm, while still ensuring that we have a reasonable
|
||
number of nodes not known to be on bogus chains.</p>
|
||
</li>
|
||
<li>
|
||
<p>Outbound (non-manual) peers that serve us block headers that are already known to be invalid (other than compact
|
||
block announcements, because BIP 152 explicitly permits nodes to relay compact blocks before fully validating them)
|
||
will now be disconnected.</p>
|
||
</li>
|
||
<li>
|
||
<p>If the chain tip has not been advanced for over 30 minutes, we now assume the tip may be stale and will try to connect
|
||
to an additional outbound peer. A periodic check ensures that if this extra peer connection is in use, we will disconnect
|
||
the peer that least recently announced a new block.</p>
|
||
</li>
|
||
<li>
|
||
<p>The set of all known invalid-themselves blocks (i.e. blocks which we attempted to connect but which were found to be
|
||
invalid) are now tracked and used to check if new headers build on an invalid chain. This ensures that everything that
|
||
descends from an invalid block is marked as such.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="rpc-changes">RPC changes</h3>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>The <code class="highlighter-rouge">currentblocksize</code> value in <code class="highlighter-rouge">getmininginfo</code> has been removed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code class="highlighter-rouge">dumpwallet</code> no longer allows overwriting files. This is a security measure as well as prevents dangerous user mistakes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code class="highlighter-rouge">backupwallet</code> will now fail when attempting to backup to source file, rather than destroying the wallet.</p>
|
||
</li>
|
||
<li>
|
||
<p><code class="highlighter-rouge">listsinceblock</code> will now throw an error if an unknown <code class="highlighter-rouge">blockhash</code> argument value is passed, instead of returning a list
|
||
of all wallet transactions since the genesis block. The behaviour is unchanged when an empty string is provided.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="miner-block-size-limiting-deprecated">Miner block size limiting deprecated</h3>
|
||
|
||
<p>Though blockmaxweight has been preferred for limiting the size of blocks returned by
|
||
getblocktemplate since 0.13.0, blockmaxsize remained as an option for those who wished
|
||
to limit their block size directly. Using this option resulted in a few UI issues as
|
||
well as non-optimal fee selection and ever-so-slightly worse performance, and has thus
|
||
now been deprecated. Further, the blockmaxsize option is now used only to calculate an
|
||
implied blockmaxweight, instead of limiting block size directly. Any miners who wish
|
||
to limit their blocks by size, instead of by weight, will have to do so manually by
|
||
removing transactions from their block template directly.</p>
|
||
|
||
<h3 id="gui-settings-backed-up-on-reset">GUI settings backed up on reset</h3>
|
||
|
||
<p>The GUI settings will now be written to <code class="highlighter-rouge">guisettings.ini.bak</code> in the data directory before wiping them when
|
||
the <code class="highlighter-rouge">-resetguisettings</code> argument is used. This can be used to retroactively troubleshoot issues due to the
|
||
GUI settings.</p>
|
||
|
||
<h3 id="duplicate-wallets-disallowed">Duplicate wallets disallowed</h3>
|
||
|
||
<p>Previously, it was possible to open the same wallet twice by manually copying the wallet file, causing
|
||
issues when both were opened simultaneously. It is no longer possible to open copies of the same wallet.</p>
|
||
|
||
<h3 id="debug--minimumchainwork-argument-added">Debug <code class="highlighter-rouge">-minimumchainwork</code> argument added</h3>
|
||
|
||
<p>A hidden debug argument <code class="highlighter-rouge">-minimumchainwork</code> has been added to allow a custom minimum work value to be used
|
||
when validating a chain.</p>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>Please see the <a href="/en/releases/0.15.1/">release notes</a> for details. To download, please visit
|
||
the <a href="/en/download">download page</a>.</p>
|
||
|
||
<p>If have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a>
|
||
chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">d64d2e27cad78bbd2a0268bdaa9efa3f1eca670a4fab462b5e851699c780e3a0 bitcoin-0.15.1-aarch64-linux-gnu.tar.gz
|
||
ceba092c9a390082ff184c8d82a24bc34d7f9b421dc5c1e6847fcf769541f305 bitcoin-0.15.1-arm-linux-gnueabihf.tar.gz
|
||
231e4c9f5cf4ba977dbaf118bf38b0fde4d50ab7b9efd65bee6647fb14035a2c bitcoin-0.15.1-i686-pc-linux-gnu.tar.gz
|
||
b6771c5d67fb6b9c4882cc351e579470a008211d76407155e544b28b00fcd711 bitcoin-0.15.1-osx64.tar.gz
|
||
0ce5ca1ba424603526d8a40d9321f1f735797a7205a7fbbe39561c078f2a0858 bitcoin-0.15.1-osx.dmg
|
||
34de2dbe058c1f8b6464494468ebe2ff0422614203d292da1c6458d6f87342b4 bitcoin-0.15.1.tar.gz
|
||
cc7a31d8fece1462955bddef87945420721e42cfe6af589a36547b0940851765 bitcoin-0.15.1-win32-setup.exe
|
||
4d2ad1371df1904367955d3f250212d0edd9f338c26d5cd60d7d8ce3f1733f5a bitcoin-0.15.1-win32.zip
|
||
905a5999fb52b083d7e3bedb2dc6704ca641823f81865db58a55a6a20b454d8c bitcoin-0.15.1-win64-setup.exe
|
||
b858521496c0d7699a6916c20767cdb123eb39be70ffc544d6876b08af3b696a bitcoin-0.15.1-win64.zip
|
||
387c2e12c67250892b0814f26a5a38f837ca8ab68c86af517f975a2a2710225b bitcoin-0.15.1-x86_64-linux-gnu.tar.gz</code></pre></figure>
|
||
|
||
</description>
|
||
<pubDate>Sat, 11 Nov 2017 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/11/11/release-0.15.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/11/11/release-0.15.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.15.0.1 Released</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>Bitcoin Core 0.15.0.1 has been released with a fix for a minor bug in 0.15.0,
|
||
which caused the GUI client to crash for some users after upgrading to 0.15.0.</p>
|
||
|
||
<p>After upgrade to 0.15.0, some clients would crash at startup because a custom
|
||
fee setting was configured that no longer exists in the GUI. This is a minimal
|
||
patch to avoid this issue from occurring.</p>
|
||
|
||
<p>Please see the <a href="/en/releases/0.15.0.1/">release notes</a> for details. To download, please visit
|
||
the <a href="/en/download">download page</a>.</p>
|
||
|
||
<p>If have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a>
|
||
chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">b1ac0cd472f98040fbce9cea79348da2c6140a452427f9fe56d060413ec67f2d bitcoin-0.15.0.1-aarch64-linux-gnu.tar.gz
|
||
7fb2290464ff056213593878cac1d111422204e81b1ccb93f95b145c309895c5 bitcoin-0.15.0.1-arm-linux-gnueabihf.tar.gz
|
||
061bdd552fdc048a98e04ab436165b121346ecd989e1bc91db0246888fcadf7d bitcoin-0.15.0.1-i686-pc-linux-gnu.tar.gz
|
||
23a36e28295ef05faf67d41be0610d5f5f1059d904aa74efca7a6700a82d6dc2 bitcoin-0.15.0.1-osx64.tar.gz
|
||
9f90a5b5623287b762e3280fd86fc7adc7180a071513d5d663133f030452b1dd bitcoin-0.15.0.1-osx.dmg
|
||
b57e9e756018e4082f5557a4216195b0cd197c5a62473b6fe0509a0aa71e519b bitcoin-0.15.0.1.tar.gz
|
||
f3e7ef9ac9d510a185efb0f0253dc1f49d627768999a66f13e86de4c38854680 bitcoin-0.15.0.1-win32-setup.exe
|
||
49578a464d043f278805b145cd8f59b115e6f41cd56de0a90049da1781df9d59 bitcoin-0.15.0.1-win32.zip
|
||
f0aebade2b43e253ad66fd920e00524048f5a9b9933936e735844d316433791a bitcoin-0.15.0.1-win64-setup.exe
|
||
25efad99a4128d9f197d7eb1c175e7597478ae39e3d05805f14e9c01392b41ae bitcoin-0.15.0.1-win64.zip
|
||
ae3efa47bf87a694a5368cd6fea96c9942fe9be7856720b5027c8902e46a88d1 bitcoin-0.15.0.1-x86_64-linux-gnu.tar.gz</code></pre></figure>
|
||
|
||
</description>
|
||
<pubDate>Mon, 02 Oct 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/10/02/release-0.15.0.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/10/02/release-0.15.0.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.15.0 Released</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#upgrade-notice" id="markdown-toc-upgrade-notice">Upgrade notice</a></li>
|
||
<li><a href="#better-fee-estimates" id="markdown-toc-better-fee-estimates">Better fee estimates</a></li>
|
||
<li><a href="#graphical-fee-bumping" id="markdown-toc-graphical-fee-bumping">Graphical fee bumping</a></li>
|
||
<li><a href="#multiwallet" id="markdown-toc-multiwallet">Multiwallet</a></li>
|
||
<li><a href="#performance-improvements" id="markdown-toc-performance-improvements">Performance improvements</a></li>
|
||
<li><a href="#the-future-p2sh-wrapped-segwit-addresses" id="markdown-toc-the-future-p2sh-wrapped-segwit-addresses">The future: P2SH-wrapped segwit addresses</a></li>
|
||
<li><a href="#conclusion" id="markdown-toc-conclusion">Conclusion</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We are pleased to announce the release of Bitcoin Core 0.15.0, which provides <a href="#better-fee-estimates">better fee estimates</a> and more accessible <a href="#graphical-fee-bumping">fee bumping</a>, initial support for <a href="#multiwallet">multiple wallets</a> in a single installation, and a number of significant <a href="#performance-improvements">performance improvements</a>. Many bug fixes, optimizations, and other improvements are also included.</p>
|
||
|
||
<h2 id="upgrade-notice">Upgrade notice</h2>
|
||
|
||
<p>One of the performance optimizations in Bitcoin Core 0.15.0 is an update to the format of the database that tracks spendable bitcoins. The first time you start Bitcoin Core 0.15.0 (or a later version), it will automatically begin this update, which will take from about 5 minutes to 30 minutes depending on the speed of your computer.</p>
|
||
|
||
<p>Graphical users can monitor the progress of the update on the Bitcoin Core splash screen; bitcoind users can monitor it in the <code class="highlighter-rouge">debug.log</code> file in their <a href="https://en.bitcoin.it/wiki/Data_directory">data directory</a>.</p>
|
||
|
||
<p>If you later decide to downgrade to an earlier version of Bitcoin Core, please see the <a href="/en/releases/0.15.0/">instructions</a> in the release notes.</p>
|
||
|
||
<h2 id="better-fee-estimates">Better fee estimates</h2>
|
||
|
||
<p>Evidence shows that users who are willing to wait just a few hours for their transactions to confirm can often save 80% or more in transaction fees over users who need rapid confirmation during periods of high demand.</p>
|
||
|
||
<p>Not only do these patient users save money, but they also help ensure Bitcoin miners always have plenty of fee-paying transactions to include in their blocks, which will be necessary to keep miners working on extending the Bitcoin block chain in the future as Bitcoin gets closer to the upper limit of 21 million bitcoins and transaction fees increasingly make up a greater share of miner income.</p>
|
||
|
||
<p>To help patient users get the best deal on transaction fees and rushed users get their transactions confirmed as quickly as possible, we’ve made several significant improvements to the built-in fee estimation algorithm and user interface in Bitcoin Core 0.15.0.</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p><strong>40x increase in maximum targets:</strong> the fee estimator can now provide reasonable estimates up to 1,008 blocks into the future (about 1 week), up from a previous maximum of 25 blocks (about 4 hours), allowing users making safe transfers between their own wallets and other non-urgent tasks to save as much as possible on transactions fees.</p>
|
||
|
||
<p>In order to expose this new increased range in the graphical user interface, the previous fee slider has been replaced by a fee dropdown:</p>
|
||
|
||
<p><img src="/assets/images/releases/fee-selector.png" alt="New fee drop-down box" /></p>
|
||
</li>
|
||
<li>
|
||
<p><strong>More responsive:</strong> fee estimates now adjust faster to changing network conditions of higher or lower demand for block space. The algorithm makes multiple extrapolations of the transaction data and selects the best one automatically. For more information about the algorithm used, please see developer Alex Morcos’s <a href="https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41">description</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Lower fee estimates for RBF users:</strong> previously it was difficult to change the fee of unconfirmed transactions after broadcasting them, so Bitcoin Core suggested fees higher than normally needed. As described later in this post, Bitcoin Core now provides tools for increasing the fee of already-sent unconfirmed transactions, so we give lower fee estimates to users of those tools since they can always increase their fee later if necessary.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>Programmers and command-line users automatically receive access to the improved fee estimation through their current RPC calls and can also use the new <code class="highlighter-rouge">estimatesmartfee</code> RPC to get access to the advanced features described above. Note that the older <code class="highlighter-rouge">estimatefee</code> RPC continues to work, but is now deprecated and will be removed in a subsequent release. For more information, run <code class="highlighter-rouge">bitcoin-cli help estimatesmartfee</code> and see the <a href="/en/releases/0.15.0/">release notes</a>.</p>
|
||
|
||
<h2 id="graphical-fee-bumping">Graphical fee bumping</h2>
|
||
|
||
<p>Bitcoin Core 0.14.0 introduced expert options to allow users to increase the amount of transaction fee they paid on their unconfirmed transactions, a process often called <em>fee bumping.</em></p>
|
||
|
||
<p>This can allow frugal users to pay a very low transaction fee, wait a while to see if the transaction confirms at that fee, and then increase the fee if it hasn’t been included in any of the recent blocks. It also helps ensure that any user who accidentally pays too low a fee can later increase that fee to get the transaction confirmed.</p>
|
||
|
||
<p>In Bitcoin Core 0.15.0, this option is no longer just for experts. In the the fee options when sending a transaction using the graphical interface, users can now choose to “Request Replace-By-Fee”, allowing them to replace one version of an unconfirmed transaction with a later version that pays a higher fee.</p>
|
||
|
||
<p><img src="/assets/images/releases/rbf-checkbox.png" alt="Screenshot of replace-by-fee checkbox" /></p>
|
||
|
||
<p>If users enable this feature on a transaction, they can later go to the Transactions tab, right-click on the transaction, and select the “Increase transaction fee” option.</p>
|
||
|
||
<p><img src="/assets/images/releases/fee-bump-menu.png" alt="Screenshot of &quot;increase transaction fee&quot; option on menu" /></p>
|
||
|
||
<p>Both the original transaction and the replacement will be shown in the Transaction tab so you can see which one gets confirmed (it isn’t guaranteed that the higher-fee transaction will be confirmed, but it is guaranteed that only one of the transactions can be confirmed). Once one version of the transaction is confirmed, all other versions of the same transaction will be shown as failed.</p>
|
||
|
||
<p>You can repeat the fee bumping step as many times as you’d like until one version of the transaction confirms, and no matter how many replacements you create, only one version of the transaction will be confirmed.</p>
|
||
|
||
<p>Users who want to request Replace-By-Fee (RBF) by default can start Bitcoin Core with the <code class="highlighter-rouge">-walletrbf</code> option or add <code class="highlighter-rouge">walletrbf=1</code> to their <a href="https://bitcoin.stackexchange.com/a/11210">configuration file</a>. Note that some services that accept unconfirmed transactions as finalized payments may not accept replace-by-fee transactions as final until they confirm; for more information about opt-in replace by fee, please see the <a href="/en/faq/optin_rbf/">RBF FAQ</a>.</p>
|
||
|
||
<h2 id="multiwallet">Multiwallet</h2>
|
||
|
||
<p>In Bitcoin Core 0.15.0, a single running Bitcoin Core program can now manage multiple wallets with ease. This feature is still new and only accessible to expert users, but we hope to make it available in the graphical user interface in the future.</p>
|
||
|
||
<p>You can use the new multiwallet mode to,</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Use one wallet for your business and one wallet for your personal use in order to simplify your accounting and prevent accidental misuse of funds.</p>
|
||
</li>
|
||
<li>
|
||
<p>Separate bitcoins that are associated with your identity from bitcoins that can’t be traced back to you in order to help protect your privacy. Each wallet uses completely different private keys and will never automatically mix its bitcoins with bitcoins from another wallet, preventing taint analysis from connecting those two wallets.</p>
|
||
</li>
|
||
<li>
|
||
<p>Manage a Bitcoin backend for an organization in much the same way that has been historically possible with the now-deprecated Bitcoin Core accounts features. As a simple example, if you handle small bitcoin balances for your less-experienced friends and family, you can now manage each person’s bitcoins in a separate wallet rather than risking mixing them up with your own bitcoins.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>These features are currently only available through the RPC interface for programmers and command-line users, and the API for them may change in future versions. Please see the bottom of this post for information about how to contribute to development if you’d like to help improve multiwallet mode and make it available in the graphical interface. For more information about multiwallet mode, please see the <a href="/en/releases/0.15.0/">release notes</a>.</p>
|
||
|
||
<h2 id="performance-improvements">Performance improvements</h2>
|
||
|
||
<p>As part of the continuing effort to make full nodes available to as many users as possible even as the block chain continues to grow in size and complexity, Bitcoin Core 0.15.0 includes several significant performance improvements.</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>30% to 40% faster block validation and 10% to 20% less memory used</strong> on tests of Initial Block Download (IBD), with far fewer writes to disk. This is the result of simplifying the format of the the chainstate database that tracks each spendable group of bitcoins and what information the owner of those bitcoins needs to provide in order to spend them.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>40% to 50% faster validation of blocks consisting of previously-seen transactions</strong> as the result of repeating fewer validation steps when a previously-verified mempool transaction is later received in a block.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Moderate performance gains on some platforms</strong> as the result of using hardware acceleration for some operations, such as support on modern computer processors for the consistency-checking operation used by the chainstate database. This mainly benefits users of 64-bit Intel and AMD processors produced in 2008 or later.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>More information on each of these improvements may be found in the <a href="/en/releases/0.15.0/">release notes</a>.</p>
|
||
|
||
<h2 id="the-future-p2sh-wrapped-segwit-addresses">The future: P2SH-wrapped segwit addresses</h2>
|
||
|
||
<p>As final preparations are being made to release Bitcoin Core 0.15.0, segregated witness has activated on the Bitcoin network and is now ready to use.</p>
|
||
|
||
<p>Bitcoin Core has supported creating segwit addresses since 0.13.0, but this support was designed for testing has only been available to expert users—we were waiting to see if segwit was adopted before adding segwit support to the regular user interfaces, both graphical and RPC.</p>
|
||
|
||
<p>The timing of segwit lock in and activation meant that we had to choose between either delaying the planned release of 0.15.0 and all its features described above or shipping 0.15.0 without a user interface defaulting to segwit.</p>
|
||
|
||
<p>We decided to take the later option, but we’re also not going to wait the normal six months before the next major update. Instead, our next feature release will generate segwit-compatible addresses by default. This will be made available as soon as it has been written and thoroughly tested.</p>
|
||
|
||
<p>For those of you interested in technical details, our plan is to use P2SH-wrapped segwit addresses that are compatible with nearly all other wallets on the network. We may support sending to Bech32 native segwit addresses generated by other wallets, but the graphical user interface will probably not support generating Bech32 addresses itself until a subsequent release.</p>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>For details on all the changes made in Bitcoin Core 0.15.0, please read the <a href="/en/releases/0.15.0/">release notes</a>. To download, please visit the <a href="/en/download">download page</a>.</p>
|
||
|
||
<p>If you are interested in contributing to Bitcoin Core, please see our <a href="/en/contribute">contributing page</a> and the document <a href="/en/faq/contributing-code/">How to contribute code to Bitcoin Core</a>. If you don’t know where to get started or have any other questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a> chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">ec5e93ebc747d3d50b6c3bc33ac840348820b0e681de734999ebc4e671803a8e bitcoin-0.15.0-aarch64-linux-gnu.tar.gz
|
||
ec6b9e0ea467f82f2f9938f8577fb41cb7c2998b027709f78b8aff02afc983a9 bitcoin-0.15.0-arm-linux-gnueabihf.tar.gz
|
||
75de087adf888f15faa4d8a65ea18dee75150ee761b0d6bcaefc7770230e1e66 bitcoin-0.15.0-i686-pc-linux-gnu.tar.gz
|
||
dd444b4e55ef8ef070c9f93f56a1ad028ea4d99205f6c3d4d631550f48937c05 bitcoin-0.15.0-osx64.tar.gz
|
||
973967c7722c9431b7bdb592981831e320fc6f67c4d10d3c3f27c0a251cab6d6 bitcoin-0.15.0-osx.dmg
|
||
54b6f54982da97f294d21ad69c6b8624f2cf40d157be0683123b2ba6db2bf2a1 bitcoin-0.15.0.tar.gz
|
||
c35f048c9e62335bba031db91bb36b7c11d9292c89c21af219f63eac1d090c34 bitcoin-0.15.0-win32-setup.exe
|
||
b7bb50796b79b18c97c15b90368962a275057d234ac674407e47148e73968497 bitcoin-0.15.0-win32.zip
|
||
94d0626426810db85b342dbf801681752e474ff0aff726783cb5297b70999a45 bitcoin-0.15.0-win64-setup.exe
|
||
d1686db57c59136c758db1536eaf1bb0b9a08c6a0fd21f54d39ee6a7b6bd39d8 bitcoin-0.15.0-win64.zip
|
||
ed57f268d8b5ea5acfcb0666e801cf557a444720d8aed5e812071ab2e2913342 bitcoin-0.15.0-x86_64-linux-gnu.tar.gz</code></pre></figure>
|
||
|
||
</description>
|
||
<pubDate>Thu, 14 Sep 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/09/01/release-0.15.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/09/01/release-0.15.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Correcting misinformation on Segwit2x and btc1</title>
|
||
<description><p>“Segwit2x”, a proposal for an incompatible change to the consensus rules of the Bitcoin network, has received increased exposure recently. There have been attempts to mislead people into believing that the btc1 project, the implementation of the Segwit2x proposal, is a necessary update to existing software—it is not. Instead, it is a contentious deviation from the existing network rules, and its users will soon find themselves disagreeing with the rest of the network about the validity of blocks and transactions.</p>
|
||
|
||
<p>Please be aware that:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Segregated Witness (or Segwit, a soft fork which will be active within the coming days) is not related to the Segwit2x hard fork. Segregated Witness is backwards compatible with all previous Bitcoin software. For the vast majority of Bitcoin users, no action is required.</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://bitcoincore.org">bitcoincore.org</a> is the official website and <a href="https://twitter.com/bitcoincoreorg">@bitcoincoreorg</a> is the official Twitter account of the Bitcoin Core project. Any other websites or Twitter accounts claiming to represent the project are fraudulent. Bitcoin Core is an open source project that welcomes contributions and review from anyone through its GitHub project. Bitcoin Core binaries can be obtained from <a href="/en/download">bitcoincore.org</a> and are always digitally signed by the release manager’s signing key. The latest version of Bitcoin Core at the time of writing is 0.14.2.</p>
|
||
</li>
|
||
<li>
|
||
<p>btc1 is <em>not</em> connected to Bitcoin Core in any way. No regular Bitcoin Core contributors support btc1 or have any connection to the project, nor were any involved in the design of its proposed hard fork.</p>
|
||
</li>
|
||
<li>
|
||
<p>We strongly advise users not to download any Bitcoin full-node software claiming to be an ‘upgrade’ to Bitcoin’s consensus rules without carefully considering the impact of the proposed changes on the Bitcoin system and the level of community support for it. This includes proposed consensus changes in new releases of Bitcoin Core.</p>
|
||
</li>
|
||
<li>
|
||
<p>While it is difficult to determine what the broader Bitcoin community supports, be wary of claims suggesting the large and diverse Bitcoin community is moving entirely to one fork or another, without independent verification. Sign-on letters have been used by companies claiming to represent their clients/users without their agreement, and have often used imprecise and misleading language. In the past, letters for Bitcoin XT, Bitcoin Classic, and Bitcoin Unlimited, as well as others, have been circulated to indicate general support of an idea, while being trumpeted as commitments to run software irrespective of community considerations, only to be dropped some months later.</p>
|
||
</li>
|
||
<li>
|
||
<p>Concerns raised by Bitcoin Core contributors and Bitcoin community members about the Segwit2x proposal have not been adequately addressed by its proponents. The details of the proposal were established before Bitcoin’s Segregated Witness activation, and before the recent creation of the BCH currency. It is irresponsible to ignore the outcome of these events when planning for the future. As an example, we’ve seen the confusion that arises when a single address is valid across two chains, yet the Segwit2x proposal intends to repeat the same mistake. Furthermore, BCH’s implementation of strong replay protection provided significant protection to users of both BCH, as well as Bitcoin, something Segwit2x does not plan on providing.</p>
|
||
</li>
|
||
<li>
|
||
<p>Bitcoin’s consensus rules should only be changed sparingly and with broad agreement from the entire community. Segwit2x, in both its process and implementation, has been opposed by many. Bitcoin Core will continue to support the Segwit soft fork and we look forward to helping Bitcoin scale to new heights over the coming years.</p>
|
||
</li>
|
||
</ul>
|
||
</description>
|
||
<pubDate>Fri, 18 Aug 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/08/18/btc1-misleading-statements/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/08/18/btc1-misleading-statements/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.14.2 Released</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>Bitcoin Core 0.14.2 has been released with a security fix for
|
||
users who manually enable the UPnP option. Please note: UPnP has been
|
||
disabled by default since <a href="https://bitcoin.org/en/release/v0.10.3#fix-buffer-overflow-in-bundled-upnp">Bitcoin Core 0.10.3</a>; you only need this
|
||
fix if you start Bitcoin Core with the <code class="highlighter-rouge">-upnp</code> option on the command
|
||
line or in your configuration file.</p>
|
||
|
||
<p>If you use <code class="highlighter-rouge">-upnp</code>, it is recommended that you upgrade to Bitcoin Core
|
||
0.14.2 as soon as possible. The security issue (<a href="https://nvd.nist.gov/vuln/detail/CVE-2017-8798">miniupnp
|
||
CVE-2017-8798</a>) allows remote attackers (within the Local Area
|
||
Network, LAN) to cause a denial of service or possibly have unspecified
|
||
other impact.</p>
|
||
|
||
<p>This release also includes a few other bug fixes, all minor. Please see
|
||
the <a href="/en/releases/0.14.2/">release notes</a> for details. To download, please visit the
|
||
<a href="https://bitcoin.org/en/download">download page</a> or the <a href="https://bitcoin.org/bin/bitcoin-core-0.14.2/">files directory</a>.</p>
|
||
|
||
<p>If have any questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a>
|
||
chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">dd877bc247efa4c90a34ec9ce1a497a8ae1f7eac4c688aa8c8b25ffe30c20541 bitcoin-0.14.2-aarch64-linux-gnu.tar.gz
|
||
f273eb5e56694fe5baecdd5ee8cda9ac495541ccd9df5ca1c22a1b10dc6d89e8 bitcoin-0.14.2-arm-linux-gnueabihf.tar.gz
|
||
1a302092d9af75db93e2d87a9da6f1f2564a209fb8ee1d7f64ca1d2828f31c03 bitcoin-0.14.2-i686-pc-linux-gnu.tar.gz
|
||
a4e98906b4fa08727cbd81371a108ed7a19ea34bb421b078e64843560490a78d bitcoin-0.14.2-osx64.tar.gz
|
||
463277b9139e890a713034b539583a0879bdcf0fc94c3c1fc08bb8aab81bb108 bitcoin-0.14.2-osx.dmg
|
||
1ac4e5ce51ac03c41df0ad1e759dbb55d91e1456b9a616e43344bf2258dbe8ca bitcoin-0.14.2.tar.gz
|
||
522bf19ff2ac1a3f100194914071cf6d1a15076268c5c847b2f891277f427af6 bitcoin-0.14.2-win32-setup.exe
|
||
b3b0cc67a9a602fee4a270efc154f4422e1e49e2aefd9b0d44b0c601a326b05a bitcoin-0.14.2-win32.zip
|
||
3a0057e4d6ca172566a93192234ef28916cbb052db9e15997569d9c08502c49a bitcoin-0.14.2-win64-setup.exe
|
||
8a2a5657a8b3243ab4f549bb4b16c8c34b47acfb5c6bc07eb0b875ee71a3ad5b bitcoin-0.14.2-win64.zip
|
||
20acc6d5d5e0c4140387bc3445b8b3244d74c1c509bd98f62b4ee63bec31a92b bitcoin-0.14.2-x86_64-linux-gnu.tar.gz</code></pre></figure>
|
||
|
||
</description>
|
||
<pubDate>Sat, 17 Jun 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/06/17/release-0.14.2/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/06/17/release-0.14.2/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.14.1 Released</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#notable-changes" id="markdown-toc-notable-changes">Notable changes</a> <ul>
|
||
<li><a href="#rpc-changes" id="markdown-toc-rpc-changes">RPC changes</a></li>
|
||
<li><a href="#mining" id="markdown-toc-mining">Mining</a></li>
|
||
<li><a href="#utxo-memory-accounting" id="markdown-toc-utxo-memory-accounting">UTXO memory accounting</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#conclusion" id="markdown-toc-conclusion">Conclusion</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We are pleased to announce the general availability of Bitcoin Core 0.14.1. This release forms part of the regular maintenance cycle of Bitcoin Core and brings bug fixes, optimisations and improvements to the 0.14.x series.</p>
|
||
|
||
<h2 id="notable-changes">Notable changes</h2>
|
||
|
||
<h3 id="rpc-changes">RPC changes</h3>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>The first positional argument of <code class="highlighter-rouge">createrawtransaction</code> was renamed from <code class="highlighter-rouge">transactions</code> to <code class="highlighter-rouge">inputs</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>The argument of <code class="highlighter-rouge">disconnectnode</code> was renamed from <code class="highlighter-rouge">node</code> to <code class="highlighter-rouge">address</code>.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>These interface changes break compatibility with 0.14.0, when the named arguments functionality, introduced in 0.14.0, is used. Client software using these calls with named arguments need to be updated.</p>
|
||
|
||
<h3 id="mining">Mining</h3>
|
||
|
||
<p>In previous versions, the <code class="highlighter-rouge">getblocktemplate</code> RPC required segwit support from downstream clients/miners once segwit activated on the network. In this version, it now supports non-segwit clients even after activation by removing all segwit transactions from the returned block template. This allows non-segwit miners to continue functioning correctly even after segwit has activated.</p>
|
||
|
||
<p>Due to the limitations in previous versions, getblocktemplate also recommended non-segwit clients to not signal for the segwit version-bit. Since this is no longer an issue, getblocktemplate now always recommends signalling segwit for all miners. This is safe because the ability to enforce the rule is the only required criteria for safe activation (actually producing segwit-enabled blocks is not required).</p>
|
||
|
||
<h3 id="utxo-memory-accounting">UTXO memory accounting</h3>
|
||
|
||
<p>Memory usage for the UTXO cache is being calculated more accurately, so that the configured limit (<code class="highlighter-rouge">-dbcache</code>) will be respected when memory usage peaks during cache flushes. The memory accounting in prior releases is estimated to only account for half the actual peak utilization.</p>
|
||
|
||
<p>The default <code class="highlighter-rouge">-dbcache</code> has also been changed in this release to 450MiB. Users who currently set <code class="highlighter-rouge">-dbcache</code> to a high value (e.g. to keep the UTXO more fully cached in memory) should consider increasing this setting in order to achieve the same cache performance as prior releases. Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.</p>
|
||
|
||
<p>Additional information relating to running on low-memory systems can be found here: <a href="https://gist.github.com/laanwj/efe29c7661ce9b6620a7">reducing-bitcoind-memory-usage</a>.</p>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>For details on all the changes made in Bitcoin Core 0.14.1, please read the <a href="/en/releases/0.14.1/">release notes</a>. To download, please visit the <a href="https://bitcoin.org/en/download">download page</a> or the <a href="https://bitcoin.org/bin/bitcoin-core-0.14.1/">files directory</a>.</p>
|
||
|
||
<p>The next major planned release will be Bitcoin Core 0.15.0. It will begin with a freeze on new feature additions in mid-July and a release when release candidate testing has completed, anticipated to be in early September. For more information, please see the <a href="https://github.com/bitcoin/bitcoin/issues/9961">schedule</a>.</p>
|
||
|
||
<p>If you are interested in contributing to Bitcoin Core, please see our <a href="/en/contribute">contributing page</a> and the document <a href="/en/faq/contributing-code/">How to contribute code to Bitcoin Core</a>. If you don’t know where to get started or have any other questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a> chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">a60d7c8dde9b77e7ff547976ce37db1fe98c71833003465befe650d6bc102b6b bitcoin-0.14.1-aarch64-linux-gnu.tar.gz
|
||
cd23ffe044b56dd56d3b9ba384e606c44000b60f44e0a74a19c313a4f30ea5c8 bitcoin-0.14.1-arm-linux-gnueabihf.tar.gz
|
||
ff6bf851dae036905de6272562cca4b94c4842f758b7bd68879a088fe7b0f662 bitcoin-0.14.1-i686-pc-linux-gnu.tar.gz
|
||
a786381246b92a81a5f5c9cb538d162ab051e51e84a10449f5f7fc310137b258 bitcoin-0.14.1-osx64.tar.gz
|
||
2052793453ad37b8e00527942a7150f23f1c5dd5903e5e3e8a3b444dee81e3e0 bitcoin-0.14.1-osx.dmg
|
||
f21203e07f054dce3177539be89a066d4faee1e2fa432157c1444e4e6dd4f9a3 bitcoin-0.14.1.tar.gz
|
||
875f5995a47e5a1b1becaa02591400fc90bfc1a471b15eed71232b161efcdb1b bitcoin-0.14.1-win32-setup.exe
|
||
7146cfd057eb9d9f37444106e2649d059cc85fa390e5af0037acd8ef61574aaf bitcoin-0.14.1-win32.zip
|
||
3ebf2c58e3b60dd79153bf2a043a5f90402b8067b21a93dd88763c96dd8baba6 bitcoin-0.14.1-win64-setup.exe
|
||
851306112811ef49e89b2a105f4c78dd38fa4997dc913b9a748040605a33640d bitcoin-0.14.1-win64.zip
|
||
0c6920a9f3181a95ca029fdac5342b5702569ee441ec2128d19051f281683058 bitcoin-0.14.1-x86_64-linux-gnu.tar.gz</code></pre></figure>
|
||
|
||
</description>
|
||
<pubDate>Sat, 22 Apr 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/04/22/release-0.14.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/04/22/release-0.14.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Technology roadmap - Prioritized block download with using full block SPV mode</title>
|
||
<description><h2 id="hybrid-full-block-spv-mode">Hybrid full block SPV mode</h2>
|
||
|
||
<p>One of the major hurdle hindering further adoption of fully validating software by regular users is the inability to use the wallet features of the client until it has fully synced the entire blockchain. For users bootstrapping a new node, this means that they are unable to receive or send transactions until every block has been downloaded and validated up to the current tip of the chain. This behaviour is not by mistake: the Bitcoin Core reference software, by default, is built to offer the strongest security and privacy guarantees a Bitcoin user can expect and this necessarily implies full validation in order to confirm the integrity of historical blockchain data.</p>
|
||
|
||
<p>On the other hand, existing features of the software such as headers-first validation provide an opportunity to improve the usability of the wallet provided users are willing to make a temporary security tradeoff. Using the hybrid full block SPV mode, the software will prioritize download of blocks according to the oldest key in the user’s wallet. Along with the previously downloaded block headers chain, which should meet expected Proof-Of-Work difficulty checks, the client can then immediately start processing relevant transactions. The entire blockchain is still downloaded and eventually validated in parallel but this feature enables users to see and spend UTXOs associated with their wallet while synchronization is happening in the background.</p>
|
||
|
||
<p>Contrary to typical implementation of SPV wallets, this model does not suffer from the <a href="http://bitcoin.stackexchange.com/questions/37756/are-public-keys-and-their-corresponding-hash-values-both-added-to-a-bitcoinj-blo">privacy degradation</a> imposed on schemes relying on bloom filters and public disclosure of public keys. This benefit comes with a tradeoff which is that it consumes more bandwidth. Another caveat: confirmations received under SPV mode are inherently less safe than those received under full validation. A user leveraging the hybrid SPV mode should wait for several confirmations (6+) until his payment can be considered secure.</p>
|
||
|
||
<h3 id="further-information">Further information</h3>
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/pull/9483">Complete patch-set PR</a></li>
|
||
<li><a href="https://bitcoin.org/en/bitcoin-core/features/privacy#perfect-privacy-for-received-transactions">Perfect privacy for received transactions</a></li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Fri, 31 Mar 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/03/31/prioritized-block-download-using-hybrid-spv/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/03/31/prioritized-block-download-using-hybrid-spv/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Technology roadmap - Schnorr signatures and signature aggregation</title>
|
||
<description><h2 id="schnorr-signatures">Schnorr Signatures</h2>
|
||
|
||
<p>The replacement of Bitcoin’s digital signature algorithm (ECDSA) for the more efficient Schnorr algorithm has long been at the top of the wish list for many Bitcoin developers. A simple algorithm leveraging elliptic curve cryptography, Schnorr enables several improvements over the existing scheme all while preserving all of its features and security assumptions.</p>
|
||
|
||
<p>Notably, Schnorr signatures support “native multisig” which enables the aggregation of multiple signatures into a single one valid for the sum of the keys of their respective inputs. This functionality offers three important benefits:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Constant-size signatures irrespective of the number of participants in the multisig setup. A 50-of-50 transaction is effectively the same size as one that uses a single public key and signature. For this reason, the performance of such schemes is significantly improved by removing the original requirement of validating every signature individually. Additionally, the verification of Schnorr signatures is slightly faster than that of ECDSA.</p>
|
||
</li>
|
||
<li>
|
||
<p>The diminished size of data to be validated and transmitted across the network also translates in interesting capacity gains. Considering the historical growth in the number of multisig transactions displayed below, the potential to reduce the size of these transactions is an enticing addition to existing scaling efforts. We should expect this trend to continue with the emergence and further adoption of payment channels.</p>
|
||
</li>
|
||
<li>
|
||
<p>From a privacy standpoint, Schnorr allows the entire policy of the multisig to be obscured and indistinguishable from a conventional single pubkey. In a threshold setup, it also becomes impossible for participants to reveal which of them authorized, or not, a transaction.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p align="center">
|
||
<img src="/assets/images/posts/utxo-repartition.png" alt="UTXO repartition" />
|
||
</p>
|
||
<p align="center">
|
||
Distribution of unspent P2SH outputs according to their multisig setup. Source: p2sh.info
|
||
</p>
|
||
|
||
<p>Unfortunately, unlike ECDSA, the Schnorr algorithm has not been standardized since its invention, likely because of the original patent enforced on it (which has since expired). While the general outlines of the system are mathematically sound, the lack of documentation and specification makes it more challenging to implement. Specifically, its application to the ephemeral keypairs design of Bitcoin involves security considerations that require further optimization.</p>
|
||
|
||
<p>The main challenge is defined by Pieter Wuille in his Scaling Bitcoin Milan presentation of Schnorr signatures as the “cancellation” problem. The possibility for a group of users to create a signature valid for the sum of their keys opens the door for an adversarial participant to subtract from the whole another user’s key. It essentially works like this:</p>
|
||
|
||
<p>Assume a 2-of-2 multisig scheme using input public keys Q1 and Q2. Rather than announce their key as Q2 to be combined with Q1, a malicious participant could provide, during the interaction phase, Q2-Q1 and effectively cancel out the other user’s key. Any fund sent to the joint public key is now only spendable by the owner of the Q2 key without the owner of Q1 even being aware of what is going on.</p>
|
||
|
||
<p>Fortunately, a solution is now available which involves multiplying every key used during the setup with a hash based on itself and all other keys involved before signing. This process is called delinearization. A proof of the security of this scheme is currently undergoing peer-review and will be formally described in an upcoming whitepaper.</p>
|
||
|
||
<p>In the near term, Schnorr signatures are being considered as viable replacement for two important functions of the Bitcoin protocol: OP_CHECKSIG &amp; OP_CHECKMULTISIG.</p>
|
||
|
||
<p>The former is currently used to check ECDSA signatures against their respective public key according to the message in a transaction. By switching to an equivalent that checks for Schnorr signatures rather than ECDSA, the opcode can be used to authorize a spend requiring multiple signatures which would typically require calling OP_CHECKMULTISIG. Using a priori interaction not observable by the network, the collection of signers compute a combined public key along with a common signature which is verified by the new OP_CHECKSIG with the benefits of increased privacy and reduced costs.</p>
|
||
|
||
<p>The latter involves threshold scenarios where only n-of-m signatures are necessary to authorize a transaction. The current implementation of OP_CHECKMULTISIG validates all of the public keys and associated signatures required by the threshold policy. Because the computation scales linearly with the number of participants, Schnorr propose a much more efficient scheme which replaces the list of signatures with a single combined one along with a subset of the required pubkeys.</p>
|
||
|
||
<p>Until more evaluation of the delinearization scheme securing signers from malicious actors is performed, further applications of Schnorr signatures may be premature but the implementation of the features above can hopefully pave the way for a better understanding of the scheme in production. Contingent on additional peer-review, a BIP for the implementation of Schnorr Signatures could be proposed by the end of the year.</p>
|
||
|
||
<h2 id="signature-aggregation">Signature aggregation</h2>
|
||
|
||
<p>The properties of Schnorr allowing for the combination of multiple signatures over a single input are also applicable to the aggregation of multiple inputs for all transactions. Bitcoin developer Gregory Maxwell was the first to introduce the idea using insights from a previous proposal based on BLS signatures.</p>
|
||
|
||
<p>To properly understand the difference between this application and the ones described above it is necessary to consider how signatures are aggregated in each respective cases. In the native multisig setup, signers collaborate between themselves to compute a common public key and its associated signature. This interaction happens outside the protocol and only concerns the parties involved. The idea behind signature aggregation is to enable system validators ie. Bitcoin nodes to compute a single key and signature for every inputs of all transactions at the protocol level.</p>
|
||
|
||
<p>Because this scheme expands the scope of aggregation outside of the deterministic set of participants, it introduces a new vector of attack for malicious actors to leverage the “cancellation” bug. For this reason, the delinearization fix highlighted in the previous section is critical to the soundness of this method.</p>
|
||
|
||
<p>In terms of implementation, the proposal is rather straightforward: OP_CHECKSIG and
|
||
OP_CHECKMULTISIG are modified so that they can stack public keys, delinearize them and once all associated inputs are validated, produce a combined signature for their respective transactions.</p>
|
||
|
||
<p>It is rather straightforward to evaluate the type of resources savings that would have been possible had signature aggregation been implemented since the genesis block. Assuming every historical signature would be reduced to 1 byte, except for one per transaction, analysis suggest the method would result in at least a 25% reduction in terms of storage and bandwidth. Increased used of n-of-n thresholds are likely to translate into more savings though they were not accounted for in this analysis.</p>
|
||
|
||
<p align="center">
|
||
<img src="/assets/images/posts/signature-agg-chart.png" alt="Schnorr signature addregation savings chart" />
|
||
</p>
|
||
|
||
<h3 id="further-information-on-schnorr-signatures">Further information on Schnorr signatures</h3>
|
||
<ul>
|
||
<li><a href="https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/">Transcript of Pieter Wuille’s Scaling Bitcoin Milan presentation on Schnorr signatures</a></li>
|
||
<li><a href="https://youtu.be/_Z0ID-0DOnc?t=2297">Video of Pieter Wuille’s presentation</a></li>
|
||
<li><a href="http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/">Discussion about Schnorr Signatures at July 2016 Bitcoin developers &amp; miners meet-up</a></li>
|
||
<li><a href="https://github.com/sipa/secp256k1/blob/968e2f415a5e764d159ee03e95815ea11460854e/src/modules/schnorr/schnorr.md">Schnorr documentation</a></li>
|
||
<li><a href="http://bitcoin.stackexchange.com/questions/34288/what-are-the-implications-of-schnorr-signatures/35351#35351">StackExchange - What are the implications of Schnorr?</a></li>
|
||
<li><a href="https://elementsproject.org/features/schnorr-signatures">Elements Project: Schnorr Signature Validation</a></li>
|
||
<li><a href="https://www.youtube.com/watch?v=TYQ-3VvNCHE">SF Bitcoin Devs Seminar: Gregory Maxwell on Schnorr multi-signatures</a></li>
|
||
<li><a href="https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html">Bitcoin Core Developers meeting notes on Schnorr signatures</a></li>
|
||
</ul>
|
||
|
||
<h3 id="further-information-on-signature-aggregation">Further information on signature aggregation</h3>
|
||
<ul>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=1377298.0">Gregory Maxwell post on signature aggregation on Bitcointalk.org forum</a></li>
|
||
<li><a href="https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html">Bitcoin Core Developers meeting notes on Schnorr signatures</a></li>
|
||
<li><a href="https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/">Transcript of Pieter Wuille’s Scaling Bitcoin Milan presentation on Schnorr signatures</a></li>
|
||
<li><a href="https://youtu.be/_Z0ID-0DOnc?t=2297">Video of Pieter Wuille’s presentation</a></li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Thu, 23 Mar 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>On-chain scaling - a review of historical performance optimization made to Bitcoin’s reference software. Part 1</title>
|
||
<description><p>The following post aims to highlight development milestones that helped preserve a reliable experience for users of the Bitcoin software client over the years. We present several upgrades that were critical in maintaining the decentralized properties of the network and mitigate the resources burden of its participants. We describe how numerous orders-of-magnitude optimizations were made so that the Bitcoin network could support the growth in transaction activity without dramatically increasing the costs of participation for new and existing users. Finally, we note how those improvements all fall within a larger, systematic approach to protocol development that uses insights from Big-O complexity concepts and leverages smarter algorithms that make more efficient use of the network’s resources.</p>
|
||
|
||
<h2 id="signature-caching">Signature Caching</h2>
|
||
<p>Release: Bitcoin-Qt 0.7.0</p>
|
||
|
||
<p>Verification of ECSDA signatures are one of the most computationally heavy operations done at the peer level. Because they need to be verified for every transaction, any superfluous validation leads to significant resource overhead for the end user. That was the case for early versions of the software which would both verify signatures before they entered a node mempool and after they were received into a block.</p>
|
||
|
||
<p>In order to gain in efficiency, developers created a cache allowing nodes to store previously validated signatures and skip redundant work once the transactions make it into an accepted block.</p>
|
||
|
||
<p>Additionally, the signature cache also mitigates a DoS vector introduced by the potential for specifically crafted transactions to stall Bitcoin clients.</p>
|
||
|
||
<h3 id="further-information">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/release/v0.7.0#core-bitcoin-handling-and-blockchain-database">Bitcoin-Qt 0.7.0 Release notes</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=136422.0">Fixed vulnerability explanation: Why the signature cache is a DoS protection</a></li>
|
||
</ul>
|
||
|
||
<h2 id="ultraprune--leveldb">Ultraprune + LevelDB</h2>
|
||
<p>Release: Bitcoin-Qt 0.8.0</p>
|
||
|
||
<p>Ultraprune was one of the first major upgrades to the Bitcoin software aimed at solving the overhead associated with validating transaction data from the blockchain. Previous versions of the Bitcoin reference client maintained an index of all transaction outputs, spent or unspent. Ultraprune significantly reduced the size of that index with the insight that you only needed to keep track of unspent outputs, and an output - once spent - can be removed from the indexes entirely.</p>
|
||
|
||
<p>To achieve this, a new database layout was implemented which allocates unspent transaction outputs to a compact custom format in order to reduce the size of information required for validation work.</p>
|
||
|
||
<p>To further optimize the performance of the system, Ultraprune was introduced in parallel with LevelDB, which deprecated the old BDB database technology. Overall, the impact was notable: depending on their hardware, users could experience at least an order of magnitude improvement when validating blockchain data. This new database structure would also pave the way for future work on pruning and lighter implementations of Bitcoin full nodes.</p>
|
||
|
||
<h3 id="further-information-1">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/release/v0.8.0#improvements">Bitcoin-Qt 0.8.0 Release notes</a></li>
|
||
<li><a href="https://archive.is/bUocJ">Ultraprune in plain english</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=119525.0">Ultraprune merged in mainline</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=91954.0">Pruning in the reference client: ultraprune mode</a></li>
|
||
</ul>
|
||
|
||
<h2 id="parallel-script-verification">Parallel script verification</h2>
|
||
<p>Release: Bitcoin-Qt 0.8</p>
|
||
|
||
<p>While a more subtle change, transitioning script verification to a more parallelized process removed significant overhead from block validation times. Early versions of the software would validate script data from inputs in between every UTXO fetch, creating a performance issue because of the linear processing of all actions. This violates a basic principle for the design of efficient computing processes, which dictates that computation should happen concurrently with I/O jobs, where possible.
|
||
With that in mind, the block validation mechanism was re-engineered in order to be able to allocate script checks to parallel threads so that their verification can happen even before the client is done fetching all of the UTXOs from the block. To achieve this, script check actions are stored in a queue after transaction are processed and are handled separately from other input validation jobs.</p>
|
||
|
||
<p>As a consequence, synchronization to the tip of the chain happens much faster by making more efficient use of the peer’s resources. During testing of the implementation, developers noted 35% to 100% speed-up when benchmarking against previous versions of the software.</p>
|
||
|
||
<h3 id="further-information-2">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/pull/2060">Parallel script verification #2060</a></li>
|
||
</ul>
|
||
|
||
<h2 id="headers-first-synchronization">Headers first synchronization</h2>
|
||
<p>Release: Bitcoin Core 0.10</p>
|
||
|
||
<p>Striving to further improve initial block download time, the Core project introduced in late 2014 an important re-architecture of the mechanism used by nodes to synchronize with the most-work valid chain.</p>
|
||
|
||
<p>Initially, the process of bootstrapping a new Bitcoin client would involve a user fetching block data from a single peer with the consequence that any interruption or decrease in connection quality would significantly stall the process. With an ever-increasing blockchain size, this would result in sometimes massive waiting time for the synchronization to complete, with a large percentage of users reporting up to multi-day periods depending on their hardware.</p>
|
||
|
||
<p>Headers first synchronization completely mitigates this issue using a new method that involves nodes first downloading and validating block headers from a single peer and then fetching block data in parallel from a multitude of others.</p>
|
||
|
||
<p>Complaints about initial block download time have been prevalent since the early days of Bitcoin. With headers first synchronization, the software took a major step forward in terms of usability for new users. Rather than wasting many hours on unreliable synchronization, nodes could now leverage their entire network of peers and cut down the bootstrapping time significantly. With the use of smarter algorithms, another asymptotic improvement was made to this crucial aspect of Bitcoin’s long term sustainability.</p>
|
||
|
||
<h3 id="further-information-3">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/release/v0.10.0#faster-synchronization">Bitcoin-Qt 0.10.0 Release notes</a></li>
|
||
<li><a href="https://bitcoin.org/en/developer-guide#headers-first">Bitcoin.org Developer Guide</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-October/006724.html">Pieter Wuille’s post to the Bitcoin-dev mailing list</a></li>
|
||
</ul>
|
||
|
||
<h2 id="block-file-pruning">Block file pruning</h2>
|
||
<p>Release: Bitcoin Core 0.11</p>
|
||
|
||
<p>Pruning of old data was a concept first described by Satoshi Nakamoto in his white paper as a potential solution to disk space scarcity. Unfortunately, the original design was inadequate and could not be implemented as imagined by its creator. Seven years later, with the blockchain reaching more than a hundred gigabytes, the introduction of block file pruning as we know it today presents a major boon to users with limited resources.</p>
|
||
|
||
<p>Block file pruning leverages previous work with ultraprune; users who have initially downloaded and validated the blockchain may now discard raw data older than 288 blocks. Because those nodes still preserve the full UTXO set, they remain able to validate unspent data, which is enough to fully validate new blocks and protect against potential double-spends.</p>
|
||
|
||
<p>Of course, pruning implies that there remains a sufficient number of archival nodes around to serve full blockchain data. On the other hand, this innovation expands the range of validators by making it more cost-effective to remain one. As a whole, the solution is a welcome addition to the options available for us to bolster network diversity.</p>
|
||
|
||
<h3 id="further-information-4">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/release/v0.11.0#block-file-pruning">Bitcoin-Qt 0.11.0 Release notes</a></li>
|
||
</ul>
|
||
|
||
<h2 id="libsecp256k1">libsecp256k1</h2>
|
||
<p>Release: Bitcoin Core 0.12</p>
|
||
|
||
<p>After measurements, it was determined that the next step after solving the inefficiencies of blockchain download was to tackle the bottleneck of transaction verification and its heavy computing load. The Core project set out to do this by using a new library designed for optimized performance of ECDSA operations. ECDSA (Elliptic Curve Digital Signature Algorithm) is the backbone of Bitcoin’s public key infrastructure and is used every time a user moves coins by signing a message with their private keys. These signatures need to be verified by every peer in the network in order to preserve the ledger’s integrity.</p>
|
||
|
||
<p>Early developers had long considered transitioning away from the original OpenSSL library and after 5 years of design considerations, testing and peer-review, Pieter Wuille’s libsecp256k1 library was introduced as its replacement. As expected, the implementation led to major speed-up of the signature validation process behind every Bitcoin transaction. Benchmarks reported 5–7x improvements over the OpenSSL implementation. For users this would translate to saving up to half the bootstrap time typically dedicated to ECSDA operations, one of the most laborious steps in synchronizing a new node from scratch.</p>
|
||
|
||
<p>Considering the growth in Bitcoin transaction activity, this upgrade was essential to preserving a reasonable user experience for network peers. Once again, reduction of algorithmic complexity provided users with more efficient usage of their resources and drastically lowered the barrier of entry for new participants.</p>
|
||
|
||
<h3 id="further-information-5">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/release/v0.12.0#signature-validation-using-libsecp256k1">Bitcoin-Qt 0.12.0 Release notes</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?action=profile;u=80376">Andrew Poelstra (andytoshi) on security and testing of libsecp256k1</a></li>
|
||
<li><a href="https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/">Greg Maxwell on testing of libsecp256k1 revealing bug in OpenSSL</a></li>
|
||
<li><a href="https://www.youtube.com/watch?v=RguZ0_nmSPw&amp;t=1297">Greg Maxwell presentation at DevCore</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=3238.0">Hal Finney post on libsecp256k1</a></li>
|
||
</ul>
|
||
|
||
<h2 id="memory-pool-limiting">Memory pool limiting</h2>
|
||
<p>Release: Bitcoin Core 0.12</p>
|
||
|
||
<p>A long standing vulnerability of the Bitcoin software was its inability to properly deal with the flooding of a peer’s memory pool. Indeed, an attacker could send a high number of low value, low fee transactions that would accumulate in the memory pool until it would overload the memory available. This would cause nodes with relatively low RAM resources to crash during periods of unusual activity. The only effective measure against this was to increase the software’s minimum relay fee which still left no upper bound on the potential size of the mempool.</p>
|
||
|
||
<p>To remediate this, developers of the Core project implemented a strict memory pool maximum size with specific eviction policies sorting transactions by fees and evicting the lowest paying ones first. In order to prevent transactions with the same fee from re-entering the memory pool, the node will increase its effective minimum relay feerate to match the one of the last evicted transaction plus the initial minimum relay feerate.</p>
|
||
|
||
<p>Configuration of the maximum size is left to the users with the default size being 300 megabytes. This update provides a much more robust experience for node users with limited resources and, in general, makes the entire network more reliable.</p>
|
||
|
||
<h3 id="further-information-6">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/release/v0.12.0#memory-pool-limiting">Bitcoin-Qt 0.12.0 Release notes</a></li>
|
||
</ul>
|
||
|
||
<p>In Part 2, we will discuss more recent improvements that build on the technologies presented above and further improve the robustness and scaling potential of the network.</p>
|
||
</description>
|
||
<pubDate>Mon, 13 Mar 2017 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.14.0 Released with Performance Improvements</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#ibd" id="markdown-toc-ibd">Improved Initial Block Download (IBD) Performance</a> <ul>
|
||
<li><a href="#assumed-valid-blocks" id="markdown-toc-assumed-valid-blocks">Assumed valid blocks</a></li>
|
||
<li><a href="#memory-sharing-between-mempool-and-utxo-db-cache" id="markdown-toc-memory-sharing-between-mempool-and-utxo-db-cache">Memory-sharing between mempool and UTXO DB cache</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#faster-relay" id="markdown-toc-faster-relay">Faster new block validation and relay</a> <ul>
|
||
<li><a href="#improved-signature-cache" id="markdown-toc-improved-signature-cache">Improved signature cache</a></li>
|
||
<li><a href="#earlier-bip152-compactblock-relay" id="markdown-toc-earlier-bip152-compactblock-relay">Earlier BIP152 compactblock relay</a></li>
|
||
<li><a href="#p2p-code-refactor-focused-on-concurrency-and-throughput" id="markdown-toc-p2p-code-refactor-focused-on-concurrency-and-throughput">P2P code refactor focused on concurrency and throughput</a></li>
|
||
<li><a href="#mempool-saved-to-disk" id="markdown-toc-mempool-saved-to-disk">Mempool saved to disk</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#fee-bump" id="markdown-toc-fee-bump">Optional fee bumping</a></li>
|
||
<li><a href="#conclusion" id="markdown-toc-conclusion">Conclusion</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We are pleased to <a href="/en/releases/0.14.0/">release</a> Bitcoin Core 0.14.0, which significantly speeds up the processing of historic blocks by newly started nodes and the validation and relay of new blocks by online nodes. An optional new feature (disabled by default) is also provided to allow wallet users to rebroadcast one of their previously-sent unconfirmed transactions with a higher fee, which may allow it to confirm more quickly.</p>
|
||
|
||
<p>A short summary of the major new features is provided below, with links to more details later in this post.</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong><a href="#ibd">Improved Initial Block Download (IBD) performance</a>:</strong> a full node that has been started for the first time can now validate all blocks up until the present faster than before. This is at least the sixth time IBD performance has been significantly improved by developers to help ensure that new users aren’t discouraged from running a full node because synchronizing the ever-growing block chain takes too long.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#faster-relay">Faster new block validation and relay</a>:</strong> miners in particular will benefit from improvements made in four existing Bitcoin Core features. The signature cache has been upgraded for machines with many CPU cores—a test on a system with 16 cores shows a 40% speed increase in processing a new block. The BIP152 CompactBlocks implementation will now relay some blocks before they’ve been fully validated, allowing those blocks to propagate across the peer-to-peer (P2P) network faster than before. The P2P network code has also generally been refactored to allow multiple actions to happen at the same time (concurrency) as well as to increase throughput, eliminating many potential delays in processing new blocks. Finally, unconfirmed transactions in each node’s mempool can now be saved to and restored from disk when the node is restarted.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#fee-bump">Optional fee bumping</a></strong>: Bitcoin Core’s wallet now allows users to optionally send transactions that opt-in to fee-based transaction replacement. This allows users to increase the fee their transactions pay even after they’ve broadcast an earlier version of the transaction. This feature is disabled by default.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="ibd">Improved Initial Block Download (IBD) Performance</h2>
|
||
|
||
<p>Over time, the constantly-increasing size of the block chain has forced new first-time nodes to process larger and large amounts of data before they can be used with a wallet to receive and send payments. Many previous Bitcoin and Bitcoin Core releases have included major improvements designed to eliminate the pain of this Initial Block Download (IBD), also called the initial sync. For example:</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Release</th>
|
||
<th>Major improvements in IBD</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><a href="https://bitcoin.org/en/release/v0.5.0">0.5.0</a></td>
|
||
<td>Skip verification of historic (checkpointed) signatures</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://bitcoin.org/en/release/v0.8.0">0.8.0</a></td>
|
||
<td>Switch to LevelDB &amp; parallel signature validation</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://bitcoin.org/en/release/v0.10.0">0.10.0</a></td>
|
||
<td>Headers-first sync and parallel block download</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://bitcoin.org/en/release/v0.11.0">0.11.0</a></td>
|
||
<td>Optional block file pruning to save disk space</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://bitcoin.org/en/release/v0.12.0">0.12.0</a></td>
|
||
<td>New fast signature validation library written from scratch (libsecp256k1)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://bitcoin.org/en/release/v0.13.1">0.13.1</a></td>
|
||
<td>Segwit to allow skipping download of historic signatures in the future</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>This 0.14.0 release includes two more improvements that significantly increase IBD speed:</p>
|
||
|
||
<ol>
|
||
<li>Assumed valid blocks</li>
|
||
<li>Memory-sharing between mempool and UTXO DB cache</li>
|
||
</ol>
|
||
|
||
<p>Those two optimizations are described in more detail below. A test of the speed of the previous release (Bitcoin Core 0.13.2) compared to the speed of this Bitcoin Core 0.14.0 release was performed using Amazon EC2 virtual private servers, type <code class="highlighter-rouge">t2.xlarge</code> with four cores and 16 GB memory at a cost of $0.188 USD per hour (excluding block storage costs). All Bitcoin Core settings were left at their defaults.</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Bitcoin Core 0.13.2 took 1 day, 12 hours, and 40 minutes to complete IBD for a total cost of $6.89.</p>
|
||
</li>
|
||
<li>
|
||
<p>Bitcoin Core 0.14.0 took 0 days, 6 hours, and 24 minutes to complete IBD for a total cost of $1.20.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>Under these testing conditions, Bitcoin Core 0.14.0 was 5.7 times faster at IBD than the previous version of Bitcoin Core.</p>
|
||
|
||
<p>Note: Bitcoin Core’s defaults are chosen to allow it to run on a large variety of hardware, including older machines with small amounts of memory. For users who want a faster sync than six hours, consider starting Bitcoin Core with the <code class="highlighter-rouge">-dbcache=</code> option higher than its <code class="highlighter-rouge">300</code> (MB) default. Many modern computers should be able to sync in about 3 hours using Bitcoin Core 0.14.0 and 8 GB of memory (<code class="highlighter-rouge">-dbcache=8000</code>).</p>
|
||
|
||
<h3 id="assumed-valid-blocks">Assumed valid blocks</h3>
|
||
|
||
<p>Bitcoin 0.3.2 introduced a mechanism called <em>checkpoints</em> to prevent denial-of-service attacks during IBD by ensuring that new full nodes couldn’t be tricked into spending excessive amounts of effort validating alternative block chains that were different than the best-known chain at certain points in time.</p>
|
||
|
||
<p>Bitcoin 0.5.0 built upon those checkpoints to speed up IBD by skipping verification of signatures in blocks that were earlier in the block chain than the most recent checkpoint.</p>
|
||
|
||
<p>Over time, other improvements in Bitcoin Core’s security (such as <a href="https://bitcoin.org/en/release/v0.10.0#faster-synchronization">headers-first sync</a> and <a href="https://github.com/bitcoin/bitcoin/pull/9053">minimum chainwork</a>) has reduced the need for checkpoints, while at the same time many Bitcoin developers have expressed the desire to remove checkpoints because they confuse new developers about the security model—checkpoints make it look like Bitcoin developers are deciding which chain is valid even though the intent was always to only accept the chain which the software had already decided was valid.</p>
|
||
|
||
<p>Assumed valid blocks is a new feature that separates the signature-skipping optimization from the checkpoints anti-denial-of-service mechanism so they can each be dealt with independently.</p>
|
||
|
||
<p>An assumed valid block is a block that individual users consider to be valid, including being part of a valid block chain. This is easy for anyone to test in a completely repeatable (deterministic) way: take any consensus-compatible Bitcoin implementation and run it on the whole block chain including the block in question. If the software doesn’t reject the block or any preceding block, it’s valid.</p>
|
||
|
||
<p>If someone who starts a new full node for the first time knows about any valid blocks, they can then provide the highest-height one of those blocks to Bitcoin Core 0.14.0 and the software will skip verifying signatures in the blocks before the assumed valid block. Since verifying signatures consumes a lot of CPU during IBD, using assumed valid blocks can significantly speed up IBD. All blocks after the assumed valid block will still have their signatures checked normally.</p>
|
||
|
||
<p>A critical difference between checkpoints and assumed valid blocks is that Bitcoin 0.3.2 required all checkpointed blocks to be part of the block chain but Bitcoin Core 0.14.0 does not require any assumed valid blocks to be part of the chain. If no assumed valid block provided by the user (or the system defaults) is part of the block chain, Bitcoin Core will simply verify all signatures for historic blocks. Or, if there’s a block chain fork and the valid block chain with the most proof of work doesn’t include a known assumed valid block, Bitcoin Core will still switch to the new best block chain even though it means abandoning the assumed valid block.</p>
|
||
|
||
<p>New users to Bitcoin probably won’t know about any valid blocks, but they probably also won’t know all the consensus rules—so they can simply use the copy of the full node software they download. Bitcoin Core 0.14.0 ships with a default assumed valid block that is set during the release process by having multiple well-known developers each confirm that a certain block is known to be valid by them (<a href="https://github.com/bitcoin/bitcoin/pull/9779">example</a>).</p>
|
||
|
||
<p>Anyone who wants to verify all signatures using Bitcoin Core can still do so by starting the program using <code class="highlighter-rouge">-assumevalid=0</code>. Anyone who wants to specify an alternative assumed valid block can specify the block identifier as a parameter to <code class="highlighter-rouge">assumevalid</code>; for example:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>-assumevalid=00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90
|
||
</code></pre></div></div>
|
||
|
||
<p>The default assumed valid block in Bitcoin Core 0.14.0 is #453354, 16
|
||
Februrary 2017, with hash
|
||
<code class="highlighter-rouge">00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90</code>.</p>
|
||
|
||
<h3 id="memory-sharing-between-mempool-and-utxo-db-cache">Memory-sharing between mempool and UTXO DB cache</h3>
|
||
|
||
<p>During IBD, Bitcoin Core doesn’t use it’s mempool because until you have
|
||
the most recent blocks there’s no way to verify most recently-created
|
||
transactions. This means that the memory allocated to the mempool
|
||
has historically simply been unallocated, meaning Bitcoin Core ran with
|
||
less memory during IBD than it did normally.</p>
|
||
|
||
<p>In Bitcoin Core 0.14.0, unused mempool memory is shared with the UTXO
|
||
database cache, which increases the number of Unspent Transaction
|
||
Outputs (UTXOs) that can be cached in fast memory rather than needing to
|
||
be stored and retrieved from a much slower disk drive.</p>
|
||
|
||
<h2 id="faster-relay">Faster new block validation and relay</h2>
|
||
|
||
<p>Four significant improvements in Bitcoin Core 0.14.0 will be especially interesting to miners and other users who need to receive and process new blocks as fast as possible.</p>
|
||
|
||
<h3 id="improved-signature-cache">Improved signature cache</h3>
|
||
|
||
<p>The first feature is an update of the signature cache to use <a href="https://en.wikipedia.org/wiki/Cuckoo_hashing">cuckoo hashing</a>. The signature cache allows Bitcoin Core to save (cache) the result of verifying signatures in an unconfirmed transaction so that when the same transaction appears in a new block, Bitcoin Core doesn’t need to verify the signatures again. Because signature verification is typically the most computationally-expensive part of processing a new block, using the signature cache significantly improves the speed at which new blocks can be processed by nodes that have been online for a while.</p>
|
||
|
||
<p>The existing signature cache in Bitcoin Core 0.13.2 and below works well for systems with fewer than eight CPU cores, but for systems with eight or more CPU cores a bottleneck (lock contention) appears that prevents the system from using all available cores as effectively as possible. The upgrade to using cuckoo hashing to provide a “cuckoo cache” eliminates this problem and allows more cores to be used effectively.</p>
|
||
|
||
<p>In a <a href="https://github.com/bitcoin/bitcoin/pull/8895#issuecomment-256931331">test</a> on a system with 16 cores, a new block was able to be added (connected) to the block chain 40% faster using 0.14.0 than a previous version of Bitcoin Core. For systems with fewer than 8 cores, there is no major performance increase, although the cuckoo cache does allow caching more signatures than before for the same amount of memory, so there can be a slight performance improvement.</p>
|
||
|
||
<h3 id="earlier-bip152-compactblock-relay">Earlier BIP152 compactblock relay</h3>
|
||
|
||
<p>The second feature improved in Bitcoin Core 0.14.0 is the BIP152 compactblock implementation. The previous implementation supported both of BIP152’s two opt-in modes:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>A <strong>low-bandwidth</strong> mode that attempts to send the minimum data necessary to relay a new block, including waiting for the receiving node to request
|
||
that specific new block.</p>
|
||
</li>
|
||
<li>
|
||
<p>A <strong>high-bandwidth</strong> mode that sends new block data without waiting for the receiving node to request that specific block. This risks sending the receiving node the same data that another node sent it—a waste of bandwidth—but helps ensure that blocks are transferred quickly.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The upgraded implementation enhances the high-bandwidth node by starting the relay of a new block before the block has been fully validated. In the best case, removing the validation delay can allow new blocks to propagate across multiple hops on the peer-to-peer network several times faster than they could before. In the worst case, some additional bandwidth is wasted transferring invalid blocks. In either case, the security model remains the same since all nodes will still reject invalid blocks.</p>
|
||
|
||
<h3 id="p2p-code-refactor-focused-on-concurrency-and-throughput">P2P code refactor focused on concurrency and throughput</h3>
|
||
|
||
<p>The third feature improved in Bitcoin Core 0.14.0 is the entire set of P2P networking code, which has been refactored to support increased concurrency and throughput. The concurrency improvements help allow newly-received blocks (such as BIP152 compactblocks) to be processed ahead of lower-priority traffic, ensuring that blocks are relayed and validated as fast as possible.</p>
|
||
|
||
<p>The refactor also now allows network activity to continue in the background during message processing, notably providing an improvement in IBD speed that complements the <a href="https://bitcoin.org/en/release/v0.10.0#faster-synchronization">headers-first sync</a> introduced in Bitcoin Core 0.10.0 (see <a href="#ibd">above</a> for more information).</p>
|
||
|
||
<h3 id="mempool-saved-to-disk">Mempool saved to disk</h3>
|
||
|
||
<p>A fourth feature which helps support the signature cache and compactblocks implementations is that the memory pool (mempool) of unconfirmed transactions received by each node is now saved to disk during regular shutdown, and is then loaded back into memory when the node starts back up.</p>
|
||
|
||
<p>Combined with compact blocks, this can save the node from having to re-download all those unconfirmed transactions when they are received in a newly-produced block. Combined with the signature cache, this allows the node to cache the signature verification of those unconfirmed transactions so that new blocks including those transactions can be validated more quickly.</p>
|
||
|
||
<h2 id="fee-bump">Optional fee bumping</h2>
|
||
|
||
<p>An optional feature in Bitcoin Core 0.14.0 (disabled by default) causes all new transactions produced by the the wallet to opt-in to <a href="https://en.bitcoin.it/wiki/Transaction_replacement">transaction replacement</a>, specifically BIP125 opt-in Replace By Fee (RBF).</p>
|
||
|
||
<p>When this feature is enabled by starting Bitcoin Core with the <code class="highlighter-rouge">-walletrbf</code> option, an additional RPC (<code class="highlighter-rouge">bumpfee</code>) is made available that allows a previously-sent unconfirmed transaction to be resent with a higher fee. Miners who support either opt-in RBF or full RBF will usually replace the lower-fee transaction with the higher-fee transaction in their queues, and the higher fee will encourage miners to mine the new version of the transaction more quickly.</p>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>For details on all the changes made in Bitcoin Core 0.14.0, please read the <a href="/en/releases/0.14.0/">release notes</a>. To download, please visit the <a href="https://bitcoin.org/en/download">download page</a> or the <a href="https://bitcoin.org/bin/bitcoin-core-0.14.0/">files directory</a>.</p>
|
||
|
||
<p>The next major planned release will be scheduled for approximately six months after the 0.14.0 release (but it will not be released until fully tested).</p>
|
||
|
||
<p>If you are interested in contributing to Bitcoin Core, please see our <a href="/en/contribute">contributing page</a> and the document <a href="/en/faq/contributing-code/">How to contribute code to Bitcoin Core</a>. If you don’t know where to get started or have any other questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a> chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<p>These are the SHA-256 hashes of the released files:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>466adccf7352f06de35afc1627a3ea721764268ceaf08fa3641f9b47e7df091a bitcoin-0.14.0-aarch64-linux-gnu.tar.gz
|
||
55957e2c35aa2ba836cbae7cbf945bcf489a46b243551b0f6fd86f60603032a6 bitcoin-0.14.0-arm-linux-gnueabihf.tar.gz
|
||
e4bb8b52acde07788dfcf024645fe291f0deca2b7172939fb2ddb8789fe56973 bitcoin-0.14.0-i686-pc-linux-gnu.tar.gz
|
||
e01e3cdd3c4138eccaf0c1267caa3bcdb6949ee63c1e396842b70f102fb4bcaf bitcoin-0.14.0-osx64.tar.gz
|
||
50fea43935e93381552b6730444eed6bbe513637a785e1b864b0c5883729228c bitcoin-0.14.0-osx.dmg
|
||
d743d4866a0d4c1457f81530c45258a8b6383d1cafc458eedcba8d01728a641e bitcoin-0.14.0.tar.gz
|
||
95a030be5c1649023e3aa81d1cd9eabd4258f1b00f0fc51066d02126219705af bitcoin-0.14.0-win32-setup.exe
|
||
864ef77b9b4812ec59adff04d44213a6039c66970a9ae31e8620997a8c1537bc bitcoin-0.14.0-win32.zip
|
||
f260d52cf2fe91c4be99ed6fcf8aa0de669ff326c5da920b7ed3a3e2ec981e0a bitcoin-0.14.0-win64-setup.exe
|
||
415693ed81cfc4960bbfcb815529003405aefbf839ef8fc901b0a2c4ef5317d0 bitcoin-0.14.0-win64.zip
|
||
06e6ceeb687e784e9aaad45e9407c7eed5f7e9c9bbe44083179287f54f0f9f2b bitcoin-0.14.0-x86_64-linux-gnu.tar.gz
|
||
</code></pre></div></div>
|
||
|
||
</description>
|
||
<pubDate>Wed, 08 Mar 2017 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/03/08/release-0.14.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/03/08/release-0.14.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.13.2 Released</title>
|
||
<description><p>We are please to announce the general availability of Bitcoin Core 0.13.2. This <a href="/en/releases/0.13.2/">release</a> forms part of the regular maintenance cycle of Bitcoin Core and brings bug fixes, optimisations and improvements to the 0.13.x series.</p>
|
||
|
||
<p>Please see the <a href="/en/releases/0.13.2/">release notes</a> for more details.</p>
|
||
|
||
<h2 id="download-now">Download Now</h2>
|
||
|
||
<p>Binaries are available from the <a href="https://bitcoin.org/bin/bitcoin-core-0.13.2/">download directory</a>. Power users can fetch and compile from the <a href="https://github.com/bitcoin/bitcoin/releases/tag/v0.13.2">Bitcoin Core v0.13.2 release tag</a>. If downloading binaries, please ensure you check the verification hashes below and from the <a href="https://bitcoin.org/en/download">download page</a>. If compiling from source, please check the <code class="highlighter-rouge">v0.13.2</code> tag signature matches.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<p>These are the <a href="https://bitcoin.org/bin/bitcoin-core-0.13.2/SHA256SUMS.asc">SHA-256 hashes</a> of the released files:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>eda24dcf0b9fae606eb9811f74ddba69a3287316950f3f02b3000b6b1c02b65f bitcoin-0.13.2-aarch64-linux-gnu.tar.gz
|
||
3c460784d3ab64645d48389c467336a38da473706a69f22f39cfcce5e0f33780 bitcoin-0.13.2-arm-linux-gnueabihf.tar.gz
|
||
790e4c7ebf9f4a734d1d2b6bb5e9f5fb3f613f6f93da30fd1420c5b4115dd72f bitcoin-0.13.2-i686-pc-linux-gnu.tar.gz
|
||
8037b25310966127c589eb419534d7763ad62c2c29b94e0a37a5c5f5d96f541a bitcoin-0.13.2-osx64.tar.gz
|
||
dac105b49c159a3d8c9463d1f05afe4cf29ec40bbd145e8961132693b7eff953 bitcoin-0.13.2-osx.dmg
|
||
621201189c0409cb17a5073278872dcdcfff1ea147ead6958b55e94416b896d7 bitcoin-0.13.2.tar.gz
|
||
27c4be7f571050f6c361e44ca70553d4d2b555b69d568306b676734100d929e1 bitcoin-0.13.2-win32-setup.exe
|
||
4d1c26675088219d8e2204b5a9f028916d5982db860298a70b6ed08e30af2a53 bitcoin-0.13.2-win32.zip
|
||
8960defc12287dd9248b99bab02a0854c072e6a3850757036c585cbd628217bf bitcoin-0.13.2-win64-setup.exe
|
||
e07ce2a8cc0913fb253a42073fd3b94921da7f916366dd0534f3b24cad7a733e bitcoin-0.13.2-win64.zip
|
||
29215a7fe7430224da52fc257686d2d387546eb8acd573a949128696e8761149 bitcoin-0.13.2-x86_64-linux-gnu.tar.gz
|
||
</code></pre></div></div>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>If you are interested in contributing to Bitcoin Core, please see our <a href="/en/contribute">contributing page</a> and the document <a href="/en/faq/contributing-code/">How to contribute code to Bitcoin Core</a>. If you don’t know where to get started or have any other questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a> chatroom and we’ll do our best to help you.</p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 03 Jan 2017 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2017/01/03/release-0.13.2/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2017/01/03/release-0.13.2/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Segregated Witness Costs and Risks</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#introduction" id="markdown-toc-introduction">Introduction</a> <ul>
|
||
<li><a href="#aims" id="markdown-toc-aims">Aims</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#serialisation-costs" id="markdown-toc-serialisation-costs">Serialisation costs</a> <ul>
|
||
<li><a href="#rationale" id="markdown-toc-rationale">Rationale</a></li>
|
||
<li><a href="#future-reductions" id="markdown-toc-future-reductions">Future reductions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#block-validation-costs" id="markdown-toc-block-validation-costs">Block validation costs</a></li>
|
||
<li><a href="#risk-of-introducing-bugs" id="markdown-toc-risk-of-introducing-bugs">Risk of introducing bugs</a> <ul>
|
||
<li><a href="#avoidance" id="markdown-toc-avoidance">Avoidance</a></li>
|
||
<li><a href="#mitigation" id="markdown-toc-mitigation">Mitigation</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#risks-related-to-complexity-and-technical-debt" id="markdown-toc-risks-related-to-complexity-and-technical-debt">Risks related to complexity and technical debt</a> <ul>
|
||
<li><a href="#avoidance-1" id="markdown-toc-avoidance-1">Avoidance</a></li>
|
||
<li><a href="#mitigation-1" id="markdown-toc-mitigation-1">Mitigation</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#risks-related-to-soft-fork-deployment" id="markdown-toc-risks-related-to-soft-fork-deployment">Risks related to soft-fork deployment</a> <ul>
|
||
<li><a href="#avoidance-2" id="markdown-toc-avoidance-2">Avoidance</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#risks-due-to-larger-blocks" id="markdown-toc-risks-due-to-larger-blocks">Risks due to larger blocks</a> <ul>
|
||
<li><a href="#avoidance-3" id="markdown-toc-avoidance-3">Avoidance</a></li>
|
||
<li><a href="#mitigation-2" id="markdown-toc-mitigation-2">Mitigation</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#risks-due-to-lower-fees" id="markdown-toc-risks-due-to-lower-fees">Risks due to lower fees</a> <ul>
|
||
<li><a href="#avoidance-4" id="markdown-toc-avoidance-4">Avoidance</a></li>
|
||
<li><a href="#mitigation-3" id="markdown-toc-mitigation-3">Mitigation</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#risks-related-to-long-term-scaling" id="markdown-toc-risks-related-to-long-term-scaling">Risks related to long term scaling</a> <ul>
|
||
<li><a href="#avoidance-5" id="markdown-toc-avoidance-5">Avoidance</a></li>
|
||
<li><a href="#mitigation-4" id="markdown-toc-mitigation-4">Mitigation</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#alternative-approaches" id="markdown-toc-alternative-approaches">Alternative approaches</a> <ul>
|
||
<li><a href="#hard-forked-segwit" id="markdown-toc-hard-forked-segwit">Hard-forked segwit</a></li>
|
||
<li><a href="#simpler-segwit" id="markdown-toc-simpler-segwit">Simpler segwit</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<h2 id="introduction">Introduction</h2>
|
||
|
||
<p>This post is a companion to the earlier post on <a href="/en/2016/01/26/segwit-benefits/">Segregated Witness Benefits</a>, giving an overview of the technical costs and risks that may be incurred by activating segregated witness via <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">BIP141</a>.</p>
|
||
|
||
<h3 id="aims">Aims</h3>
|
||
|
||
<p>For the purpose of this post, we will use <em>costs</em> to describe negative results that are certain to occur if segwit is deployed and activated, and <em>risks</em> to describe negative impacts that may not happen, or changes that not everyone may consider negative.</p>
|
||
|
||
<p>When analysing risks, we consider steps undertaken to <em>avoid</em> the risk (that is, to minimise the chance of it occurring), and steps undertaken to <em>mitigate</em> the risk (that is, if it does occur, how the negative impact can be minimised).</p>
|
||
|
||
<p>This post does not attempt to produce a conclusion as to whether the benefits outweigh the costs or whether segwit should be deployed or activated, but rather to assist by providing background information to assist stakeholders in making informed decisions.</p>
|
||
|
||
<h2 id="serialisation-costs">Serialisation costs</h2>
|
||
|
||
<p>Transactions and block information are serialised for three main purposes:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>Transmission across the peer-to-peer network;</p>
|
||
</li>
|
||
<li>
|
||
<p>Storage of the blockchain on disk; and</p>
|
||
</li>
|
||
<li>
|
||
<p>Evaluation of block limits.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>Segwit affects serialisation in two ways:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>A witness commitment is included in the coinbase transaction, adding between 38 and 47 bytes, or about 0.005% of a block. (See <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure">BIP 141 - commitment structure</a>)</p>
|
||
</li>
|
||
<li>
|
||
<p>A new transaction serialisation that includes the segregated witness data is defined (see <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_ID">BIP 141</a>, or <a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#Serialization">BIP 144</a>). This adds an overhead of 2 bytes per transaction to allow the serialisation formats to be easily distinguished, and an overhead of 1 byte per input for the count of witness items for each input. These combine to about 1% per transaction.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The segwit transaction formats (see <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program">BIP 141 - witness program</a>) have the following impact when serialised:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Compared to P2PKH, P2WPKH uses 3 <em>fewer</em> bytes (-1%) in the scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.</p>
|
||
</li>
|
||
<li>
|
||
<p>Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the scriptPubKey, and the same number of witness bytes as P2SH scriptSig.</p>
|
||
</li>
|
||
<li>
|
||
<p>Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.</p>
|
||
</li>
|
||
<li>
|
||
<p>Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig compared to P2SH scriptPubKey, and the same number of witness bytes as P2SH scriptSig.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The percentages above are based on a transaction of 180 bytes with one input and one output. These proportions remain roughly the same as the number of inputs/outputs increases, but decreases if more complicated transaction scripts (such as multisig) are in use.</p>
|
||
|
||
<h3 id="rationale">Rationale</h3>
|
||
|
||
<p>The transaction size overhead is due to two factors:</p>
|
||
|
||
<ol>
|
||
<li>using a 256 bit hash for P2WSH rather than the 160 bit hash for P2SH; and</li>
|
||
<li>encoding via P2SH so that old wallets that don’t support segwit can send funds that can be spent using segwit, allowing the receiver to gain segwit’s benefits.</li>
|
||
</ol>
|
||
|
||
<p>Without these two factors, the overhead would be negligible at -3 bytes for P2WPKH and +1 bytes for P2WSH.</p>
|
||
|
||
<p>The motivation behind the first factor is discussed under <a href="/en/2016/01/26/segwit-benefits/#increased-security-for-multisig-via-pay-to-script-hash-p2sh">Increased security for multisig via pay-to-script-hash (P2SH)</a>.</p>
|
||
|
||
<p>The second factor is a tradeoff that individual users can make when publishing a receiving address, and users who choose P2WPKH/P2SH or P2WSH/P2SH will pay higher fees in proportion to the overhead. This should naturally limit the impact of this overhead in the long term.</p>
|
||
|
||
<h3 id="future-reductions">Future reductions</h3>
|
||
|
||
<p>It is possible to make most of this overhead disappear via changes to the network and storage serialisation formats: the full serialisation can be recovered from a simple flag indicating which format is in use (P2PKH, P2WPKH, P2WPKH/P2SH, etc) along with the actual data (the pubkey and signature). (For example, <a href="https://people.xiph.org/~greg/compacted_txn.txt">compacted_txn.txt</a>)</p>
|
||
|
||
<h2 id="block-validation-costs">Block validation costs</h2>
|
||
|
||
<p>With segwit, additional processing is introduced when validating a block in order both to check the witness merkle tree, and to deal with P2SH-encoded witness transactions. This requires about five additional SHA256 hashes per transaction, an additional SHA256 per P2SH-encoded-P2WSH input, and an additional HASH160 per P2SH-encoded-P2WPKH output. This however only amounts to about six SHA256 runs over at most 4MB of data, or roughly about 24MB of SHA256 data in total, which should translate to at most an additional 15
|
||
seconds per block on a Raspberry Pi v1, or under 1/10th of a second on more capable hardware.</p>
|
||
|
||
<h2 id="risk-of-introducing-bugs">Risk of introducing bugs</h2>
|
||
|
||
<p>The segwit patch set is a major change to Bitcoin, and was rolled out, though not activated on the main Bitcoin network, in Bitcoin Core 0.13.0. Any major change like this runs a variety of risks, including:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Outright bugs: mistakes can be made in design or implementation giving unexpected or harmful results. For example <a href="https://github.com/bitcoin/bitcoin/pull/8525">PR#8525</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p>User errors: changes to the system can result in user confusion, resulting in incorrect use of the system, which in turn may lead to harmful results.</p>
|
||
</li>
|
||
<li>
|
||
<p>Ecosystem interactions: different parts of the Bitcoin ecosystem may have hard-coded assumptions that will be violated with the update. For example, applications that parse bitcoind’s block store will need to be updated to understand the new serialisation.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="avoidance">Avoidance</h3>
|
||
|
||
<p>In order to reduce the chances of these risks occurring when segwit is activated, the following steps have been undertaken:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Peer review: all the changes in segwit, both design and implementation, have been presented publicly and reviewed by multiple independent experts; often resulting in suggested improvements being undertaken.</p>
|
||
|
||
<p>Public presentations include:</p>
|
||
|
||
<ul>
|
||
<li><a href="https://www.elementsproject.org/elements/segregated-witness/">Elements Project</a></li>
|
||
<li><a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/">Scaling Bitcoin Hong Kong</a></li>
|
||
<li><a href="https://www.youtube.com/watch?v=NOYNZB5BCHM">SF Bitcoin Devs</a></li>
|
||
<li><a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/segwit-lessons-learned/">Scaling Bitcoin Milan</a></li>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">BIP141</a>,
|
||
<a href="https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki">BIP142</a>,
|
||
<a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">BIP143</a>,
|
||
<a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki">BIP144</a>, and
|
||
<a href="https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki">BIP145</a></li>
|
||
</ul>
|
||
|
||
<p>Technical reviews include:</p>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/pull/7910">PR#7910</a></li>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/pull/8149">PR#8149</a></li>
|
||
<li><a href="https://github.com/sipa/bitcoin/pulls?utf8=%E2%9C%93&amp;q=is%3Apr%20">Development branch pull requests</a></li>
|
||
<li><a href="/logs/2016-05-zurich-meeting-notes.html">Bitcoin Core Zurich Meeting</a></li>
|
||
<li><a href="https://petertodd.org/2016/segwit-consensus-critical-code-review">Peter Todd’s review</a></li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Test cases: as described in the <a href="/en/2016/06/24/segwit-next-steps/#how-segwit-was-tested">Next Steps</a> post, “The combined changes to the consensus rules and the P2P networking code consist of 1,486 lines of added or modified code. The segwit patch also includes an additional 3,338 lines of added or modified code in the unit and integration tests that help ensure segwit is functioning as expected on every full build of the Bitcoin Core program.”</p>
|
||
</li>
|
||
<li>Test networks: during development, segregated witness has been deployed on multiple test nets, allowing the code to be vetted, and developers from the wider ecosystem, such as block explorers and wallets, to ensure their software interoperates correctly with segregated witness. These test networks have included:
|
||
<ul>
|
||
<li>Elements Project – tested the concept of segregated witness implemented as a hard-fork, along with many other changes</li>
|
||
<li>segnet1 through segnet4 – tested implementation of segwit as a soft-fork, between January and May 2016</li>
|
||
<li>testnet3 – segwit activated on the standard testnet in May 2016</li>
|
||
</ul>
|
||
</li>
|
||
<li>Alternative implementations: the segwit BIPs have been reimplemented in <a href="https://github.com/btcsuite/btcd/pull/656">btcd</a> (Go) and <a href="https://medium.com/purse-essays/introducing-bcoin-fdfcb22dfa34">Bcoin</a> (Javascript), as well as in various wallets and libraries. Independent reimplementation helps shake out unstated assumptions and ambiguities in the design, and avoid bugs that may result from them.</li>
|
||
</ul>
|
||
|
||
<h3 id="mitigation">Mitigation</h3>
|
||
|
||
<p>A major factor in mitigating the impact of any bugs is that segwit is implemented as a soft-fork. This means:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Users of Bitcoin can simply avoid newly introduced features until they are personally confident they are implemented correctly, without losing any functionality.</p>
|
||
</li>
|
||
<li>
|
||
<p>All valid segwit blocks are also valid blocks to pre-segwit software, so earlier versions of Bitcoin that don’t include the segwit changes, and hence don’t include any bugs introduced in those changes, can be used to verify blocks to provide a second level of assurance against the possibility of consensus regressions.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>In addition, the possibility of versioning the “script” language introduces the possibility to fix bugs in the Bitcoin script language, including both pre-existing bugs as well as any potential new bugs that segwit may introduce.</p>
|
||
|
||
<h2 id="risks-related-to-complexity-and-technical-debt">Risks related to complexity and technical debt</h2>
|
||
|
||
<p>The concept of <em>technical debt</em> is that an easy fix now might cause enough difficulty and problems in the long term, that spending more time and effort now will turn out to be more economical.</p>
|
||
|
||
<p>In the context of Bitcoin, there are two types of technical debt:</p>
|
||
|
||
<ul>
|
||
<li>ugly or complicated code, that can be refactored without impacting users or consensus; and</li>
|
||
<li>poor design decisions, many of which have to be retained indefinitely, as otherwise Bitcoin users would lose access to their existing coins.</li>
|
||
</ul>
|
||
|
||
<h3 id="avoidance-1">Avoidance</h3>
|
||
|
||
<p>As noted above, the segwit code has been heavily reviewed, which helps resist the introduction of technical debt at both a code and design level.</p>
|
||
|
||
<p>Also as noted above, segwit has multiple independent reimplementations, which helps discover any unnecessary complexity and technical debt at the point that it can still be avoided.</p>
|
||
|
||
<p>In support of existing efforts to pay down technical debt by refactoring and improving the Bitcoin codebase, segwit was merged as a code-only update as part of <a href="/en/meetings/2016/05/26/">work towards the 0.13.0 release</a>.</p>
|
||
|
||
<h3 id="mitigation-1">Mitigation</h3>
|
||
|
||
<p>Bitcoin already suffers from some significant design debt, and segwit is specifically designed to reduce the impact of some of this debt (notably transaction malleability, quadratic scaling of signature hashing, and non-signing of input values).</p>
|
||
|
||
<p>The script versioning method provided by segwit provides an elegant way of allowing future soft-fork updates to further reduce design debt, including by fixing bugs in existing opcodes (such as CHECKMULTISIG), re-enabling disabled opcodes (such as CAT), or switching to superior verification methods (such as Schnorr signatures, or aggregate signatures).</p>
|
||
|
||
<p>Generally, design debt in Bitcoin script cannot be fully paid off, as it is always possible that there are some unspent transactions paying to P2SH addresses that make use of the “ugly” functionality. Disabling those features would render those transactions unspendable, effectively stealing funds from users. Script versioning allows the “cost” of this design debt to be reduced, by partitioning such “ugly” functionality as only applicable to “old” script versions, thus allowing new development work to largely ignore the old code.</p>
|
||
|
||
<h2 id="risks-related-to-soft-fork-deployment">Risks related to soft-fork deployment</h2>
|
||
|
||
<p>A soft-fork is any change to Bitcoin consensus rules that invalidates some set of previously valid transaction. A poorly handled soft-fork can cause a number of problems in the Bitcoin ecosystem, and, because segwit makes the additional witness data critical to establishing Bitcoin’s distributed consensus, a poorly handled upgrade could cause the system to fail in additional ways. The primary potential failure modes include:</p>
|
||
|
||
<ol>
|
||
<li>making it impossible for some Bitcoin holders to spend their money</li>
|
||
<li>causing old nodes and upgraded nodes to have a different view of which unconfirmed transactions are valid and likely to be mined</li>
|
||
<li>having miners mistakenly mine blocks that are not valid under the new rules</li>
|
||
<li>being activated, with some actual use, then backed out</li>
|
||
<li>allowing large blockchain forks, due to the p2p network being effectively disconnected as a result of connections via old nodes that are unable to forward witness data</li>
|
||
</ol>
|
||
|
||
<h3 id="avoidance-2">Avoidance</h3>
|
||
|
||
<p>Numerous soft-forks have already been activated in Bitcoin (including BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki">16</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki">34</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki">65</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">66</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">68</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">112</a>, and <a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">113</a>), and this experience has been codified in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> process for activating soft-forks. The BIP9 process was used for deploying the CSV soft-fork (BIPs 68, 112, and 113), and resulted in a fast and unproblematic upgrade to the consensus rules for that change.</p>
|
||
|
||
<p>The segwit design and BIP9 deployment avoids the problems listed above in the following ways:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>The new restrictions imposed by segwit only affect transactions that no one would currently make use of because:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>The affected transactions would be non-standard, and thus not relayed by the vast majority of nodes or mined by most miners.</p>
|
||
</li>
|
||
<li>
|
||
<p>Any transactions that were affected would currently be considered obvious “anyone can spend” payments, and could immediately be claimed by anyone monitoring the blockchain, and therefore should have been expected to be “lost”.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Old nodes will consider transactions spending segwit outputs as non-standard, due to apparent violation of <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki">BIP62</a> CLEANSTACK rules, and thus won’t be included in old nodes’ mempools. Similarly, transactions with P2WPKH or P2WSH outputs (though not P2WPKH/P2WSH encoded via P2SH) will also be considered non-standard due to being a new output type.</p>
|
||
|
||
<p>This makes it impossible to achieve double spends of segwit outputs by relaying one transaction through old nodes and a different transaction through segwit nodes.</p>
|
||
|
||
<p>However, these differences may still be used to attempt a double spend, for example by combining a non-segwit output and a segwit output in a single transaction (that will only be relayed via the upgraded segwit nodes), then attempting to double-spend it via a higher fee transaction only using the non-segwit output, which may be successfully relayed via the old nodes.</p>
|
||
|
||
<p>These concerns only affect unconfirmed transactions in the mempool; once a transaction is confirmed and mined in a block, double spending remains impossible. Existing methods for monitoring double spends should remain equally effective, provided the monitoring tools are able to track segwit spends at all.</p>
|
||
</li>
|
||
<li>
|
||
<p>Ensuring miners mine valid blocks is obviously a high priority to everyone involved, and significant work has gone into guaranteeing this is the case with segwit. This includes both the direct work, under <a href="https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki">BIP145</a>, as well as indirect work, such as Compact Blocks (<a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">BIP152</a>).</p>
|
||
</li>
|
||
<li>
|
||
<p>If the segwit soft-fork were reverted after being activated, this could allow anyone who had made segwit transactions to lose funds – for example, a malicious miner could replay the transaction on a chain without segwit enabled, at which point it would be anyone-can-spend, and the miner could then steal the funds by spending it to themselves. There are two ways in which a segwit soft-fork could be reverted after being activated while allowing theft of segwit-enabled transactions:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Miners could abandon the segwit enabled chain and start mining from prior to segwit’s activation. Based on the <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> activation rules, this would require abandoning over 2016 blocks (the LOCKED IN period, plus enough blocks to ensure the 95% threshold wasn’t reached). This would require miners to abandon over 25,200 BTC in block reward, which at current prices is over $15,000,000 USD.</p>
|
||
</li>
|
||
<li>
|
||
<p>Miners could simply use software that does not recognise segwit rules (such as earlier versions of Bitcoin Core) to mine blocks on top of a chain that has activated segwit. This would be a hard-fork as far as segwit-aware software is concerned, and those blocks would consequently be ignored by Bitcoin users using segwit-aware validating nodes. If there are sufficiently many users using segwit nodes, such a hard-fork would be no more effective than introducing a new alt coin.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>As a result, neither approach seems likely.</p>
|
||
</li>
|
||
<li>
|
||
<p>Significant work has gone into ensuring that segwit enabled peers will form a strongly connected subgraph of the Bitcoin P2P network. This includes providing a dedicated service bit for witness enabled nodes and preferentially connecting to such nodes.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<h2 id="risks-due-to-larger-blocks">Risks due to larger blocks</h2>
|
||
|
||
<p>Segwit updates the 1MB block size limit to a 4M unit block weight limit, counting serialised witness data as one unit, and core block data as four units. As transactions that use segwit features begin to be used, this change will allow more data to be included per block (with 100% of transactions using segwit features this is expected to be about 2MB of data per block, however in the worst case could be up to 4MB of data per block). In so far as it allows a greater transaction volume, it can be expected to increase the UTXO database more quickly (with 100% of transactions using segwit features, the rate of increase might be expected to approximately double; however because segwit is a soft fork, the worst case UTXO growth is unchanged).</p>
|
||
|
||
<p>These outcomes may have positive attributes (more volume allows more user uptake, for example), but also have possibly significant negatives:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Larger blocks may result in slower block transmission, resulting in higher orphan rates for miners – this in turn may result in lower security (less hashpower required to take over the network), or higher centralisation (larger miners being more able to reduce their orphan rate).</p>
|
||
</li>
|
||
<li>
|
||
<p>Larger blocks will result in higher resource requirements for full nodes, potentially causing users to shut down their nodes, which would result in higher centralisation.</p>
|
||
</li>
|
||
<li>
|
||
<p>Larger UTXO sets will result in higher resource requirements for miners, potentially causing miners to share validation resources, which would result in higher centralisation.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="avoidance-3">Avoidance</h3>
|
||
|
||
<p>The negative impact of larger blocks is limited in a number of ways:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Validation times of blocks have been significantly reduced thanks to deployment of libsecp256k1.</p>
|
||
</li>
|
||
<li>
|
||
<p>Deployment of Compact Blocks via <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">BIP152</a> helps limit the impact of larger blocks on block transmission, and hence orphan rates, and also reduces the bandwidth usage of full nodes.</p>
|
||
</li>
|
||
<li>
|
||
<p>Pruning support allows users to run full nodes without storing the entire history of the blockchain, which allows users who have constrained storage resources to continue running full nodes, even with a larger block size.</p>
|
||
</li>
|
||
<li>
|
||
<p>The changes to the signature hashing algorithm used by segwit signatures to avoid quadratic scaling, provides a significant reduction in cost for some large transactions.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The negative impact of increased UTXO growth is limited by:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>The deployment of segwit as a soft-fork to ensure the worst-case UTXO growth does not get any worse.</p>
|
||
</li>
|
||
<li>
|
||
<p>The reduced weighting of witness data to rebalance the lifecycle cost of a UTXO, reducing the cost of introducing an additional input that spends a segwit output, and therefore (relatively) increasing the cost of introducing an additional output creating a new UTXO, changing the create/spend cost ratio from about 1:4.5 to about 1:2. This should moderately reduce incentives to increase the UTXO set by both discouraging UTXO creation, and encouraging spending of UTXOs.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="mitigation-2">Mitigation</h3>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Since the maximum amount of data per block is capped at no more than four times the current rate, mitigation work to address problems that arise from large blocks should be within the bounds of relatively straightforward engineering work. Further, since the expected amount of data per block is only approximately double the current rate, this means any necessary mitigation efforts should be further eased.</p>
|
||
</li>
|
||
<li>
|
||
<p>There is ongoing work to improve on-disk and network serialisation of transactions and blocks, further reducing the storage and bandwdith requirements of running a full node.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="risks-due-to-lower-fees">Risks due to lower fees</h2>
|
||
|
||
<p>The security of the Bitcoin blockchain is provided by hashpower, which is rewarded by both a fixed block reward and by fees from individual transactions. As a result, decreases in fee income have the potential to reduce the hashpower used to mine Bitcoin, which in turn may lower the security of the Bitcoin blockchain.</p>
|
||
|
||
<p>In so far as the individual transaction fees are determined by market forces and supply and demand, the changes introduced by segwit may risk lowering prices by increasing supply (presuming that demand does not also rise, either because of or at least concurrent with segwit deployment), and lower individual prices may result in lower overall mining revenue (if the price elasticity of demand is in the inelastic range).</p>
|
||
|
||
<p>In addition, the changes made in segwit may make “layer two” solutions, such as the Lightning Network, more compelling. If this leads to users treating layer two solutions as a substitute for on-chain transactions, this may significantly decrease demand for on-chain transactions, which would put additional downward pressure on transaction fee levels.</p>
|
||
|
||
<h3 id="avoidance-4">Avoidance</h3>
|
||
|
||
<p>Fees are currently approximately 0.5 BTC per block versus 12.5 BTC per block from the block subsidy, or about 4% of miner income, so the potential impact on miner income and hence network security is likely small in the short term.</p>
|
||
|
||
<p>In addition, fees have been rising over the past twelve months both in BTC denominated value (from under 0.2 BTC per block a year ago) and in real terms (from under $300 USD per BTC a year ago, to over $600 USD per BTC today), so moderate falls in fee levels will only be equivalent to reverting to fee incomes from up to twelve months ago, which should not be a major impact.</p>
|
||
|
||
<h3 id="mitigation-3">Mitigation</h3>
|
||
|
||
<p>Miners are able to individually and collectively limit supply, either by individually setting a soft-limit on the maximum weight for blocks they produce (“blockmaxweight” setting, which defaults to 3M), or by collectively using a soft-fork to effectively lower the consensus limits by orphaning blocks above a particular weight. This approach has the potential to prevent any fee decreases due to increased supply (or indeed to increase individual fees by reducing supply, though that may not increase overall revenue), but cannot prevent decreases to fee income due to substitution effects (such as the adoption of layer two networks).</p>
|
||
|
||
<p>While layer two networks may act as a substitute for on-chain transactions, they cannot avoid on-chain transactions entirely, and in some scenarios, even these comparatively few on-chain transactions from layer two networks can easily saturate the on-chain capacity with segwit enabled. Even if only a very small amount of the value of these networks are captured via on-chain transaction fees, this would likely be substantially above the current fee value.</p>
|
||
|
||
<h2 id="risks-related-to-long-term-scaling">Risks related to long term scaling</h2>
|
||
|
||
<p>As described above, full adoption of segwit by all transactions is expected to approximately double capacity. This provides a significant one-time increase in capacity, in either the short or medium term, depending on the speed of adoption. In addition, by adding features to enable layer two networks, some additional medium and long term scaling may be achieved. By fixing the quadratic sighash scaling bug, segwit also reduces the risk of negative impacts due to future capacity increases.</p>
|
||
|
||
<p>Segwit does not, however, provide any direct mechanism for scaling on-chain transaction volume further other than that one-off doubling.</p>
|
||
|
||
<p>This runs this risk that approaches to long-term scaling may be prevented or delayed: stakeholders may consider segwit to be “enough” scaling and decline to work on or support further scaling efforts.</p>
|
||
|
||
<h3 id="avoidance-5">Avoidance</h3>
|
||
|
||
<p>Efforts to avoid this risk have included:</p>
|
||
|
||
<ul>
|
||
<li>Inclusion of “moderate block size increase proposals” in the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html">2015-12-07 Capacity increases roadmap</a></li>
|
||
<li>Inclusion of “flex caps or incentive-aligned dynamic block size controls” in the same roadmap.</li>
|
||
<li>Inclusion of features in segwit to make later scaling less risky, particularly <a href="/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations">Linear scaling of sighash operations</a> and <a href="/en/2016/01/26/segwit-benefits/#moving-towards-a-single-combined-block-limit">Moving towards a single combined block limit</a>.</li>
|
||
<li>Work on techniques to use block space more efficiently, such as using <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/">Schnorr signatures and signature aggregation</a></li>
|
||
<li>Research on alternative models to the blockchain, maintaining decentralisation and security, but with better scalability properties, for example <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/mimblewimble/">Mimblewimble</a>, <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/breaking-the-chain/">Braiding</a>, and <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/jute-braiding/">Jute Braiding</a>.</li>
|
||
</ul>
|
||
|
||
<p>Additionally, work that has made the scale increases segwit allows achievable (such as libsecp256k1 and compact blocks) have also, obviously, made further potential scale increases more achievable.</p>
|
||
|
||
<h3 id="mitigation-4">Mitigation</h3>
|
||
|
||
<p>Segwit does not make further scaling any more difficult on any technical level – the risk here is entirely social. As a consequence, the most effective mitigation efforts are likely also social in nature: such as by having companies who support long-term scaling commit development resources to making that happen.</p>
|
||
|
||
<p>That segwit enables transaction volume to increase to approximately double current levels also provides the opportunity to demonstrate the actual impact of scaling, such as on node performance, decentralisation, and transaction demand, as well as the speed with which ecosystem upgrades can be undertaken. This data could reasonably be collected and used to support future scaling efforts, either by showing that some feared outcomes are less likely than expected, or by confirming valid concerns and allowing work to be focused on addressing those concerns.</p>
|
||
|
||
<h2 id="alternative-approaches">Alternative approaches</h2>
|
||
|
||
<p>This section provides a brief comparison with some alternative approaches to achieving some or all of the benefits of segwit, and how those different approaches might change the costs and risks involved.</p>
|
||
|
||
<h3 id="hard-forked-segwit">Hard-forked segwit</h3>
|
||
|
||
<p>Any hard-fork implementation of segwit would add significant new costs and risks, due to requiring all nodes to upgrade to understand the new rules prior to activation, and risking a chain fork into “old Bitcoin” and “new Bitcoin” with consequent confusion and loss of value. Due to the comparative lack of experience with hard-forks in the Bitcoin community, unexpected risks and costs might also occur, though that is obviously hard to analyse by its very nature.</p>
|
||
|
||
<p>A hard-fork implementation of segwit could realistically be made in two ways:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>SPV-invisible: if the witness commitment was moved from the coinbase into the block transaction merkle tree, most non-validating clients and wallets would continue to work without needing an upgrade. This would save the 38-47 bytes from the coinbase transaction, but does not offer any other advantages.</p>
|
||
</li>
|
||
<li>
|
||
<p>SPV-visible: if calculation of transaction hashes were changed to exclude the scriptSig, this might allow for a simpler implementation, and reduce the per-transaction overhead; however it would render all existing Bitcoin software unable to work with those transactions prior to be being updated. Additionally, separate code paths to manage old style transactions would need to be kept, increasing code complexity and the possibility of bugs. <a href="https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki">BIP 134, Flexible Transactions</a> presents an alternative approach at gaining some of the benefits of segwit via an SPV-visible hard-fork.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>Either approach to a hard-fork would make it possible to simultaneously drastically alter the consensus limits on blocks.</p>
|
||
|
||
<h3 id="simpler-segwit">Simpler segwit</h3>
|
||
|
||
<p>Many of the benefits of segwit could logically be separated into independent changes, and evaluated and deployed separately. The implementation requirements for the various features are, however, closely related:</p>
|
||
|
||
<ul>
|
||
<li>Linear scaling of sighash operations: the CHECKSIG and CHECKMULTISIG opcodes need replacement.</li>
|
||
<li>Signing of input values: the CHECKSIG and CHECKMULTISIG opcodes need replacement.</li>
|
||
<li>Increased security for multisig via P2SH: the P2SH payment format needs replacement.</li>
|
||
<li>Script versioning: the P2SH payment format needs replacement.</li>
|
||
</ul>
|
||
|
||
<p>Doing these fixes independently would increase the complexity of the Bitcoin codebase due to the need to handle different features being active at different times on the blockchain; while deploying them concurrently removes this complexity.</p>
|
||
|
||
<p>Because increasing capacity is dangerous due to the quadratic scaling of sighash operations with the existing CHECKSIG and CHECKMULTISIG opcodes, some limit on these operations needs to be in place. Since segwit only allows increased signature operations via the updated opcodes, the old opcodes remain naturally limited. In contrast if a capacity increase were applied independently, additional limits would need to be implemented to ensure the increase was safe, likely adding complexity to mining and fee calculation.</p>
|
||
</description>
|
||
<pubDate>Fri, 28 Oct 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/10/28/segwit-costs/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/10/28/segwit-costs/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.13.1 Released with Segregated Witness</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#detailed-segwit-benefits" id="markdown-toc-detailed-segwit-benefits">Detailed segwit benefits</a> <ul>
|
||
<li><a href="#eliminate-malleability" id="markdown-toc-eliminate-malleability">1. Elimination of unwanted transaction malleability</a></li>
|
||
<li><a href="#capacity-increase" id="markdown-toc-capacity-increase">2. Capacity increase</a></li>
|
||
<li><a href="#weight-data-by-performance" id="markdown-toc-weight-data-by-performance">3. Weighting data based on how it affects node performance</a></li>
|
||
<li><a href="#signature-covers-value" id="markdown-toc-signature-covers-value">4. Signature covers value</a></li>
|
||
<li><a href="#linear-scaling-of-sighash-operations" id="markdown-toc-linear-scaling-of-sighash-operations">5. Linear scaling of sighash operations</a></li>
|
||
<li><a href="#increased-security-for-multisig" id="markdown-toc-increased-security-for-multisig">6. Increased security for multisig</a></li>
|
||
<li><a href="#more-efficient-security" id="markdown-toc-more-efficient-security">7. More efficient almost-full-node security</a></li>
|
||
<li><a href="#script-versioning" id="markdown-toc-script-versioning">8. Script versioning</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#segwit-testing" id="markdown-toc-segwit-testing">How segwit was tested</a></li>
|
||
<li><a href="#null-dummy-soft-fork" id="markdown-toc-null-dummy-soft-fork">Null dummy soft fork</a></li>
|
||
<li><a href="#conclusion" id="markdown-toc-conclusion">Conclusion</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We are pleased to <a href="/en/releases/0.13.1/">release</a> Bitcoin Core 0.13.1, which contains code miners can use to signal support for the segregated witness (segwit) soft fork and which nodes can use to validate segwit transactions if the soft fork is activated.</p>
|
||
|
||
<p>The segwit soft fork is fully backwards compatible with all Bitcoin wallets, so you will continue to be able to safely send and receive bitcoins whether or not segwit is activated. If you are a miner, you may need to take action if it appears that segwit will activate; for all other Bitcoin users, there is no action you need to take related to segwit now or in the future. However, if you want to support segwit or if you want more details about the changes you may see if segwit activates, please see our <a href="/en/2016/10/27/segwit-upgrade-guide/">segwit upgrade guide</a>.</p>
|
||
|
||
<p>Segwit timeline:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="#signal" id="signal">#</a> Miners will be able to signal that they are willing and able to enforce segwit starting at the beginning of the first 2,016-block retarget period on or after 15 November 2016 (UTC).</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="#lock-in" id="lock-in">#</a> If 95% of blocks within any retarget period signal support for segwit, it locks-in.</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="#activate" id="activate">#</a> After another 2,016-block (roughly two week) retarget period, segwit will activate, allowing miners to produce blocks containing segwit transactions on Bitcoin’s mainnet.</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="#fail" id="fail">#</a> If segwit has not activated by the end of one retarget period after 15 November 2017, segwit will cease to be eligible for activation.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>If segwit is activated, transaction-producing software will be able to separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid. This provides several immediate benefits:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p><strong><a href="#eliminate-malleability">Elimination of unwanted transaction malleability</a></strong> for transactions that use segregated witnesses, making it easier to write Bitcoin wallet software and simplifying the design of smart contracts for Bitcoin.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#capacity-increase">Capacity increase</a></strong> allowing blocks to hold more transactions than before.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#weight-data-by-performance">Weighting data based on how it affects node performance</a></strong> so that miners are allowed to include more data in the parts of the block that don’t reduce node performance long-term.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#signature-covers-value">Signature covers value</a></strong> to reduce the number of steps secure signature generators (such as hardware wallets) need to perform to create a secure signature. This makes it easier to develop hardware wallets and may significantly improve the speed of existing hardware wallets.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#linear-scaling-of-sighash-operations">Linear scaling of sighash operations</a></strong> to ensure that transactions using segwit can’t trigger the problem that caused a block in 2015 to take 25 seconds to validate.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#increased-security-for-multisig">Increased security for multisig</a></strong> so security goes from about 80 bits with P2SH to about 128 bits with segwit—which is about 281 trillion times more security against certain attacks.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#more-efficient-security">More efficient almost-full-node security</a></strong> to allow newly-started nodes who are willing to give up some security guarantees to build an accurate copy of the Bitcoin ledger without having to download all the data from every block. (This is a feature made possible by segwit; it is not included in Bitcoin Core 0.13.1.)</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#script-versioning">Script versioning</a></strong> to allow users to individually opt-in to future soft fork changes made to Bitcoin’s scripting language.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>For more information about each of the benefits above, please see the <a href="#detailed-segwit-benefits">detailed segwit benefits</a> section below or the longer and more detailed <a href="/en/2016/01/26/segwit-benefits/">segwit benefits FAQ</a> page on this website.</p>
|
||
|
||
<p>For more information about upgrading for segwit, please see the <a href="/en/2016/10/27/segwit-upgrade-guide/">segwit upgrade guide</a>.</p>
|
||
|
||
<h2 id="detailed-segwit-benefits">Detailed segwit benefits</h2>
|
||
|
||
<p>The following subsections describe in more detail the features that were summarized above.</p>
|
||
|
||
<h3 id="eliminate-malleability">1. Elimination of unwanted transaction malleability</h3>
|
||
|
||
<p>Segregating the witness allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.</p>
|
||
|
||
<h3 id="capacity-increase">2. Capacity increase</h3>
|
||
|
||
<p>Segwit transactions contain new fields that are not part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size.</p>
|
||
|
||
<p>Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).</p>
|
||
|
||
<h3 id="weight-data-by-performance">3. Weighting data based on how it affects node performance</h3>
|
||
|
||
<p>Some parts of each Bitcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain.</p>
|
||
|
||
<p>One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different “weight” to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.</p>
|
||
|
||
<h3 id="signature-covers-value">4. Signature covers value</h3>
|
||
|
||
<p>A simple improvement in the way signatures are generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of bitcoins being spent is exactly the same as was signed.</p>
|
||
|
||
<p>For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.</p>
|
||
|
||
<h3 id="linear-scaling-of-sighash-operations">5. Linear scaling of sighash operations</h3>
|
||
|
||
<p>In 2015 a block was produced that required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can’t be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature hashing method that doesn’t suffer from this problem and doesn’t have any unwanted side-effects.</p>
|
||
|
||
<h3 id="increased-security-for-multisig">6. Increased security for multisig</h3>
|
||
|
||
<p>Bitcoin addresses (both P2PKH addresses that start with a ‘1’ and P2SH addresses that start with a ‘3’) use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security—which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address.</p>
|
||
|
||
<p>Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the SHA256 hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Bitcoin’s choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)</p>
|
||
|
||
<h3 id="more-efficient-security">7. More efficient almost-full-node security</h3>
|
||
|
||
<p>Satoshi Nakamoto’s original Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto’s method can’t guarantee that a newly-started node using this method will produce an accurate copy of Bitcoin’s current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes.</p>
|
||
|
||
<p>Although the problems with Nakamoto’s method can’t be fixed in a soft fork, segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Bitcoin Core does not provide an option to use this capability as of this 0.13.1 release.</p>
|
||
|
||
<h3 id="script-versioning">8. Script versioning</h3>
|
||
|
||
<p>Segwit makes it easy for future soft forks to allow Bitcoin users to individually opt-in to almost any change in the Bitcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merkelized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.</p>
|
||
|
||
<h2 id="segwit-testing">How segwit was tested</h2>
|
||
|
||
<p>Developers from Bitcoin Core and a number of other Bitcoin projects have been testing and using one version of segwit or another since June 2015—and have been testing the final version of segwit implementation since April 2016. A few of the development and testing milestones are described below:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>June 2015</strong> saw the release of the <a href="https://elementsproject.org/">Elements Project sidechain</a>, which included a version of segwit described as being “from scratch” because it wasn’t intended to be compatible with previous Bitcoin software as it wasn’t known how to do that at the time. This version of segwit continued to be used on Elements-based sidechains until recently, when the Elements Project switched to using the version provided by Bitcoin Core 0.13.1 because of the comprehensive testing it received as well as its compatibility with existing Bitcoin software.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>October 2015</strong> was when a developer described how segwit could be implemented in Bitcoin as a soft fork. Developers with experience developing the “from scratch” version immediately began designing a soft fork implementation that is backwards compatible with all existing Bitcoin software (although programs do need to upgrade to fully understand segwit).</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>December 2015</strong> ended with the launch of a special segwit-specific testnet (called segnet) that allowed implementers and testers to run segwit in a multi-user environment, and which also allowed wallet authors to test their code for generating segwit transactions. Segnet went through several iterations as problems were found and fixed, and as improvements were discovered and implemented.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>April 2016</strong> opened with a pull request for segwit made to Bitcoin Core, and all Bitcoin developers from any project were encouraged to provide feedback (and many did).</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>May 2016</strong> marked the activation of segwit on Bitcoin’s testnet. This provided a live integration test of Bitcoin Core’s implementation against the large variety of other software on testnet to see if it there were any problems interoperating with other software that had upgraded to segwit or whether any problems appeared in programs that had not been upgraded for segwit. The success of this testing helped demonstrate that segwit would not cause problems for anyone (besides miners) who does not upgrade when segwit activates. As of the Bitcoin Core 0.13.1 release, segwit has been activated for over six months on testnet with no known consensus failures.</p>
|
||
|
||
<p>Also in May 2016, twenty Bitcoin Core developers <a href="https://bitcoincore.org/en/meetings/2016/05/20/">met in Switzerland</a> for (among other things) an in-person review of the segwit code and ensuring that test coverage was adequate.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>June 2016</strong> saw the completion of the segwit code review, with several experienced Bitcoin developers completing their reviews and indicating support for segwit’s code changes.</p>
|
||
|
||
<p>Also in June was the merge of compact blocks, a peer-to-peer protocol enhancement based on developments made over the last several years in the Fast Block Relay Network. Compact blocks allows more efficient announcements of new blocks between cooperating peers, which is expected to minimize the bandwidth and latency impact of the larger blocks allowed for by segwit.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>September 2016</strong> saw adoption of Bitcoin Core 0.13.0 (containing compact blocks) starting to be used in production, with over 1,300 Bitcoin Core 0.13.0 nodes accepting incoming connections by the end of the month. Also by the end of the month, a number of programs besides Bitcoin Core—including the btcd full node and many commonly-used mining programs—had code ready to upgrade to segwit and were actively being used to generate blocks on testnet.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="null-dummy-soft-fork">Null dummy soft fork</h2>
|
||
|
||
<p>Also in Bitcoin Core 0.13.1 and combined with the segwit soft fork is an additional change that turns a long-existing network relay policy into a consensus rule. The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY opcodes consume an extra stack element (“dummy element”) after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script.</p>
|
||
|
||
<p>Because any value can be used for this dummy element, it’s possible for a third-party to insert data into other people’s transactions, changing the transaction’s txid (called transaction malleability) and possibly causing other problems.</p>
|
||
|
||
<p>Since Bitcoin Core 0.10.0, nodes have defaulted to only relaying and mining transactions whose dummy element was a null value (0x00, also called OP_0). The null dummy soft fork turns this relay rule into a consensus rule both for non-segwit transactions and segwit transactions, so that this method of mutating transactions is permanently eliminated from the network.</p>
|
||
|
||
<p>Signaling for the null dummy soft fork is done by signaling support for segwit, and the null dummy soft fork will activate at the same time as segwit.</p>
|
||
|
||
<p>For more information, please see <a href="https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki">BIP147</a>.</p>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>For details on all the changes made in Bitcoin Core 0.13.1, please read the <a href="/en/releases/0.13.1/">release notes</a>. To download, please visit the <a href="/en/download">download page</a> or the <a href="https://bitcoincore.org/bin/bitcoin-core-0.13.1/">files directory</a>.</p>
|
||
|
||
<p>Bitcoin Core 0.13.1 is the only soft fork release planned for the 0.13 release series. The next major planned release is Bitcoin Core 0.14.0, which has feature freeze <a href="https://github.com/bitcoin/bitcoin/issues/8719">scheduled</a> for mid-January 2017 and release to follow after all testing is completed (this typically takes more than a month in order to give everyone sufficient time to test).</p>
|
||
|
||
<p>If you are interested in contributing to Bitcoin Core, please see our <a href="/en/contribute">contributing page</a> and the document <a href="/en/faq/contributing-code/">How to contribute code to Bitcoin Core</a>. If you don’t know where to get started or have any other questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a> chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<p>These are the SHA-256 hashes of the released files:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cce8417f27953bf01daf4a89de8161d70b88cc3ce78819ca70237b27c944aa55 bitcoin-0.13.1-aarch64-linux-gnu.tar.gz
|
||
e84620f51e530c6f7d2b4f47e26df3f365009b2f426f82f6ca3bc894c7cdcb46 bitcoin-0.13.1-arm-linux-gnueabihf.tar.gz
|
||
63a5f3e602b8640c5320c402f04379d2f452ea14d2fe84277a5ce95c9ff957c4 bitcoin-0.13.1-i686-pc-linux-gnu.tar.gz
|
||
499be4f48c933d92c43468ee2853dddaba4af7e1a17f767a85023b69a21b6e77 bitcoin-0.13.1-osx64.tar.gz
|
||
ca063833ffcfe9ac5c8f0e213a39b90132f32eb408e675c1e40eeaf3fcb0404f bitcoin-0.13.1-osx.dmg
|
||
d8edbd797ff1c8266113e54d851a85def46ab82389abe7d7bd0d2827e74cecd7 bitcoin-0.13.1.tar.gz
|
||
a7d1d25bbc46b4f0fe333f7d3742c22defdba8db9ffd6056770e104085d24709 bitcoin-0.13.1-win32-setup.exe
|
||
fcf6089fc013b175e3c5e32580afb3cb4310c62d2e133e992b8a9d2e0cbbafaa bitcoin-0.13.1-win32.zip
|
||
c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419 bitcoin-0.13.1-win64-setup.exe
|
||
3956daf2c096c4002c2c40731c96057aecd9f77a559a4bc52b409cc13d1fd3f2 bitcoin-0.13.1-win64.zip
|
||
2293de5682375b8edfde612d9e152b42344d25d3852663ba36f7f472b27954a4 bitcoin-0.13.1-x86_64-linux-gnu.tar.gz
|
||
</code></pre></div></div>
|
||
|
||
</description>
|
||
<pubDate>Thu, 27 Oct 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/10/27/release-0.13.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/10/27/release-0.13.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Segregated Witness Upgrade Guide</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#miners" id="markdown-toc-miners">Miners</a> <ul>
|
||
<li><a href="#upgrading" id="markdown-toc-upgrading">Upgrading</a></li>
|
||
<li><a href="#not-upgrading" id="markdown-toc-not-upgrading">Not upgrading</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#full-node-users" id="markdown-toc-full-node-users">Full node users</a> <ul>
|
||
<li><a href="#upgrading-1" id="markdown-toc-upgrading-1">Upgrading</a></li>
|
||
<li><a href="#not-upgrading-1" id="markdown-toc-not-upgrading-1">Not upgrading</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#wallet-users" id="markdown-toc-wallet-users">Wallet users</a> <ul>
|
||
<li><a href="#upgrading-2" id="markdown-toc-upgrading-2">Upgrading</a></li>
|
||
<li><a href="#not-upgrading-2" id="markdown-toc-not-upgrading-2">Not upgrading</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#bitcoin-software-developers" id="markdown-toc-bitcoin-software-developers">Bitcoin software developers</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>Almost two years of iterative design, development, and testing has gone into the version of segwit being released in Bitcoin Core 0.13.1, with much of the effort over the last year focused on making it as easy as possible for existing Bitcoin users, businesses, developers, and miners to upgrade to segwit.</p>
|
||
|
||
<p>Initial segwit adoption requires the participation of two groups:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong><a href="#miners">Miners</a></strong> representing 95% or more of the total Bitcoin network hash rate must signal support for segwit in order to lock-in segwit’s activation.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="#full-node-users">Full nodes</a></strong> run by a reasonable number of users and business to validate the payments they receive need to be upgraded to Bitcoin Core 0.13.1 or above, or another segwit-compatible implementation in order to incentivize miners to follow segwit’s rules after segwit activates. (This is Bitcoin’s normal incentivization mechanism where miners only receive income for generating a block if they follow all of the consensus rules, which will include the new segwit consensus rules once segwit activates.)</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The segwit soft fork has been designed to allow individuals in both groups to voluntarily decide whether or not they want to adopt segwit, and guides are provided below for both those who want to adopt segwit and those who don’t.</p>
|
||
|
||
<p>If enough miners do decide to adopt segwit, it will eventually activate and wallet users will be able to begin creating transactions with segregated witnesses. The segwit soft fork has also been designed to be both backwards and forwards compatible with all commonly-used wallets, so wallet developers and users can also independently decide whether they want to adopt segwit or continue making transactions without segregated witnesses. Guides are provided below for both adopting and non-adopting <a href="#bitcoin-software-developers">developers</a> and <a href="#wallet-users">users</a>.</p>
|
||
|
||
<p>In addition to instructions, the end of each guide section below also provides a short list of recommended places to ask any segwit-related questions you may have.</p>
|
||
|
||
<h2 id="miners">Miners</h2>
|
||
|
||
<p><em>This section is written for solo miners and mining pool operators. Pool miners should contact their pool operators for information about what they need to do (if anything) to upgrade or not upgrade to segwit.</em></p>
|
||
|
||
<p>The BIP9 soft fork deployment mechanism is being used for segwit—the same mechanism used for the BIP 68/112/113 soft fork that activated on 4 July 2016. Whether you wish to upgrade or not, you should understand the important stages of the upgrade process:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>Started:</strong> Segwit will be in the <em>started</em> stage from the beginning of the first retarget period on or after 15 November 2016 until it either activates or is considered failed (under BIP9’s policy) after one year of not reaching locked-in. During this time, miners who are willing and able to enforce segwit’s new consensus rules will be signaling their intent to do so by placing bit 1 in the block header versionbits field.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Locked-in:</strong> if 95% of blocks during a 2,016-block retarget period signal support for segwit, the segwit soft-fork will be <em>locked-in</em> with <em>activation</em> scheduled for 2,016 blocks later (about two weeks).</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Activated:</strong> after the completion of the <em>locked-in</em> period, the miners who signaled readiness to enforce segwit will begin producing segwit-style blocks that contain transactions with segregated witnesses.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="upgrading">Upgrading</h3>
|
||
|
||
<p>The BIP9 parameters for the segwit soft fork allow miners to begin signaling their support for it at the beginning of the first retarget period on or after 15 November 2016. To signal support, you will need to do the following:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Upgrade the full node you use for transaction selection and block construction to Bitcoin Core 0.13.1+ or another segwit-compatible full node.</p>
|
||
</li>
|
||
<li>
|
||
<p>Upgrade your mining software, mining pool software, or both to a segwit-compatible version.</p>
|
||
</li>
|
||
<li>
|
||
<p>Begin producing blocks containing segwit’s BIP9 versionbit, which is bit 1.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>When segwit is activated, you will want to be able to mine and relay segwit-style blocks. The following mining software has been upgraded to support segwit.</p>
|
||
|
||
<ul>
|
||
<li>Full nodes:
|
||
<ul>
|
||
<li><a href="https://bitcoin.org/en/download">Bitcoin Core</a> 0.13.1 or later</li>
|
||
<li><a href="http://bitcoinknots.org/">Bitcoin Knots</a> 0.13.1 or later</li>
|
||
<li><a href="https://github.com/btcsuite/btcd/pull/656">Btcd</a>*</li>
|
||
</ul>
|
||
</li>
|
||
<li>Mining software:
|
||
<ul>
|
||
<li><a href="https://github.com/luke-jr/bfgminer">BFGMiner</a>*</li>
|
||
<li><a href="https://github.com/ckolivas/cgminer">CGMiner</a></li>
|
||
<li><a href="https://github.com/bitcoin/libblkmaker/pull/6">libblkmaker</a>*</li>
|
||
</ul>
|
||
</li>
|
||
<li>Pool software:
|
||
<ul>
|
||
<li><a href="https://bitbucket.org/ckolivas/ckpool">ckpool</a></li>
|
||
<li><a href="https://github.com/luke-jr/eloipool">Eloipool</a></li>
|
||
<li><a href="https://github.com/slush0/stratum-mining/pull/16">Stratum-Mining</a>*</li>
|
||
</ul>
|
||
</li>
|
||
<li>Relay software:
|
||
<ul>
|
||
<li><a href="http://bitcoinfibre.org/">Bitcoin FIBRE</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>Please note that software that supports the GetBlockTemplate (GBT) RPC must be upgraded to support the BIP9 and BIP145 changes to GBT. All the programs linked above that support GBT have been upgraded.</p>
|
||
|
||
<p>Segwit is already activated and enforced on testnet, so you may find it useful to test your infrastructure upgrade by mining with some small amount of hashrate on testnet. Alternatively, Bitcoin Core 0.13.1’s regression test mode (regtest) also supports segwit by default.</p>
|
||
|
||
<p><strong>Questions?</strong> Solo miners and pool operators are welcome to ask for help in #bitcoin-mining on irc.freenode.net. Pool miners should contact their pool operators for any questions about the pool’s policies regarding segwit.</p>
|
||
|
||
<h3 id="not-upgrading">Not upgrading</h3>
|
||
|
||
<p>This section describes what you can do as a miner if you don’t want to enforce segwit.</p>
|
||
|
||
<p>During the <em>started</em> phase, if you don’t want to adopt segwit, you may simply refuse to upgrade to a segwit-compatible full node such as Bitcoin Core 0.13.1 or above, as well as avoiding any mining software that assumes you want to set segwit’s versionbit of bit 1.</p>
|
||
|
||
<p>If segwit reaches <em>locked-in</em>, you still don’t need to upgrade, but upgrading is strongly recommended. The segwit soft fork does not require you to produce segwit-style blocks, so you may continue producing non-segwit blocks indefinitely. However, once segwit activates, it will be possible for other miners to produce blocks that you consider to be valid but which every segwit-enforcing node rejects; if you build any of your blocks upon those invalid blocks, your blocks will be considered invalid too.</p>
|
||
|
||
<p>For this reason, after segwit reaches <em>locked-in</em>, it is recommended that you either upgrade your full node to Bitcoin Core 0.13.1 or later (or a compatible full node), or that you follow the “not upgrading” instructions in the Full Node section below to use Bitcoin Core 0.13.1 or later as a filter for your pre-segwit software.</p>
|
||
|
||
<h2 id="full-node-users">Full node users</h2>
|
||
|
||
<p><em>This section is written for anyone operating a full node, including both businesses and individuals.</em></p>
|
||
|
||
<p>Full nodes prevent their users from accepting any blocks that violate any of Bitcoin’s consensus rules. In a soft fork upgrade such as segwit, new rules are added, and any nodes that don’t upgrade won’t know about those new rules. This is not a problem: the segwit soft fork is designed to allow non-upgraded users to continue using Bitcoin the same way they did before the soft fork.</p>
|
||
|
||
<p>However, anyone who wants to use the features enabled by the segwit soft fork will want to know that a sufficient number of full node users have upgraded their nodes to refuse blocks and transactions that violate the segwit rules, thereby providing a strong incentive for miners to follow segwit’s updated consensus rules.</p>
|
||
|
||
<p>This system has worked well in the past, with at least 25% of reachable nodes (and usually 50% or more) upgraded before each of the previous several soft forks activated (not counting the BIP50 emergency and temporary soft fork). There is no reason to expect any differently for the segwit soft fork, and upgrading is an easy way for people who support segwit to help encourage its adoption. Those who are uninterested in segwit may, of course, simply not upgrade. Details for both cases are described below.</p>
|
||
|
||
<h3 id="upgrading-1">Upgrading</h3>
|
||
|
||
<p>To upgrade to a segwit-compatible release, download a segwit-compatible version of your full node software (such as the <a href="https://bitcoin.org/en/download">Bitcoin Core 0.13.1 release</a>), ensure that the files you downloaded are legitimate (using PGP or another method), stop the old version of your node software, and start the new version of the software. Note that if you upgrade after segwit has activated, your node will need to download and resync blocks from the activation point forward, since the old version did not download them completely.</p>
|
||
|
||
<p>You may use the Bitcoin Core RPC <code class="highlighter-rouge">getblockchaininfo</code> to track the status of the segwit soft fork (labeled <code class="highlighter-rouge">segwit</code> in the list of BIP9-style soft forks). This information includes how many recent blocks have been produced by miners signaling their intention to enforce segwit’s new consensus rules. The results from the <code class="highlighter-rouge">getblockchaininfo</code> RPC will also let you determine when segwit’s soft fork has become locked in (meaning it will activate within the next 2,016 blocks) and activated (meaning it is now enforced by miners).</p>
|
||
|
||
<p>The wallet provided with Bitcoin Core 0.13.1 will continue to only generate non-segwit P2PKH addresses for receiving payment by default. Later releases are expected to allow users to choose to receive payments to segwit addresses.</p>
|
||
|
||
<p>If you’re a developer or expert user who wants to generate addresses for testing, please see the <a href="/en/segwit_wallet_dev/">segwit dev guide</a>.</p>
|
||
|
||
<p><strong>Questions?</strong> If you use Bitcoin Core as your full node, please see the <a href="https://bitcoin.org/en/bitcoin-core/help">Get Help</a> page on Bitcoin.org for various support options. If you use another full node, the best place to ask is wherever users of your full node software go for support. The maintainers of your software will be familiar with the idea behind segwit at the very least, and they will be able to tell you when it will be implemented and how it will affect you.</p>
|
||
|
||
<h3 id="not-upgrading-1">Not upgrading</h3>
|
||
|
||
<p>If you don’t want to upgrade to segwit and you aren’t a miner, you may simply continue using your current full node software. Segwit is implemented as a soft fork, so you don’t need to upgrade. You also don’t need to upgrade any wallets that connect to your full node; they will continue working as they did before (see the <a href="#wallet-users">wallet section</a> below for details).</p>
|
||
|
||
<p>However, if you accept transactions with fewer blocks of confirmation (such as a single block or two), please note that after a soft fork activates, there is a small increased risk that full nodes which don’t upgrade will temporarily accept invalid blocks. The situation will resolve itself within a few blocks as upgraded miners continue to enforce the new segwit consensus rules, but there is no guarantee that transactions shown as confirmed in the invalid block will continue to be confirmed in valid blocks.</p>
|
||
|
||
<p>The easiest way to prevent this problem is to upgrade to Bitcoin Core 0.13.1 or later, or another full node release that is compatible with the segwit soft fork. If you still don’t wish to upgrade, it is possible to use a newer Bitcoin Core release as a filter for older Bitcoin Core releases.</p>
|
||
|
||
<p><img src="/assets/images/filtering-by-upgraded-node.svg" alt="Filtering by an upgraded node" /></p>
|
||
|
||
<p>In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.</p>
|
||
|
||
<p>When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block.</p>
|
||
|
||
<p>Configuration:</p>
|
||
|
||
<p>For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Core’s configuration file):</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> -whitebind=&lt;addr&gt;
|
||
Bind to given address and whitelist peers connecting to it. Use
|
||
[host]:port notation for IPv6
|
||
|
||
-whitelist=&lt;netmask&gt;
|
||
Whitelist peers connecting from the given netmask or IP address. Can be
|
||
specified multiple times. Whitelisted peers cannot be DoS banned
|
||
and their transactions are always relayed, even if they are
|
||
already in the mempool, useful e.g. for a gateway
|
||
</code></pre></div></div>
|
||
|
||
<p>For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>-connect=&lt;IP_address_or_DNS_name_of_newer_node&gt;
|
||
</code></pre></div></div>
|
||
|
||
<p>For example,</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>-connect=192.168.8.8
|
||
</code></pre></div></div>
|
||
|
||
<p>This will cause the older node to only connect to the newer node so that all blocks and transactions are filtered by the newer node.</p>
|
||
|
||
<h2 id="wallet-users">Wallet users</h2>
|
||
|
||
<p><em>This section is written for anyone using a lightweight wallet, a web wallet, a wallet connected to a personal full node, or any other wallet.</em></p>
|
||
|
||
<h3 id="upgrading-2">Upgrading</h3>
|
||
|
||
<p>If you do want to upgrade to segwit, you will first need to wait for miners to activate segwit, and then you will need a wallet that supports receiving and spending segwit-style payments. This applies to Bitcoin Core’s wallet, lightweight wallets, and wallets where third-parties send and receive bitcoins on your behalf (sometimes called web wallets). Users of Bitcoin Core or other full nodes should also read the section above about full nodes.</p>
|
||
|
||
<p>After your wallet is upgraded to support segwit, it will generate receiving addresses that start with a ‘3’ (a P2SH address). Some wallets have been generating P2SH addresses for years, so this may not be a change for you.</p>
|
||
|
||
<p>All commonly used wallets are able to pay P2SH addresses, so you will be able to receive payments from any common wallet, whether or not they have upgraded to segwit. When spending your bitcoins after the upgrade to segwit, you will still be able to pay the original type of Bitcoin addresses that start with a ‘1’ (a P2PKH address) as well as being able to pay other users of P2SH addresses.</p>
|
||
|
||
<p>When spending your bitcoins with a segwit wallet, you will notice the following:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>When spending only bitcoins you received before upgrading, you should notice no difference to transactions you created before upgrading.</p>
|
||
</li>
|
||
<li>
|
||
<p>When spending bitcoins you received after upgrading to segwit to someone who has not upgraded to segwit, they may not see your transaction until after it is included in a block. This is a safety feature that avoids showing them transactions their wallet doesn’t entirely understand until those transactions have confirmed. After the transaction confirms, they will be able to see and spend the bitcoins you sent them like normal.</p>
|
||
</li>
|
||
<li>
|
||
<p>When spending bitcoins you received to your new P2SH addresses after upgrading, you may notice that the transaction fee you pay is slightly lower than when spending non-segwit payments you previously received. This is because the part of the transaction that contains your signature (the “witness”) doesn’t need to be accessed quickly by Bitcoin full nodes, so segwit allows miners to store up to 4 times as many witness bytes in a block as they store non-witness bytes. This better aligns the cost of creating a block (and thus its transaction fees) with the actual costs of operating a full node.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p><strong>Questions?</strong> If you have any questions, the best place to ask is wherever users of your wallet go for support. The maintainers of your wallet will be familiar with the ideas behind segwit, and they will be able to tell you if segwit will be implemented for your wallet, when that might happen, and how it will affect your usage of your wallet.</p>
|
||
|
||
<h3 id="not-upgrading-2">Not upgrading</h3>
|
||
|
||
<p>If you don’t want to upgrade to segwit, you may simply continue to use any wallet that has not added segwit support. Even though you haven’t upgraded, you will be able to transact with both users who have upgraded to segwit and users who, like you, haven’t upgraded to segwit.</p>
|
||
|
||
<p>If you don’t upgrade, you may experience one difference: if someone who has upgraded to segwit pays you, your wallet may not show you the payment until after it has been included in a block. This is a safety feature that prevents your wallet from seeing transactions it doesn’t completely understand until they’ve been confirmed by a miner.</p>
|
||
|
||
<h2 id="bitcoin-software-developers">Bitcoin software developers</h2>
|
||
|
||
<p><em>This section is written for developers of any Bitcoin software that processes transactions or blocks.</em></p>
|
||
|
||
<p>All Bitcoin software (including mining software, provided it only selects transactions that follow the default relay policy) should continue working as before, and you will only need to upgrade your software if you want to take advantage of segwit’s new features.</p>
|
||
|
||
<p>Segwit is described for developers in the following documents:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong><a href="/en/segwit_wallet_dev/">Segwit wallet developers guide</a>:</strong> a summary description of everything you need to know to upgrade your wallet to support segwit.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">BIP141</a> Segregated witness (consensus layer):</strong> developers seeking to implement any aspect of segwit should read the Specification section of this document. Developers of mining and full node software will find the BIP9 parameters for segwit in the Deployment section.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">BIP143</a> Transaction signature verification for version 0 witness program:</strong> developers of any software that wish to create or verify segwit signatures should read the Specification section of this document and are recommend to use the Example section for testing.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki">BIP144</a> Segregated witness (peer services):</strong> developers seeking to send or receive segregated witnesses over the Bitcoin P2P network should read the Specification section of this document.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki">BIP145</a> getblocktemplate updates for segregated witness:</strong> developers of mining and other software that produce or use the GetBlockTemplate RPC should read BIP145 and the related GBT changes in <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki">BIP147</a> Dealing with dummy stack element malleability:</strong> developers of wallets and especially new transaction scripts should be aware of this new consensus rule that mirrors a long-existing default network relay policy in forbidding passing anything besides the <code class="highlighter-rouge">OP_0</code> “null” opcode as the “dummy” parameter to a checkmultisig-style opcode. After segwit is activated, this new consensus rule will apply to both transactions that use segwit and those that don’t.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="/en/2016/06/08/version-bits-miners-faq/">VersionBits FAQ</a>:</strong> miners and developers of mining software should read
|
||
this FAQ for information about setting their versionbits to signal
|
||
support for soft forks. Segwit uses bit 1 for versionbits.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>Please note, <a href="https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki">BIP142</a> (address format for segregated witness) is in <em>deferred</em> status (as defined by BIP1) and is not proposed as a standard. Instead, wallet developers are invited to discuss on the <a href="http://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">bitcoin-dev mailing list</a> the creation of a new Bitcoin address format that will be more usable than current base58check-encoded addresses.</p>
|
||
|
||
<p>Most implementation details for BIPs 141, 143, 144, and 145 may be found in <a href="https://github.com/bitcoin/bitcoin/pull/8149">Bitcoin Core PR#8149</a>. The implementation for BIP147 may be found in <a href="https://github.com/bitcoin/bitcoin/pull/8636">Bitcoin Core PR#8636</a>.</p>
|
||
|
||
<p>For testing changes on a segwit-enabled network, testnet (testnet3) has supported segwit for several months now and includes a large number of segwit blocks, including blocks that have very nearly the maximum block size allowed for by segwit. Bitcoin Core’s regression-testing (regtest) mode also supports segwit by default in Bitcoin Core 0.13.0 and 0.13.1.</p>
|
||
|
||
<p>A number of free and open source software Bitcoin wallets and packages besides Bitcoin Core have also already added segwit compatibility or have segwit-compatible code ready to deploy, so you may be able to use their code changes as an example for updating your software if their copyright license is compatible with your code.</p>
|
||
|
||
<p><strong>Questions?</strong> Bitcoin development questions may be asked in the #bitcoin-dev IRC chatroom on irc.freenode.net. Questions may also be asked on Bitcoin.StackExchange.com and the BitcoinTalk.org <a href="https://bitcointalk.org/index.php?board=6.0">technical discussion board.</a></p>
|
||
|
||
</description>
|
||
<pubDate>Wed, 26 Oct 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.13.0 Released!</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#preparation-for-segregated-witness" id="markdown-toc-preparation-for-segregated-witness">Preparation for segregated witness</a></li>
|
||
<li><a href="#compact-block-relay" id="markdown-toc-compact-block-relay">Compact block relay</a></li>
|
||
<li><a href="#fee-filtering" id="markdown-toc-fee-filtering">Fee filtering</a></li>
|
||
<li><a href="#bip32-hd-wallet-support" id="markdown-toc-bip32-hd-wallet-support">BIP32 HD wallet support</a></li>
|
||
<li><a href="#more-intelligent-transaction-selection-for-mining" id="markdown-toc-more-intelligent-transaction-selection-for-mining">More intelligent transaction selection for mining</a></li>
|
||
<li><a href="#official-builds-for-linux-on-arm" id="markdown-toc-official-builds-for-linux-on-arm">Official builds for Linux on ARM</a></li>
|
||
<li><a href="#conclusion" id="markdown-toc-conclusion">Conclusion</a></li>
|
||
<li><a href="#hashes-for-verification" id="markdown-toc-hashes-for-verification">Hashes for verification</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>We’re pleased to <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-August/000018.html">announce</a> the official release of Bitcoin Core 0.13.0. During the six-month development cycle leading to this release, <a href="/en/releases/0.13.0/#credits">dozens of contributors</a> have made <a href="/en/releases/0.13.0/#change-log">hundreds of notable improvements</a> to Bitcoin Core. Among the many upgrades available in this release, the following may be especially interesting to miners, node operators, and wallet users:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>Preparation for segregated witness</strong> to increase capacity, eliminate unwanted transaction malleability, and enable new ways to upgrade Bitcoin’s Script language using soft forks. The code in this release prepares for segwit only; it does not support segwit on mainnet, so users who want segwit support will need to upgrade to a future version.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Compact block relay</strong> on the peer-to-peer network to eliminate a major source of redundant data transfer among nodes that relay transactions, as well as reduce the peak amount of bandwidth those nodes use when downloading newly-generated blocks.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Fee-based filtering</strong> to eliminate another source of unnecessary data transfer on the peer-to-peer network by allowing nodes to skip relaying any unconfirmed low-fee transactions that they know their peers would ignore anyway.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>BIP32 HD wallet support</strong> in Bitcoin Core’s built-in wallet to allow users to backup every private key they will ever generate with the wallet rather than the old default of just the next 100 private keys.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Child Pays For Parent (CPFP) transaction selection</strong> to allow miners to mine more profitably (when possible) and give users the ability to incentivize mining of selected transactions in cases where the users can’t increase transaction fees directly.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Official Bitcoin Core binary executables for ARM chipsets used with Linux</strong> to allow users of those platforms to take advantage of pre-built software secured by the Gitian deterministic building and multiple attestation process.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>For a more comprehensive list of the changes made in Bitcoin Core 0.13.0, please see the <a href="/en/releases/0.13.0/">release notes</a>. The improvements listed above are described in more detail below.</p>
|
||
|
||
<h2 id="preparation-for-segregated-witness">Preparation for segregated witness</h2>
|
||
|
||
<p>The most significant code change made in Bitcoin Core 0.13.0 is the inclusion of the segregated witness (segwit) code in preparation for an upcoming soft fork. Please note that this release will not activate segwit, and if segwit is activated, this release will not act any differently, so those who want to use or enforce segwit will need to upgrade to a later release that does contain the activation mechanism.</p>
|
||
|
||
<p>By including the segwit code in Bitcoin Core 0.13.0, users gain several advantages:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p><strong>Easier upgrade to segwit:</strong> The code differences (“diff”) from this release to a subsequent release that includes segwit will be small. This allows users who modify their version of Bitcoin Core to easily convert any modifications they make to Bitcoin Core 0.13.0 to the release that contains segwit (which is expected to be 0.13.1).</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Easier segwit testing:</strong> Although this release won’t run segwit code on mainnet, it does run the code on testnet and in regression testing mode (regtest), which makes it easy for developers, administrators, and testers to use segwit in a safe environment with a version of Bitcoin Core that will be very close to the first version that is ready for miners to activate segwit.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Full integration with other features:</strong> all the other features included in this release – such as feefiltering, compact block relay, child-pays-for-parent mining, and official binaries for Linux on ARM – are integrated with the segwit code and will probably be in production for two or more months before segwit activates, providing extra time for potential problems to be discovered through community review and
|
||
testing.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p><strong>More information:</strong></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="/en/releases/0.13.0/#segregated-witness">Release notes</a></p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://bitcoincore.org/en/2016/06/24/segwit-next-steps/">Segregated Witness: the next steps</a> BitcoinCore.org blog post</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">BIP141: Segregated witness (consensus layer)</a>, technical information about segwit and where the activation parameters for segwit will be published. See also BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">143</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki">144</a>, and <a href="https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki">145</a>.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="compact-block-relay">Compact block relay</h2>
|
||
|
||
<p>Prior to Bitcoin Core 0.13.0, a running full node would (by default) receive many transactions twice:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>Before the transaction was confirmed, as an individual transaction being relayed across the network.</p>
|
||
</li>
|
||
<li>
|
||
<p>After the transaction was confirmed, as part of a group of transactions contained in a newly-mined block being relayed across the network.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>There’s no need for the node to receive the transaction a second time if it still has the first copy. Compact block relay (BIP152) can eliminate this redundancy by allowing a node to receive from its peers an ordered list of what transactions are included in a new block. With this knowledge, the node can use the transactions it has already received to partly or fully reconstruct the transactions part of the block for itself. If the node doesn’t receive all the transactions it needs to fully reconstruct the block, it requests the missing transactions from its peers, and then uses them to complete the block.</p>
|
||
|
||
<p><img src="https://raw.githubusercontent.com/bitcoin/bips/master/bip-0152/protocol-flow.png" alt="Compact Blocks diagram" /></p>
|
||
|
||
<p>Compact blocks provides three very important benefits to the network:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>By reducing the amount of bandwidth used by transaction relay nodes, compact blocks help offset the expected increase in bandwidth that will occur when the segwit capacity increases are enabled by miners. This offset should allow nodes to continue operating on the network after segwit even if they’re presently near their current bandwidth caps.</p>
|
||
</li>
|
||
<li>
|
||
<p>By eliminating the bandwidth spike that occurs when nodes receive a new block, compact blocks may make it easier to keep a node operating on connections with limited peak bandwidth. For example, several users have reported that receiving a new block slows down other important activity on their network, such as video conferencing, so some of those users shut down Bitcoin Core before starting those activities. Compact blocks may eliminate those bandwidth spikes and make running Bitcoin Core less inconvenient for those users.</p>
|
||
</li>
|
||
<li>
|
||
<p>Faster propagation of blocks across the network, by dramatically reducing the amount of data that needs to be transported when a new block is found.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p><strong>More information:</strong></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="/en/releases/0.13.0/#compact-block-support-bip-152">Release notes</a></p>
|
||
</li>
|
||
<li>
|
||
<p><a href="/en/2016/06/07/compact-blocks-faq/">Compact Block Relay FAQ</a></p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">BIP152</a>, which describes the compact blocks protocol</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="http://bitcoinfibre.org/">Bitcoin FIBRE</a>, an open source protocol and implementation that builds upon compact blocks to minimize latency for new block announcements between peers on managed networks. FIBRE was designed and implemented alongside compact block relay version 1 and it is being used to test improvements for a subsequent version of compact block relay.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="fee-filtering">Fee filtering</h2>
|
||
|
||
<p>For several years now, Bitcoin Core nodes have used a minimum relay fee rate to help determine what unconfirmed transactions they’ll process, relay, and store in their individual memory pools. Each node gets to decide its own minimum relay fee rate, and if they receive a transaction whose fee rate is below that limit, they don’t add it to their memory pools or relay it to their other peers (although another mechanism called <a href="https://en.bitcoin.it/wiki/Transaction_fees#Priority_transactions">transaction priority</a> historically allowed some transactions that pay a low fee to be accepted into mempools and relayed).</p>
|
||
|
||
<p>Prior to Bitcoin Core 0.13.0, nodes didn’t tell each other what minimum fee rate they were using, which could lead to wasted bandwidth. For example, Alice sends Bob a transaction without realizing that the transaction’s fee rate is below Bob’s minimum. Because of the way Bitcoin transactions are relayed, Bob has no way of knowing that the transaction is below his limit until he has already downloaded the whole transaction, at which point he stops processing the transaction because its fee rate is too low, so both his bandwidth and Alice’s bandwidth end up being wasted.</p>
|
||
|
||
<p>Bitcoin Core 0.13.0 supports a new message that has been added to the peer-to-peer (P2P) protocol, the <code class="highlighter-rouge">feefilter</code> message, which has been designed to help eliminate this wasted bandwidth. This P2P message allows Bob to tell Alice what he is currently using as his minimum relay fee rate so that Alice will not bother trying to relay to him any transactions that pay a fee below his rate.</p>
|
||
|
||
<p><strong>More information</strong></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="/en/releases/0.13.0/#low-level-rpc-changes">Release notes for feefilter</a></p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki">BIP133: <code class="highlighter-rouge">feefilter</code>
|
||
message</a></p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="bip32-hd-wallet-support">BIP32 HD wallet support</h2>
|
||
|
||
<p>When Bitcoin Core starts for the first time, it will now generate a BIP32 Hierarchical Deterministic (HD) wallet where every private key in the wallet is derived from a single piece of information using a repeatable (deterministic) process. This means backing up that single piece of information will back up every private key your wallet will ever generate, ensuring that you can recover any bitcoins controlled by those private keys in the future.</p>
|
||
|
||
<p>Backups are hard to get right, so please note the following information:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>If you upgrade from any version of Bitcoin Core before 0.13.0, you will continue using the old style of wallet where each private key is generated individually, with (by default) up to 100 of them pre-generated in advance to make backups easier—meaning you need to create additional backups every 100 transactions, since each default-style transaction uses one private key.</p>
|
||
</li>
|
||
<li>
|
||
<p>If you create a new wallet with 0.13.0 (or above) and you change from the default unencrypted wallet to an encrypted wallet, a new HD wallet will be generated for you. You will still have access to any bitcoins sent to the unencrypted wallet, but you will need to backup the wallet again.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>If you aren’t sure whether you’re using an HD wallet, you can check using the <code class="highlighter-rouge">getwalletinfo</code> RPC:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>If you use the Bitcoin Core graphical user interface, you can click the <em>Help</em> menu, choose the <em>Debug</em> option, click the <em>Console</em> tab, and then type in <code class="highlighter-rouge">getwalletinfo</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>If you use the <code class="highlighter-rouge">bitcoin-cli</code> command to access the RPC interface, you can type <code class="highlighter-rouge">bitcoin-cli getwalletinfo</code>.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>In either case, if you see a line labeled “masterkeyid”, then you’re using an HD wallet; if you don’t see it, then you’re using a wallet with individually generated keys.</p>
|
||
|
||
<p>Backing up an HD wallet ensures that you will be able to re-generate any private keys produced by that wallet in the future, but that is the only information you can recover from the backup in the future. Any additional information you enter into your wallet after you make the backup, such as descriptions of transactions you sent or received, will be lost if you have to restore from the HD wallet backup, so we recommend that you continue to make regular backups of your wallet in order to preserve that information.</p>
|
||
|
||
<p>Importantly, if you manually import any private keys to your wallet, they cannot be recovered using any backups made prior to the import, so you will need to make a new wallet backup and use that.</p>
|
||
|
||
<p><strong>More information</strong></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="/en/releases/0.13.0/#hierarchical-deterministic-key-generation">Release notes</a></p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://en.bitcoin.it/wiki/Deterministic_wallet">Deterministic
|
||
wallets</a> (Bitcoin
|
||
Wiki)</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">BIP32: Hierarchical Deterministic Wallets</a></p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="more-intelligent-transaction-selection-for-mining">More intelligent transaction selection for mining</h2>
|
||
|
||
<p>Ancestor fee rate mining is the new default transaction selection method for mining in Bitcoin Core 0.13.0. Miners can use it to select which transactions to put in their next block, providing two important benefits:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p><strong>For miners</strong> often more revenue can be earned from transaction fees per block because ancestor fee rate mining is able to prioritize certain higher-fee transactions.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>For users</strong> as a side benefit of miners choosing transactions more intelligently, it becomes possible for the recipient of an unconfirmed transaction to incentivize miners to mine that transaction.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>Bitcoin has rule that says if Alice spends a bitcoin to Bob, the transaction where Alice originally receives the bitcoin must appear earlier in the blockchain than the transaction where she spends that bitcoin to Bob. In other words, the parent transaction must appear earlier in the blockchain than its child transaction, forming an ancestor relationship.</p>
|
||
|
||
<p>Both the child and parent transactions can appear in the same block, but if they do, the parent must appear earlier in that block than the child. This means that if an unconfirmed child transaction pays a high fee, miners should be incentivized by this existing Bitcoin rule to mine that transaction’s unconfirmed parent (even if it pays a low fee) in order to get the child’s high fee.</p>
|
||
|
||
<p>This incentivization scheme is often called Child Pays For Parent (CPFP). In the simplest version, miners group a transaction and all of its ancestors together, calculating their total fee-per-byte in order to determine whether mining them together pays a high enough fee to outbid other individual transactions the miner wants to include in its next block.</p>
|
||
|
||
<p>A key advantage of ancestor fee rate mining is that the two transactions don’t need to be created by the same person. For example, if Bob is waiting for confirmation of a transaction that Alice sent him, Bob can independently create a child transaction that incentivizes miners to confirm his transaction and Alice’s transaction together.</p>
|
||
|
||
<p>It is important to note that ancestor fee rate mining doesn’t guarantee that a low-fee transaction will be mined just because it has a high-fee child or other descendent. In particular, almost all miners and nodes will ignore transactions that don’t pay a minimal amount of fee per kilobyte of data (the exact ratio varies by node), so if a parent transaction is ignored because the fee it pays is below this limit, then its children will not be mined no matter how high a fee they pay.</p>
|
||
|
||
<p><strong>More information:</strong></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="/en/releases/0.13.0/#mining-transaction-selection-child-pays-for-parent">Release notes</a></p>
|
||
</li>
|
||
<li>
|
||
<p>Child Pays For Parent (CPFP) compared to opt-in Replace-by-Fee (RBF)
|
||
in the <a href="/en/faq/optin_rbf/#what-is-child-pays-for-parent-cpfp">opt-in RBF
|
||
FAQ</a></p>
|
||
</li>
|
||
<li>
|
||
<p><a href="https://www.reddit.com/r/Bitcoin/comments/4oeqhk/bitcoin_core_child_pays_for_parent_merged/d4cg8ov?context=1">Brief history of CPFP development in Bitcoin
|
||
Core</a>,
|
||
a Reddit comment by Gregory Maxwell</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="official-builds-for-linux-on-arm">Official builds for Linux on ARM</h2>
|
||
|
||
<p>The official Bitcoin Core binaries built and cryptographically signed by multiple contributors through the <a href="https://bitcoinmagazine.com/articles/what-is-gitian-building-how-bitcoin-s-security-processes-became-a-model-for-the-open-source-community-1461862937">Gitian process</a> now includes two new platforms:</p>
|
||
|
||
<ul>
|
||
<li>bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries for the most common 32-bit ARM architecture.</li>
|
||
<li>bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries for the most common 64-bit ARM architecture.</li>
|
||
</ul>
|
||
|
||
<p>If you have the GNU C compiler installed, you can run the following command to figure out which platform you’re using:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>gcc -print-multiarch
|
||
</code></pre></div></div>
|
||
|
||
<p>Or you if use a Debian-based system, you can try the following command:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>dpkg-architecture -q DEB_HOST_GNU_SYSTEM
|
||
</code></pre></div></div>
|
||
|
||
<p>These binaries are designed for Linux using GNU libc6; they are not expected to run by default on Android or other operating systems.</p>
|
||
|
||
<p>The new builds are still experimental, so please <a href="https://github.com/bitcoin/bitcoin/issues/new">report any problems</a> that you encounter.</p>
|
||
|
||
<p><strong>More information</strong></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="/en/releases/0.13.0/#linux-arm-builds">Release notes</a></p>
|
||
</li>
|
||
<li>
|
||
<p>The Bitcoin Wiki has a list of <a href="https://en.bitcoin.it/wiki/Bitcoin_Core_compatible_devices">Bitcoin Core compatible devices</a>. Please add any unlisted devices that are also compatible.</p>
|
||
</li>
|
||
<li>
|
||
<p>The Debian Wiki includes information about boards that are <em>probably</em> compatible with these builds: <a href="https://wiki.debian.org/ArmHardFloatPort#Hardware">32-bit arm-linux-gnueabihf</a> and <a href="https://wiki.debian.org/Arm64Port#Hardware.2C_emulators_and_models">64-bit aarch64-linux-gnu</a></p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="conclusion">Conclusion</h2>
|
||
|
||
<p>For details on all the changes made in Bitcoin Core 0.13.0, please <a href="/en/releases/0.13.0/">read the release notes</a>. To download, please visit the <a href="https://bitcoin.org/en/download">download page</a> or the <a href="https://bitcoin.org/bin/bitcoin-core-0.13.0/">files directory</a></p>
|
||
|
||
<p>With the release of Bitcoin Core 0.13.0, we begin the six-month release cycle for the next version of Bitcoin Core (expected to be 0.14.0). With the participation of the community, we will also be choosing the BIP9 parameters for segregated witness and releasing a minor version (expected to be 0.13.1) with segwit fully enabled.</p>
|
||
|
||
<p>If you are interested in contributing to Bitcoin Core, please see our <a href="/en/contribute">contributing page</a> and the document <a href="/en/faq/contributing-code/">How to contribute code to Bitcoin Core</a>. If you don’t know where to get started or have any other questions, please stop by our <a href="https://en.bitcoin.it/wiki/IRC_channels">IRC</a> chatroom and we’ll do our best to help you.</p>
|
||
|
||
<h2 id="hashes-for-verification">Hashes for verification</h2>
|
||
|
||
<p>These are the SHA-256 hashes of the released files:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>f94123e37530f9de25988ff93e5568a93aa5146f689e63fb0ec1f962cf0bbfcd bitcoin-0.13.0-aarch64-linux-gnu.tar.gz
|
||
7c657ec6f6a5dbb93b9394da510d5dff8dd461df8b80a9410f994bc53c876303 bitcoin-0.13.0-arm-linux-gnueabihf.tar.gz
|
||
d6da2801dd9d92183beea16d0f57edcea85fc749cdc2abec543096c8635ad244 bitcoin-0.13.0-i686-pc-linux-gnu.tar.gz
|
||
2f67ac67b935368e06f2f3b83f0173be641eef799e45d0a267efc0b9802ca8d2 bitcoin-0.13.0-osx64.tar.gz
|
||
e7fed095f1fb833d167697c19527d735e43ab2688564887b80b76c3c349f85b0 bitcoin-0.13.0-osx.dmg
|
||
0c7d7049689bb17f4256f1e5ec20777f42acef61814d434b38e6c17091161cda bitcoin-0.13.0.tar.gz
|
||
213e6626ad1f7a0c7a0ae2216edd9c8f7b9617c84287c17c15290feca0b8f13b bitcoin-0.13.0-win32-setup.exe
|
||
5c5bd6d31e4f764e33f2f3034e97e34789c3066a62319ae8d6a6011251187f7c bitcoin-0.13.0-win32.zip
|
||
c94f351fd5266e07d2132d45dd831d87d0e7fdb673d5a0ba48638e2f9f8339fc bitcoin-0.13.0-win64-setup.exe
|
||
54606c9a4fd32b826ceab4da9335d7a34a380859fa9495bf35a9e9c0dd9b6298 bitcoin-0.13.0-win64.zip
|
||
bcc1e42d61f88621301bbb00512376287f9df4568255f8b98bc10547dced96c8 bitcoin-0.13.0-x86_64-linux-gnu.tar.gz
|
||
</code></pre></div></div>
|
||
|
||
</description>
|
||
<pubDate>Tue, 23 Aug 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/08/23/release-0.13.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/08/23/release-0.13.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Segregated witness: the next steps</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#background" id="markdown-toc-background">Background</a></li>
|
||
<li><a href="#how-segwit-was-tested" id="markdown-toc-how-segwit-was-tested">How segwit was tested</a></li>
|
||
<li><a href="#compact-blocks" id="markdown-toc-compact-blocks">Compact Blocks</a></li>
|
||
<li><a href="#deployment-plan" id="markdown-toc-deployment-plan">Deployment plan</a></li>
|
||
<li><a href="#how-segwit-will-affect-you" id="markdown-toc-how-segwit-will-affect-you">How segwit will affect you</a></li>
|
||
<li><a href="#future-upgrades-made-easier-by-segwit" id="markdown-toc-future-upgrades-made-easier-by-segwit">Future upgrades made easier by segwit</a> <ul>
|
||
<li><a href="#schnorr-signatures" id="markdown-toc-schnorr-signatures">Schnorr signatures</a></li>
|
||
<li><a href="#mast" id="markdown-toc-mast">MAST</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>Segregated witness (segwit) is approaching release. This post provides some background information, details about how segwit was tested, information about how the upgrade is expected to proceed, and a description of some future features that segwit makes easier to implement.</p>
|
||
|
||
<h2 id="background">Background</h2>
|
||
|
||
<p><a href="/en/2016/01/26/segwit-benefits/">Segwit</a> is a proposal to allow transaction-producing software to separate (segregate) transaction signatures (witnesses) from the rest of the data in a transaction, and to allow miners to place those witnesses outside of the traditional block structure. This provides two immediate benefits:</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p><strong>Elimination of malleability:</strong> Segregating the witness allows both existing software and upgraded software that receives transactions to calculate the transaction identifier (txid) of segwit-using transactions without referencing the witness. This solves all known cases of unwanted third-party transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Capacity increase:</strong> Moving witness data outside of the traditional block structure (but still inside a new-style block structure) means new-style blocks can hold more data than older-style blocks, allowing a modest increase to the amount of transaction data that can fit in a block.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<p>Segwit also simplifies the ability to add new features to Bitcoin and improves the efficiency of full nodes, which provides long-term benefits that will be described in more detail later in this document.</p>
|
||
|
||
<p>For more information about segwit, please see <a href="/en/2016/01/26/segwit-benefits/">our FAQ</a> or BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">141</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">143</a>, and <a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki">144</a>.</p>
|
||
|
||
<h2 id="how-segwit-was-tested">How segwit was tested</h2>
|
||
|
||
<p>Segwit changes several parts of the Bitcoin system, most notably the consensus rules that full validation nodes use to come to agreement on the state of the Bitcoin ledger. If nodes cease to agree on the state of the ledger, then it becomes unsafe to receive new Bitcoin transactions, so Bitcoin developers should be careful about making any such changes and perform extensive testing on any such proposed changes.</p>
|
||
|
||
<p>Also important are changes to the peer-to-peer network code used to relay blocks and transactions. As segwit transactions and blocks are organized differently than earlier transaction and block versions, it’s important to ensure the network implementation can both relay segwit data to segwit nodes and older-style data to older nodes.</p>
|
||
|
||
<p>These combined changes to the consensus rules and the P2P networking code consist of 1,486 lines of added or modified code. The segwit patch also includes an additional 3,338 lines of added or modified code in the unit and integration tests that help ensure segwit is functioning as expected on every full build of the Bitcoin Core program.</p>
|
||
|
||
<p>In addition to over 3,000 lines of added automated testing code, segwit has been extensively tested by Bitcoin developers. This section describes just some of the rigorous testing they performed on different versions of segwit over the last year.</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Segwit was originally implemented by Pieter Wuille and several other Blockstream developers on the <a href="http://elementsproject.org/">Elements Project</a> sidechain in April through June 2015 as a “from scratch” version that wasn’t intended to be compatible with previous Bitcoin software. This version has been used for every single transaction on Elements-based sidechains.</p>
|
||
</li>
|
||
<li>
|
||
<p>In late October 2015, Luke Dashjr <a href="https://botbot.me/freenode/bitcoin-core-dev/2015-10-21/">described</a> a method that would allow segwit to be implemented in Bitcoin as a soft fork and Wuille used his experience with the Elements version to begin working on this new implementation that is backwards compatible with all existing Bitcoin software (although programs do need to upgrade to fully understand segwit).</p>
|
||
</li>
|
||
<li>
|
||
<p>The code became fully operational in late December 2015 on a special segwit-specific testnet (called segnet) that allowed implementers and testers to run the code in a multi-user environment, and which also allowed wallet authors to test their code for generating segwit transactions. Segnet went through several iterations as problems were found and fixed, and as improvements were discovered and implemented.</p>
|
||
</li>
|
||
<li>
|
||
<p>In April 2016, after four months of active development and testing, Wuille submitted a <a href="https://github.com/bitcoin/bitcoin/pull/7910">pull request</a> to the Bitcoin Core project for review.</p>
|
||
</li>
|
||
<li>
|
||
<p>May 2016, Segwit was enabled on Bitcoin’s regular testnet where it was tested not just against other software that was expected to interact with segwit but also all the other programs which are regularly tested on Bitcoin’s testnet and which had not been upgraded for segwit.</p>
|
||
</li>
|
||
<li>
|
||
<p>Also in May 2016, twenty Bitcoin Core developers <a href="/logs/2016-05-zurich-meeting-notes.html">met in Switzerland</a> for (among other things) an in-person review of the segwit code and ensuring that test coverage was adequate.</p>
|
||
</li>
|
||
<li>
|
||
<p>In June 2016, after almost two months of very active review on the original pull request plus extended operation on both segnet and testnet, Wuille created a <a href="https://github.com/bitcoin/bitcoin/pull/8149">second pull request</a> that contained all the improvements made to the original pull request, rebased on top of the most recent version of Bitcoin Core’s development branch, and which was specially formatted to make final review easy as well as ensure all reviews made to the original pull request remained valid.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>With the original sidechains implementation of segwit having been used by a number of reviewers over the past year and the Bitcoin soft fork implementation having received rigorous testing and review over six months, the Bitcoin Core developers believe it is now ready to move to production.</p>
|
||
|
||
<h2 id="compact-blocks">Compact Blocks</h2>
|
||
|
||
<p>Segwit will allow Bitcoin miners to include more transaction data in the blocks they create than they can now. This will increase the bandwidth demands on Bitcoin full nodes that relay all that data as well as increase the latency between when a new block is published and when nodes receive it (as larger amounts of data typically take longer to propagate). To help reduce these negative side effects, Bitcoin Core developers plan to make <a href="/en/2016/06/07/compact-blocks-faq/">compact block relay</a> available for Bitcoin Core 0.13 and above.</p>
|
||
|
||
<p>Bitcoin full nodes currently download many transactions twice: once when they receive the transaction by itself and a second time when the transaction is received as part of a block. Compact block relay can eliminate most (and sometimes all) of this duplication by sending nodes just the information they need in order to reconstruct blocks using the transactions that the nodes have already received.</p>
|
||
|
||
<p>In the optimistic case this reduces the amount of bandwidth a node uses by almost half. Since segwit is expected to increase maximum capacity to about double, these two improvements roughly balance each other out to keep node bandwidth usage at roughly the same level as now.</p>
|
||
|
||
<p>More importantly, compact block relay helps reduce peak bandwidth load. Currently a freshly-received block of approximately 1 megabyte has to be downloaded all at once; when segwit is deployed, that will mean 2 megabyte or larger blocks may need to be downloaded. On all but the fastest connections, these bandwidth spikes hurt the performance of other services users are running at the same time, such as games or video streaming. With compact blocks, the user can receive transactions in a steady stream and then reconstruct each block using a small description of the block, eliminating bandwidth spikes that inconvenience many users.</p>
|
||
|
||
<p>Lastly, by reducing the amount of data that needs to be sent when a new block is announced, compact block relay also achieves much better block propagation speeds. Compact block relay takes special advantage of this by supporting two operating modes, a low-bandwidth mode that’s optimized to reduce bandwidth (although it also improves speed in most cases) and a high-bandwidth mode that significantly improves speed and still manages to greatly reduce peak bandwidth usage by only requiring an average of 20 kilobytes more than the low-bandwidth mode.</p>
|
||
|
||
<p>The high bandwidth mode is being used as the basis for further development into optimizations for peer-to-peer block relay. It’s especially intended for use by miners who need to receive blocks as fast as possible (especially if other non-peer-to-peer block relay methods fail), but users with extra bandwidth can also enable this mode to help relay blocks to miners faster and also help discourage denial-of-service attacks by making it less evident which high-bandwidth nodes are being run by miners and which are being run by ordinary peers.</p>
|
||
|
||
<h2 id="deployment-plan">Deployment plan</h2>
|
||
|
||
<p>The following plan describes how segwit is expected to be deployed.</p>
|
||
|
||
<p><strong>Merge to master (without mainnet activation code):</strong> after Bitcoin Core developers “ACK” (approve) the final segwit pull request, it will be merged into the Bitcoin Core master Git repository branch. The code that is being merged will include everything in segwit except for the activation code. This will make it easy for developers to test other features on top of segwit, such as compact blocks. <strong>Activation on testnet</strong> has already occurred so users and developers may experiment and test segwit on testnet.</p>
|
||
|
||
<p><strong>Backport to 0.12 branch:</strong> the unactivated code will be backported to the 0.12 maintenance branch and the backport will receive its own testing.</p>
|
||
|
||
<p><strong>Choosing the BIP9 parameters:</strong> <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> is a soft fork deployment mechanism that allows miners to signal their readiness to enforce new consensus rules. Each soft fork made with BIP9 chooses when miners can begin signaling for the soft fork, when the soft fork is considered unsuccessful if not enough miners have signaled for it, and which bit in the block header version field will be used by miners to signal their readiness. These parameters will be selected at this time and implemented along with the code to activate segwit on both the master and 0.12 branches.</p>
|
||
|
||
<p><strong>Release candidate phase:</strong> after all developer testing is successfully concluded, a release candidate (probably named 0.12.2RC1) will be publicly provided to anyone willing to test the code. Miners, merchants, and wallet vendors are especially encouraged to test. If any problems are found, they will be fixed and a new release candidate will be issued. This will be repeated as necessary until a release candidate is found with no known problems.</p>
|
||
|
||
<p><strong>Binary release:</strong> the final release candidate will have its version changed to the final release version (expected to be 0.12.2) and will be released for all users to download and begin running at their leisure (segwit is a soft fork, so upgrading is only required if they plan to use segwit features).</p>
|
||
|
||
<p><strong>Miners upgrade:</strong> miners who choose to upgrade to 0.12.2 will be able to start producing blocks that signal readiness to enforce segwit once the date defined as segwit’s BIP9 started date is reached.</p>
|
||
|
||
<p><strong>Lock-in:</strong> once 95% of blocks in a 2,016-block long retarget period have signaled that their miners are ready to enforce segwit, segwit will lock-in – meaning that unless the blockchain is rolled back at that point, segwit will become active (see next point).</p>
|
||
|
||
<p><strong>Activation:</strong> 2,016 blocks (about two weeks) after segwit is locked-in, it will activate. That means all full nodes running segwit-aware code will begin requiring miners to enforce the new segwit consensus rules.</p>
|
||
|
||
<p><strong>Wallets upgrade:</strong> similar to the P2SH soft fork in 2012, after segwit activates it will not immediately be safe for wallets to upgrade to support segwit. That’s because spends from segwit transactions look like unsecured transactions to older nodes, so if the blockchain is forked soon after segwit activates, those spends could be placed in an earlier block that is not subject to segwit’s rules. For this reason, it is suggested that wallets avoid upgrading for a few weeks after segwit activates. Allowing that extra time to pass provides extra security to wallet users, although anyone who wants to test with a small amount of money they can afford to lose can begin spending as soon as segwit activates. Users can also begin testing immediately using testnet or regtest with the proposed segwit code or (when available) any release containing segwit.</p>
|
||
|
||
<h2 id="how-segwit-will-affect-you">How segwit will affect you</h2>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>Miners</strong> who choose to run segwit will have the responsibility of ensuring that they’re ready to enforce it by upgrading their full validation nodes to segwit-enforcing code. When they’ve done this and performed whatever testing they believe is prudent, they can begin signaling support for segwit.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Full node operators</strong> can continue using their existing nodes but they are recommended to upgrade to a segwit-enforcing version. If any miners end up producing blocks that are invalid according to the segwit rules after segwit activates, upgraded full nodes will automatically reject those blocks, ensuring that those upgraded full node users see accurate confirmation counts.</p>
|
||
|
||
<p>This upgrade is especially important for anyone, such as a business, who accepts transactions with low numbers of confirmations.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Bitcoin Core wallet users</strong> can continue using their existing nodes. Even if you upgrade, you will see no changes beyond those described above. The code expected to be released in 0.12.2 does not begin generating segwit receiving addresses by default.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Users of other wallets</strong> can continue using their existing wallets. It is recommended that lightweight wallet users always wait for several confirmations when receiving significant amounts of money, so no extra waiting is expected to be required here.</p>
|
||
|
||
<p>When you have the opportunity to upgrade to a version of your wallet that supports segwit, you may find that the transaction fee you have to pay is slightly lower when you spend bitcoins you received after upgrading to segwit because the witness is external and therefore the transaction size is counted as smaller.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="future-upgrades-made-easier-by-segwit">Future upgrades made easier by segwit</h2>
|
||
|
||
<p>Segwit is a major step towards improving the operation of the Bitcoin system. In addition to the fixes for third-party malleability and the capacity increase described above, it also provides a mechanism that allows Bitcoin’s Script language to be more easily upgraded.</p>
|
||
|
||
<p>Since Bitcoin 0.3.6, the scripting language has supported ten special NOP opcodes whose behavior could be redefined in certain ways in later versions. Two of these ten special NOP opcodes have already been used to add new features to the system: NOP2 was changed to <code class="highlighter-rouge">OP_CHECKLOCKTIMEVERIFY</code> (CLTV) per <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki">BIP65</a> and NOP3 was changed to <code class="highlighter-rouge">OP_CHECKSEQUENCEVERIFY</code> (CSV) per <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">BIP112</a>.</p>
|
||
|
||
<p>Such operations need to be implemented very carefully to preserve the NOP semantics used by old nodes, which limits what soft forks can do and can make adding features this way somewhat messy. For example, because both CLTV and CSV accept parameters, each time they are used an <code class="highlighter-rouge">OP_DROP</code> opcode must also be used in order to preserve compatibility with their original NOP behavior. This makes it harder to both write and read scripts using them.</p>
|
||
|
||
<p>Segwit eliminates all of these problems by allowing segwit users to specify what version of the Bitcoin Script language to use. Each version can be either a minor improvement on an earlier version or an entirely new language – and the multiple versions can coexist together, allowing individual users to specify which version they want used to protect their transactions.</p>
|
||
|
||
<p>For example, segwit ships with an improvement to the <code class="highlighter-rouge">OP_CHECKSIG</code>, <code class="highlighter-rouge">OP_CHECKMULTISIG</code>, and related signature-checking opcodes that removes a known denial-of-service vulnerability vector that can be exploited through those opcodes. This isn’t a complete solution to that problem because the previous versions of the CHECKSIG opcodes are still available for non-segwit transactions, but it does help make segwit transactions harder to abuse than non-segwit transactions.</p>
|
||
|
||
<p>Some ideas for future upgrades using this mechanism are described below:</p>
|
||
|
||
<h3 id="schnorr-signatures">Schnorr signatures</h3>
|
||
|
||
<p>Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA). There’s a simpler digital signature algorithm that also uses elliptic curves but which was patented up until shortly before Bitcoin was originally released. This algorithm is called <a href="https://en.wikipedia.org/wiki/Schnorr_signature">Schnorr</a> and it supports all the features in ECDSA that Bitcoin uses, including the ability to create secure signatures as well as the ability to create HD wallets.</p>
|
||
|
||
<p>Schnorr signatures are already used outside of Bitcoin. For example, the well-known <a href="http://ed25519.cr.yp.to/">Ed25519 signature scheme</a> is based on Schnorr.</p>
|
||
|
||
<p>Verification of Schnorr signatures is slightly faster than ECDSA signatures (which makes running full nodes more convenient) and the signatures can be made smaller because the DER encoding currently used for ECDSA signatures doesn’t need to be used for Schnorr (providing a modest increase in capacity).</p>
|
||
|
||
<p>Schnorr also allows for “native multisig” in cases where all participants need to sign (such as 2-of-2, 3-of-3, or any n-of-n) that allows all <em>n</em> public keys to be combined into a single overall public key and all <em>n</em> signatures to be combined into a single overall signature. The overall public keys and signatures are the same size as a single one of the original public keys and signatures, so it’s possible to create a 100-of-100 multisig transaction that’s no larger than a 1-of-1 transaction. This will be quite useful as it expected that the network will see increased use of n-of-n multisig transactions (for example 2-of-2 is used in many payment channel transactions).</p>
|
||
|
||
<p>Schnorr support is already available in the <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a> library that Bitcoin Core uses for creating and verifying signatures, although Bitcoin doesn’t currently use Schnorr in any way and there are some changes the developers would like to make to the Schnorr parts of the library before starting to use it. This, combined with segwit’s support for Bitcoin Script versioning should make adding the features described above fairly easy.</p>
|
||
|
||
<p>A more difficult feature to add that is supported by Schnorr is <a href="https://bitcointalk.org/index.php?topic=1377298.0">signature aggregation</a>. This would change how signature validation works and would allow multisig transactions requiring 1-of-2, 2-of-3, or any m-of-n signatures to create just one signature per transaction provided all the signers are online simultaneously. This would also allow creating one signature for each transaction no matter how many inputs it has (again, if all signers are online simultaneously).</p>
|
||
|
||
<p>Since signatures are often the largest individual part of transactions and many transactions have two or more inputs each requiring at least one signature, this would significantly reduce the size of many transactions and would also speed up validation (as only one signature total would need to be validated rather than one signature per input).</p>
|
||
|
||
<p>Once implemented, signature aggregation could be combined with the coinjoin privacy-enhancing technique to create a significant financial incentive to use coinjoin for spending your bitcoins. Currently, there is a slight financial incentive to use coinjoin as a coinjoin transaction that combines what would be multiple individual transactions from different people is slightly smaller than what would be the total size of all those individual transactions. With signature aggregation, the combined transaction would be significantly smaller because it would only need one signature rather than many signatures.</p>
|
||
|
||
<p>Although signature aggregation is still being designed, it will be easy to add support for it to the protocol using segwit’s support for different versions of the Bitcoin Script evaluation language.</p>
|
||
|
||
<h3 id="mast">MAST</h3>
|
||
|
||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki">Merkelized Abstract Syntax Trees</a> (MAST) allow the <a href="https://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327">creation of Bitcoin scripts</a> with many different conditionals but which may allow only a relatively small amount of data to be placed in transactions.</p>
|
||
|
||
<p>They work by taking a program and splitting each conditional part of it into a separate segment, and then placing each of those segments into a merkle tree. Bitcoins are spent (encumbered) to the merkle root of the merkle tree.</p>
|
||
|
||
<p>A minimal set of conditions that need to be used for final validation can be revealed to all full validation nodes, but code that does not execute can be replaced by a simple hash as part of a partial merkle branch, allowing all parts of the script to be connected to the merkle root used in the encumbrance so that validation can be completed.</p>
|
||
|
||
<p>This not only saves space but it may also help improve privacy. For example, if Alice wants to be able to spend her bitcoins normally every day but also wants her estate lawyer Bob to be able to spend her bitcoins if they’ve been inactive for a year, she can place both of those conditions in separate branches. When Alice is making normal spends, nobody can see just by looking at the transaction what that second condition is.</p>
|
||
|
||
<p>Enabling MAST can be done using the versioning of Bitcoin Script enabled by segwit.</p>
|
||
|
||
</description>
|
||
<pubDate>Fri, 24 Jun 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/06/24/segwit-next-steps/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/06/24/segwit-next-steps/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>CSV softfork - Important upgrade instructions for miners</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#status-of-csv-soft-fork" id="markdown-toc-status-of-csv-soft-fork">Status of CSV soft fork</a></li>
|
||
<li><a href="#for-all-miners" id="markdown-toc-for-all-miners">For all miners</a></li>
|
||
<li><a href="#for-miners-who-manually-hardcoded-the-block-version" id="markdown-toc-for-miners-who-manually-hardcoded-the-block-version">For miners who manually hardcoded the block version</a></li>
|
||
<li><a href="#with-regard-to-the-nlocktime-field-of-the-generation-transaction" id="markdown-toc-with-regard-to-the-nlocktime-field-of-the-generation-transaction">With regard to the nLockTime field of the generation transaction</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>There is an ongoing soft fork of the Bitcoin consensus rules. While everything appears to be proceeding well, this article contains important information and checklists for miners and pool operators which must not be ignored.</p>
|
||
|
||
<p>If there is any doubt, miners and pool operators are welcome to <a href="/en/contact/">contact us</a>.</p>
|
||
|
||
<p>TL;DR</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>Check all your nodes have been upgraded to Bitcoin Core 0.12.1 or compatible software. This must happen before block #419328. Note that if your GBT client(s) implement the protocol correctly, you will need to patch in <a href="https://patch-diff.githubusercontent.com/raw/bitcoin/bitcoin/pull/8176">PR #8176</a> (<a href="https://patch-diff.githubusercontent.com/raw/bitcoin/bitcoin/pull/8176.patch">patch</a>) or use <a href="http://bitcoinknots.org/">Bitcoin Knots</a> which already includes it.</p>
|
||
</li>
|
||
<li>
|
||
<p>If you hardcode the block version please unset bit 0 of the version field before block 419328, or preferably stop hardcoding it and let bitcoind do it automatically.</p>
|
||
</li>
|
||
<li>
|
||
<p>Use a nLockTime value of 0xffffffff for the generation transaction to avoid any potential conflict with BIP113.</p>
|
||
</li>
|
||
<li>
|
||
<p>If you have to use a different nLockTime value, you must follow the instructions carefully.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<h2 id="status-of-csv-soft-fork">Status of CSV soft fork</h2>
|
||
|
||
<p>The “CSV” soft fork has reached the “locked in” threshold required to proceed to activation. Out of the 2016 blocks from #415296 to #417311, 1946 (96.53%) signaled the readiness for the <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">BIP68</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">BIP112</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">BIP113</a> (“CSV”) softfork. As of block #417312 (2016-06-21 05:18:58 UTC), the CSV softfork is now in a “locked in” grace period for about 2 weeks up to block 419327. After that, the new <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">BIP68</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">BIP112</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">BIP113</a> rules will be activated and enforced by the network. It has passed the “point-of-no-return” and is irreversible without a massive rollback of the blockchain.</p>
|
||
|
||
<h2 id="for-all-miners">For all miners</h2>
|
||
|
||
<p>During the grace period, all miners must upgrade to Bitcoin Core 0.12.1 or any implementation which supports the CSV softfork. In practice, at the time of writing, Bitcoin Core and Knots 0.12.1 are the only versions that supports the CSV softfork. Miners must double check to make sure all the mining nodes and backup nodes have been upgraded. Failing to do so may result in generation of invalid blocks, or cause your nodes to build upon any invalid blocks causing chain forks and monetary loss to the concerned miners and general Bitcoin users.</p>
|
||
|
||
<h2 id="for-miners-who-manually-hardcoded-the-block-version">For miners who manually hardcoded the block version</h2>
|
||
|
||
<p>By default, Bitcoin Core automatically set and unsets version bits as required, however, we are aware some miners hardcode the block version numbers. We strongly advise against hardcoding the block version because it can introduce risk to the Bitcoin system because the version signals support for certain consensus rules.</p>
|
||
|
||
<p>If a miner inadvertently has any nodes that don’t support the rules indicated by the block version, it could cause invalid blocks to be produced, and it could cause the miner to follow and build upon an invalid chain. In short, by not using the default value provided by bitcoind, it increases the risk of decoupling of block rules signalling and block rules enforcement.</p>
|
||
|
||
<p>Unlike the IsSuperMajority softfork used in BIP33/66/65, in the BIP9 softfork system, no blocks will be orphaned due to a wrong version number (as long as the version is &gt;= 4, which is required by BIP65). Therefore, there should be no incentive for miners to hardcode the block version, which would unnecessarily increase the burden of maintenance and risks of human error.</p>
|
||
|
||
<p>However, if you are manually setting the block version against this recommendation, you MUST take specific action. Now that the “point of no return” grace period has been reached for CSV, you must unset the CSV version bit, bit 0. This means if you were signalling 0x20000001 you should signal 0x20000000. This MUST be changed before block #419328 or you will trigger “unknown softfork” messages in the logs of all BIP9 compliant nodes. For more information please see the <a href="/en/2016/06/08/version-bits-miners-faq/#when-should-miners-set-bits">Version Bits FAQ</a>.</p>
|
||
|
||
<p>Failing to follow this advice may trigger the upgrade warning system of all BIP9 compliant nodes on the network, which will be very disruptive.</p>
|
||
|
||
<p>For miners that allow bitcoind to set the block version automatically, no further action is required. Please note it will keep generating blocks with version 0x20000001 until block #419328 at which point is will automatically unset bit 0.</p>
|
||
|
||
<h2 id="with-regard-to-the-nlocktime-field-of-the-generation-transaction">With regard to the nLockTime field of the generation transaction</h2>
|
||
|
||
<p>This is uncommon, but miners using the nLockTime field must pay extra attention due to the activation of <a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">BIP113</a>.</p>
|
||
|
||
<p>If a miner is interfering with the nLockTime of the generation transaction in any manner, they must make sure that the value, if interpreted as an UNIX timestamp (i.e. &gt;= 500000000), must be smaller than the median timestamp value of the past 11 blocks, unless the nSequence of the generation transaction is exactly 0xffffffff.</p>
|
||
|
||
<p>If you do not use nLockTime field of the generation transaction, please use a value of 0.</p>
|
||
|
||
<p>Failing to follow the above instructions may result in generation of invalid blocks, causing a chain fork and monetary loss of the concerned miners and general Bitcoin users.</p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 21 Jun 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/06/21/csv-softfork-instructions/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/06/21/csv-softfork-instructions/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Version bits FAQ for miners</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#what-is-version-bits-bip9" id="markdown-toc-what-is-version-bits-bip9">What is <em>version bits</em> BIP9?</a></li>
|
||
<li><a href="#how-is-version-bits-activated" id="markdown-toc-how-is-version-bits-activated">How is <em>version bits</em> activated?</a></li>
|
||
<li><a href="#what-are-soft-fork-timeouts" id="markdown-toc-what-are-soft-fork-timeouts">What are soft fork timeouts?</a></li>
|
||
<li><a href="#what-is-the-activation-workflow" id="markdown-toc-what-is-the-activation-workflow">What is the activation workflow?</a></li>
|
||
<li><a href="#what-is-the-version-bit" id="markdown-toc-what-is-the-version-bit">What is the version bit?</a></li>
|
||
<li><a href="#when-should-miners-set-bits" id="markdown-toc-when-should-miners-set-bits">When should miners set bits?</a></li>
|
||
<li><a href="#how-does-it-differ-to-an-ism-soft-fork" id="markdown-toc-how-does-it-differ-to-an-ism-soft-fork">How does it differ to an ISM soft fork?</a></li>
|
||
<li><a href="#do-miners-have-to-upgrade" id="markdown-toc-do-miners-have-to-upgrade">Do miners have to upgrade?</a></li>
|
||
<li><a href="#who-assigns-version-bits-to-different-upgrade-proposals" id="markdown-toc-who-assigns-version-bits-to-different-upgrade-proposals">Who assigns version bits to different upgrade proposals?</a></li>
|
||
<li><a href="#further-reading" id="markdown-toc-further-reading">Further reading</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<h2 id="what-is-version-bits-bip9">What is <em>version bits</em> BIP9?</h2>
|
||
|
||
<p>The <em>version bits</em> <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> system is a way to introduce backward compatible rule changes to the Bitcoin consensus rules, known as a soft fork.</p>
|
||
|
||
<p><em>version bits</em> allows miners to signal that they can validate the soft fork rules. It also allows for up to 29 soft forks to be proposed concurrently.</p>
|
||
|
||
<h2 id="how-is-version-bits-activated">How is <em>version bits</em> activated?</h2>
|
||
|
||
<p><em>version bits</em> does not require activation, it’s simply a way for miners to signal readiness for a soft fork by setting bits in the block header nVersion field.</p>
|
||
|
||
<h2 id="what-are-soft-fork-timeouts">What are soft fork timeouts?</h2>
|
||
|
||
<p>Soft forks have a start time and a <em>timeout</em> during which the proposal is active. The soft fork can only be activated between <em>start time</em> and <em>timeout</em>. If the soft fork does not get activated by the <em>timeout</em>, the soft fork proposal fails and will not activate even if signalled.</p>
|
||
|
||
<h2 id="what-is-the-activation-workflow">What is the activation workflow?</h2>
|
||
|
||
<p>Under <em>version bits</em>, a soft fork proposal goes through a workflow:</p>
|
||
|
||
<ul>
|
||
<li><code class="highlighter-rouge">[DEFINED]</code> -&gt; <code class="highlighter-rouge">[STARTED]</code> -&gt; <code class="highlighter-rouge">[LOCKED_IN]</code> -&gt; <code class="highlighter-rouge">[ACTIVE]</code></li>
|
||
</ul>
|
||
|
||
<p>or</p>
|
||
|
||
<ul>
|
||
<li><code class="highlighter-rouge">[DEFINED]</code> -&gt; <code class="highlighter-rouge">[STARTED]</code> -&gt; <code class="highlighter-rouge">[FAILED]</code></li>
|
||
</ul>
|
||
|
||
<p><img src="https://raw.githubusercontent.com/bitcoin/bips/master/bip-0009/states.png" alt="version bits state diagram" /></p>
|
||
|
||
<p>The Bitcoin network retargets mining difficulty every 2016 blocks; at this time <em>version bits</em> will look at the window of the previous 2016 blocks to see how many blocks signal for a given soft fork. If 95% of the blocks signal readiness for the soft fork, the state changes from <code class="highlighter-rouge">[STARTED]</code> to <code class="highlighter-rouge">[LOCKED_IN]</code>.</p>
|
||
|
||
<p>After <code class="highlighter-rouge">[LOCKED_IN]</code> the rules will activate after one more difficulty retarget, i.e. a further 2016 blocks. Nodes software will warn that an upgrade is pending.</p>
|
||
|
||
<h2 id="what-is-the-version-bit">What is the version bit?</h2>
|
||
|
||
<p>When no soft forks are being signalled, miners should set the block version field to <code class="highlighter-rouge">0x20000000</code>.</p>
|
||
|
||
<h2 id="when-should-miners-set-bits">When should miners set bits?</h2>
|
||
|
||
<p>To signal readiness for soft fork(s), miners should set the relevant version bit(s) together with <code class="highlighter-rouge">0x20000000</code>. This should only be done after the soft fork’s <em>start time</em>.</p>
|
||
|
||
<p>The bits should be unset if either the soft fork activates, or reached <code class="highlighter-rouge">[FAILED]</code> state.</p>
|
||
|
||
<p>For example:</p>
|
||
|
||
<p>“alice” soft fork uses bit 0, i.e. <code class="highlighter-rouge">0x1</code> + <code class="highlighter-rouge">0x20000000</code></p>
|
||
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>1</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>…</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>1</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>“bob” soft fork uses bit, 1, i.e. <code class="highlighter-rouge">0x2</code> + <code class="highlighter-rouge">0x20000000</code></p>
|
||
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>1</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>…</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>1</td>
|
||
<td>0</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>To signal both soft forks at once, use <code class="highlighter-rouge">0x20000003</code> (i.e. <code class="highlighter-rouge">0x1</code> + <code class="highlighter-rouge">0x2</code> + <code class="highlighter-rouge">0x20000000</code>*)</p>
|
||
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>1</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>…</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>0</td>
|
||
<td>1</td>
|
||
<td>1</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<ul>
|
||
<li>note if one is activated before the other, you must unset the relevant bit and continue signalling the other. IF one fails to activate and the timeout expires, you should also unset the bit.</li>
|
||
</ul>
|
||
|
||
<h2 id="how-does-it-differ-to-an-ism-soft-fork">How does it differ to an ISM soft fork?</h2>
|
||
|
||
<p>IsSuperMajority() or ISM for short, is a legacy soft fork trigger that activates new rules once 950 out of 1000 blocks are mined which signal the new block version.</p>
|
||
|
||
<ol>
|
||
<li>
|
||
<p>An IsSuperMajority() soft fork will orphan all blocks with previous version after activation. For example, if the current version is 4, and the next soft fork introduces version 5 blocks, then after activation is reached (950/1000 blocks), nodes will reject all version 4 blocks.</p>
|
||
</li>
|
||
<li>
|
||
<p>Once a <em>version bits</em> soft fork reaches activation, nodes will simply begin enforcing the new rules, and will NOT orphan a non-signalling block <em>unless</em> it violates the new rules.</p>
|
||
</li>
|
||
<li>
|
||
<p>ISM() looks at the previous 1000 blocks on a rolling basis; <em>version bits</em> looks at the previous 2016 block once each time the mining difficulty retargets.</p>
|
||
</li>
|
||
<li>
|
||
<p>ISM() soft forks do not expire. <em>version bits</em> soft forks can only activate between the <em>start time</em> and the <em>timeout</em>.</p>
|
||
</li>
|
||
</ol>
|
||
|
||
<h2 id="do-miners-have-to-upgrade">Do miners have to upgrade?</h2>
|
||
|
||
<p>No. A <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> soft fork will not activate unless 95% of the miners signal readiness. If a soft fork reaches <code class="highlighter-rouge">[LOCKED_IN]</code> state, where the vast majority of the miners are ready for the change, the remaining miners should upgrade <em>before</em> the next difficulty retarget (about 2 weeks).</p>
|
||
|
||
<p>Non-upgraded miners risk producing invalid blocks which would be orphaned if they are not able to validate the newly activated rules.</p>
|
||
|
||
<h2 id="who-assigns-version-bits-to-different-upgrade-proposals">Who assigns version bits to different upgrade proposals?</h2>
|
||
|
||
<p>Soft forks are proposed through the <a href="https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki">BIPs process</a>. Active <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> soft fork proposals are listed on the <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#deployments">assignments page</a></p>
|
||
|
||
<h2 id="further-reading">Further reading</h2>
|
||
|
||
<ul>
|
||
<li><a href="http://rusty.ozlabs.org/?p=576">http://rusty.ozlabs.org/?p=576</a></li>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=1067693.msg11446462#msg11446462">https://bitcointalk.org/index.php?topic=1067693.msg11446462#msg11446462</a></li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Wed, 08 Jun 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Compact Blocks FAQ</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#summary" id="markdown-toc-summary">Summary</a></li>
|
||
<li><a href="#what-are-some-useful-benchmarks-for-this" id="markdown-toc-what-are-some-useful-benchmarks-for-this">What are some useful benchmarks for this?</a></li>
|
||
<li><a href="#how-are-expected-missing-transactions-chosen-to-immediately-forward" id="markdown-toc-how-are-expected-missing-transactions-chosen-to-immediately-forward">How are expected missing transactions chosen to immediately forward?</a></li>
|
||
<li><a href="#how-does-the-fast-relay-network-factor-into-this" id="markdown-toc-how-does-the-fast-relay-network-factor-into-this">How does the Fast Relay Network factor into this?</a></li>
|
||
<li><a href="#does-this-scale-bitcoin" id="markdown-toc-does-this-scale-bitcoin">Does this scale Bitcoin?</a></li>
|
||
<li><a href="#who-benefits-from-compact-blocks" id="markdown-toc-who-benefits-from-compact-blocks">Who benefits from compact blocks?</a></li>
|
||
<li><a href="#what-is-the-timeline-on-coding-testing-reviewing-and-deploying-compact-block-propagation" id="markdown-toc-what-is-the-timeline-on-coding-testing-reviewing-and-deploying-compact-block-propagation">What is the timeline on coding, testing, reviewing and deploying compact block propagation?</a></li>
|
||
<li><a href="#how-can-this-be-adapted-for-even-faster-p2p-relay" id="markdown-toc-how-can-this-be-adapted-for-even-faster-p2p-relay">How can this be adapted for even faster p2p relay?</a></li>
|
||
<li><a href="#is-this-idea-new" id="markdown-toc-is-this-idea-new">Is this idea new?</a></li>
|
||
<li><a href="#further-reading-resources" id="markdown-toc-further-reading-resources">Further reading resources</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p><em>Compact block relay</em>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">BIP152</a>, is a method of reducing the amount of bandwidth used to propagate new blocks to full nodes.</p>
|
||
|
||
<h2 id="summary">Summary</h2>
|
||
|
||
<p>Using simple techniques it is possible to reduce the amount of bandwidth necessary to propagate new blocks to full nodes when they already share much of the same mempool contents. Peers send compact block “sketches” to receiving peers. These sketches include the following information:</p>
|
||
|
||
<ul>
|
||
<li>The 80-byte header of the new block</li>
|
||
<li>Shortened transaction identifiers (txids), that are designed to prevent Denial-of-Service (DoS) attacks</li>
|
||
<li>Some full transactions which the sending peer predicts the receiving peer doesn’t have yet</li>
|
||
</ul>
|
||
|
||
<p>The receiving peer then tries to reconstruct the entire block using the received information and the transactions already in its memory pool. If it is still missing any transactions, it will request those from the transmitting peer.</p>
|
||
|
||
<p>The advantage of this approach is that transactions only need to be sent once in the best case—when they are originally broadcast—providing a large reduction in overall bandwidth.</p>
|
||
|
||
<p>In addition, the compact block relay proposal also provides a second mode of operation (called <em>high bandwidth mode</em>) where the receiving node asks a few of its peers to send new blocks directly without asking for permission first, which may increase bandwidth (because two peers may try sending the same block at the same time) but which further reduces the amount of time it takes blocks to arrive (latency) on high-bandwidth connections.</p>
|
||
|
||
<p>The diagram below shows the way nodes currently send blocks compared to compact block relay’s two operating modes. The grey box on node A’s timeline represents the period in which it is performing validation.</p>
|
||
|
||
<p><img src="https://raw.githubusercontent.com/bitcoin/bips/master/bip-0152/protocol-flow.png" alt="Compact Blocks diagram" /></p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>In <strong>Legacy Relaying,</strong> a block is validated (the grey bar) by Node A, who then sends an <code class="highlighter-rouge">inv</code> message to Node B requesting permission to send the block. Node B replies with a request (<code class="highlighter-rouge">getdata</code>) for the block and Node A sends it.</p>
|
||
</li>
|
||
<li>
|
||
<p>In <strong>High Bandwidth Relaying,</strong> Node B uses <code class="highlighter-rouge">sendcmpt(1)</code> (send compact) to tell Node A that it wants to receive blocks as soon as possible. When a new block arrives, Node A performs some basic validation (such as validating the block header) and then automatically begins sending the header, shortened txids, and predicted missing transaction (as described above) to Node B. Node B attempts to reconstruct the block and requests any transactions it is still missing (<code class="highlighter-rouge">getblocktxn</code>), which Node A sends (<code class="highlighter-rouge">blocktxn</code>). In the background, both nodes complete their full validation of the block before adding it to their local copies of the blockchain, maintaining the same full node security as before.</p>
|
||
</li>
|
||
<li>
|
||
<p>In <strong>Low Bandwidth Relaying,</strong> Node B uses <code class="highlighter-rouge">sendcmpt(0)</code> to tell Node A that it wants to minimize bandwidth usage as much as possible. When a new block arrives, Node A fully validates it (so it doesn’t relay any invalid blocks). Then it asks Node B whether it wants the block (<code class="highlighter-rouge">inv</code>) so that if Node B has already received the block from another peer, it can avoid downloading it again. If Node B does want the block, it asks for it in compact mode (<code class="highlighter-rouge">getdata(CMPCT)</code>) and Node A sends the header, short txids, and predicted missing transactions. Node B attempts to reconstruct the block, requests any transactions it is still missing, and Node A sends those transactions. Node B then fully validates the block normally.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="what-are-some-useful-benchmarks-for-this">What are some useful benchmarks for this?</h2>
|
||
|
||
<p>An average full 1MB block announcement can be reconstructed by the receiving node with a block sketch of 9KB, plus overhead for each transaction in the block that is not in the receiving node’s mempool. The largest block sketches seen top out at a few bytes north of 20KB.</p>
|
||
|
||
<p>When running live experiments in ‘high bandwidth’ mode and having nodes prefill up to 6 transactions, we can expect to see well over 90% of blocks propagate immediately without needing to request any missing transactions. Even without prefilling any transactions except for the coinbase, experiments show we can see well north of 60% of blocks propagate immediately, the rest requiring a full additional network round trip.</p>
|
||
|
||
<p>Since the difference between mempools and blocks for warmed up nodes is rarely more than 6 transactions, this means that compact block relay achieves a dramatic reduction in required peak bandwidth.</p>
|
||
|
||
<h2 id="how-are-expected-missing-transactions-chosen-to-immediately-forward">How are expected missing transactions chosen to immediately forward?</h2>
|
||
|
||
<p>To reduce the number of things that need to be reviewed in the initial implementation, only the coinbase transaction will be pre-emptively sent.</p>
|
||
|
||
<p>However, in the described experiments, the sending node used a simple formula to choose which transactions to send: when Node A received a block, it checked to see which transactions were in the block but not in its mempool; those were the transactions it predicted that its peer didn’t have. The reasoning is that (without additional information) the transactions you didn’t know about are probably also the transactions your peers don’t know about. With this basic heuristic, a large improvement was seen, illustrating that many times the simplest solutions are the best.</p>
|
||
|
||
<h2 id="how-does-the-fast-relay-network-factor-into-this">How does the Fast Relay Network factor into this?</h2>
|
||
|
||
<p>The <a href="http://bitcoinrelaynetwork.org/">Fast Relay Network</a> (FRN) consists of two pieces:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>The curated set of nodes currently in the Fast Relay Network</p>
|
||
</li>
|
||
<li>
|
||
<p>The Fast Block Relay Protocol (FBRP)</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The set of curated nodes in the FRN have been carefully chosen with minimal relay over the globe as the number one priority. Failure of these nodes would result in a significant increase of wasted hashpower and potential further centralization of mining. A large majority of mining hashpower today connects to this network.</p>
|
||
|
||
<p>The original FBRP is how the participating nodes communicate block information to each other. Nodes keep track of what transactions they send to each other, and relay block differentials based off of this knowledge. This protocol is nearly optimal for one-to-one server-client communication of new blocks. More recently, a UDP and Forward Error Correction (FEC) based protocol, named RN-NextGeneration, has been deployed for testing and use by miners. These protocols however require a not-well connected relay topology and are more brittle than a more general p2p network. Improvements at the protocol level using compact blocks will shrink the performance gap between the curated network of nodes and the p2p network in general. The increased robustness of the p2p network and block propagation speed at large will play a role in how the network develops in the future.</p>
|
||
|
||
<h2 id="does-this-scale-bitcoin">Does this scale Bitcoin?</h2>
|
||
|
||
<p>This feature is intended to save peak block bandwidth for nodes, reducing bandwidth spikes which can degrade end-user internet experience. However, the centralization pressures of mining exist in a large part due to latency of block propagation, as described in the following video. Compact blocks version 1 is not primarily designed to solve that problem.</p>
|
||
|
||
<iframe width="560" height="315" src="https://www.youtube.com/embed/Y6kibPzbrIc" frameborder="0" allowfullscreen=""> </iframe>
|
||
|
||
<p>It is expected that miners will continue to use the <a href="http://bitcoinrelaynetwork.org/">Fast Relay Network</a> until a lower-latency or more robust solution is developed. However improvements to the base p2p protocol will increase robustness in the case of FRN failure, and perhaps reduce the advantage of private relay networks, making them not worthwhile to run.</p>
|
||
|
||
<p>Furthermore, the experiments conducted and data collected using the first version of compact blocks will inform the design of the future improvements we expect to be more competitive with the FRN.</p>
|
||
|
||
<h2 id="who-benefits-from-compact-blocks">Who benefits from compact blocks?</h2>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Full node users who want to relay transactions but who have limited internet bandwidth. If you simply want to save the most bandwidth possible while still relaying blocks to peers, there is a <code class="highlighter-rouge">blocksonly</code> mode already available starting in Bitcoin Core v0.12. Blocks-only mode only receives transactions when they’re included in a block, so there is no extra transaction overhead.</p>
|
||
</li>
|
||
<li>
|
||
<p>The network as a whole. Decreasing block propagation times on the p2p network creates a healthier network with a better baseline relay security margin.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="what-is-the-timeline-on-coding-testing-reviewing-and-deploying-compact-block-propagation">What is the timeline on coding, testing, reviewing and deploying compact block propagation?</h2>
|
||
|
||
<p>The first version of compact blocks has been assigned <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">BIP152</a>, has a working implementation, and is being actively tested by the developer community.</p>
|
||
|
||
<ul>
|
||
<li>BIP152: <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki</a></li>
|
||
<li>Reference implementation: <a href="https://github.com/bitcoin/bitcoin/pull/8068">https://github.com/bitcoin/bitcoin/pull/8068</a></li>
|
||
</ul>
|
||
|
||
<h2 id="how-can-this-be-adapted-for-even-faster-p2p-relay">How can this be adapted for even faster p2p relay?</h2>
|
||
|
||
<p>Additional improvements to the compact block scheme can be made. These are related to RN-NG and are two-fold:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>First, replace TCP transmission of block information with UDP transmission.</p>
|
||
</li>
|
||
<li>
|
||
<p>Second, handle dropped packets and pre-emptively send missing transaction data by using forward error correction (FEC) codes.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>UDP transmission allows data to be sent by the server and digested by the client as fast as the path allows, without worrying about intermittent dropped packets. A client would rather receive packets out of order to construct the block as fast as possible but TCP does not allow this.</p>
|
||
|
||
<p>In order to deal with the dropped packets and receiving non-redundant block data from multiple servers, FEC codes will be employed. A FEC code is a method of transforming the original data into a redundant code, allowing lossless transmission as long as a certain percentage of packets arrive at its destination, where the required data is only slightly larger than the original size of the data.</p>
|
||
|
||
<p>This would allow a node to begin sending a block as soon as it receives them, and allow the recipients to reconstruct blocks being streamed from multiple peers simultaneously. All of this work continues to build on the compact blocks work already completed. This is a medium-term extension, and development is ongoing.</p>
|
||
|
||
<h2 id="is-this-idea-new">Is this idea new?</h2>
|
||
|
||
<p>The idea of using bloom filters (such as those used in <a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki">BIP37</a> filteredblocks) to more efficiently transmit blocks was proposed a number of years ago. It was also implemented by Pieter Wuille (sipa) in 2013 but he found the overhead made it slow down the transfer.</p>
|
||
|
||
<figure class="highlight"><pre><code class="language-text" data-lang="text">[#bitcoin-dev, public log (excerpts)]
|
||
|
||
[2013-12-27]
|
||
09:12 &lt; sipa&gt; TD: i'm working on bip37-based block propagation
|
||
[...]
|
||
10:27 &lt; BlueMatt&gt; sipa: bip37 doesnt really make sense for block download, no? why do you want the filtered merkle tree instead of just the hash list (since you know you want all txn anyway)
|
||
[...]
|
||
15:14 &lt; sipa&gt; BlueMatt: the overhead of bip37 for full match is something like 1 bit per transaction, plus maybe 20 bytes per block or so
|
||
15:14 &lt; sipa&gt; over just sending the txid list
|
||
|
||
[2013-12-28]
|
||
00:11 &lt; sipa&gt; BlueMatt: i have a ~working bip37 block download branch, but it's buggy and seems to miss blocks and is very slow
|
||
00:15 &lt; sipa&gt; BlueMatt: haven't investigated, but my guess is transactions that a peer assumes we have and doesn't send again
|
||
00:15 &lt; sipa&gt; while they already have expired from our relay pool
|
||
[...]
|
||
00:17 &lt; sipa&gt; if we need to ask for missing transactions, there is an extra roundtrip, which makes it likely slower than full block download for many connections
|
||
00:18 &lt; BlueMatt&gt; you also cant request missing txn since they are no longer in mempool [...]
|
||
00:21 &lt; gmaxwell&gt; sounds like we really do need a protocol extension for this.
|
||
[...] 00:23 &lt; sipa&gt; gmaxwell: i don't see how to do it without extra roundtrip
|
||
00:23 &lt; BlueMatt&gt; send a list of txn in your mempool (or bloom filter over them or whatever)!</code></pre></figure>
|
||
|
||
<p>As was noted in the excerpt, simply extending the protocol to support sending individual transaction hashes for requesting transactions as well as individual transactions in blocks ended up allowing the compact blocks scheme to be much simpler, DoS-resistant, and more efficient.</p>
|
||
|
||
<h2 id="further-reading-resources">Further reading resources</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://people.xiph.org/~greg/efficient.block.xfer.txt">https://people.xiph.org/~greg/efficient.block.xfer.txt</a></li>
|
||
<li><a href="https://people.xiph.org/~greg/lowlatency.block.xfer.txt">https://people.xiph.org/~greg/lowlatency.block.xfer.txt</a></li>
|
||
<li><a href="https://people.xiph.org/~greg/weakblocks.txt">https://people.xiph.org/~greg/weakblocks.txt</a></li>
|
||
<li><a href="https://people.xiph.org/~greg/mempool_sync_relay.txt">https://people.xiph.org/~greg/mempool_sync_relay.txt</a></li>
|
||
<li><a href="https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding">https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding</a></li>
|
||
<li><a href="http://diyhpl.us/~bryan/irc/bitcoin/block-propagation-links.2016-05-09.txt">http://diyhpl.us/~bryan/irc/bitcoin/block-propagation-links.2016-05-09.txt</a></li>
|
||
<li><a href="http://diyhpl.us/~bryan/irc/bitcoin/weak-blocks-links.2016-05-09.txt">http://diyhpl.us/~bryan/irc/bitcoin/weak-blocks-links.2016-05-09.txt</a></li>
|
||
<li><a href="http://diyhpl.us/~bryan/irc/bitcoin/propagation-links.2016-05-09.txt">http://diyhpl.us/~bryan/irc/bitcoin/propagation-links.2016-05-09.txt</a></li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Tue, 07 Jun 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.12.1 Released!</title>
|
||
<description><p>We are pleased to announce the release of Bitcoin Core 0.12.1. This maintenance update includes the first soft fork deployment utilising “<a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">version bits</a>” as part of the <a href="/en/2015/12/23/capacity-increases-faq/">capacity increases</a> roadmap.</p>
|
||
|
||
<p>The soft fork seeks to activate three BIPs: <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">BIP68 sequence locks</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">BIP112 OP_CHECKSEQUENCEVERIFY</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">BIP113 Median time past</a>, which together are known as the “csv” deployment. Signalling begins at midnight on May 1st, 2016.</p>
|
||
|
||
<p>CHECKSEQUENCEVERIFY, the invention of Mark Friedenbach, upgrades the Bitcoin scripting language so bitcoins can be “frozen” for a specific amount of time, starting from the first confirmation,. It enables a variety of complex bi-directional payment channel applications; for example, Lightning Network will rely heavily on this.</p>
|
||
|
||
<p>This release also debuts <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9 “version bits”</a>, the invention of Pieter Wuille, which allows up to 29 parallel soft fork deployments at the same time and will speed up the rate at which new features can be added to the protocol.</p>
|
||
|
||
<p>You can find more details in the <a href="/en/releases/0.12.1/">release notes</a>.</p>
|
||
|
||
<p>To remain updated on future developments, you can subscribe to our <a href="/en/list/announcements/join/">announcements list</a>.</p>
|
||
|
||
<p>Download the new release from <a href="https://bitcoin.org/bin/bitcoin-core-0.12.1/">https://bitcoin.org/bin/bitcoin-core-0.12.1/</a>.</p>
|
||
|
||
<p>The Bitcoin Core Development Team</p>
|
||
|
||
</description>
|
||
<pubDate>Fri, 15 Apr 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/blog/2016/04/15/release-0.12.1/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/blog/2016/04/15/release-0.12.1/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>New Repository Maintainer Appointed</title>
|
||
<description><p>Hereby I’m announcing Marco Falke as the new Testing &amp; QA maintainer for
|
||
Bitcoin Core.</p>
|
||
|
||
<p>Testing and QA has always been essential to this project, and with the growing
|
||
pace of development it has become more critical than ever.</p>
|
||
|
||
<p>Marco has been doing a great job contributing to the project for the last year,
|
||
especially on the test framework and unit tests, increasing coverage, but also
|
||
by sanity-checking the wallet fee functionality and with reviewing other pull
|
||
requests. So it’s pretty much what he’s been already doing, and it’s natural to
|
||
consider him for this.</p>
|
||
|
||
<p>He’s going to oversee and merge pull requests for the QA and Testing framework,
|
||
and keep an eye on the overall quality of testing.</p>
|
||
|
||
<p>Welcome to the team Marco!</p>
|
||
|
||
<p>Regards,</p>
|
||
|
||
<p>Wladimir van der Laan</p>
|
||
|
||
</description>
|
||
<pubDate>Thu, 14 Apr 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/blog/2016/04/14/maintainer/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/blog/2016/04/14/maintainer/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Keep updated!</title>
|
||
<description><p>In an effort to increase communications, we are now providing opt-in, <em>announcement-only</em> information for users of Bitcoin Core to receive notifications of security issues and new releases.</p>
|
||
|
||
<p>While the Bitcoin Core project has a variety of communication channels, there have been a number of requests for a method of receiving only important announcements. This new source is intended to be extremely low volume, focused on critical notifications as well as to announce new releases.</p>
|
||
|
||
<p>If you use Bitcoin Core, please consider <a href="/en/list/announcements/join">subscribing</a>.</p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 15 Mar 2016 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/03/15/announcement-list/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/03/15/announcement-list/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>The first successful Zero-Knowledge Contingent Payment</title>
|
||
<description><p>I am happy to announce the first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network.</p>
|
||
|
||
<p>ZKCP is a transaction protocol that allows a buyer to purchase information from a seller using Bitcoin in a manner which is private, scalable, secure, and which doesn’t require trusting anyone: the expected information is transferred if and <em>only</em> if the payment is made. The buyer and seller do not need to trust each other or depend on arbitration by a third party.</p>
|
||
|
||
<p>Imagine a movie-style “briefcase swap” (one party with a briefcase full of cash, another containing secret documents), but without the potential scenario of one of the cases being filled with shredded newspaper and the resulting exciting chase scene.</p>
|
||
|
||
<p>An example application would be the owners of a particular make of e-book reader cooperating to purchase the DRM master keys from a failing manufacturer, so that they could load their own documents on their readers after the vendor’s servers go offline. This type of sale is inherently
|
||
irreversible, potentially crosses multiple jurisdictions, and involves parties whose financial stability is uncertain–meaning that both parties either take a great deal of risk or have to make difficult arrangement. Using a ZKCP avoids the significant transactional costs involved in a
|
||
sale which can otherwise easily go wrong.</p>
|
||
|
||
<p>In today’s transaction I purchased a solution to a 16x16 Sudoku puzzle for 0.10 BTC from Sean Bowe, a member of the Zcash team, as part of a demonstration performed live at <a href="http://fc16.ifca.ai/">Financial Cryptography 2016</a> in Barbados. I played my part in the transaction remotely from California.</p>
|
||
|
||
<p>The transfer involved two transactions:</p>
|
||
|
||
<ul>
|
||
<li><a href="https://www.blocktrail.com/BTC/tx/8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e">8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e</a></li>
|
||
<li><a href="https://www.blocktrail.com/BTC/tx/200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae">200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae</a></li>
|
||
</ul>
|
||
|
||
<p>Almost all of the engineering work behind this ZKCP implementation was done by Sean Bowe, with support from Pieter Wuille, myself, and Madars Virza.</p>
|
||
|
||
<p>See the slides from the <a href="https://z.cash/zkcp3.pdf">live demo</a>.</p>
|
||
|
||
<h2 id="background">Background</h2>
|
||
|
||
<p>I first proposed the ZKCP protocol in 2011 in an <a href="https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment">article on the Bitcoin Wiki</a> as an example of how tremendously powerful the existing primitives in Bitcoin Script already were.</p>
|
||
|
||
<h3 id="zero-knowledge-proofs">Zero Knowledge Proofs</h3>
|
||
|
||
<p>My ZKCP protocol required as a building block a zero-knowledge proof for arbitrary programs. Many kind of specialized zero-knowledge proofs exist:
|
||
common digital signatures are an example, as are the range proofs in <a href="https://people.xiph.org/~greg/confidential_values.txt">Confidential Transaction</a>.</p>
|
||
|
||
<p>A zero-knowledge proof for <em>general computation</em> is a cryptographic system which lets a person run an arbitrary program with a mixture of public and secret inputs and prove to others that this specific program accepted the inputs, without revealing anything more about its operation or the secret inputs.</p>
|
||
|
||
<p>If this seems like impossible magic, for educational purposes I came up with <a href="https://people.xiph.org/~greg/simple_verifyable_execution.txt">a very simple but inefficient ZKP system</a> that uses nothing fancier than boolean circuits and cryptographic hashes, or see Matthew Green’s
|
||
<a href="http://blog.cryptographyengineering.com/2014/11/zero-knowledge-proofs-illustrated-primer.html">Graph coloring ZKP example</a>.</p>
|
||
|
||
<p>As my initial write-up on ZKCP noted, no such system was readily available in 2011 but they were believed to be possible, especially under specific constraints that would have worked for ZKCP.</p>
|
||
|
||
<p>In 2012 Gennaro, Gentry, Parno, and Raykova published a paper (“<a href="https://eprint.iacr.org/2012/215">Quadratic Span Programs and Succinct NIZKs without PCPs</a>”) which described an especially efficient construction. Since then, several groups have continued to advance this work, creating compilers, performance improvements, and most critically, practical tools like libsnark. The GGPR’12 cryptosystem requires a trusted setup, but for the ZKCP application this is no real limitation since the buyer can perform it. Because of this work, ZKCP can now become a practical tool.</p>
|
||
|
||
<p>Further reading:</p>
|
||
|
||
<ul>
|
||
<li><a href="https://eprint.iacr.org/2012/215">GGPR’12 paper</a></li>
|
||
<li><a href="http://research.microsoft.com/en-us/projects/verifcomp/">Microsoft Verifiable Computing group</a></li>
|
||
<li><a href="http://www.scipr-lab.org/">SCIPR Lab</a></li>
|
||
<li><a href="https://github.com/scipr-lab/libsnark">Libsnark</a></li>
|
||
</ul>
|
||
|
||
<p>Because these efficient ZKPs are cutting-edge technology which depend on new strong cryptographic assumptions, their security is not settled yet. But in applications like ZKCP where our only alternatives are third-party trust, they can be used in ways which are a strict improvement over what we could do without them.</p>
|
||
|
||
<h2 id="how-zkcp-works">How ZKCP works</h2>
|
||
|
||
<p>If you accept the existence of the zero-knowledge proof system as a black box, the rest of the ZKCP protocol is quite simple.</p>
|
||
|
||
<p>The buyer first creates a program that can decide whether the input it is given is the data the buyer wants to buy. This program only verifies the information, it does not produce it–the buyer does not even have to have any idea how to produce it. (For example, it is easy to write a program to verify that a Sudoku solution is correct, but harder to write a Sudoku solver, Sudoku is NP-complete. The buyer here only needs to write the solution verifier.)</p>
|
||
|
||
<p>The buyer performs the trusted setup for the proof system and sends the resulting setup information over to the seller.</p>
|
||
|
||
<p>The seller picks a random encryption key and encrypts the information the buyer wishes to buy.</p>
|
||
|
||
<p>Using the ZKP system, the seller proves a composite statement:</p>
|
||
|
||
<ul>
|
||
<li>Ex is an encryption of an input that satisfies the Buyer’s program.</li>
|
||
<li>Y is the sha256 hash of the decryption key for Ex.</li>
|
||
</ul>
|
||
|
||
<p>The seller sends Ex, Y, the proof, and his pubkey to the buyer. Once the buyer’s computer verifies the proof, the buyer knows that if he learns the input to SHA256 that yields hash Y, he can decrypt his answer.</p>
|
||
|
||
<p>So the buyer initially wanted to buy an input for his program, but now he would be just as happy to buy the preimage of a hash. As it turns out, Bitcoin already provides a way to sell hash preimages in a secure manner.</p>
|
||
|
||
<p>The buyer makes his payment to the following ScriptPubkey:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>OP_SHA256
|
||
&lt;Y&gt; OP_EQUAL
|
||
OP_IF
|
||
&lt;Seller Pubkey&gt;
|
||
OP_ELSE
|
||
&lt;block_height+100&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP
|
||
&lt;Buyer Pubkey&gt;
|
||
OP_ENDIF
|
||
OP_CHECKSIG
|
||
</code></pre></div></div>
|
||
|
||
<p>The effect of this payment is that the seller can collect it if he provides the hash preimage of Y and a signature with his key. To avoid tying up the buyer’s funds forever, if the seller does not collect his payment within (e.g.) a day the buyer can reclaim the payment.</p>
|
||
|
||
<p>As a result, when the seller collects his payment he is forced to reveal the information that the buyer needs in order to decrypt the answer. If he doesn’t, the buyer gets his funds back.</p>
|
||
|
||
<p>This ScriptPubkey is also the same as would be used for a cross-chain atomic swap or a lightning payment channel.</p>
|
||
|
||
<p>Wallet support for these transactions has been implemented for Bitcoin Core in <a href="https://github.com/bitcoin/bitcoin/pull/7601">PR#7601</a>. This wallet support is used by the sudoku ZKCP client and server available at <a href="https://github.com/zcash/pay-to-sudoku">https://github.com/zcash/pay-to-sudoku</a>.</p>
|
||
|
||
<p>The buyer’s program can be arbitrarily long and complex without adding any additional burden to Bitcoin’s blockchain–the only impact would be the increased time required for setup and proving, which all happens external to Bitcoin. No one outside of the buyer or seller learns anything about the buyer’s program (that is, they do not learn the nature of the information being sold).</p>
|
||
|
||
<h2 id="limitations-and-alternatives">Limitations and alternatives</h2>
|
||
|
||
<p>This approach is much more scalable and private than conducting smart contracts inside the blockchain, and it isn’t subject to being held back by any performance or functionality limitations in Bitcoin’s smart contracting.</p>
|
||
|
||
<p>There are two primary restrictions of this approach. First, that it is interactive: the buyer can’t simply make a broadcast offer and have any interested seller accept the payment without back and forth communication. And second, that the ZKP system, while fast enough to be practical, is still not very fast. For example, in our demo the ZKP system proves 5 executions of SHA256 and the Sudoku constraints, and takes about 20 seconds to execute on a laptop. (The verification of the proof takes only a few milliseconds.)</p>
|
||
|
||
<p>One alternative to ZKCP is Peter Todd’s 2014 <a href="https://github.com/unsystem/paypub">“paypub” protocol</a>.
|
||
In Paypub, instead of using a zero-knowledge proof the buyer is shown a random subset of the data they are attempting to buy, and the seller is forced to unlock the rest when they collect their payment. Paypub avoids the complexity of dealing with a zero-knowledge proof– and also allowing the exchange of information that only humans can verify–, but at the cost of some vulnerability to cheating, and only being usable with a relatively large set of randomly verifiable information.</p>
|
||
|
||
<p>In general I think that “trustless” smart contracts like these have the most value where either there are frequent automated transactions of very low value – such that the overhead of traditional methods of conflict resolution deprives the participants of meaningful access to justice–or for very high value exchanges where the speed, unreliability (especially across jurisdictions), or lack of privacy of traditional conflict resolution would be unacceptable.</p>
|
||
|
||
<p>I look forward to the exciting applications people will find for them as the technology becomes increasingly practical.</p>
|
||
|
||
<p><em>Gregory Maxwell</em></p>
|
||
</description>
|
||
<pubDate>Fri, 26 Feb 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Core 0.12.0 Released!</title>
|
||
<description><p>We’re very excited to announce the official release of Bitcoin Core v0.12.0. A lot of hard work has gone into this release and it may just be the biggest one yet, with more significant improvements than any other before.</p>
|
||
|
||
<p>Here are the major improvements you’ll get to benefit from if you upgrade your nodes to version 0.12:</p>
|
||
|
||
<ol>
|
||
<li>7x Faster Signature Validation</li>
|
||
<li>Ability to Limit Upload Traffic</li>
|
||
<li>Crash Prevention via Memory Pool Limits</li>
|
||
<li>Option to Send Transactions That Can Be Fee-Boosted</li>
|
||
<li>Automatic Usage of Tor When it’s Running</li>
|
||
<li>Ability for Apps to Subscribe to Notifications With ZeroMQ</li>
|
||
<li>Massively Reduced Disk Usage for Wallets</li>
|
||
<li>Much Faster Block Assembly for Miners</li>
|
||
</ol>
|
||
|
||
<p>In addition to these, there are 13 other improvements that didn’t make the top list but are nonetheless quite valuable. You can find a complete list of them at the end of this post.</p>
|
||
|
||
<p>Now, let’s go and take a deeper dive into each of these improvements.</p>
|
||
|
||
<h2 id="7x-faster-signature-validation">7x Faster Signature Validation</h2>
|
||
|
||
<p>In Bitcoin Core, OpenSSL was traditionally used to validate ECDSA signatures in Bitcoin transactions. OpenSSL is very comprehensive in its capabilities (doing much more than simply validating ECDSA signatures), but this enormous feature set means that its attack surface is fairly large as a result. Because of the threat this represents to Bitcoin security, it became a priority to de-couple OpenSSL from Bitcoin Core and replace it with a simpler, more focused alternative.</p>
|
||
|
||
<p>To address this issue, a new ECDSA signature validation library called libsecp256k1 has been developed by members of the Bitcoin Core team and plugged in as a replacement for OpenSSL. It is the result of almost 3 years of complex engineering, and with this integration, the attack surface for signature validation code has been greatly reduced.</p>
|
||
|
||
<p>Further, libsecp256k1’s signature validation is much faster than that performed by OpenSSL. It is up to 7x faster on 64-bit architecture, and raw reindexing and block validation now takes less than half the time it did before - a major step forward for validating Bitcoin transactions.</p>
|
||
|
||
<p><em>Credits: Pieter Wuille, Greg Maxwell, and Cory Fields</em></p>
|
||
|
||
<h2 id="ability-to-limit-upload-traffic">Ability to Limit Upload Traffic</h2>
|
||
|
||
<p>Node upload traffic can be burdensome for some users, so the ability to put limitations on such traffic is a much-needed improvement. Node users now have the ability to set soft limits on how much data they upload and serve to their peers. Users can set a parameter that specifies how much data the node should target to be served daily. It will try to stay below the limit, rather than hit it, and if it hits the limit it will only serve blocks requested within the last week.</p>
|
||
|
||
<p><em>Credits: Jonas Schnelli</em></p>
|
||
|
||
<h2 id="crash-prevention-via-memory-pool-limits">Crash Prevention via Memory Pool Limits</h2>
|
||
|
||
<p>Older versions of Bitcoin Software had no limit on the number of transactions they would allow into their memory pool. Even though nodes will only accept transactions that have a certain specified minimum relay fee, at times the number of transactions that meet those requirements will get arbitrarily large and cause nodes with relatively low RAM to crash. Particularly concerning is that attackers can take advantage of this system by flooding the network with transactions in order to crash a subset of nodes.</p>
|
||
|
||
<p>With this update, nodes now have default limitations on the size of their memory pools and the operator can configure this to the amount of memory they want to dedicate to the mempool. When the memory limit is reached, new transactions can still be accepted, while transactions with the lowest fees will be dropped from the mempool. This new memory limitation ensures that unexpected crashes will not happen due to the number of cached transactions getting out of hand.</p>
|
||
|
||
<p><em>Credits: Matt Corallo and Suhas Daftuar</em></p>
|
||
|
||
<h2 id="option-to-send-transactions-that-can-be-fee-boosted">Option to Send Transactions That Can Be Fee-Boosted</h2>
|
||
|
||
<p>Transactions often get stuck if they have fees that are too low. This can cause problems because unspent transactions outputs (UTXOs) that were used in those transactions can be hard to spend, potentially freezing funds. Appropriate transaction fees are hard to calculate because they are highly dependent on the volume of transactions and their fees at any given time. Thus, one either typically underestimates, resulting in many stuck transactions or overestimates, resulting in a massive overpayment and a steady loss of funds.</p>
|
||
|
||
<p>A new feature called Opt-in Replace-by-Fee gives transaction senders the option to configure their transactions to be able to be replaced later by other transactions that specify larger fees. Senders can start with a low fee and see if their transaction gets accepted, and if not they can increase their fee until it gets accepted. This allows senders to both minimize the fees they pay and maximize the chance that their transactions will be included in a block.</p>
|
||
|
||
<p><em>Credits: Peter Todd and Suhas Daftuar</em></p>
|
||
|
||
<h2 id="automatic-usage-of-tor-when-its-running">Automatic Usage of Tor When it’s Running</h2>
|
||
|
||
<p>Nodes will now detect whether Tor is running and if it is they will automatically create Tor hidden services and connect to other nodes through the Tor network. No manual configuration is required.</p>
|
||
|
||
<p><em>Credits: Wladimir van der Laan</em></p>
|
||
|
||
<h2 id="ability-for-apps-to-subscribe-to-notifications-with-zeromq">Ability for Apps to Subscribe to Notifications With ZeroMQ</h2>
|
||
|
||
<p>Up until now, there has been limited support for external services to subscribe to notifications about the arrival of new blocks and incoming transactions. Services now have this ability thanks to an integration with ZeroMQ.</p>
|
||
|
||
<p><em>Credits: Johnathan Corgan</em></p>
|
||
|
||
<h2 id="massively-reduced-disk-usage-for-wallets">Massively Reduced Disk Usage for Wallets</h2>
|
||
|
||
<p>Users of the Bitcoin Core wallet often feel the burden of the high data storage requirements that come with running a full node (which is now up to 60GB and continues to rise). For users who have limitations on storage capacity and still want to use a wallet with a full node, they now have the ability to run their wallet in pruned mode. This means that the node will only focus on keeping track of unspent outputs and will forget previously-processed blocks as well as outputs that have been spent. This in turn means users will be able to run a full node while only storing around 2GB of data, a massive reduction from the previously-required 60GB.</p>
|
||
|
||
<p><em>Credits: Jonas Schnelli, Greg Maxwell, and Adam Weiss</em></p>
|
||
|
||
<h2 id="much-faster-block-assembly-for-miners">Much Faster Block Assembly for Miners</h2>
|
||
|
||
<p>Traditionally, block template creation has been quite expensive for miners, requiring high computation times and quite a bit of memory. The high computation time is a consequence of the fact that historically, miners have had to perform consensus critical calcuations for block validation simultaneously while they assemble a block. The high memory requirements have been due to the fact that historically during block assembly, every transaction in one’s memory pool would need to have its inputs pulled into an in-memory cache for various calculations.</p>
|
||
|
||
<p>With the 0.12 release, consensus-critical calculations pertaining to individual transactions are no longer performed all at once during block assembly, but are pre-calculated on all transactions as soon as they hit the memory pool and then cached. This means that during block assembly, most of the calculations have already been performed and the block template can be created extremely quickly. Specifically, this represents a time reduction from an interval measured in seconds to one measured in tens of milliseconds.</p>
|
||
|
||
<p>The pre-calculations that are peformed also mean that the inputs of all the transactions in one’s memory pool no longer have to be pulled into the cache all at once, leading to a sizeable reduction in memory requirements.</p>
|
||
|
||
<p><em>Credits: Alex Morcos</em></p>
|
||
|
||
<h2 id="closing-word">Closing Word</h2>
|
||
|
||
<p>The release of Version 0.12 will be a major move forward for the Bitcoin Core client. However, there is still much more to do and we’re always looking for more contributors. For more details see our <a href="/en/contribute/">contributing</a> page and specifically <a href="/en/faq/contributing-code/">CONTRIBUTING.md</a>. There are many other ways to contribute too - just ask others how you can help out (see community resources below).</p>
|
||
|
||
<p>Download from <a href="https://bitcoin.org/bin/bitcoin-core-0.12.0/">https://bitcoin.org/bin/bitcoin-core-0.12.0/</a>.</p>
|
||
|
||
<p>The Bitcoin Core Development Team</p>
|
||
|
||
<h2 id="v012-resources">v0.12 Resources</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md">Official Release Notes</a>.</li>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#0120-change-log">Changelog</a>.</li>
|
||
<li><a href="https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+milestone%3A0.12.0+is%3Aclosed">Pull requests</a>.</li>
|
||
</ul>
|
||
|
||
<h2 id="community-resources">Community Resources</h2>
|
||
|
||
<p><a href="https://bitcoincore.org/en/meetings/">Weekly Meeting Summaries</a></p>
|
||
|
||
<p>IRC Community:
|
||
Join the <code class="highlighter-rouge">#bitcoin-dev</code> and <code class="highlighter-rouge">#bitcoin-core-dev</code> channels on <code class="highlighter-rouge">irc.freenode.net</code>.</p>
|
||
|
||
<p>Twitter:
|
||
Follow Bitcoin Core updates at <a href="https://twitter.com/bitcoincoreorg">@bitcoincoreorg</a></p>
|
||
|
||
<p><em>This blog post was written by Ryan Shea based on the official <a href="https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md">release notes</a>.</em></p>
|
||
</description>
|
||
<pubDate>Tue, 23 Feb 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/02/23/release-0.12.0/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/02/23/release-0.12.0/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Clarifying Communications</title>
|
||
<description><p>Initially, bitcoin.org was used to host the original Bitcoin paper and became the homepage for the <a href="https://bitcoin.org/en/download">Bitcoin program</a>. The site evolved into a general educational resource for Bitcoin, and is <a href="https://bitcoin.org/en/bitcoin-core/about-site">not affiliated</a> with the modern Bitcoin Core project. The Bitcoin Core project’s official website is bitcoincore.org and while other websites continue to host information about Bitcoin Core, their views do not represent Bitcoin Core. We know that the Bitcoin ecosystem can be confusing, and we are working hard to make these relationships more clear.</p>
|
||
|
||
<p>For development work, Bitcoin Core mainly uses the <code class="highlighter-rouge">#bitcoin-core-dev</code> IRC channel on irc.libera.chat, <a href="https://github.com/bitcoin/bitcoin">Github</a>, and <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/">the bitcoin-dev mailing list</a>.</p>
|
||
|
||
<p>While there are many forums in which the Bitcoin community and, indeed, Bitcoin Core contributors engage, Bitcoin Core is not responsible for those forums or their policies, nor does Bitcoin Core take official positions on the community’s decisions to use them. Still, we believe it is critical that the Bitcoin community be able to freely discuss and critique every aspect of Bitcoin.</p>
|
||
|
||
<p>The Bitcoin community can become extremely excited and heated when discussing Bitcoin, but we must all work to maintain a civil tone. Community members should not engage in brigading, denial-of-service attacks, or otherwise disrupt healthy discussion and we should all do our best to assume good faith in absence of reason to believe otherwise.</p>
|
||
</description>
|
||
<pubDate>Thu, 28 Jan 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/01/28/clarification/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/01/28/clarification/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Segregated Witness Benefits</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#malleability-fixes" id="markdown-toc-malleability-fixes">Malleability Fixes</a> <ul>
|
||
<li><a href="#who-benefits" id="markdown-toc-who-benefits">Who benefits?</a></li>
|
||
<li><a href="#further-information" id="markdown-toc-further-information">Further information</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#linear-scaling-of-sighash-operations" id="markdown-toc-linear-scaling-of-sighash-operations">Linear scaling of sighash operations</a> <ul>
|
||
<li><a href="#who-benefits-1" id="markdown-toc-who-benefits-1">Who benefits?</a></li>
|
||
<li><a href="#further-information-1" id="markdown-toc-further-information-1">Further information</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#increased-security-for-multisig-via-pay-to-script-hash-p2sh" id="markdown-toc-increased-security-for-multisig-via-pay-to-script-hash-p2sh">Increased security for multisig via pay-to-script-hash (P2SH)</a> <ul>
|
||
<li><a href="#who-benefits-2" id="markdown-toc-who-benefits-2">Who benefits?</a></li>
|
||
<li><a href="#further-information-2" id="markdown-toc-further-information-2">Further information</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#script-versioning" id="markdown-toc-script-versioning">Script versioning</a> <ul>
|
||
<li><a href="#who-benefits-3" id="markdown-toc-who-benefits-3">Who benefits?</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#reducing-utxo-growth" id="markdown-toc-reducing-utxo-growth">Reducing UTXO growth</a> <ul>
|
||
<li><a href="#who-benefits-4" id="markdown-toc-who-benefits-4">Who benefits?</a></li>
|
||
<li><a href="#further-information-3" id="markdown-toc-further-information-3">Further information</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#efficiency-gains-when-not-verifying-signatures" id="markdown-toc-efficiency-gains-when-not-verifying-signatures">Efficiency gains when not verifying signatures</a> <ul>
|
||
<li><a href="#who-benefits-5" id="markdown-toc-who-benefits-5">Who benefits?</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#block-capacitysize-increase" id="markdown-toc-block-capacitysize-increase">Block capacity/size increase</a> <ul>
|
||
<li><a href="#who-benefits-6" id="markdown-toc-who-benefits-6">Who benefits?</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#moving-towards-a-single-combined-block-limit" id="markdown-toc-moving-towards-a-single-combined-block-limit">Moving towards a single combined block limit</a> <ul>
|
||
<li><a href="#who-benefits-7" id="markdown-toc-who-benefits-7">Who benefits?</a></li>
|
||
<li><a href="#further-information-4" id="markdown-toc-further-information-4">Further information</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#update-2016-10-19" id="markdown-toc-update-2016-10-19">Update 2016-10-19</a></li>
|
||
<li><a href="#update-2020-06-23" id="markdown-toc-update-2020-06-23">Update 2020-06-23</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<p>The Segregated Witness soft-fork (segwit) includes a wide range of features, many of which are highly technical. This page summarises some of the benefits of those features.</p>
|
||
|
||
<h2 id="malleability-fixes">Malleability Fixes</h2>
|
||
|
||
<p>Bitcoin transactions are identified by a 64-digit hexadecimal hash called a transaction identifier (txid) which is based on both the coins being spent and on who will be able to spend the results of the transaction.</p>
|
||
|
||
<p>Unfortunately, the way the txid is calculated allows anyone to make small modifications to the transaction that will not change its meaning, but will change the txid. This is called third-party malleability. BIP 62 (“dealing with malleability”) attempted to address these issues in a piecemeal manner, but was too complicated to implement as consensus checks and has been withdrawn.</p>
|
||
|
||
<p>For example, you could submit a transaction with txid ef74…c309 to the network, but instead find that a third-party, such as a node on the network relaying your transaction, or the miner who includes your transaction in a block, modifies the transaction slightly, resulting in your transaction still spending the same coins and paying the same addresses, but being confirmed under the completely different txid 683f…8bfa instead.</p>
|
||
|
||
<p>More generally, if one or more of the signers of the transaction revise their signatures then the transaction remains valid and pays the same amounts to the same addresses, but the txid changes completely because it incorporates the signatures. The general case of changes to signature data (but not the outputs or choice of inputs) modifying the transaction is called scriptSig malleability.</p>
|
||
|
||
<p>Segwit prevents third-party and scriptSig malleability by allowing Bitcoin users to move the malleable parts of the transaction into the <em>transaction witness,</em> and segregating that witness so that changes to the witness does not affect calculation of the txid.</p>
|
||
|
||
<h3 id="who-benefits">Who benefits?</h3>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>Wallet authors tracking spent bitcoins:</strong> it’s easiest to monitor the status of your own outgoing transactions by simply looking them up by txid. But in a system with third-party malleability, wallets must implement extra code to be able to deal with changed txids.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Anyone spending unconfirmed transactions:</strong> if Alice pays Bob in transaction 1, Bob uses that payment to pay Charlie in transaction 2, and then Alice’s payment gets malleated and confirmed with a different txid, then transaction 2 is now invalid and Charlie has not been paid. If Bob is trustworthy, he will reissue the payment to Charlie; but if he isn’t, he can simply keep those bitcoins for himself.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>The Lightning Network:</strong> with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Anyone using the block chain:</strong> smart contracts today, such as micropayment channels, and anticipated new smart contracts, become less complicated to design, understand, and monitor.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>Note: segwit transactions only avoid malleability if all their inputs are segwit spends (either directly, or via a backwards compatible segwit P2SH address).</p>
|
||
|
||
<h3 id="further-information">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://en.bitcoin.it/wiki/Transaction_Malleability">Bitcoin Wiki on Malleability</a></li>
|
||
<li><a href="http://cointelegraph.com/news/115374/the-ongoing-bitcoin-malleability-attack">Coin Telegraph article on 2015 Malleability attack</a></li>
|
||
<li><a href="https://bitcoinmagazine.com/articles/the-who-what-why-and-how-of-the-ongoing-transaction-malleability-attack-1444253640">Bitcoin Magazine article on 2015 Malleability attack</a></li>
|
||
<li><a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/">“Overview of BIPs necessary for Lightning” transcript</a></li>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki">BIP 62</a></li>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki">BIP 140 – alternative approach to malleability fixes</a></li>
|
||
<li><a href="http://bitcoin.stackexchange.com/questions/22051/transaction-malleability-in-the-blockchain/22058#22058">Stack exchange answer regarding 683f…8bfa transaction</a></li>
|
||
</ul>
|
||
|
||
<h2 id="linear-scaling-of-sighash-operations">Linear scaling of sighash operations</h2>
|
||
|
||
<p>A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.</p>
|
||
|
||
<p><img src="/assets/images/linear-quad-scale.png" alt="Linear versus quadratic" /></p>
|
||
|
||
<p>In essence, doubling the size of a transaction can double both the number of signature operations, and the amount of data that has to be hashed for each of those signatures to be verified. This has been seen in the wild, where an individual block required 25 seconds to validate, and maliciously designed transactions could take over 3 minutes.</p>
|
||
|
||
<p>Segwit resolves this by changing the calculation of the transaction hash for signatures so that each byte of a transaction only needs to be hashed at most twice. This provides the same functionality more efficiently, so that large transactions can still be generated without running into problems due to signature hashing, even if they are generated maliciously or much larger blocks (and therefore larger transactions) are supported.</p>
|
||
|
||
<h3 id="who-benefits-1">Who benefits?</h3>
|
||
|
||
<p>Removing the quadratic scaling of hashed data for verifying signatures makes increasing the block size safer. Doing that without also limiting transaction sizes allows Bitcoin to continue to support payments that go to or come from large groups, such as payments of mining rewards or crowdfunding services.</p>
|
||
|
||
<p>The modified hash only applies to signature operations initiated from witness data, so signature operations from the base block will continue to require lower limits.</p>
|
||
|
||
<h3 id="further-information-1">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">BIP 143</a></li>
|
||
<li><a href="http://rusty.ozlabs.org/?p=522">Blog post by Rusty Russell on the 25s transaction</a></li>
|
||
<li><a href="https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2013-2292">CVE 2013-2292 on Bitcoin wiki</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009494.html">Proposal to limit transactions to 100kB</a></li>
|
||
<li><a href="https://github.com/bitcoinclassic/bitcoinclassic/commit/842dc24b23ad9551c67672660c4cba882c4c840a">Bitcoin Classic commit on 0.11.2 branch adding additional consensus limit on sighash bytes</a></li>
|
||
</ul>
|
||
|
||
<h2 id="increased-security-for-multisig-via-pay-to-script-hash-p2sh">Increased security for multisig via pay-to-script-hash (P2SH)</h2>
|
||
|
||
<p>Multisig payments currently use P2SH which is secured by the 160-bit HASH160 algorithm (RIPEMD of SHA256). However, if one of the signers wishes to steal all the funds, they can find a collision between a valid address as part of a multisig script and a script that simply pays them all the funds with only 80-bits (2<sup>80</sup>) worth of work, which is already within the realm of possibility for an extremely well-resourced attacker. (For comparison, at a sustained 1 exahash/second, the Bitcoin mining network does 80-bits worth of work every two weeks)</p>
|
||
|
||
<p>Segwit resolves this by using HASH160 only for payments direct to a single public key (where this sort of attack is useless), while using 256-bit SHA256 hashes for payments to a script hash.</p>
|
||
|
||
<h3 id="who-benefits-2">Who benefits?</h3>
|
||
|
||
<p>Everyone paying to multisig or smart contracts via segwit benefits from the extra security provided for scripts.</p>
|
||
|
||
<h3 id="further-information-2">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html">Gavin Andresen asking if 80-bit attacks are worth worrying about</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012202.html">Ethan Heilman describing a cycle finding algorithm</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012227.html">Rusty Russell calculating costs of performing an attack</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012218.html">Anthony Towns applying the cycle finding algorithm to exploit transactions</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012234.html">Gavin Andresen summarising the thread</a></li>
|
||
</ul>
|
||
|
||
<h2 id="script-versioning">Script versioning</h2>
|
||
|
||
<p>Changes to Bitcoin’s script allow for both improved security and improved functionality. However, the design of script only allows backwards-compatible (soft-forking) changes to be implemented by replacing one of the ten extra OP_NOP opcodes with a new opcode that can conditionally fail the script, but which otherwise does nothing. This is sufficient for many changes – such as introducing a new signature method or a feature like OP_CLTV, but it is both slightly hacky (for example, OP_CLTV usually has to be accompanied by an OP_DROP) and cannot be used to enable even features as simple as joining two strings.</p>
|
||
|
||
<p>Segwit resolves this by including a version number for scripts, so that additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.</p>
|
||
|
||
<h3 id="who-benefits-3">Who benefits?</h3>
|
||
|
||
<p>Easier changes to script opcodes will make advanced scripting in Bitcoin easier. This includes changes such as introducing Schnorr signatures, using key recovery to shrink signature sizes, supporting sidechains, or creating even smarter contracts by using Merklized Abstract Syntax Trees (MAST) and other research-level ideas.</p>
|
||
|
||
<h2 id="reducing-utxo-growth">Reducing UTXO growth</h2>
|
||
|
||
<p>The Unspent Transaction Output (UTXO) database is maintained by each validating Bitcoin node in order to determine whether new transactions are valid or fraudulent. For efficient operation of the network, this database needs to be very quick to query and modify, and should ideally be able to fit in main memory (RAM), so keeping the database’s size in bytes as small as possible is valuable.</p>
|
||
|
||
<p>This becomes more difficult as Bitcoin grows, as each new user must have at least one UTXO entry of their own and will prefer having multiple entries to help improve their privacy and flexibility, or to provide as backing for payment channels or other smart contracts.</p>
|
||
|
||
<p>Segwit improves the situation here by making signature data, which does not impact the UTXO set size, cost 75% less than data that does impact the UTXO set size. This is expected to encourage users to favour the use of transactions that minimise impact on the UTXO set in order to minimise fees, and to encourage developers to design smart contracts and new features in a way that will also minimise the impact on the UTXO set.</p>
|
||
|
||
<p>Because segwit is a soft-forking change and does not increase the base blocksize, the worst case growth rate of the UTXO set stays the same.</p>
|
||
|
||
<h3 id="who-benefits-4">Who benefits?</h3>
|
||
|
||
<p>Reduced UTXO growth will benefit miners, businesses, and users who run full nodes, which in turn helps maintain the current security of the Bitcoin network as more users enter the system. Users and developers who help minimise the growth of the UTXO set will benefit from lower fees compared to those who ignore the impact of their transactions on UTXO growth.</p>
|
||
|
||
<h3 id="further-information-3">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="http://statoshi.info/dashboard/db/unspent-transaction-output-set">Statoshi UTXO dashboard</a></li>
|
||
</ul>
|
||
|
||
<h2 id="efficiency-gains-when-not-verifying-signatures">Efficiency gains when not verifying signatures</h2>
|
||
|
||
<p>Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.</p>
|
||
|
||
<p>Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.</p>
|
||
|
||
<h3 id="who-benefits-5">Who benefits?</h3>
|
||
|
||
<p>As more transactions use segwit addresses, people running pruned or SPV nodes will be able to operate with less bandwidth and disk space.</p>
|
||
|
||
<h2 id="block-capacitysize-increase">Block capacity/size increase</h2>
|
||
|
||
<p>Since old nodes will only download the witness-stripped block, they only enforce the 1 MB block size limit rule on that data.
|
||
New nodes, which understand the full block with witness data, are therefore free to replace this limit with a new one, allowing for larger block sizes. Segregated witness therefore takes advantage of this opportunity to raise the block size limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).</p>
|
||
|
||
<h3 id="who-benefits-6">Who benefits?</h3>
|
||
|
||
<p>People who run upgraded wallets will be able to take advantage of the increased block size by moving signatures to the witness section of the transaction.</p>
|
||
|
||
<h2 id="moving-towards-a-single-combined-block-limit">Moving towards a single combined block limit</h2>
|
||
|
||
<p>Currently there are two consensus-enforced limits on blocksize: the block can be no larger than 1MB and, independently, there can be no more than 20,000 signature checks performed across the transactions in the block.</p>
|
||
|
||
<p>Finding the most profitable set of transactions to include in a block given a single limit is an instance of the knapsack problem, which can be easily solved almost perfectly with a simple greedy algorithm. However adding the second constraint makes finding a good solution very hard in some cases, and this theoretical problem has been exploited in practice to force blocks to be mined at a size well below capacity.</p>
|
||
|
||
<p>It is not possible to solve this problem without either a hardfork, or substantially decreasing the block size. Since segwit can’t fix the problem, it settles on not making it worse: in particular, rather than introducing an independent limit for the segregated witness data, instead a single limit is applied to the weighted sum of the UTXO data and the witness data, allowing both to be limited simultaneously as a combined entity.</p>
|
||
|
||
<h3 id="who-benefits-7">Who benefits?</h3>
|
||
|
||
<p>Ultimately miners will benefit if a future hardfork that changes the block capacity limit to be a single weighted sum of parameters. For example:</p>
|
||
|
||
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>50*sigops + 4*basedata + 1*witnessdata &lt; 10M
|
||
</code></pre></div></div>
|
||
|
||
<p>This lets miners easily and accurately fill blocks while maximising fee income, and that will benefit users by allowing them to more reliably calculate the appropriate fee needed for their transaction to be mined.</p>
|
||
|
||
<h3 id="further-information-4">Further information</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://en.wikipedia.org/wiki/Knapsack_problem">Knapsack problem</a></li>
|
||
<li><a href="https://bitcointalk.org/index.php?topic=1166928.0;all">Sigop attack discussion on bitcointalk in Aug 2015</a></li>
|
||
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011870.html">Gregory Maxwell on bitcoin-dev on witness limits</a></li>
|
||
<li><a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/validation-cost-metric/">“Validation Cost Metric” transcript</a></li>
|
||
</ul>
|
||
|
||
<h2 id="update-2016-10-19">Update 2016-10-19</h2>
|
||
|
||
<p>Earlier versions of this page listed “Compact fraud proofs” as a benefit of segwit. However, as implemented, segwit does not make this any easier: with or without segwit, a future soft-fork enabling compact fraud proofs and the benefits they bring, will need to include its own commitment (eg, in the coinbase transaction), rather than being able to extend the commitment data used by segwit.</p>
|
||
|
||
<p>The previous text was:</p>
|
||
|
||
<blockquote>
|
||
<p><strong>Compact fraud proofs</strong></p>
|
||
|
||
<p>As the Bitcoin userbase expands, validating the entire blockchain naturally becomes more expensive. To maintain the decentralised, trustless nature of Bitcoin, it is important to allow those who cannot afford to validate the entire blockchain to at least be able to cheaply validate as much of it as they can afford.</p>
|
||
|
||
<p>Segwit improves the situation here by allowing a future soft-fork to extend the witness structure to include commitment data, which will allow lightweight (SPV) clients to enforce consensus rules such such as the number of bitcoins introduced in a block, the size of a block, and the number of sigops used in a block.</p>
|
||
|
||
<p><strong>Who benefits?</strong></p>
|
||
|
||
<p>Fraud proofs allow SPV users to help enforce Bitcoin’s consensus rules, which will potentially greatly increase the security of the Bitcoin network as a whole, as well as reduce the ways in which individual users can be attacked.</p>
|
||
|
||
<p>These fraud proofs can be added to the witness data structure as part of a future soft-fork, and they’ll help SPV clients enforce the rules even on transactions that don’t make use of the segwit features.</p>
|
||
</blockquote>
|
||
|
||
<h2 id="update-2020-06-23">Update 2020-06-23</h2>
|
||
|
||
<p>Earlier versions of this page listed “Signing of input values” as a benefit of segwit.
|
||
However, as implemented, segwit does not make this safe:
|
||
with or without segwit, a future soft-fork will be needed to rely on signed input values.</p>
|
||
|
||
<p>Since the values of each input are signed individually, the apparent fee can be manipulated in deceiving ways.
|
||
(CVE-2020-14199)</p>
|
||
|
||
<p>The previous text was:</p>
|
||
|
||
<blockquote>
|
||
<p><strong>Signing of input values</strong></p>
|
||
|
||
<p>When a hardware wallet signs a transaction, it can easily verify the total amount being spent, but can only safely determine the fee by having a full copy of all the input transactions being spent, and must hash each of those to ensure it is not being fed false data. Since individual transactions can be up to 1MB in size, this is not necessarily a cheap operation, even if the transaction being signed is itself quite small.</p>
|
||
|
||
<p>Segwit resolves this by explicitly hashing the input value. This means that a hardware wallet can simply be given the transaction hash, index, and value (and told what public key was used), and can safely sign the spending transaction, no matter how large or complicated the transaction being spent was.</p>
|
||
|
||
<p><strong>Who benefits?</strong></p>
|
||
|
||
<p>Manufacturers and users of hardware wallets are the obvious beneficiaries; however this likely also makes it much easier to safely use Bitcoin in small embedded devices for “Internet of things” applications.</p>
|
||
|
||
<p>This benefit is only available when spending transactions sent to segwit enabled addresses (or segwit-via-P2SH addresses).</p>
|
||
|
||
<p><strong>Further information</strong></p>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">BIP 143</a></li>
|
||
</ul>
|
||
</blockquote>
|
||
|
||
</description>
|
||
<pubDate>Tue, 26 Jan 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/01/26/segwit-benefits/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/01/26/segwit-benefits/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Launch of Segregated Witness Testnet</title>
|
||
<description><p>We are extremely pleased and excited to announce the <a href="https://github.com/sipa/bitcoin/commits/segwit">Segregated Witness Testnet</a>! All developers are encouraged to help begin testing and integration right away.</p>
|
||
|
||
<p>This represents one of the most hotly anticipated and exciting developments to date that is an important foundation for many future improvements and innovations. Segregated Witness frees up space on the Bitcoin blockchain by securely moving transaction signature data to a specially delegated “Segregated Witness” data structure outside of the transaction block.</p>
|
||
|
||
<p>This significant innovation leads to dramatically more efficient use of the Bitcoin blockchain, while simultaneously opening up exciting new possibilities and opportunities for the broader Bitcoin ecosystem, particularly around smart contract applications and dramatically faster transactions, while also providing the groundwork for more advanced features and possibilities in the future.</p>
|
||
|
||
<p>This development began with a research effort by Bitcoin Core developer, Dr. Pieter Wuille, initially focused on addressing transaction malleability, a longstanding and well-known concern and priority. However, in the process of this research, and in the narrowing toward a solution, additional properties of the solution were discovered that allow for increasing the block size while also simultaneously opening up some incredibly exciting secondary benefits.</p>
|
||
|
||
<p>This effort was initiated by Dr. Pieter Wuille, but included contributions from many others, with particular thanks to Eric Lombrozo, Johnson Lau, Alex Morcos, Nicolas Dorier, Bryan Bishop, Gregory Maxwell, Peter Todd, Cory Fields, Suhas Daftuar, and Luke-Jr.</p>
|
||
|
||
<h2 id="bitcoin-core-ecosystem">Bitcoin Core Ecosystem</h2>
|
||
|
||
<p>There is broad excitement and anticipation as far as what providers and other exchange operators will create with the fundamental developments and innovations included in this release. So far, the most popular wallets and supporting libraries have stated they will support segwit including Ledger, Trezor, Electrum, and Bitgo. Additionally, work on numerous other libraries such as bitcoinj, bitcoinjs, pycoin and bitcore has already begun.</p>
|
||
|
||
<p>A faucet is available for “segnet” coins <a href="https://segwit.greenaddress.it/faucet/">here</a>.</p>
|
||
|
||
<p>Early previews of third party wallet support are available at:</p>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/ciphrex/mSIGNA/tree/segwit">mSIGNA</a> (wallet source-code)</li>
|
||
<li><a href="https://segwit.greenaddress.it/">Green Address</a> (web wallet)</li>
|
||
</ul>
|
||
|
||
<h2 id="how-to-get-involved">How to get involved</h2>
|
||
|
||
<p>Please join the <code class="highlighter-rouge">segwit-dev</code> IRC channel on irc.freenode.net.</p>
|
||
|
||
<p>Wallet providers should read the <a href="/en/segwit_wallet_dev">migration guide</a>.</p>
|
||
|
||
<h2 id="testing">Testing</h2>
|
||
|
||
<p>Finally and most importantly, please help test the Segwit Testnet!</p>
|
||
|
||
<p>The source-code can be located <a href="https://github.com/sipa/bitcoin/tree/segwit">here</a> checkout the <code class="highlighter-rouge">segwit</code> branch.</p>
|
||
|
||
<p>Once compiled, add <code class="highlighter-rouge">-segnet</code> to the standard <code class="highlighter-rouge">bitcoind</code> and <code class="highlighter-rouge">bitcoin-cli</code> command line.</p>
|
||
|
||
<h2 id="additional-background-and-history">Additional Background and History</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/">Scaling Bitcoins Hong Kong Presentation</a></li>
|
||
<li><a href="https://bitcoincore.org/en/2015/12/14/segregated-witness">Extended Video</a></li>
|
||
<li><a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/">Transcript</a></li>
|
||
</ul>
|
||
|
||
<h2 id="technical-references">Technical References</h2>
|
||
|
||
<h3 id="segwit-bips">SegWit BIPs</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">BIP141</a>: An overview of the segregated witness soft fork, and a discussion on its benefits, backwards compatibility, consensus limits, and deployment.</li>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki">BIP143</a>: The definition of a new digest algorithm for signature verification used in segregated witness transactions.</li>
|
||
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki">BIP144</a>: The new message types and serialization formats for segregated witness transactions.</li>
|
||
</ul>
|
||
|
||
<h3 id="references">References</h3>
|
||
|
||
<ul>
|
||
<li><a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012248.html">Analysis of segwit benefits</a></li>
|
||
<li><a href="https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks">Hard Forks vs. Soft Forks</a></li>
|
||
<li><a href="https://scalingbitcoin.org/hongkong2015/presentations/DAY1/1_overview_1_timon.pdf">Early Exploration of “Non-contentious” Hard Fork Research</a></li>
|
||
</ul>
|
||
|
||
</description>
|
||
<pubDate>Thu, 21 Jan 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/01/21/launch_segwit_testnet/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/01/21/launch_segwit_testnet/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Core Development Visualisation for 2015</title>
|
||
<description><p>The following video shows commit activity in the <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core repository</a> during 2015. A full list of code contributors during this period can be found <a href="https://github.com/bitcoin/bitcoin/graphs/contributors?from=2015-01-01&amp;to=2016-01-01&amp;type=c">here</a>.</p>
|
||
|
||
<iframe width="560" height="315" src="https://www.youtube.com/embed/FIt7GLxxIpY" frameborder="0" allowfullscreen=""> </iframe>
|
||
|
||
<p>In 2015, the Bitcoin Core project released 2 major versions of it’s software together with 5 further maintenance releases.
|
||
Additionally, two soft forks upgrades were deployed and successfully activated. The first, <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">BIP66</a>, fixed a potentially serious security vulnerability introduced by openssl; and the second, <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki">BIP65</a>, added a new opcode CHECKLOCKTIMEVERIFY to the Bitcoin scripting language.</p>
|
||
|
||
<p>The project also completed the bulk of the work for the next major release, <a href="https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md">0.12</a>, scheduled for release in February. <a href="https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md">0.12</a> will include <a href="https://github.com/bitcoin/secp256k1">libsecp256k1</a> which has been in development for the last <a href="https://github.com/bitcoin/secp256k1/graphs/contributors?from=2013-03-04&amp;to=2015-12-01&amp;type=c">two and a half years</a>, and brings a 7 fold increase to signature validation speeds which is essential for increasing scalability going forward.</p>
|
||
|
||
<p>Please note that commit activity represents only a part of the overall developer activity and does not record the activity of peer reviewers, code reviewers, integration testers and translators. It also does not accurately reflect the amount of time that goes into research, discussion and development before being accepted into the codebase.</p>
|
||
|
||
<p>We would also like to take this opportunity to thank everyone who has been involved so far in contributing to Bitcoin Core and helping make Bitcoin better for everyone.</p>
|
||
|
||
</description>
|
||
<pubDate>Wed, 13 Jan 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/01/13/development-visualisation-2015/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/01/13/development-visualisation-2015/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Statement from Bitcoin Core -- 2016-01-07</title>
|
||
<description><p>Bitcoin is a “peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution”. Our vision for Bitcoin is to expand the flexibility of the system to work efficiently at extremely high scale, while at the same time maintaining security and the core properties of decentralization that make Bitcoin unique.</p>
|
||
|
||
<p>We believe Bitcoin can accomplish this by providing the foundation for additional layers on top of the protocol and interfaces with other systems. Furthermore, our long term goals include protecting and improving the privacy of Bitcoin users.</p>
|
||
|
||
<p>“Bitcoin Core” refers to an open source software project that is a direct descendant of the original Bitcoin implementation. As project contributors, we maintain and release software for the Bitcoin community for users’ consideration. We strive to make improvements to the consensus protocol by proposing upgrades that we believe make technical sense according to our understanding of the goals of Bitcoin, and that we believe stand a reasonable chance of widespread support and adoption.</p>
|
||
|
||
<p>Changes to the Bitcoin consensus rules can be made through either soft forks or hard forks (see Appendix A). Soft forks allow compatible changes. With soft forks, old and new software can co-exist on the network. Soft forks can introduce new features without disruption because users who want to use the new features can upgrade, while those who do not are free to continue as normal.</p>
|
||
|
||
<p>Hard forks break compatibility of all previous Bitcoin software and require every participant to upgrade to the same rules by a deadline or risk losing money. Such events can also harm network effects by pushing participants off the network if they take no action, and by potentially breaking downstream software and applications.</p>
|
||
|
||
<p>For these reasons, Bitcoin Core strongly favours compatibility and believes it should be each user’s choice not to upgrade the rules of their current Bitcoin software. It turns out it is possible to add almost any new feature with a soft fork. Occasionally, hard forks may have some benefits, and if there is near-universal agreement, these benefits may outweigh the downsides. Except for these rare cases, soft forks are to be preferred. We believe this is in the best interests of current and future users of the system.</p>
|
||
|
||
<p>We also expect that as the Bitcoin ecosystem grows, the number of alternative Bitcoin protocol implementations may increase, and it is inevitable that other software projects may release radically different software proposals for the ecosystem to consider. At the end of the day, the Bitcoin Core development team does not decide the Bitcoin consensus rules. Instead, users participate in Bitcoin by making their own choice of which Bitcoin software to run. This is why Bitcoin Core software deliberately does not have an auto-update feature. Its omission ensures voluntary user participation in every upgrade, so users always retain the choice over which software they run.</p>
|
||
|
||
<h3 id="appendix-a">Appendix A</h3>
|
||
|
||
<p>A hard fork is a change to consensus rules, in which blocks that would have been invalid under the old rules may become valid under the new rules.</p>
|
||
|
||
<p>A soft fork is a change to consensus rules, in which blocks that would have been valid under the old rules may become invalid under the new rules, but all blocks that would have been invalid under the old rules remain invalid under the new rules.</p>
|
||
|
||
</description>
|
||
<pubDate>Thu, 07 Jan 2016 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2016/01/07/statement/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2016/01/07/statement/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Bitcoin Capacity Increases FAQ</title>
|
||
<description><section id="table-of-contents" class="toc">
|
||
<header>
|
||
|
||
<h3 class="toc-header"><i class="fa fa-book"></i> Overview</h3>
|
||
</header>
|
||
<div class="toc-drawer">
|
||
<ul id="markdown-toc">
|
||
<li><a href="#roadmap-dates" id="markdown-toc-roadmap-dates">What specific technologies are included in the roadmap, and when can we expect them?</a></li>
|
||
<li><a href="#segwit-size" id="markdown-toc-segwit-size">Is the segregated witness soft fork equivalent to a 4 MB block size increase, a 2 MB increase, a 1.75 MB increase, or what? I keep hearing different numbers.</a></li>
|
||
<li><a href="#ecosystem-ready" id="markdown-toc-ecosystem-ready">Segregated witness sounds complicated; will the ecosystem be prepared for its deployment?</a></li>
|
||
<li><a href="#size-bump" id="markdown-toc-size-bump">Segregated witness still sounds complicated. Why not simply raise the maximum block size?</a></li>
|
||
<li><a href="#pre-segwit-fork" id="markdown-toc-pre-segwit-fork">Will there be a hard fork before or as part of the segregated witness implementation?</a></li>
|
||
<li><a href="#why-not-now" id="markdown-toc-why-not-now">If there’s eventually going to be a hard fork, why not do it now?</a></li>
|
||
<li><a href="#segwit-in-wallets" id="markdown-toc-segwit-in-wallets">How will segregated witness transactions work for wallets?</a></li>
|
||
<li><a href="#why-upgrade" id="markdown-toc-why-upgrade">If no one is forced to upgrade, why will anyone bother to upgrade? I heard P2SH took almost two years to become widely deployed.</a></li>
|
||
<li><a href="#rbf" id="markdown-toc-rbf">I heard you were breaking zero-confirmation transactions. Which technology in the scaling roadmap is doing that?</a></li>
|
||
<li><a href="#weak-blocks-iblts" id="markdown-toc-weak-blocks-iblts">Weak blocks and IBLTs just say “2016” in the roadmap schedule. Does this mean you have no idea when they’ll be available?</a></li>
|
||
<li><a href="#why-mine-segwit" id="markdown-toc-why-mine-segwit">“Why would miners adopt the SegWit format, given that it does not provide any savings of bandwidth, storage, or processing time to them?”</a></li>
|
||
<li><a href="#how-can-i-help" id="markdown-toc-how-can-i-help">How can I help?</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</section>
|
||
<!-- /#table-of-contents -->
|
||
|
||
<h2 id="roadmap-dates">What specific technologies are included in the roadmap, and when can we expect them?</h2>
|
||
|
||
<p>New technology will be deployed when it is ready and has been tested. However, we believe the following is a reasonable schedule for the specific improvements described in the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html">roadmap</a>.</p>
|
||
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td>Dec 2015</td>
|
||
<td> </td>
|
||
<td>Deploy segregated witness testnet</td>
|
||
<td><img src="/assets/images/ok-48.png" alt="delivered" title="delivered" /></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Feb 2016</td>
|
||
<td>0.12.0</td>
|
||
<td><a href="https://github.com/bitcoin/bitcoin/pull/6954">libsecp256k1 verification</a></td>
|
||
<td><img src="/assets/images/ok-48.png" alt="delivered" title="delivered" /></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Feb 2016</td>
|
||
<td> </td>
|
||
<td>Segregated witness feature complete &amp; ready for general review</td>
|
||
<td><img src="/assets/images/ok-48.png" alt="delivered" title="delivered" /></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Mar 2016</td>
|
||
<td>0.12.1</td>
|
||
<td>Deploy OP_CHECKSEQUENCEVERIFY (BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">68</a> &amp; <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">112</a>) + <a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki">BIP113</a> as first <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> versionbits soft fork</td>
|
||
<td><img src="/assets/images/ok-48.png" alt="delivered" title="delivered" /></td>
|
||
</tr>
|
||
<tr>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td><a href="https://github.com/bitcoin/bitcoin/pull/7910">Segregated witness pull request</a></td>
|
||
<td><img src="/assets/images/ok-48.png" alt="delivered" title="delivered" /></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Oct 2016</td>
|
||
<td>0.13.1</td>
|
||
<td>Deploy segregated witness (including block size increase)</td>
|
||
<td><img src="/assets/images/ok-48.png" alt="delivered" title="delivered" /></td>
|
||
</tr>
|
||
<tr>
|
||
<td>2017</td>
|
||
<td> </td>
|
||
<td>Weak blocks and IBLT, Lightning, or both</td>
|
||
<td> </td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>Segregated witness testnet:</strong> a separate testnet (not part of the regular testnet) that provides an opportunity for Bitcoin Core contributors to test segregated witness and for wallet authors to begin working with it.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/secp256k1">Libsecp256k1</a> verification:</strong> 500% to 700% speed boost on x86_64 hardware during verification to help new full nodes join the network and to lighten the burden on existing nodes.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">OP_CHECKSEQUENCEVERIFY</a>:</strong> 25,000% improvement in bi-directional <a href="https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf">payment channel efficiency</a> by allowing users to keep channels open as long as they want.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">VersionBits</a>:</strong> increase the maximum number of soft forks able to be deployed simultaneously from 1 to 29, allowing for faster and more decentralized future upgrades of the network.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki">Segregated witness</a>:</strong> 175% to 400% direct capacity upgrade, 66% additional improvement in bi-directional channel efficiency by consolidating channel open and close operations, an end to third-party malleability that hurts smart contract deployment, fraud proofs to allow lightweight clients to better participate in economic enforcement, and ability to more easily upgrade Bitcoin’s Script language so that new and more powerful trustless contracts may be devised.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>IBLTs and weak blocks:</strong> 90% or more reduction in critical bandwidth to relay blocks created by miners who want their blocks to propagate quickly with a modest <a href="https://scalingbitcoin.org/hongkong2015/presentations/DAY1/3_block_propagation_1_rosenbaum.pdf">increase in total bandwidth</a>, bringing many of the benefits of the <a href="http://bitcoinrelaynetwork.org/">Bitcoin Relay Network</a> to all full nodes. This improvement is accomplished by spreading bandwidth usage out over time for full nodes, which means IBLT and weak blocks may allow for safer future increases to the max block size.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="segwit-size">Is the segregated witness soft fork equivalent to a 4 MB block size increase, a 2 MB increase, a 1.75 MB increase, or what? I keep hearing different numbers.</h2>
|
||
|
||
<p>The <a href="https://youtu.be/fst1IK_mrng?t=2234">current proposal</a> for soft fork segregated witness (segwit) replaces the block size limit with a new block <em>cost</em> limit, counting each byte of witness data as 1 unit of cost and UTXO transaction data as 4 units; as a result, the maximum size of a block becomes just under 4 MB.</p>
|
||
|
||
<p>However, blocks are not expected to consist entirely of witness data, so blocks near 4 MB in size would be unlikely.</p>
|
||
|
||
<p>According to some <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html">calculations</a> performed by Anthony Towns, a block filled with standard single-signature P2PKH transactions would be about 1.6 MB and a block filled with 2-of-2 multisignature transactions would be about 2.0 MB.
|
||
It is further likely that future scaling improvements, such as Lightning, may slightly improve the ratio such that filled blocks become larger than 2 MB.</p>
|
||
|
||
<h2 id="ecosystem-ready">Segregated witness sounds complicated; will the ecosystem be prepared for its deployment?</h2>
|
||
|
||
<p>Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.</p>
|
||
|
||
<p>Segwit can be deployed incrementally without breaking compatibility, so no significant preparation of the ecosystem is necessary. Developers who want immediate hands-on experience with segwit have begun to test their software on the segwit testnet deployed Dec 2015.</p>
|
||
|
||
<p>Initially, only miners who wish to support it need to upgrade in order to activate it and enforce it on the mainnet. Existing applications only need to change if they wish to take advantage of the new features and additional block space.</p>
|
||
|
||
<p>Segregated witness transactions will require lower fees, will afford much greater performance optimizations, and can support multistage smart contracts and protocols such as bi-directional payment channels that can scale without writing extra data to the blockchain. Wallets are strongly encouraged to upgrade but can continue to operate without modification as the deployment does not break backwards compatibility.</p>
|
||
|
||
<h2 id="size-bump">Segregated witness still sounds complicated. Why not simply raise the maximum block size?</h2>
|
||
|
||
<p>There’s a <a href="https://github.com/bitcoin/bitcoin/blob/3038eb63e8a674b4818cb5d5e461f1ccf4b2932f/src/consensus/consensus.h#L10">single line of code</a> in Bitcoin Core that says the maximum block size is 1,000,000 bytes (1 MB). The simplest code modification would be a hard fork to update that line to say, for example, 2,000,000 bytes (2 MB).</p>
|
||
|
||
<p>However, hard forks are anything but simple:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><strong>We don’t have experience:</strong> Miners, merchants, developers, and users have never deployed a non-emergency hard fork, so techniques for safely deploying them have not been tested.</p>
|
||
|
||
<p>This is unlike soft forks, whose deployments were initially managed by Nakamoto, where we gained experience from the complications in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki">BIP16</a> deployment, where we refined our technique in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki">BIP34</a> deployment, and where we’ve gained enough experience with BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">66</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki">65</a> to begin managing multiple soft forks with <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> version bits in the future.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Upgrades required:</strong> Hard forks require all full nodes to upgrade or everyone who uses that node may lose money. This includes the node operator, if they use it to protect their wallet, as well as lightweight clients who get their data from the node.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Other changes required:</strong> Even a single-line change such as increasing the maximum block size has effects on other parts of the code, some of which are undesirable. For example, right now it’s possible to construct a transaction that takes up almost 1 MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2 MB blocks, a 2 MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>Despite these considerable complications, with sufficient precautions, none of them is fatal to a hard fork, and we do expect to make hard forks in the future. But with segregated witness (segwit) we have a soft fork, similar to other soft forks we’ve performed and gained experience in deploying, that provides us with many benefits in addition to allowing more transactions to be added to the blockchain.</p>
|
||
|
||
<p>Segwit does require more changes in higher level software stacks than a simple block size increase, but if we truly want to see bitcoin scale, far more invasive changes will be needed anyway, and segwit will gently encourage people to upgrade to more scalable models right away without forcing them to do so.</p>
|
||
|
||
<p>Developers, miners, and the community have accrued significant experience deploying soft forks, and we believe segwit can be deployed at least as fast, and probably more securely, than a hard fork that increases the maximum block size.</p>
|
||
|
||
<h2 id="pre-segwit-fork">Will there be a hard fork before or as part of the segregated witness implementation?</h2>
|
||
|
||
<p>No. That is not part of the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html">roadmap</a>.</p>
|
||
|
||
<h2 id="why-not-now">If there’s eventually going to be a hard fork, why not do it now?</h2>
|
||
|
||
<p>We currently have the ability to increase the capacity of the system through soft forks that have widespread consensus without any of the complications of a hard fork, as described in an <a href="#size-bump">earlier question</a>, so the expectation that there will be an eventual hard fork is not sufficient reason to attempt one now.</p>
|
||
|
||
<p>In addition to giving us extra transaction capacity, the improvements proposed in the roadmap (combined with other technology such as bi-directional payment channels) give users the ability to reduce the amount of blockchain space they use on average—effectively increasing the capacity of the Bitcoin system without increasing the amount of full node bandwidth used.</p>
|
||
|
||
<p>For example,</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">BIP68</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki">BIP112</a> allow bi-directional payment channels to stay open indefinitely, which we expect to vastly reduce the number of payment channel transactions that need to be committed to the blockchain.</p>
|
||
</li>
|
||
<li>
|
||
<p>Segregated witness allows a payment channel close transaction to be combined with a payment channel open transaction, reducing the blockchain space used to change channels by about 66%.</p>
|
||
</li>
|
||
<li>
|
||
<p>Segregated witness allows soft forks to change the Bitcoin Script language in ways that could reduce the average size of a transaction, such as using public-key-recovery-from-signatures or Schnorr combined signatures.</p>
|
||
</li>
|
||
<li>
|
||
<p>Segregated witness permits the creation of compact fraud proofs that may bring the security of Simplified Payment Verification (SPV) lightweight clients up near to that of full nodes, which may allow the network to function well with fewer full nodes than it can under currently-deployed technology.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>The actual effect of these technologies is unknown, but scaling now with a soft fork that has wide consensus allows us to obtain the immediate gains, test and measure the mid-term possibilities, and use that data to formulate long-term plans.</p>
|
||
|
||
<h2 id="segwit-in-wallets">How will segregated witness transactions work for wallets?</h2>
|
||
|
||
<p>Wallets that currently support P2SH can migrate to full segregated witness in two phases:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Phase 1: Scripts are hashed twice, first to 256 bits and then to 160 bits. The 160 bit hash will be compatible with existing P2SH addresses, so upgraded wallets will be able to send and receive bitcoins to and from currently existing wallets.</p>
|
||
</li>
|
||
<li>
|
||
<p>Phase 2: Scripts are hashed once to 256 bits. This format will not be compatible with existing wallets but will allow more efficient use of block space and will offer better security due to greater collision resistance.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="why-upgrade">If no one is forced to upgrade, why will anyone bother to upgrade? I heard P2SH took almost two years to become widely deployed.</h2>
|
||
|
||
<p>Each byte of the witness part of a segregated witness (segwit) transaction will only count as 0.25 bytes towards the size of the transaction. Since transaction fees are based on the size of a transaction, this is effectively a 75% discount on fees for that part of a transaction—but only for people who use segwit.</p>
|
||
|
||
<p>David Harding provided a table of <a href="https://www.reddit.com/r/bitcoinxt/comments/3w1i6b/i_attended_scaling_bitcoin_hong_kong_these_are_my/cxtkaih">estimated savings</a> at various fee/transaction levels. That is, if the fee for a typical 250-byte transaction is $0.01 USD, using segwit will save about $0.003 when spending a P2PK-in-P2SH transaction output.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Transaction</th>
|
||
<th>Bytes saved</th>
|
||
<th>$0.01/250B</th>
|
||
<th>$0.05/250B</th>
|
||
<th>$0.25/250B</th>
|
||
<th>$1.00/250B</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>P2PK-in-P2SH</td>
|
||
<td>79/107</td>
|
||
<td>$0.003</td>
|
||
<td>$0.015</td>
|
||
<td>$0.079</td>
|
||
<td>$0.316</td>
|
||
</tr>
|
||
<tr>
|
||
<td>1-of-1 P2SH multisig</td>
|
||
<td>83/112</td>
|
||
<td>$0.003</td>
|
||
<td>$0.016</td>
|
||
<td>$0.083</td>
|
||
<td>$0.332</td>
|
||
</tr>
|
||
<tr>
|
||
<td>2-of-2 P2SH multisig</td>
|
||
<td>163/219</td>
|
||
<td>$0.006</td>
|
||
<td>$0.032</td>
|
||
<td>$0.163</td>
|
||
<td>$0.652</td>
|
||
</tr>
|
||
<tr>
|
||
<td>2-of-3 P2SH multisig</td>
|
||
<td>189/254</td>
|
||
<td>$0.007</td>
|
||
<td>$0.037</td>
|
||
<td>$0.189</td>
|
||
<td>$0.756</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>(We don’t expect fees to get as high as the highest seen in this table; they are just provided for reference.)</p>
|
||
|
||
<p>Web wallets and exchanges that send large numbers of transactions each day at fixed rates (such as for free or for 1% per spend) are expected to be early adopters—even the small savings per spend seen in the table above will add up to significant amounts of money if repeated hundreds or thousands of times a day.</p>
|
||
|
||
<h2 id="rbf">I heard you were breaking zero-confirmation transactions. Which technology in the scaling roadmap is doing that?</h2>
|
||
|
||
<p>None of them. By default, current versions of Bitcoin Core won’t replace an unconfirmed transaction with another transaction that spends any of the same inputs. Some people think this means the first transaction they see that spends a particular input is safe, but this is untrue. (If it were true, we wouldn’t need the blockchain.)</p>
|
||
|
||
<p>This current default policy does mean that people who want to be able to update their unconfirmed transactions can’t do that. The original version of Bitcoin provided people with a way to indicate that they wanted to be able to update their transactions, but Nakamoto had to disable it in 2010 to prevent denial-of-service (DoS) attacks.</p>
|
||
|
||
<p>Recent Bitcoin Core developers realized that they could prevent the DoS attack by requiring updated transactions pay extra fees, and they’ve re-enabled Nakamoto’s mechanism for indicating when a transaction can be replaced. This feature is planned for Bitcoin Core 0.12.0 (expected Jan/Feb 2016) but, like Nakamoto’s original feature, is opt-in so people who want to be able to replace their transactions have to use a wallet that supports that feature.</p>
|
||
|
||
<p>Currently there are no wallets that provide this feature, but wallets that do provide it in the future may be able to combine multiple transactions together to reduce the amount of blockchain space they use as well as increase the fees they pay on transactions that are taking a long time to confirm, helping to prevent transactions from getting “stuck” (a known usability problem).</p>
|
||
|
||
<h2 id="weak-blocks-iblts">Weak blocks and IBLTs just say “2016” in the roadmap schedule. Does this mean you have no idea when they’ll be available?</h2>
|
||
|
||
<p><a href="https://www.youtube.com/watch?v=ivgxcEOyWNs&amp;t=1h40m20s">Weak blocks and IBLTs</a> are two separate technologies that are still being <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/">actively studied</a> to choose the right parameters, but the number of developers working on them is limited and so it’s difficult to guess when they’ll be deployed.</p>
|
||
|
||
<p>Weak blocks and IBLTs can both be deployed as network-only enhancements (no soft or hard fork required) which means that there will probably only be a short time from when testing is completed to when their benefits are available to all upgraded nodes. We hope this will happen within 2016.</p>
|
||
|
||
<p>After deployment, both weak blocks and IBLTs may benefit from a simple non-controversial soft fork (<a href="https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions">canonical transaction ordering</a>), which should be easy to deploy using the <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki">BIP9</a> versionBits system described elsewhere in this FAQ.</p>
|
||
|
||
<h2 id="why-mine-segwit">“Why would miners adopt the SegWit format, given that it does not provide any savings of bandwidth, storage, or processing time to them?”</h2>
|
||
|
||
<p>Most <a href="https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki#classification-of-existing-bips">previous soft forks</a> have not provided these benefits to miners either. For example,</p>
|
||
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki">BIP16</a> (P2SH)</td>
|
||
<td>New transaction type</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki">BIP30</a> (duplicate txids)</td>
|
||
<td>Required checking for duplicate txids</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki">BIP34</a> (height in coinbase)</td>
|
||
<td>Reduced miner coinbase space by 4 bytes</td>
|
||
</tr>
|
||
<tr>
|
||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki">BIP65</a> (OP_CLTV)</td>
|
||
<td>New opcode</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>The <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">BIP66</a> (strict DER) soft fork which activated in July 2015 will soon be providing reduced processing time by making it possible to switch to libsecp256k1 for validation as described elsewhere in this FAQ. The reduced validation time makes it uncommon among soft forks in that it provides direct benefits to miners.</p>
|
||
|
||
<p>What segregated witness (segwit) does is provide several major benefits to anyone who uses it to create transactions:</p>
|
||
|
||
<p>A permanent fix for third-party malleability, allowing multi-stage smart contracts to flourish. A modest reduction in fees. Easy future upgrades to Bitcoin Script, so wallets can more easily gain access to new features.</p>
|
||
|
||
<p>Through the previous soft forks, and through conversations such as the <a href="https://youtu.be/H-ErmmDQRFs?t=1086">Miners’ Panel</a> at Scaling Bitcoin Hong Kong, miners have repeatedly shown that they want Bitcoin to be the most useful system possible even if they don’t receive any direct benefits. Segwit and the other improvements in the roadmap provide significant usability enhancements.</p>
|
||
|
||
<p>In addition, segwit allows miners to put more transactions in their blocks, which may allow them to increase their per-block revenue.</p>
|
||
|
||
<h2 id="how-can-i-help">How can I help?</h2>
|
||
|
||
<p>Start by reading the <a href="https://bitcoin.org/en/bitcoin-core/">Bitcoin Core contributor</a> pages on Bitcoin.org. In particular, <a href="https://bitcoin.org/en/development#code-review">code review</a> is a critical part of getting soft forks deployed.</p>
|
||
|
||
<p>To get specific suggestions on how you can help, please join the
|
||
<a href="https://webchat.freenode.net/?channels=bitcoin-dev&amp;uio=d4">#bitcoin-dev</a> IRC channel.</p>
|
||
|
||
</description>
|
||
<pubDate>Wed, 23 Dec 2015 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Capacity increases for the Bitcoin system</title>
|
||
<description><p>We, the undersigned, support the roadmap in <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html">Capacity increases for the Bitcoin system.</a> We have been working on scalability for several years within the Bitcoin Core project and consider this the best possible continuation of our efforts.</p>
|
||
|
||
<p>For more information, please see the <a href="/en/2015/12/23/capacity-increases-faq">FAQ</a>.</p>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/adam3us">Adam Back</a></li>
|
||
<li><a href="https://github.com/morcos">Alex Morcos</a></li>
|
||
<li><a href="https://github.com/apoelstra">Andrew Poelstra</a></li>
|
||
<li><a href="https://github.com/bpdavenport">Ben Davenport</a></li>
|
||
<li><a href="https://github.com/bgorlick">Ben Gorlick</a></li>
|
||
<li><a href="https://github.com/bramcohen">Bram Cohen</a></li>
|
||
<li><a href="https://github.com/kanzure">Bryan Bishop</a></li>
|
||
<li><a href="https://github.com/btcdrak">BtcDrak</a></li>
|
||
<li><a href="https://github.com/coblee">Charlie Lee</a></li>
|
||
<li><a href="https://github.com/carnesen">Chris Arnesen</a></li>
|
||
<li><a href="https://github.com/cdecker">Christian Decker</a></li>
|
||
<li><a href="https://github.com/cobra-bitcoin">Cøbra</a></li>
|
||
<li><a href="https://github.com/theuni">Cory Fields</a></li>
|
||
<li><a href="https://github.com/crwatkins">Craig Watkins</a></li>
|
||
<li><a href="https://github.com/arowser">Daniel</a></li>
|
||
<li><a href="https://github.com/domob1812">Daniel Kraft</a></li>
|
||
<li><a href="https://github.com/harding">David A. Harding</a></li>
|
||
<li><a href="https://github.com/DavidVorick">David Vorick</a></li>
|
||
<li><a href="https://github.com/devrandom">Dev Random</a></li>
|
||
<li><a href="https://github.com/dexX7">DexX7</a></li>
|
||
<li><a href="https://github.com/jrmithdobbs">Douglas Huff</a></li>
|
||
<li><a href="https://github.com/CodeShark">Eric Lombrozo</a></li>
|
||
<li><a href="https://github.com/ghtdak">Glenn H Tarbox</a></li>
|
||
<li><a href="https://github.com/gmaxwell">Gregory Maxwell</a></li>
|
||
<li><a href="https://github.com/instagibbs">Gregory Sanders</a></li>
|
||
<li><a href="https://github.com/jameshilliard">James Hilliard</a></li>
|
||
<li><a href="https://github.com/bityogi">Kawal Singh</a></li>
|
||
<li><a href="https://github.com/jmcorgan">Johnathan Corgan</a></li>
|
||
<li><a href="https://github.com/jl2012">Johnson Lau</a></li>
|
||
<li><a href="https://github.com/jonasschnelli">Jonas Schnelli</a></li>
|
||
<li><a href="https://github.com/Joukehofman">Jouke Hofman</a></li>
|
||
<li><a href="https://github.com/greenaddress">Lawrence Nahum</a></li>
|
||
<li><a href="https://github.com/lucayepa">Luca Venturini</a></li>
|
||
<li><a href="https://github.com/luke-jr">Luke Dashjr</a></li>
|
||
<li><a href="https://github.com/maaku">Mark Friedenbach</a></li>
|
||
<li><a href="https://github.com/FinalHash">Marshall Long</a></li>
|
||
<li><a href="https://github.com/martindale">Eric Martindale</a></li>
|
||
<li><a href="https://github.com/MarcoFalke">Marco Falke</a></li>
|
||
<li><a href="https://github.com/TheBlueMatt">Matt Corallo</a></li>
|
||
<li><a href="https://github.com/midnightmagic">Midnight Magic</a></li>
|
||
<li><a href="https://github.com/fanquake">Michael Ford</a></li>
|
||
<li><a href="https://github.com/btchip">Nicolas Bacca</a></li>
|
||
<li><a href="https://github.com/NicolasDorier">Nicolas Dorier</a></li>
|
||
<li><a href="https://github.com/obi">Obi Nwosu</a></li>
|
||
<li><a href="https://github.com/psztorc">Paul Sztorc</a></li>
|
||
<li><a href="https://github.com/pstratem">Patrick Strateman</a></li>
|
||
<li><a href="https://github.com/paveljanik">Pavel Janik</a></li>
|
||
<li><a href="https://github.com/sipa">Pieter Wuille</a></li>
|
||
<li><a href="https://github.com/randy-waterhouse">Randy Waterhouse</a></li>
|
||
<li><a href="https://github.com/nvk">Rodolfo Novak</a></li>
|
||
<li><a href="https://github.com/shangzhou">Shangzhou Wu</a></li>
|
||
<li><a href="https://github.com/sdaftuar">Suhas Daftuar</a></li>
|
||
<li><a href="https://github.com/theymos">Theymos</a></li>
|
||
<li><a href="https://github.com/afk11">Thomas Kerin</a></li>
|
||
<li><a href="https://github.com/wangchun">Wang Chun</a></li>
|
||
<li><a href="https://github.com/wtogami">Warren Togami</a></li>
|
||
<li><a href="https://github.com/laanwj">Wladimir J. van der Laan</a></li>
|
||
</ul>
|
||
|
||
<hr />
|
||
|
||
<p>Signatures may be added to bitcoincore.org pull request <a href="https://github.com/bitcoin-core/website/issues/53">#53</a></p>
|
||
|
||
</description>
|
||
<pubDate>Mon, 21 Dec 2015 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2015/12/21/capacity-increase/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2015/12/21/capacity-increase/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Segregated Witness Video Presentation</title>
|
||
<description><p>This is the extended presentation of Segregated Witness by Pieter Wuille.</p>
|
||
|
||
<iframe width="560" height="315" src="https://www.youtube.com/embed/NOYNZB5BCHM" frameborder="0"> </iframe>
|
||
</description>
|
||
<pubDate>Mon, 14 Dec 2015 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2015/12/14/segregated-witness/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2015/12/14/segregated-witness/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Capacity increases Roadmap for the Bitcoin system</title>
|
||
<description><p><em>The following roadmap was originally posted to the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html">bitcoin-dev mailing list</a>, by Gregory Maxwell on 2015-12-07.</em></p>
|
||
|
||
<p>The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating proposals were presented.
|
||
I think this would be a good time to share my view of the near term arc for capacity increases in the Bitcoin system.
|
||
I believe we’re in a fantastic place right now and that the community is ready to deliver on a clear forward path with a shared vision that addresses the needs of the system while upholding its values.</p>
|
||
|
||
<p>I think it’s important to first clearly express some of the relevant principles that I think should guide the ongoing development of the Bitcoin system.</p>
|
||
|
||
<p>Bitcoin is P2P electronic cash that is valuable over legacy systems because of the monetary autonomy it brings to its users through decentralization. Bitcoin seeks to address the root problem with conventional currency: all the trust that’s required to make it work–</p>
|
||
|
||
<p>– Not that justified trust is a bad thing, but trust makes systems brittle, opaque, and costly to operate.
|
||
Trust failures result in systemic collapses, trust curation creates inequality and monopoly lock-in, and naturally arising trust choke-points can be abused to deny access to due process.
|
||
Through the use of cryptographic proof and decentralized networks Bitcoin minimizes and replaces these trust costs.</p>
|
||
|
||
<p>With the available technology, there are fundamental trade-offs between scale and decentralization.
|
||
If the system is too costly people will be forced to trust third parties rather than independently enforcing the system’s rules.
|
||
If the Bitcoin blockchain’s resource usage, relative to the available technology, is too great, Bitcoin loses its competitive advantages compared to legacy systems because validation will be too costly (pricing out many users), forcing trust back into the system.
|
||
If capacity is too low and our methods of transacting too inefficient, access to the chain for dispute resolution will be too costly, again pushing trust back into the system.</p>
|
||
|
||
<p>Since Bitcoin is an electronic cash, it <em>isn’t</em> a generic database; the demand for cheap highly-replicated perpetual storage is unbounded, and Bitcoin cannot and will not satisfy that demand for non-ecash (non-Bitcoin) usage, and there is no shame in that.
|
||
Fortunately, Bitcoin can interoperate with other systems that address other applications, and–with luck and hard work–the Bitcoin system can and will satisfy the world’s demand for electronic cash.</p>
|
||
|
||
<p>Fortunately, a lot of great technology is in the works that make navigating the trade-offs easier.</p>
|
||
|
||
<p>First up: after several years in the making Bitcoin Core has recently merged libsecp256k1, which results in a huge increase in signature validation performance.
|
||
Combined with other recent work we’re now getting ConnectTip performance 7x higher in 0.12 than in prior versions. This
|
||
has been a long time coming, and without its anticipation and earlier work such as headers-first I probably would have been arguing for a block size decrease last year.
|
||
This improvement in the state of the art for widely available production Bitcoin software sets a stage for some capacity increases while still catching up on our decentralization deficit. This shifts the bottlenecks off of CPU and more strongly onto propagation latency and bandwidth.</p>
|
||
|
||
<p>Versionbits (BIP9) is approaching maturity and will allow the Bitcoin network to have multiple in-flight soft-forks. Up until now we’ve had to completely serialize soft-fork work, and also had no real way to handle a soft-fork that was merged in core but rejected by the network.
|
||
All that is solved in BIP9, which should allow us to pick up the pace of improvements in the network. It looks like versionbits will be ready for use in the next soft-fork performed on the network.</p>
|
||
|
||
<p>The next thing is that, at Scaling Bitcoin Hong Kong, Pieter Wuille presented on bringing Segregated Witness to Bitcoin.
|
||
What is proposed is a <em>soft-fork</em> that increases Bitcoin’s scalability and capacity by reorganizing data in blocks to handle the signatures separately, and in doing so takes them outside the scope of the current blocksize limit.</p>
|
||
|
||
<p>The particular proposal amounts to a 4MB blocksize increase at worst. The separation allows new security models, such as skipping downloading data you’re not going to check and improved performance for lite clients (especially ones with high privacy).
|
||
The proposal also includes fraud proofs which make violations of the Bitcoin system provable with a compact proof.
|
||
This completes the vision of “alerts” described in the “Simplified Payment Verification” section of the Bitcoin whitepaper, and would make it possible for lite clients to enforce all the rules of the system (under a new strong assumption that they’re not partitioned from someone who would generate the proofs).
|
||
The design has numerous other features like making further enhancements safer and eliminating signature malleability
|
||
problems. If widely used this proposal gives a 2x capacity increase (more if multisig is widely used), but most importantly it makes that additional capacity–and future capacity beyond it–safer by increasing efficiency and allowing more trade-offs (in particular, you can use much less bandwidth in exchange for a strong non-partitioning assumption).</p>
|
||
|
||
<p>There is a working implementation (though it doesn’t yet have the fraud proofs) at <a href="https://github.com/sipa/bitcoin/commits/segwit">https://github.com/sipa/bitcoin/commits/segwit</a>.</p>
|
||
|
||
<p>(Pieter’s talk is at: <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/">transcript</a>, <a href="https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/">slides</a>, <a href="https://www.youtube.com/watch?v=fst1IK_mrng#t=36m">Video</a>).</p>
|
||
|
||
<p>I had good success deploying an earlier (hard-fork) version of segwit in the Elements Alpha sidechain; the soft-fork segwit now proposed is a second-generation design. And I think it’s quite reasonable to get this deployed in a relatively short time frame.
|
||
The segwit design calls for a future bitcoinj compatible hardfork to further increase its efficiency–but it’s not necessary to reap most of the benefits,and that means it can happen on its own schedule and in a non-contentious manner.</p>
|
||
|
||
<p>Going beyond segwit, there has been some considerable activity brewing around more efficient block relay. There is a collection of proposals, some stemming from a p2pool-inspired informal sketch of mine and some independently invented, called “weak blocks”, “thin blocks” or “soft blocks”.
|
||
These proposals build on top of efficient relay techniques (like the relay network protocol or IBLT) and move virtually all the transmission time of a block to before the block is found, eliminating size from the orphan race calculation. We already desperately need this at the current block sizes. These have not yet been implemented, but fortunately the path appears clear.
|
||
I’ve seen at least one more or less complete specification, and I expect to see things running using this in a few months. This tool will remove propagation latency from being a problem in the absence of strategic behavior by miners. Better understanding their behavior when miners behave strategically is an open question.</p>
|
||
|
||
<p>Concurrently, there is a lot of activity ongoing related to “non-bandwidth” scaling mechanisms.
|
||
Non-bandwidth scaling mechanisms are tools like transaction cut-through and bidirectional payment channels which increase Bitcoin’s capacity and speed using clever smart contracts rather than increased bandwidth.
|
||
Critically, these approaches strike right at the heart of the capacity vs autotomy trade-off, and may allow us to achieve very high capacity and very high decentralization. CLTV (BIP65), deployed a month ago and now active on the network, is very useful for these techniques (essential for making hold-up refunds work); CSV (BIP68 / BIP112) is in the pipeline for merge in core and making good progress (and will likely be ready ahead of segwit).
|
||
Further Bitcoin protocol improvements for non-bandwidth scaling are in the works: Many of these proposals really want anti-malleability fixes (which would be provided by segwit), and there are checksig flag improvements already tendered and more being worked on, which would be much easier to deploy with segwit.
|
||
I expect that within six months we could have considerably more features ready for deployment to enable these techniques. Even without them I believe we’ll be in an acceptable position with respect to capacity in the near term, but it’s important to enable them for the future.</p>
|
||
|
||
<p><a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning">http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning</a> is a relevant talk for some of the wanted network features for Lightning, a bidirectional payment channel proposal which many parties are working on right now; other non-bandwidth improvements discussed in the past include transaction cut-through, which I consider a must-read for the basic intuition about how transaction capacity can be greater than blockchain capacity: <a href="https://bitcointalk.org/index.php?topic=281848.0">https://bitcointalk.org/index.php?topic=281848.0</a>, though there are many others.)</p>
|
||
|
||
<p>Further out, there are several proposals related to flex caps or incentive-aligned dynamic block size controls based on allowing miners to produce larger blocks at some cost.
|
||
These proposals help preserve the alignment of incentives between miners and general node operators, and prevent defection between the miners from undermining the fee market behavior that will eventually fund security.
|
||
I think that right now capacity is high enough and the needed capacity is low enough that we don’t immediately need these proposals, but they will be critically important long term.
|
||
I’m planning to help out and drive towards a more concrete direction out of these proposals in the following months.</p>
|
||
|
||
<p>(Relevant talks include <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/">http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/</a>.</p>
|
||
|
||
<p>Finally–at some point the capacity increases from the above may not be enough.
|
||
Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit’s increase).
|
||
Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them.
|
||
In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, to keep the basic software engineering from being the limiting factor.</p>
|
||
|
||
<p>Our recent and current progress has well positioned the Bitcoin ecosystem to handle its current capacity needs.
|
||
I think the above sets out some clear achievable milestones to continue to advance the art in Bitcoin capacity while putting us in a good position for further improvement and evolution.</p>
|
||
|
||
<p>TL;DR: I propose we work immediately towards the segwit 4MB block soft-fork which increases capacity and scalability, and recent speedups and incoming relay improvements make segwit a reasonable risk. BIP9 and segwit will also make further improvements easier and faster to deploy.
|
||
We’ll continue to set the stage for non-bandwidth-increase-based scaling, while building additional tools that would make bandwidth increases safer long term.
|
||
Further work will prepare Bitcoin for further increases, which will become possible when justified, while also providing the groundwork to make them justifiable.</p>
|
||
|
||
<p>Thanks for your time,</p>
|
||
|
||
<p><em>Originally posted to the bitcoin-dev mailing list at <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html</a>, by Gregory Maxwell on 2015-12-07</em></p>
|
||
</description>
|
||
<pubDate>Mon, 07 Dec 2015 00:00:00 -0500</pubDate>
|
||
<link>https://bitcoincore.org/en/2015/12/07/roadmap/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2015/12/07/roadmap/</guid>
|
||
</item>
|
||
|
||
<item>
|
||
<title>An Open Letter to the Bitcoin Community</title>
|
||
<description><p>As active contributors to Bitcoin, we share this letter to communicate our plan of action related to technical consensus and Bitcoin scalability.</p>
|
||
|
||
<p>Bitcoin is many things to many people. However, the development and maintenance of Bitcoin is a human endeavor. Satoshi sought review and cooperation, and the subsequent work by Bitcoin’s developers has made the system more secure and orders of magnitude faster. The Bitcoin developer community is dedicated to the future of Bitcoin, looks after the health of the network, strives for the highest standards of performance, and works to keep Bitcoin secure on behalf of everyone.</p>
|
||
|
||
<p>We’re committed to Bitcoin and responsive to the needs of the community. For the past five years, we’ve written code and managed over <a href="https://github.com/bitcoin/bitcoin/tree/master/doc/release-notes">50 Bitcoin releases</a> and reviewed more than <a href="https://github.com/bitcoin/bips">45 formal proposals</a> to improve Bitcoin’s performance, security, and scalability. Technical discussions, while heated at times, are always focused on improving Bitcoin.</p>
|
||
|
||
<p>Much work has already been done in this area, from substantial improvements in CPU bottlenecks, memory usage, network efficiency, and initial block download times, to algorithmic scaling in general. However, a number of key challenges still remain, each with many significant considerations and tradeoffs to evaluate. We have worked on Bitcoin scaling for years while safeguarding the network’s core features of decentralization, security, and permissionless innovation. We’re committed to ensuring the largest possible number of users benefit from Bitcoin, without eroding these fundamental values.</p>
|
||
|
||
<p>There will be controversy from time to time, but Bitcoin is a security-critical system with billions of dollars of users’ assets that a mistake could compromise. To mitigate potential existential risks, it behooves us all to take the time to evaluate proposals that have been put forward and agree on the best solutions via the consensus-building process.</p>
|
||
|
||
<p>In the upcoming months, two open workshops will bring the community together to explore these issues. The first <a href="https://scalingbitcoin.org/montreal2015/">Scaling Bitcoin workshop</a> will be in Montreal on September 12-13. The second workshop is planned for December 6-7 and will be hosted in Hong Kong to be more inclusive of Bitcoin’s global user base.</p>
|
||
|
||
<p>We ask the community to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops. It’s great to already see broad excitement for the event and the high concentration of technical participants attending.</p>
|
||
|
||
<p>We’re confident that by working together we can agree on the best course of action. We believe this is the way forward and reinforces the existing review process that has served the Bitcoin development community (and Bitcoin in general) well to date.</p>
|
||
|
||
<p>We welcome your participation as we continue our efforts to bring Bitcoin into the future.</p>
|
||
|
||
<p>Signed,</p>
|
||
|
||
<p>(List of Technical contributors who support this letter)</p>
|
||
|
||
<p>Wladimir J. van der Laan</p>
|
||
|
||
<p>Pieter Wuille</p>
|
||
|
||
<p>Cory Fields</p>
|
||
|
||
<p>Luke Dashjr</p>
|
||
|
||
<p>Jonas Schnelli</p>
|
||
|
||
<p>Jorge Timón</p>
|
||
|
||
<p>Greg Maxwell</p>
|
||
|
||
<p>Eric Voskuil</p>
|
||
|
||
<p>Amir Taaki</p>
|
||
|
||
<p>Dave Collins</p>
|
||
|
||
<p>Michael Ford</p>
|
||
|
||
<p>Peter Todd</p>
|
||
|
||
<p>Phillip Mienk</p>
|
||
|
||
<p>Suhas Daftuar</p>
|
||
|
||
<p>R E Broadley</p>
|
||
|
||
<p>Eric Lombrozo</p>
|
||
|
||
<p>Daniel Kraft</p>
|
||
|
||
<p>Chris Moore</p>
|
||
|
||
<p>Alex Morcos</p>
|
||
|
||
<p>dexX7</p>
|
||
|
||
<p>Warren Togami</p>
|
||
|
||
<p>Mark Friedenbach</p>
|
||
|
||
<p>Ross Nicoll</p>
|
||
|
||
<p>Pavel Janík</p>
|
||
|
||
<p>Josh Lehan</p>
|
||
|
||
<p>Andrew Poelstra</p>
|
||
|
||
<p>Christian Decker</p>
|
||
|
||
<p>Bryan Bishop</p>
|
||
|
||
<p>Benedict Chan</p>
|
||
|
||
<p>฿tcDrak</p>
|
||
|
||
<p>William Swanson</p>
|
||
|
||
<p>Charlie Lee</p>
|
||
|
||
<p>Jeremy Rubin</p>
|
||
|
||
<p>Esteban Ordano</p>
|
||
|
||
<p>Manuel Araoz</p>
|
||
|
||
<p>Ruben de Vries</p>
|
||
|
||
<p><strong>Further signatures can be found at <a href="https://www.change.org/p/the-community-an-open-letter-to-the-bitcoin-community">change.org</a>.</strong></p>
|
||
|
||
<p><em>This letter was originally published in Bitcoin Magazine on 1st September 2015 at <a href="https://bitcoinmagazine.com/articles/open-letter-bitcoin-community-developers-1441146317">https://bitcoinmagazine.com/articles/open-letter-bitcoin-community-developers-1441146317</a>.</em></p>
|
||
|
||
</description>
|
||
<pubDate>Tue, 01 Sep 2015 00:00:00 -0400</pubDate>
|
||
<link>https://bitcoincore.org/en/2015/09/01/open-letter/</link>
|
||
<guid isPermaLink="true">https://bitcoincore.org/en/2015/09/01/open-letter/</guid>
|
||
</item>
|
||
|
||
</channel>
|
||
</rss>
|