Awemany - Discovery and disclosure author (Bitcoin Cash developer)
https://medium.com/@awemany/600-microseconds-b70f87b0b2a6
Topic: Bitcoin Core 0.16.3 Released - page 2. (Read 2376 times)
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)
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)
Sorry I don't understand, I'm having trouble updating to bitcoin core version 0.16.3. what if I don't update to that version?
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.does it affect my comments?
This question does not make sense. This ?
Yes Quote
There appears to be a workaround to bypass the assert check in Bitcoin Core 0.16 that allows one to mint new coins by using an input multiple times and it be accepted by the network without crashing. Probably will be waiting until the dust settles on this before publishing that test case though, since it's clearly much more severe than a DoS
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.
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 ?
Quote
There appears to be a workaround to bypass the assert check in Bitcoin Core 0.16 that allows one to mint new coins by using an input multiple times and it be accepted by the network without crashing. Probably will be waiting until the dust settles on this before publishing that test case though, since it's clearly much more severe than a DoS
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.
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.
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. 
Virustotal says:
-snip-
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.
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. -snip-
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.
-snip-
It found 2 viruses after installation of this new version.
Those are not viruses, those are false positives. Most AV programs are essentially scams FYI. It found 2 viruses after installation of this new version.
Virustotal says:
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.
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.
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
That is why i was saying don't place the key/file in same location.
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
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
OOo so its not like an md5 hash then? Thought it was in that case we are all good
Sorries still a noobz
Icon
Sorries still a noobz
Icon
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. 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
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
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.
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.
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
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.
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
Icon
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.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.
Jump to: