Bitcoin Core 0.16.3 Released

[achow101]

Bitcoin Core version 0.16.3 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.16.3/>

This is a new minor version release, with various bugfixes.

Please report bugs using the issue tracker at GitHub:

  <https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <https://bitcoincore.org/en/list/announcements/join/>

How to Upgrade
==============

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or newer, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
-------------------

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. Existing
wallets that were created with older versions are not affected by this.

Compatibility
==============

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===============

Denial-of-Service vulnerability
-------------------------------

A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has
been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended
to upgrade any of the vulnerable versions to 0.16.3 as soon as possible.

0.16.3 change log
------------------

### Consensus
- #14249 `696b936` Fix crash bug with duplicate inputs within a transaction (TheBlueMatt, sdaftuar)

### RPC and other APIs
- #13547 `212ef1f` Make `signrawtransaction*` give an error when amount is needed but missing (ajtowns)

### Miscellaneous
- #13655 `1cdbea7` bitcoinconsensus: invalid flags error should be set to `bitcoinconsensus_err` (afk11)

### Documentation
- #13844 `11b9dbb` correct the help output for -prune (hebasto)

Credits
=======

Thanks to everyone who directly contributed to this release:

- Anthony Towns
- Hennadii Stepanov
- Matt Corallo
- Suhas Daftuar
- Thomas Kerin
- Wladimir J. van der Laan

And to those that reported security issues:

- (anonymous reporter)

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

0768c6c15caffbaca6524824c9563b42c24f70633c681c2744649158aa3fd484  bitcoin-0.16.3-aarch64-linux-gnu.tar.gz
fb2818069854a6ad20ea03b28b55dbd35d8b1f7d453e90b83eace5d0098a2a87  bitcoin-0.16.3-arm-linux-gnueabihf.tar.gz
75a537844313b0a84bdb61ffcdc5c4ce19a738f7ddf71007cd2edf664efd7c37  bitcoin-0.16.3-i686-pc-linux-gnu.tar.gz
78c3bff3b619a19aed575961ea43cc9e142959218835cf51aede7f0b764fc25d  bitcoin-0.16.3-osx64.tar.gz
c67e382b05c26640d95d8dddd9f5203f7c5344f1e1bb1b0ce629e93882dbb416  bitcoin-0.16.3-osx.dmg
836eed97dfc79cff09f356e8fbd6a6ef2de840fb9ff20ebffb51ccffdb100218  bitcoin-0.16.3.tar.gz
1fe280a78b8796ca02824c6e49d7873ec71886722021871bdd489cbddc37b1f3  bitcoin-0.16.3-win32-setup.exe
e3d6a962a4c2cbbd4798f7257a0f85d54cec095e80d9b0f543f4c707b06c8839  bitcoin-0.16.3-win32.zip
bd48ec4b7e701b19f993098db70d69f2bdc03473d403db2438aca5e67a86e446  bitcoin-0.16.3-win64-setup.exe
52469c56222c1b5344065ef2d3ce6fc58ae42939a7b80643a7e3ee75ec237da9  bitcoin-0.16.3-win64.zip
5d422a9d544742bc0df12427383f9c2517433ce7b58cf672b9a9b17c2ef51e4f  bitcoin-0.16.3-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJboV68AAoJEJDIAZ42wulkrD0P/iULbLc7SRAXPPaQDxRV+nXO
bTOF3Ueti1hOY9/02drnfd5z2HNYuZGJvL4t5UuVrSM/KGPbwMNPq0MLoVqp0z91
yWCPTUdbjnvstJ5maFSZ3EHHrmKKR/8Ue6VVT1rDwZHTjKSUMli05QhRWsQsGgdp
gVrCId/572xJw9R7QGtcatoP1Y+LpDf3PGsfSn7YLzezvXMDjrgYAXaW/QYPbl5I
+vGSmNPhjnQpatVgg7OnLgyCAul7Rqq898MURpAboMC7qgbsINZ4UVha0IqFPWt9
HS9z84wtOsV69gDro5BpgtMSXjvjdTAOs9wq+VGgxfZf1K3kFZ6zVmrP/Ea/HJKV
WbIYNyvW/bnK/GA2gfciqmjAL0xjhWnCzBdrFSbIAHbfoHIOeSw2TSJ90Oiqb1ch
cgIWZpEzoteVtMEoSOhCiPFHEAYOO8DiBkqLUgc0CkkcXfffeQEO/OvqGOJe1zAo
O1sWR/na0d9qv4qVK/jNCKIHjtF24npdqgdDjyKdMOGBkS1pgSGwkH8Hd7cffJJm
LZswdRm2rEmchmqhVXwvYRlmU5nhAyb2GrW5g78DyTPbKCO+z7ejYfM7h6YQQHS3
Y1x/vMdf092djWF0jvr52WtbPfcYL9OCWgTB6LLlXhfPhqPUoiYzcFIO2obRwXR1
FZnWhOUcfsVHgmbN1g6b
=/Gqy
-----END PGP SIGNATURE-----

[1714785165]

1714785165

[1714785165]

1714785165

[1714785165]

1714785165

[vit05]

Denial-of-Service vulnerability
-------------------------------

A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has
been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended
to upgrade any of the vulnerable versions to 0.16.3 as soon as possible.

Can anyone explain in an Eli5 exactly what this means?  Does "exploitable" mean that this possibility existed or was exploited? And that leaves the various forks of this last year at risk, doesn't it? I doubt they have the ability to fix it so fast until someone can exploit it.

[achow101]

Can anyone explain in an Eli5 exactly what this means?

If a node running Bitcoin Core from versions 0.14.0 to 0.16.2, receives a block that contains a transaction that has a duplicate input, that node will crash.

Does "exploitable" mean that this possibility existed or was exploited?

It means that the vulnerability currently exists and Bitcoin Core versions 0.14.0 to 0.16.2 and could be exploited by anyone who has enough hashrate to mine a block. There are no known instances of it actually being exploited.

And that leaves the various forks of this last year at risk, doesn't it? I doubt they have the ability to fix it so fast until someone can exploit it.

The person who reported this reported it to other projects as well, including BCH node software Bitcoin ABC. They have fixed this bug, however I do not know if other fork coins have as well.

[DeathAngel]

Are bitcoin’s stored in Core wallets safe?
I mean how urgent is the upgrade, nobody can access my private keys right?

[cellard]

Are bitcoin’s stored in Core wallets safe?
I mean how urgent is the upgrade, nobody can access my private keys right?

There's a sticky about this in the News section by theymos:

https://bitcointalk.org/index.php?topic=5032443.0

I had a small heart attack because the part in bold that says "Stored funds are not at risk." I did read as "Stored funds are at risk." and I was tripping.

Of course, I also realized I don't have my wallet online with the node so still I should be ok, but if someone managed to steal funds from wallet.dats it would be a disaster nontheless. Luckily this seems to be none of that.

[BitHodler]

but if someone managed to steal funds from wallet.dats it would be a disaster nontheless. Luckily this seems to be none of that.

If someone manages to empty your wallet.dat file then it's your fault entirely for being exposed to external risks, and not the bug that has been discovered. The bug only causes your client to crash, nothing more nothing less.

I completed the upgrade of my potentially vulnerable client, thanks for the heads-up. If these updates weren't conveniently placed on top of the forum page it would probably take a while before people actually know what's going on.

[pooya87]

Can anyone explain in an Eli5 exactly what this means?

If a node running Bitcoin Core from versions 0.14.0 to 0.16.2, receives a block that contains a transaction that has a duplicate input, that node will crash.

how can a transaction have a duplicate input? can you give an example also point us to its PR on github?

[theymos]

how can a transaction have a duplicate input? can you give an example also point us to its PR on github?

Such a transaction is invalid, so you won't find any examples in the block chain. But Bitcoin Core crashes upon detecting its invalidness in a valid-PoW block (not when the transaction is free-floating). The crash is caused by an optimization which had incorrect assumptions; the fix simply disables the optimization, changing a false to a true.

[achow101]

If the node is crashed, then is it possible that the blockchain/chainstate corrupted? It would be suck for those who use older version and use HDD if someone decide to use the exploit.

It is unlikely as those issues were identified as bugs a while ago (around 0.10 or 0.11 IIRC) and fixed. If the process dies or is killed, starting it again should have it pick up where it stopped (or very near it) and not require a reindex. For several major versions now, I have been able to kill bitcoind (using sudo kill -9 so it actually kills it with SIGKILL) and have it be fine when it starts back up again.

[jackleszz]

Would have been wiser not to reveal how it can be exploited, because it will take a while for nodes to upgrade.

[Lauda]

Would have been wiser not to reveal how it can be exploited, because it will take a while for nodes to upgrade.

It would have been wiser to keep your mouth shut. As soon as it was patched publicly, anyone with some understanding of the protocol and codebase knew how to exploit it. Therefore, revealing is a direct consequence of patching.

[jackleszz]

Would have been wiser not to reveal how it can be exploited, because it will take a while for nodes to upgrade.

As soon as it was patched publicly, anyone with some understanding of the protocol and codebase knew how to exploit it. Therefore, revealing is a direct consequence of patching.

Still, just telling it to programmers who are familiar with the codebase or bother checking it is different from telling it to everyone. Anyway, I guess for the sake of transparency it's a good thing and it will just motivate people to upgrade faster if someone does exploit it so not such a big deal.

edit: After checking the code, yes it's obvious to programmers who either remembered what the change would do or checked what it does.

[Lauda]

Would have been wiser not to reveal how it can be exploited, because it will take a while for nodes to upgrade.

As soon as it was patched publicly, anyone with some understanding of the protocol and codebase knew how to exploit it. Therefore, revealing is a direct consequence of patching.

That false to true change alone didn't tell that. The github comments did. Anyway, I guess for the sake of transparency it's a good thing and it will just motivate people to upgrade faster if someone does exploit it so not such a big deal.

It did. Read the bolded part. Please go away from this thread and refrain from creating more misleading posts.

[Icon]

Just a suggestion for safety safe, don't put the sha256 sigs on the same ftp/host as the files. That way if the files do get hacked the hacker cant alter the sha256 sigs too.

Icon

[cellard]

So we don't need to delete the chainstate folder before opening the new update?

Just a suggestion for safety safe, don't put the sha256 sigs on the same ftp/host as the files. That way if the files do get hacked the hacker cant alter the sha256 sigs too.

Icon

Good point. I think devs should separately put sha256 hashes on their twitter or in here or just in as many separate places as possible so then it's impossible that a hacker gets away with it since he would need to have control on all these different points of failure.

Some altcoin devs put hashes on github release page too but for bitcoin i can't find it.

[theymos]

Just a suggestion for safety safe, don't put the sha256 sigs on the same ftp/host as the files. That way if the files do get hacked the hacker cant alter the sha256 sigs too.

This is well-addressed by the verification procedures you should follow.

So we don't need to delete the chainstate folder before opening the new update?

No, deleting old stuff is never necessary. If any adjustments are necessary, the new version will do it for you.

[Icon]

Just a suggestion for safety safe, don't put the sha256 sigs on the same ftp/host as the files. That way if the files do get hacked the hacker cant alter the sha256 sigs too.

This is well-addressed by the verification procedures you should follow.

So we don't need to delete the chainstate folder before opening the new update?

No, deleting old stuff is never necessary. If any adjustments are necessary, the new version will do it for you.

Theymos, what i was referring to is seeing you keep the sig and the file in the same location, what is keeping a hacker for rehashing the key after he hacks the client and reposting his version of the sha256 sig file?

Seeing we are verifying the sig from the same site as the file. Its like locking your house and placing the house key under your welcome mat.  The file and sig are too close together.

Icon



 

[achow101]

Theymos, what i was referring to is seeing you keep the sig and the file in the same location, what is keeping a hacker for rehashing the key after he hacks the client and reposting his version of the sha256 sig file?

Seeing we are verifying the sig from the same site as the file. Its like locking your house and placing the house key under your welcome mat.  The file and sig are too close together.

Icon

The sig indicates who signed it though. The attacker can only do this successfully if he is able to compromise Wladimir and get the signing key from him. Otherwise, replacing the sums file and the sig with his own versions will either result in an invalid sig, or a sig from the wrong key. When users verify the download, they should be checking that the downloaded binary's sha256 matches, that the signature for the sums file is valid, and that the key that made the signature is Wladimir's release signing key.

[Icon]

OOo so its not like an md5 hash then? Thought it was in that case we are all good

Sorries still a noobz

Icon

[pooya87]

OOo so its not like an md5 hash then? Thought it was in that case we are all good

Sorries still a noobz

Icon

note that hashes (SHA256, MD5,...) are different from signatures (PGP). those hashes are like checksums of the files. they don't prove anything on their own. them combined with PGP are what you are looking for and PGP has 3 parts. the first is the public key that you download and save as below, second is the file, third is the signature of the file. or at least these hashed signed with a PGP key that you trust.

the whole  concept is mainly based on something called Web of Trust[1] that you need to build for yourself. which is basically you building a list of PGP public keys that you trust. for example what you do in case of bitcoin core, you try different sources to get the keys[2][3][4], if you have a friend that you trust you call him up on the phone and ask him to send you the keys over Email, or physical main,... or sign them with his own key that you already have the pubkey to. then when you added the key to your list, from that point you don't worry about hacks,... you can simply download the file + provided signature and verify if the file was signed with the real keys or not.

[1] https://en.wikipedia.org/wiki/Web_of_trust
[2] https://bitcointalk.org/verify_pubkeys.txt
[3] https://bitcoincore.org/en/download/ (01EA5486DE18A882D4C2684590C8019E36C2E964 at the bottom)
[4] https://www.reddit.com/r/Bitcoin/wiki/pgp_keys