Bitcoin 0.8.4

[lenny]

4 September 2013

Bitcoin version 0.8.4 released

Bitcoin-Qt version 0.8.4 is now available from:
http://sourceforge.net/projects/bitcoin ... oin-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/1 ... 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

[virus]

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

Mam rozumieć że teraz zamiast od genesis block synchronizowac sie bedzie od 250k bloku ?

[rav3n_pl]

Nie.
Checkpoint tylko "upewnia" że nie jesteś w jakimś dzikim forku.

[virus]

a szkoda... była by to fajna opcja.
Tak by sie synchronizował od 250k i mozna było już działąć, a w tle dociągał reszte powolutku

[lenny]

Nie można by było działać. Wysłać transakcję można dopiero wtedy, gdy portfel jest 100% zsynchronizowany. Jak wyślesz coś przed 100% synchronizacją, to będą problemy - transakcja nigdy się nie potwierdzi, aż nie usuniesz i ściągniesz od nowa wszystkich bloków. Raz tak miałem, śpieszyło mi się i kliknąłem wyślij gdy portfel miał "2 hours behind" - transakcja za cholerę nie chciała wyjść do sieci, żaden --rescan nie pomagał, tylko pełny re-download bloków pomógł Na szczęście mój portfel się synchronizuje za pomocą prowadzonego przeze mnie bitcoin-node'a 24/7 w tej samej sieci lokalnej - dzięki temu pełna synchronizacja portfela u mnie trwała tylko kilka godzin, zamiast 1-2 dni

[prezes]

Wysłać transakcję można dopiero wtedy, gdy portfel jest 100% zsynchronizowany. Jak wyślesz coś przed 100% synchronizacją, to będą problemy - transakcja nigdy się nie potwierdzi, aż nie usuniesz i ściągniesz od nowa wszystkich bloków.

Muszę się z Tobą częściowo nie zgodzić wiele razy wysyłałem bez synchronizacji i nie było problemów co nie oznacza że nie mogły by być, jak widać na Twoim przykładzie.

[lenny]

Być może niezsynchronizowany portfel użył inputów, których na adresach już mogło nie być (double-spend)?

[gkucmierz]

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

Dzięki za info To jest to co mnie denerwowało w poprzedniej wersji.

[virus]

ja też tak miałem bez synchronizacji, ale chodzilo o to że wysłałem BTC beż fee i jakąś strasznie małą kwotę.
w końcu oczywiście przeszły, ale trwało to chyba z dobe

Ja miałem na myśli ludzi którzy pierwszy portfel tworzą... nie potrzeba im pełnej synchronizacji na moment odpalenia bo i tak adresy są puste i nie ma żadnych inputów

Swoją drogą ... tutaj rodzi się pomysł by klient czyścił wydane inputy ... ciekawe ile wtedy by "ważyła" baza... można by było tutaj nieźle optymalizować

[gkucmierz]

Swoją drogą ... tutaj rodzi się pomysł by klient czyścił wydane inputy ... ciekawe ile wtedy by "ważyła" baza... można by było tutaj nieźle optymalizować

No ale w ten sposób to mógłbyś tylko wallet.dat odchudzić. Dobrze rozumiem?

[WMP]

Nie można by było działać. Wysłać transakcję można dopiero wtedy, gdy portfel jest 100% zsynchronizowany. Jak wyślesz coś przed 100% synchronizacją, to będą problemy - transakcja nigdy się nie potwierdzi, aż nie usuniesz i ściągniesz od nowa wszystkich bloków.

A multibit to on jak wysyła? Z tego co wiem to się nie synchronizuje.

[Nuke]

Multibit pobiera tylko nagłówki, a nie całe bloki. Dlatego synchronizacja jest znacznie szybsza.

[123mamut]

A ten Multibit gdzie w nim pokazuje te pobieranie? Bo u mnie pisze tylko połączony.

[lenny]

A ten Multibit gdzie w nim pokazuje te pobieranie? Bo u mnie pisze tylko połączony.

Bo już pobrał. Jak synchronizuje nagłówki, to na dole okna masz stosowny komunikat o tym fakcie.

[prezes]

Być może niezsynchronizowany portfel użył inputów, których na adresach już mogło nie być (double-spend)?

Używając portfela na jednym kliencie jest to chyba mało prawdopodobne, żeby inputów już nie było skoro portfel jest niezsynchronizowany ale przenosząc portfel miedzy klientami jest to jak najbardziej możliwe. Ja wysyłałem bez synchronizacji wiedząc, że na portfelu nie robiłem żadnych operacji i że to co pokazuje mi klient jest jednoznaczne z tym co faktycznie jest pomimo braku synchronizacji.

[123mamut]

W którym pliku tego programu są zapisane BTC?

[lenny]

wallet.dat

[hanti]

multibit ma xxx.wallet np #4.wallet do tego kopia i pliki .info

[darekry]

Czy istnieje już inna implementacja bitcoind?
Taka, która nie powstała przez edycje kodu źródłowego, tylko napisana od zera na podstawie specyfikacji protokołu.

[lenny]

Tak istnieje ich wiele, niektóre już od bardzo dawna:

bitcoinj - w pełni otwarta implementacja protokołu bitcoin w języku Java, jedna z najstarszych (z 2011 roku) prowadzona przez Mike'a Hearna (inżynier w Google'u, miałem okazję go poznać osobiście)
btcd - kolejna pełna implementacja protokołu, napisana w języku Go, prowadzona przez firmę Conformal Systems LLC
libbitcoin - pełna implementacja protokołu pisana przez Amir'a Taaki'ego wraz z zespołem innych developerów w języku C++ (p. Amir'a też znam osobiście)
Bits of Proof - jedna z najciekawszych implementacji protokołu, stworzona dla ogromnych, skalowanych środowisk tj. sklepy, giełdy itp. Prowadzona przez p. Tamása Blummera, którego wykładu nt. jego produktu (The BOP Enterprise Bitcoin Server) też miałem przyjemność wysłuchać na żywo.

Jeśli jakieś przegapiłem, proszę dać znać.