If you are running an older version, shut it down. Wait until it has completelyshut down (which might take a few minutes for older versions), then run theinstaller (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 anew 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 noautomatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgradingdirectly 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.16and will not work if you try to use newly created wallets in older versions. Existingwallets that were created with older versions are not affected by this.

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

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

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

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

A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners hasbeen discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommendedto 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.