Bitcoin-Qt / bitcoind version 0.8.4 released, fixes critical DoS vulnerability

[KSV]

Thanks to all working on the client, trying out the MAC OSX update now.

Had to delete the .Bitcoin folder and reindex all the blocks (corrupt database). Hope this works.

[RodeoX]

new update just after alot news about regulation.
prism backdor added?

Feeling paranoid ? Recompile from source ....

Exactly. If you are worried, look at the code yourself. Open source means nothing is hidden from you in the code.

[KSV]

MAC OSX - system error DB corrupted.

Ever since i changed to a SSD its been going crazy.

[Jace]

Checkpoint at block 250,000 to speed up initial block downloads
and make the progress indicator when downloading more accurate.

What does this mean? Does it contain or download a truncated version of the blockchain (well, the first 250K blocks) or...?

[WSDN]

Thanks for the update. The client is running fine from the update with the same wallet.

[superpanos2]

but I installed 0.8.4 and now I have to redownload the blockchain?!??!! 

[World]

OSX: use 'FD_FULLSYNC' with LevelDB, which will (hopefully!)
prevent the database corruption issues many people have
experienced on OSX.

Thanks very much for addressing this one!

+1

+1 Thank you dev team

[gmaxwell]

but I installed 0.8.4 and now I have to redownload the blockchain?!??!! 

No.  If you are one of the unfortunate people on OSX with an already corrupted database you'll still have to reindex, but otherwise it should just continue like normal.

[seafarer124]

Do I just click on the link and it will update the current version?

I would then need to back-up the new version?

[silvergoldandbitcoin]

Sad to see that updates are neccessary, but glad to see neccessary updates come out

+1

It can be troubling that "bugs" or "vulnerabilities" are there, but at least they are found! We're all only human anyway.

[nofuture]

I see the following message when I run bitcoin

assertion failed:
Progra(x86)\bitcoin-qt.ese
file.db/dbformat.h
lineZ:96
expression: Internal_keylsize() >=8

for more informaton on how your program can cause an asserationj failure see...

[nofuture]

Did anyone lose coins as a result of the bugs?

[giszmo]

Did anyone lose coins as a result of the bugs?

could anyone loose coins as a result of the bugs fixed in this release?

Gnah, updating is always such a pain when money is at risk. The "do you know the ppa guy" question being unanswered is also priceless. For Bitcoin and sensitive apps like that we need some signing mechanism that is easy to use and transparent.
When I use the ppa, I want to see something like "This binary is signed by A, B and C. D is missing. Should we install anyway?" If yes: "Do you generally trust updates containing just A, B and C?"

My other question: To have multiple people confirm the quality of a binary, can they compile it separately, getting the same binary? I would love to see as many people that review code to sign the binaries to gain trust. The source being trustful and the binary being signed by just one person is kind of a joke with the money at stake. No offense, Gavin, you are doing a great job and it's maybe a lack of tools or maybe a lack of understanding on my side (which would be a lack of easy and well known tools) but I think this update process needs more trust.

Extending this to mobile, I earlier mentioned how it is a joke to advertise a wallet as open source when 99.99% of all users use the binary. There needs to be a way to get what you want and to sign stuff.

To understand how many signatures I am thinking of: I want to be able to publicly approve of stuff and I want to be able to configure my friends' PCs to warn about updates if I did not approve of this version publicly.

[gmaxwell]

could anyone loose coins as a result of the bugs fixed in this release?

No. The whole network could be shut down, but the coins would stay put.

My other question: To have multiple people confirm the quality of a binary, can they compile it separately, getting the same binary? I would love to see as many people that review code to sign the binaries to gain trust. The source being trustful and the binary being signed by just one person is kind of a joke with the money at stake. No offense, Gavin, you are doing a great job and it's maybe a lack of tools or maybe a lack of understanding on my side (which would be a lack of easy and well known tools) but I think this update process needs more trust.

Uhhh.

Our binaries are bit-reproducible, and are always authenticated by multiple parties before being posted: https://github.com/bitcoin/gitian.sigs

We are innovators in this space, your criticism here is really misplaced.

[giszmo]

could anyone loose coins as a result of the bugs fixed in this release?

No. The whole network could be shut down, but the coins would stay put.

Thanx.

My other question: To have multiple people confirm the quality of a binary, can they compile it separately, getting the same binary? I would love to see as many people that review code to sign the binaries to gain trust. The source being trustful and the binary being signed by just one person is kind of a joke with the money at stake. No offense, Gavin, you are doing a great job and it's maybe a lack of tools or maybe a lack of understanding on my side (which would be a lack of easy and well known tools) but I think this update process needs more trust.

Uhhh.

Our binaries are bit-reproducible, and are always authenticated by multiple parties before being posted: https://github.com/bitcoin/gitian.sigs

We are innovators in this space, your criticism here is really misplaced.

It was not meant as criticism of the dev team. You all do a great job. It can't be as I don't know how to do it better. It is meant to raise awareness of how many people actually blindly install anything that comes as bitcoin.exe. The "criticism" also contains "it's maybe a lack of tools or maybe a lack of understanding on my side". It is a fact that the majority of users install without ever checking a sig. I know it is not trivial to improve this and have no solution. Having some github repo with the sigs helps experts supervise the hosted files and I guess there is a bunch of people supervising all kind of hostings but the doubt – mine and the doubt of others – is a problem when it comes to getting updates spread fast.

It's good to learn that binaries are bit-reproducible. This is essential to trust any binary.

[gmaxwell]

It was not meant as criticism of the dev team. You all do a great job. It can't be as I don't know how to do it better. It is meant to raise awareness of how many people actually blindly install anything that comes as bitcoin.exe. The "criticism" also contains "it's maybe a lack of tools or maybe a lack of understanding on my side". It is a fact that the majority of users install without ever checking a sig.

You have my complete agreement there. In the future we should use an updater program (e.g. "gitian updater") which checks the signature for the users, so at least once users have one good copy they should be okay on future ones.

[Joe_Bauers]

I am unable to compile 0.8.4 in Debian 7. I checked out 0.8.3 and was able to compile with no issues. When I switch back to 0.8.4 I get the following:

Your paste indicates you are building the development version (master, aka pre-0.9), not 0.8.4 release.

Your 0.9 build fails due to lack of the protobufs compiler, "protoc"

You want to check out the v0.8.4 branch.

Yep - I checked out  v0.8.4r2 and it worked. I'm guessing that a lot of folks are just going to git clone https://github.com/bitcoin/bitcoin.git and get the same issue though.
Anyway, thanks for the update.

[Gorgoy]

Roger that upgrading now thanks as always to the devs

+ Thanks a million to all the Dev, will go update.

[LightRider]

Win7x64 operating without issue.

[emisi]

Thanks for the update! Upgrading now...