Bitcoin Forum

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)

---

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.

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.

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.

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.

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.

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 (https://github.com/bitcoin/bitcoin/pull/14247) simply disables the optimization, changing a false to a true.

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.

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.

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

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


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.

This is well-addressed by the verification procedures you should follow (https://bitcointalk.org/index.php?topic=1588906.0).


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



 

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.

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

what i thought had happen is they compile the file do a sha256 hash on it to verify the file integrity and post the file and the sha256 hash on the same site, we download the file and re run the same sha256 hash on and verify the hash to make sure they match is what i thought was happening. Meaning any hacker could do the same. Hack the file rehash output and post on the site.

That is why i was saying don't place the key/file in same location.

Icon

Virustotal says:

http://screenshot.ru/eae106bacd9b7ea9aaa1116e03d9fc4b.png

 ???

Dr.Web on my Windows PC swears too on this file...

So as 360 Total Security does not like "bitcoin-0.16.3-win64-setup.exe" file. It found 2 viruses after installation of this new version.

SHA-256 checksums are OK in both cases.

Those are not viruses, those are false positives. Most AV programs are essentially scams FYI.

It's a false positive. Antivirus software frequently false positive on Bitcoin Core because it contains code that is found in malware. Namely, it looks for and opens a wallet.dat file (because it is the thing that makes it in the first place and uses it for your wallet), and it contains bitcoin mining code (it does, but that can only be used on regtest). However, many coin stealing malware look for a wallet.dat file. And other malware will mine cryptocurrencies without you knowing. Since Bitcoin Core can do both of those things, it is usually flagged as being malware when it really is not.

Please report the malware false positive.  False positives have also happened because there have been several public campaigns in an altcoin forum to report the bitcoin software as malware. :(

There was actually more to the bug than just a DoS vulnerability. It allowed for inflation. Users MUST upgrade now.

Full disclosure is available here: https://bitcoincore.org/en/2018/09/20/notice/

The reason this has been disclosed after such a short notice is because someone has independently discovered these vulnerabilities and posted about them publicly on Hacker News.

This ?

Yes

Then you are at risk of being attacked and could possibly accept an invalid block. You could be made to believe that some coins exist which do not actually exist. You are at risk of being defrauded if you perform any transactions. You are at risk of being forked onto a different blockchain than the rest of the Bitcoin network.

This question does not make sense.

can all core fans now admit core are not perfect and diverse teams of multiple code bases all on the network as a consensual level playing field would have been beneficial than the monarchy core has became

expect drama similar to last years assert() but this time core being on the receiving end
and may core react as the opposite side of the argument of last years assert() drama last year

its time the community admit, its time to diversify the network and release core from a leadership(reference) position

diversity + distribution = decentralised network
distribution alone does not = decentralisation

(expect my post to get deleted as its not core friendly)

Awemany - Discovery and disclosure author (Bitcoin Cash developer)
https://medium.com/@awemany/600-microseconds-b70f87b0b2a6

And it is already being used by this idiot to spread propaganda:


We should thank him for not breaking the law? ::)

---

He can't face the fact that he is significantly less competent than even the least competent Core developers. That's his problem. He's a sad, bitter and definitely pathetic, developer (based off of this article) who got a little lucky. :-*

No, because code is law on cryptocurrencies.

firstly some do not wish to protect and defend the network, some only wishes to protect a team of developers
i find it funny in that regard as the proof is clear when you look at some attitudes about the assert ddos bug of yesteryear compared to the block ddos assert bug this year.

neither of which did some sound like network defending arguments.. but sounded like arguments to why some want to hug a core dev and smother them with affection

one day, its been 3 years so far some will learn about the the network concepts of consensus and decentralisation that have become lost, and hopefully learn that when devs retire the network should live on and that caring about a certain dev is a meaningless pursuit as it does not help the network

if people cared for the network more than a certain dev. they too would actually want
diversified codebases in consensus and decentralised
instead of a
monarchy 'reference' codebase and distribution.
as the two concepts are vastly different


but hey. some has a long way to go yet. and many have tried reminding them to learn about the network and code protocols but stil see some only reply protecting developers


*i removed names in replacement for 'some' to avoid the auto reply of the ad-hom buzzword, of which has been a over utilised defensive argument to avoid addressing the content about caring for the network more than a developer point of my post. if anyone feels that 'some' equals them. than do not reply just realise that they have just confirmed to themselves that they care more about a developer than the network and thus no point trying to reply to sway that argument. as replying is just confirming it more. i also greyed out this statement to ensure some really concentrate on the care of the network content of which we should all want diverse codebases instead of a monarchy codebase. rather than have some reply only to rply with persona attack defense posts that distract the point about the network

Then why don't you start developing your own implementation or start running one of the other implementations available? I heard Mircea Popescu's "The Real Bitcoin" is the closest to "Satoshi's Bitcoin".

Plus we care enough for the network to support the best developers. But they are human, and maybe they also deserve some criticism for leaving a bug unseen for that long. It should also be taken as a sign that smart developers like you, franky1, should keep an eye on the code. 8)


https://i.imgflip.com/2/ttabf.jpg

that has been tried for years by other teams that wanted a united network of multiple implementations (not altcoins)
all using real consensus to activate their proposals or just plodding along.. using current consensus rules if no majority preference is seen... not using mandatory bilateral split bips

end result were endless REKT campaigns and 'go F**k off, and "your not wanted here" statements
(ill let you decide if ** = UC or OR)

having the mindset that xt, classic, bu and (as theymos shows in other topic) btcd and other implementations should not run on the network.. shows how defensive and core cuddling some people are.

i did find it funny that theymos in the midst or a core bug was still saying other nodes that did not have the bug, were buggy..

i did try to keep this topic away from certain people replying. but that certain kitty in sunglasses must not have read the grey writing

anyway, moving on


i do read and review their code. but my interest is more in looking for issues that change the bitcoin networks purpose. not to debug a codebase i do not use

i have though informed them of bugs before. i can even remember achowe and myself arguing for months about the 'anyone can spend' issue pre segwit if using segwit transactions before activation
and eventually and funnily enough. core eventually without admission succumbed to the realisation and they done a work around by not letting people actually make a segwit formatted tx until weeks after it was activated. to ensure the issue i addressed would not occur. (though he will not admit remembering such conversations nor my input had any impact on that workaround yet forum post dates and quotes can be found)
its also why segwit would have only worked with 100% segwit compliance instead of their weak 35% flag.. but thats been discussed endlessly in other topics about their methods of getting 100% compliance

so moving on

 i personally do run my own node and it has not crashed and does not have that bug and it's my own code. because i did not use c++, thus i did not just copy and paste it from core.
it was wrote from scratch and does validate transactions and does validate blocks and relays transactions and blocks but i say this
(pre-empting  standard core defence replies)
 it is not xt,classic,bu, abc based either. nor am i part of the cash group.
i am independent and believe in a diverse network of multiple teams that use consensus as it should be used
certain some who again are defending core by thinking diverse codebases being on the same network are the enemy. will not tolerate such sacrilegious code. so i just use it for myself, happily

again lets keep this about the network diversity and not the picking of names and insulting (i know, they poked the bear and i bit. but lets get back to concentrating on the matter at hand)

---

edit to avoid spam but address the comment below ill repeat whats already been said:
certain some who again are defending core by thinking diverse codebases being on the same network are the enemy. will not tolerate such sacrilegious code. so i just use it for myself, happily

that has been tried for years by other teams that wanted a united network of multiple implementations (not altcoins)
all using real consensus to activate their proposals or just plodding along.. using current consensus rules if no majority preference is seen... not using mandatory bilateral split bips

end result were endless REKT campaigns and 'go F**k off, and "your not wanted here" statements
(ill let you decide if ** = UC or OR)

having the mindset that xt, classic, bu and (as theymos shows in other topic) btcd and other implementations should not run on the network.. shows how defensive and core cuddling some people are.

If it was based on any newer Core version it would have the bug. Sounds like you are clearly lying. Where is this magical implementation? If you were pro-diversity, you'd publish the code. Hint: You aren't; you are just a pathetic troll.

---

Wind_FURY please stop indulging the idiot.

question translated:
Is Bitcoin stored in the Core wallet?
I mean how is the upgrade as urgent, no one can access my private key properly?

answer:
Bitcoin is stored on the blockchain. Your wallet is for your private key.
bitcoin-core is software that connects two parts

This error does not affect your wallet.

If people need to upgrade but not upgrade then. If a mining exploit block occurs, they will get it and send it to someone causing the problem to some people.

If no one is vulnerable to software attacks. Then an exploited block is ignored by everyone


If a block uses malicious exploits:
This error can cause any new transaction to appear as confirmation and then not confirmed.
As well as the ability to create more fake btc appear,
but only if someone can exploit a block and only lasts until the exploited blocks are deleted.

answer translated:
Bitcoin được lưu trữ trên blockchain. Ví của bạn là dành cho khóa riêng của bạn.
bitcoin-core là phần mềm kết nối hai phần

Lỗi này không ảnh hưởng đến ví của bạn.


Nếu mọi người cần nâng cấp nhưng không nâng cấp thì. Nếu một khối khai thác khai thác xảy ra, họ sẽ nhận được nó và gửi nó cho ai đó gây ra vấn đề cho một số người.

Nếu không ai dễ bị tấn công phần mềm. Sau đó, một khối bị khai thác bị bỏ qua bởi tất cả mọi người

Nếu một khối sử dụng khai thác độc hại:
Lỗi này có thể khiến bất kỳ giao dịch mới nào xuất hiện dưới dạng xác nhận và sau đó không được xác nhận.
Cũng như khả năng tạo thêm btc giả mạo xuất hiện,
nhưng chỉ khi ai đó có thể khai thác một khối và chỉ cho đến khi các khối bị khai thác bị xóa.

(excuse any broken vietnamese i speak english and used google translate to vietnamese)

these two are completely different arguments though.
implementations such as XT, classic,... were planning on enforcing (eventually) different consensus rules and they were created because certain people didn't want SegWit and wanted bigger blocks. if there were no SegWit or bigger blocks then these implementations wouldn't have existed at all. that is one thing. not to mention that they were forks (copies) of bitcoin core so that is not even related to this discussion because technically since they copied the code they would have had the same bugs.

another thing which is what @ETFbitcoin is talking about is having other clients that do enforce and continue to enforce the same consensus rules. there currently are other implementations (https://bitcointalk.org/index.php?topic=199306.0). it is not like they don't exist at all but not many use them.

The bug is very serious. I suggest that for at least one month we all put a signature message to remind that everyone should upgrade. I already did it  ;)

If you have used the bitcoin code for your altcoin then you gotta upgrade as well

Bitcore is completely unrelated to Bitcoin Core. Questions about bitcore are off topic for this thread.

I downloaded the BTC blockchain and created a couple of wallets with the new version on a USB hard drive. I ran a few mined coins through the wallets and into CoinBase with no problems.

The trouble began when I inadvertently unplugged the hard drive. This is my second day attempting to recover the blockchain. Actually the first attempt resulted in a disk error and scan which was pretty fast but now it seems that I'm having to download the whole blockchain again which of course takes a day or so.

I'm hoping that my wallets are still intact after recovery. I have two workers pointed at those wallets so I am curious to see if the coins mined during the down time will be there.

I also wonder what happens if I ever shut down the node on purpose. I am assuming the wallets will be there but will I have to download the whole damn chain when I restart Core?

I would recommend against using USB drives for the blockchain. You are more likely to run into database corruption errors and accidentally corrupt the database by prematurely unplugging the drive (as you have done).

If you are able to start Bitcoin Core with those wallets, then the wallets should be fine. Of course, you should double check that the private keys are correct by signing and verifying a few messages with your addresses.

A wallet does not need to be online in order to receive Bitcoin.

Bitcoin Core requires downloading and verifying the blockchain to work. The blockchain can be pruned, in which case blocks are discarded after they have been verified and area few hundred blocks deep into the blockchain. If you do not have a copy of the blockchain, it will need to be redownloaded.

Am I reading this right... 0.17.0 has just been released?

https://github.com/bitcoin/bitcoin/releases/tag/v0.17.0

It has been tagged and will be released in the next few days. The releases occur a few days after the tag is made so that the deterministic builds are done.

What about Bitcoin having like 11 forks?

Developers of every single fork will have to take care of that issue on their own. Litecoin, which is a fork of Bitcoin, has already got its client patched. I wouldn't expect any reaction from the developers of, for example, Bitcoin Diamond, Emerald and any other Bitcoin clone which nobody uses.

@achow101 Do you happen to know why the minimum transaction fee is going to be lowered in the 0.18 release and not in the 0.17 one?

The PR for that change was too close to the 0.17 branch off date and it did not have sufficient review to be merged.

Bitcoin Core 0.17.0 has been released (https://bitcointalk.org/index.php?topic=5043017.0)