Bitcoin 0.7.2

[lenny]

16 December 2012

Bitcoin version 0.7.2 released

Bitcoin version 0.7.2 is now available from:
http://sourceforge.net/projects/bitcoin ... coin-0.7.2

This is a bug-fix minor release.

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 were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Explanation of -detachdb (and the new "stop true" RPC command):
The Berkeley DB database library stores data in both ".dat" and
"log" files, so the database is always in a consistent state,
even in case of power failure or other sudden shutdown. The
format of the ".dat" files is portable between different
versions of Berkeley DB, but the "log" files are not-- even minor
version differences may have incompatible "log" files. The
-detachdb option moves any pending changes from the "log" files
to the "blkindex.dat" file for maximum compatibility, but makes
shutdown much slower. Note that the "wallet.dat" file is always
detached, and versions prior to 0.6.0 detached all databases
at shutdown.

Bug fixes
---------

* Prevent RPC 'move' from deadlocking. This was caused by trying to lock the
database twice.

* Fix use-after-free problems in initialization and shutdown, the latter of
which caused Bitcoin-Qt to crash on Windows when exiting.

* Correct library linking so building on Windows natively works.

* Avoid a race condition and out-of-bounds read in block creation/mining code.

* Improve platform compatibility quirks, including fix for 100% CPU utilization
on FreeBSD 9.

* A few minor corrections to error handling, and updated translations.

* OSX 10.5 supported again

----------------------------------------------------
Thanks to everybody who contributed to this release:

Alex
dansmith
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Luke Dashjr
Philip Kaufmann
Pieter Wuille
Wladimir J. van der Laan
grimd34th

[lenny]

Z wersją Bitcoin 0.7.2 był związany bardzo poważny bug, który spowodował podzielenie się sieci na 2 łańcuchy, łańcuch tworzony przez Bitcoin 0.7.2 oraz starsze wersje oraz drugi łańcuch tworzony przez klienty 0.8. Było to spowodowane stworzeniem przez pool Slush (www.bitcoin.mining.cz) bloku o wielkości 974 KB, zawierającego 1752 transakcji. Poprzez ograniczenia w bazie danych wersji 0.7.2 blok ten był odrzucany przez Bitcoin 0.7.2 oraz starsze wersje. Decyzją developerów i społeczności, wszystkie centralne poole zmieniły swoje wersje bitcoind na 0.7.2, co spowodowało po kilku godzinach odrzucenie łańcucha tworzonego wyłącznie przez wersję 0.8.

Link do feralnego bloku, teraz już osieroconego: http://blockchain.info/block-index/3579 ... 2df480c023
Szczegóły:
https://bitcointalk.org/index.php?topic=152030.0
http://forum.bitcoin.pl/fork-risk-t5134.html

[lenny]

Szczegóły opis zaistniałej sytuacji:
http://bitcoin.org/chainfork.html

11/12 March 2013 Chain Fork Information
What happened

A bitcoin miner running version 0.8.0 created a large block (at height 225,430) that is incompatible with earlier versions of Bitcoin.

The result was a block chain fork, with miners, merchants and users running the new version of bitcoin accepting, and building on, that block, and miners, merchants and users running older versions of bitcoin rejecting it and creating their own block chain.
What is being done

Large mining pools running version 0.8.0 were asked to switch back to version 0.7, to create a single block chain compatible with all bitcoin software.
Questions & Answers
I'm not a miner or a merchant, what should I do?

Nothing. Your bitcoin software will switch to the correct chain automatically, no matter which version you are running.
Are my bitcoins safe?

Yes.
I'm a merchant accepting bitcoins, what should I do?

If you are running version 0.8.0, there is a small risk that payments with more than 6 confirmations could be double-spent on the 0.7-compatible blockchain. The risk is small because this is not a network split-- transactions are being sent to both sides of the chain split, and it is unlikely (but possible) that somebody could get two versions of the same transaction into the two sides of the chain.
What will be done

The core developers are investigating exactly what causes the old versions to reject the new blocks, and will release a 0.8.1 version that avoids creating blocks that are incompatible with older versions.

[rav3n_pl]

Zapominamy o 072, wszyscy robią update do 081 http://forum.bitcoin.pl/bitcoin-0-8-1-1 ... t5205.html

[lenny]

Warto dodać, że przez tego buga pool BTC Guild stracił okolo 1400 BTC. https://www.btcguild.com/index.php?page=home

This was posted on the official forum thread at Bitcointalk previously. Those who have already heard about it, this is just a summary/recap, not a repeat event.

On March 11th, an upgrade was being done to move the Merged Mining server to bitcoind 0.8. Previously, upgrading the bitcoind software on a pool server was safe to do live. Simply stopping the old binary, copying over the new one, and restarting it, would keep the pool up and running, and prevent miners from disconnecting.

These updates were done live in the past because the ~30 seconds of "downtime" (a block can't be solved during this brief downtime) was worth the cost of miners disconnecting and possibly being stuck offline/on a backup pool. However, something went very wrong with the upgrade to bitcoind 0.8. The main reason to upgrade to 0.8 was the drastically improved speed of the bitcoin client, which reduces stales and reduced the chance of orphan blocks. This was accomplished with a new database backend, LevelDB. Unfortunately, when upgrading to 0.8, it does not automatically update your old blockchain information. It resync's the blockchain from scratch.

The problem on March 11th was this brief period where the server was resync'ing the blockchain. It was not caught instantly, it took about 45 seconds to notice. During this time, the pool server recorded work at the network difficulty from very early blocks, a difficulty of 1. Users were being awarded 25 BTC per share.

These increased rewards being logged were not caught immediately, and a total of 16 users were able to withdraw 1,254 BTC (the balance of the hot wallet) that they should not have earned. All rewards from this period have since been revoked, but only one of the 16 users has returned any funds (a total of 47 BTC).

This news post was made to keep the incident transparent. The pool suffered approximately 1,400 BTC in losses this week. 1,254 from the error in payouts, and somewhere between 150 and 250 coins from the hard fork event. My plan is to simply absorb these losses, and continue moving forward.