Please help test: Bitcoin-Qt, bitcoind version 0.5.2rc1

[Luke-Jr]

Bitcoin version 0.5.2rc1 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/test/

This is a bugfix-only release based on 0.5.1.

Please report bugs by replying to this forum thread.

Stable source code is hosted at Gitorious:
  http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2rc1#.tar.gz

BUG FIXES

• Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download; this was not a security vulnerability).
• Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
• Fixed some address-handling deadlocks (client freezes).
• No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
• Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
• Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
• Don't show "IP" for transactions which are not necessarily IP transactions.
• Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

Thanks to everybody who contributed code or helped test this release:

Luke Dashjr
Matt Corallo
Wladimir J. van der Laan
Gavin Andresen
Pieter Wuille
Dylan Noblesmith

[Mushoz]

What's the ETA on the official release? It's looking good so far! 

[Luke-Jr]

What's the ETA on the official release? It's looking good so far! 

Technically, it's already tagged. We just wanted to make sure more people tested it before putting it on the front page.

[pc]

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).

That sounds scary. Could you clarify what risks somebody has in using 0.5.0 and 0.5.1 right now? Is there link to a forum thread or the like about this? Or is this not as scary as it sounds?

[Luke-Jr]

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).

That sounds scary. Could you clarify what risks somebody has in using 0.5.0 and 0.5.1 right now? Is there link to a forum thread or the like about this? Or is this not as scary as it sounds?

It's not that scary if you follow best practices of waiting 6 confirmations for transactions. Even if there's a malicious miner out there, other miners would have rejected his blocks.

[Mushoz]

I think it's crucial this gets released ASAP though. But of course, not without being sure there aren't any major bugs in this release. The thing is, the downloads for the client are picking up, most likely because of the The Good Wife show. Loads of new people might get turned off by the hours long blockchain synchronization. Decisions, decisions...

[fornit]

seems to work with win7 64-bit.
didnt do anything special though, just checking all tabs, options and sorting and let it download a few weeks of blocks.

[finway]

Working fine on WinXP

[pc]

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).

That sounds scary. Could you clarify what risks somebody has in using 0.5.0 and 0.5.1 right now? Is there link to a forum thread or the like about this? Or is this not as scary as it sounds?

It's not that scary if you follow best practices of waiting 6 confirmations for transactions. Even if there's a malicious miner out there, other miners would have rejected his blocks.

If somebody were mining using 0.5.0 or 0.5.1, could they have in theory been "tricked" into building onto malicious blocks?

I do understand that anything with a handful of confirmations is fine, but it's rather disconcerting that the client has been effectively a lightweight client (trusting the miners entirely), especially as the Satoshi client is a reference of how to mine in addition to the core transaction client.

I guess this all just builds into Gavin's wish for more automated tests to try to verify correct operations. But it makes me wonder whether I should keep upgrading to the latest versions as soon as they come out, or whether the tried-and-true older versions are more or less likely to be "correct"…

[Luke-Jr]

But it makes me wonder whether I should keep upgrading to the latest versions as soon as they come out, or whether the tried-and-true older versions are more or less likely to be "correct"…

That's why I'm maintaining the 0.4.x series.

[Gavin Andresen]

If somebody were mining using 0.5.0 or 0.5.1, could they have in theory been "tricked" into building onto malicious blocks?

No, that's not a realistic attack.

For an attacker to feed you a malicious block chain, they would have to be able to produce malicious blocks that have CORRECT proof-of-work. I don't think it is realistic to think that any attacker would throw lots of hash power onto a malicious block chain just so they can feed a bad block chain to somebody who connects to them.

Especially since that somebody would discover that their version of the block chain was incorrect within about 10 minutes, as soon as they got a new block message.

The bugfix was a "belt and suspenders" change to limit the potential damage from somebody who already had more than 50% of hashing power.

[nibor]

I know I am always behind adding new versions to the charts! You guys keep adding them too often and I have not worked out a nice easy way to add the to rrd. Anyway I have now added a table so you can at least see the current number of all versions:

http://bitcoinstatus.rowit.co.uk/#versions

[Luke-Jr]

I know I am always behind adding new versions to the charts! You guys keep adding them too often and I have not worked out a nice easy way to add the to rrd. Anyway I have now added a table so you can at least see the current number of all versions:

Unfortunately, since this number is becoming the protocol version and neither of the more common clients (bitcoind and Bitcoin-Qt) comply with BIP 0014, such nice statistics will probably become history anyway.

[nibor]

Arh - shame. Also the stats are wrong cos of Multibit and bitcoin spinner type clients that do not send address messages.

From a marketing point of view being able to say xx thousand active users is useful.

Bit of a useless post though as have no real solution to issue.

[pc]

Are there digital signatures or hashes or such for the files? It looks like they're not even hosted on sourceforge over SSL (I don't know how hard it would be for them to set that up), and it'd be useful if the downloads were signed by the developers (preferably several), who could attest to the fact that the binaries are correctly compiled and won't (intentionally at least) take all our money.

[Luke-Jr]

Are there digital signatures or hashes or such for the files? It looks like they're not even hosted on sourceforge over SSL (I don't know how hard it would be for them to set that up), and it'd be useful if the downloads were signed by the developers (preferably several), who could attest to the fact that the binaries are correctly compiled and won't (intentionally at least) take all our money.

I think I'm the only one who signed rc1. BlueMatt built it. The same binaries (except Bitcoin-Qt for Windows, since it isn't 100% deterministic yet) are being renamed to final now, built and signed by devrandom and sipa, and signed again by me. I expect Gavin might sign the hashes when he uploads them too.

[stcupp]

just wondering why arn't some of the new RPC functions that are in the source built into this build?  like  getblockbyhash?

[Luke-Jr]

just wondering why arn't some of the new RPC functions that are in the source built into this build?  like  getblockbyhash?

As stated in the initial post, this is a bugfix-only release. New features will be in 0.6.

[stcupp]

oh i see.... any estimated date for 6.0?

[Luke-Jr]

oh i see.... any estimated date for 6.0?

0.6, not 6.0. Big difference. I wouldn't bet on it being until March.