Bitcoin Core
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&uio=d4″>web</a>) and we’ll do our best to help you.</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>
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&uio=d4″>web</a>) and we’ll do our best to help you.</p>
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&uio=d4″>web</a>) and we’ll do our best to help you.</p>
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>
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>
<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>
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>
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>
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>
<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=<path></code> option where <code class=”highlighter-rouge”><path></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:
* 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).
* The existing field <code class=”highlighter-rouge”>isscript</code> will now also report True for P2WSH addresses.
* 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.
* 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.
* 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.</p>
<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=<file></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->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>
<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>
<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>
<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 "increase transaction fee" 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>
<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>
<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>
<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>
<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>
<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 & 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 & 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>
<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.linuxfoundat
Published at
