Bitcoin-Qt version 0.8.5 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/

This is a maintenance release to fix a critical bug;
we urge all users to upgrade.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues


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).

If you are upgrading from version 0.7.2 or earlier, the first time you
run 0.8.5 your blockchain files will be re-indexed, which will take
anywhere from 30 minutes to several hours, depending on the speed of
your machine.

0.8.5 Release notes
===================

Bugs fixed
----------

Transactions with version numbers larger than 0x7fffffff were
incorrectly being relayed and included in blocks.

Blocks containing transactions with version numbers larger
than 0x7fffffff caused the code that checks for LevelDB database
inconsistencies at startup to erroneously report database
corruption and suggest that you reindex your database.

This release also contains a non-critical fix to the code that
enforces BIP 34 (block height in the coinbase transaction).

--

Thanks to Gregory Maxwell and Pieter Wuille for quickly
identifying and fixing the transaction version number bug.

There was an interesting research paper (which I can't find) that claimed that high frequency trading is largely driven by the artifically high limit on bid/ask spreads. The claim is that if trading was allowed in much smaller fractions of a dollar traders would compete by underbidding/overoffering instead of competing to be first in the trading queue.

That seems plausible to me-- set an arbitrary constraint ("bids must be in multiples of a tenth of a penny" -- or whatever it is these days) and you often get unintended consequences.

I still plan on writing up why I disagree with the idea that a larger block size will lead to centralization, but I'm working on some higher priority things first. I really don't understand why you would think that our current, arbitrary 1MB limit is the Best Size For All Time. I think that arbitrary constraint will have bad unintended consequences.

Most likely explanation is one of your blockchain data files is corrupted, but the old version doesn't care. You might be serving up a corrupted blocks to anybody who downloads from you, but you wouldn't notice that either.

I wrote a big comment in init.cpp describing how shutdown works:


I don't know nuthin about Windows' SetConsoleCtrlHandler(), but just setting the fRequestShutdown global variable should do the right thing.

My build environment changed and the first -linux.tar.gz contained ._foo files (see http://superuser.com/questions/61185/why-do-i-get-files-like-foo-in-my-tarball-on-os-x ).

So I untarred and re-tarred with the magic "don't be clever, please, OSX" environment variable set and uploaded a new .tar.gz and SHASUMS.

Bitcoin-Qt version 0.8.4 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.4/

This is a maintenance release to fix a critical bug and three
security issues; we urge all users to upgrade.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues


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).

If you are upgrading from version 0.7.2 or earlier, the first time you
run 0.8.4 your blockchain files will be re-indexed, which will take
anywhere from 30 minutes to several hours, depending on the speed of
your machine.

0.8.4 Release notes
===================

Security issues
---------------

An attacker could send a series of messages that resulted in
an integer division-by-zero error in the Bloom Filter handling
code, causing the Bitcoin-Qt or bitcoind process to crash.
Bloom filters were introduced with version 0.8, so versions 0.8.0
through 0.8.3 are vulnerable to this critical denial-of-service attack.

A constant-time algorithm is now used to check RPC password
guess attempts; fixes https://github.com/bitcoin/bitcoin/issues/2838
(CVE-2013-4165)

Implement a better fix for the fill-memory-with-orphan-transactions
attack that was fixed in 0.8.3. See
https://bitslog.wordpress.com/2013/07/18/buggy-cve-2013-4627-patch-open-new-vectors-of-attack/
for a description of the weaknesses of the previous fix.
(CVE-2013-4627)

Bugs fixed
----------

Fix multi-block reorg transaction resurrection.

Fix non-standard disconnected transactions causing mempool orphans.
This bug could cause nodes running with the -debug flag to crash.

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

Linux: clicking on bitcoin: links was broken if you were using
a Gnome-based desktop.

Fix a hang-at-shutdown bug that only affects users that compile
their own version of Bitcoin against Boost versions 1.50-1.52.

Other changes
-------------

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


Thanks to everybody who contributed to the 0.8.4 releases!
----------------------------------------------------------

Pieter Wuille
Warren Togami
Patrick Strateman
pakt
Gregory Maxwell
Sergio Demian Lerner
grayleonard
Cory Fields
Matt Corallo
Gavin Andresen

It bloats the UTXO set, which is bad.

MasterCoin transactions should all be spendable or provably prune-able. There are plenty of ways to accomplish that, the easiest of which that works today would be to stuff data into unused public keys of an OP_CHECKMULTISIG transaction.

Yes, please stop polluting the UTXO set. There are much better ways to accomplish what you want to accomplish.

So, one thought:

Instead of "staging" all of the dependencies and then modifying the makefile/.pro to look for the dependencies in six different places, it would be cleaner to configure with --prefix=<somewhere>  and then 'make install' to put all the dependency libraries/include files in one spot. Ideally, none of the makefiles/.pro files would contain specific version numbers for anything.

Specific notes as I worked through doing that on a Windows system, putting dependencies in C:\deps :

Openssl:  /bin/perl Configure --prefix=/c/deps mingw ...etc

BDB: ../dist/configure --prefix=/c/deps ...etc

Boost: b2.exe --layout=system --prefix=C:\deps link=static threading=multi runtime-link=static toolset=gcc ...etc

Qt: configure.exe -prefix=C:\deps -I "C:\deps\include" -L "C:\deps\lib" ...etc

How big is your wallet?

getbalance() is O(N) where N is the total number of transactions in the wallet. (actually, it can be even worse than O(N) if you have long chains of unconfirmed transactions in your wallet)

"Patches welcome" to fix that, I expected one of the big bitcoind-using services would submit a performance fix patch long ago.

That's incorrect. The following command-line or bitcoin.conf configuration parameters let miners set their transaction acceptance policy:


The -mintxfee / -minrelaytxfee options currently control how large a fee-per-kilobyte is needed for a transaction to be considered "fee paying" versus "free".

I would much rather people help test individual pull requests or 'git HEAD' rather than "random collection of changes". Putting eleven unrelated changes together makes figuring out what caused a bug/regression much harder.

I spent a bunch of time getting the mingw-cross-compiled Qt compiled with -openssl-linked for the payment protocol work (it uses QtNetwork to fetch PaymentRequest/PaymentACK messages via https).

The magic configure incantation was:

Nothing special needed to be done for the openssl build:



The payment protocol code add a couple more depedencies to Bitcoin-Qt:

+ QtNetwork with OpenSSL support
+ Google's protocol buffer library and compiler.

Nice work!

RE: gcc creating different binaries:

The gitian build does two main things to make builds reproducible:

1. Uses libfaketime.so so all calls to time()/etc during compilation return the same time.
 (I don't know if it is the compiler, linker, or archiver that likes to put timestamps in binaries)

2. Passes -frandom-seed=constant  to g++, so it doesn't create random names for generated methods.

The problem is that there is a mismatch between the criteria used to accept a transaction into the memory pool / relayed and the criteria most miners use to choose transactions for their blocks.

The fix is not conceptually hard; just modify the memory pool code so the memory pool is treated like it is an extra-large block, and only relay/store the transactions that are likely to be mined in the next few blocks.

That hasn't been implemented yet because it just hasn't been a high priority.

Bitcoin-Qt version 0.8.3 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.3/

This is a maintenance release to fix a denial-of-service attack that
can cause nodes to crash.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

0.8.3 Release notes

Truncate over-size messages to prevent a memory exhaustion attack.

Fix a regression that causes excessive re-writing of the 'peers.dat' file.

---

Thanks to Peter Todd for responsibly disclosing the vulnerability
( CVE-2013-4627 ) and creating a fix.

No.

Sold!  (I hope)

Two offers over 26 BTC, best offer was 30 BTC.

Pieter and Wladimir are not US citizens, so a US judge can't order them to do anything.

If I was ordered to insert a backdoor, I'd just resign as lead developer and find something else to work on.

But this whole scenario sounds like a paranoid delusion; has there EVER been a case where a judge has ordered a software developer to do anything other than stop distributing their software (because of some copyright or patent issue) ?

It is mining over 0.2 BTC per day right now, so if difficulty doesn't change (HAH!) and you have free electricity (DOUBLE HAH!) you'll break even in 4 or 5 months.

PS: best offer so far is a private offer of 26 BTC plus shipping.