Bitcoin Core version 0.10.1

[lenny]

27 April 2015

Bitcoin Core version 0.10.1 released


Bitcoin Core version 0.10.1 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.10.1/

This is a new minor version release, bringing bug fixes and translation updates. If you are using 0.10.0, it is recommended to upgrade to this version.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues
Upgrading and downgrading
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).
Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this.

The block index database will now hold headers for which no block is stored on disk, which earlier versions won’t support.

If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.
Notable changes

This is a minor release and hence there are no notable changes. For the notable changes in 0.10, refer to the release notes for the 0.10.0 release at https://github.com/bitcoin/bitcoin/blob ... e-notes.md
0.10.1 Change log

Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates.

RPC:

• 7f502be fix crash: createmultisig and addmultisigaddress
• eae305f Fix missing lock in submitblock

Block (database) and transaction handling:

• 1d2cdd2 Fix InvalidateBlock to add chainActive.Tip to setBlockIndexCandidates
• c91c660 fix InvalidateBlock to repopulate setBlockIndexCandidates
• 002c8a2 fix possible block db breakage during re-index
• a1f425b Add (optional) consistency check for the block chain data structures
• 1c62e84 Keep mempool consistent during block-reorgs
• 57d1f46 Fix CheckBlockIndex for reindex
• bac6fca Set nSequenceId when a block is fully linked

P2P protocol and network code:

• 78f64ef don’t trickle for whitelisted nodes
• ca301bf Reduce fingerprinting through timestamps in ‘addr’ messages.
• 200f293 Ignore getaddr messages on Outbound connections.
• d5d8998 Limit message sizes before transfer
• aeb9279 Better fingerprinting protection for non-main-chain getdatas.
• cf0218f Make addrman’s bucket placement deterministic (countermeasure 1 against eclipse attacks, see http://cs-people.bu.edu/heilman/eclipse/)
• 0c6f334 Always use a 50% chance to choose between tried and new entries (countermeasure 2 against eclipse attacks)
• 214154e Do not bias outgoing connections towards fresh addresses (countermeasure 2 against eclipse attacks)
• aa587d4 Scale up addrman (countermeasure 6 against eclipse attacks)
• 139cd81 Cap nAttempts penalty at 8 and switch to pow instead of a division loop

Validation:

• d148f62 Acquire CCheckQueue’s lock to avoid race condition

Build system:

• 8752b5c 0.10 fix for crashes on OSX 10.6

Wallet:

N/A

GUI:

• 2c08406 some mac specifiy cleanup (memory handling, unnecessary code)
• 81145a6 fix OSX dock icon window reopening
• 786cf72 fix a issue where “command line options”-action overwrite “Preference”-action (on OSX)

Tests:

• 1117378 add RPC test for InvalidateBlock

Miscellaneous:

• c9e022b Initialization: set Boost path locale in main thread
• 23126a0 Sanitize command strings before logging them.
• 323de27 Initialization: setup environment before starting QT tests
• 7494e09 Initialization: setup environment before starting tests
• df45564 Initialization: set fallback locale as environment variable

Credits

Thanks to everyone who contributed to this release:

Alex Morcos
Cory Fields
dexX7
fsb4000
Gavin Andresen
Gregory Maxwell
Ivan Pustogarov
Jonas Nick
Jonas Schnelli
Matt Corallo
mrbandrews
Pieter Wuille
Ruben de Vries
Suhas Daftuar
Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.

[Multi]

a po polsku i w skrócie, co nam daje ??

[pm7]

This is a minor release and hence there are no notable changes.

Tylko drobne poprawki.

[rav3n_pl]

Sporo poprawek w P2P w celu uniknięcia pobrania "złego łańcucha" od "złośliwych" węzłów.

[powered]

W konfiguracji nowego bitcoin core nie można już użyć takiego zapisu:
rpcallowip=192.168.0.*
jak zastąpić powyższy wpis aby dać dostęp do portfela z całej sieci lokalnej?
Próbowałem tak jak poniżej ale nie działa
rpcallowip=192.168.0.0/255.255.255.0
rpcallowip=192.168.0.0/24
rpcallowip=W:192.168.0/24

[rav3n_pl]

Ten zapis

Kod: Zaznacz cały

rpcallowip=192.168.0.0/255.255.255.0

powinien działać bez problemu zamiast 192.168.0.*
Jeżeli chcesz udostępnić konkretnej maszynie czy dwóm, lepiej podaj ich IPki zamiast maski.

[powered]

W specyfikacji są podane takie przykłady:
rpcallowip=192.168.1.0/255.255.255.0
rpcallowip=172.16.0.0/24
ale w ten sposób nigdy się nie połączyłem z portfelem. Próbowałem na różnych wersjach portfela a nawet na różnych innych kryptowalutach.

Tak działało (konkreny IP albo cała grupa IP)
rpcallowip=192.168.0.10
rpcallowip=192.168.0.*

W sieci wszystko mi działa po DHCP i nie chce mi się zmieniać na stałe IP, więc pozostaje mi chyba tylko powrót do starszej wersji portfela

[pm7]

Router nie obsługuje przypisania określonego IP do MAC, żeby zawsze ten sam nadawać?
Jak nie, to polecam taki, co potrafi (OpenWRT ).

[rav3n_pl]

Jeżeli masz IP routera 192.168.1.1 maska 255.255.255.0 to powinno działać 192.168.1.0/24 i 192.168.1.1/255.255.255.0

[Nuke]

Z tego co rozumiem, mam wywalić stary blockchain i zaciągnąć nowy.
Czy nie jest to aby zagrożenie dla bezpieczeństwa??

[lenny]

Z tego co rozumiem, mam wywalić stary blockchain i zaciągnąć nowy.
Czy nie jest to aby zagrożenie dla bezpieczeństwa??

Nie jest. Bitcoin na tym właśnie się opiera, że każdy ma możliwość pobrania 100% poprawnego łańcucha bloków, w każdej chwili, 24/7. Każda kopia blockchaina w każdym nodzie ma być taka sama, niezależnie od źródła. Pobierając od nowa bloki potwierdzisz tylko tą regułę.

[rav3n_pl]

Nie musisz wywalać starego i nie musisz zaciągać na nowo.
Jak chcesz zmniejszyć nieco ilość zajmowanego miejsca, możesz zrobić sobie bootstrapa przez linearize i go użyć. Ale konieczności nie ma.
Zrobienie bootstrapa wymaga tyle dodatkowego miejsca ile zajmują same bloki.

[Nuke]

Dziękować.

Więc o co się rozchodzi w tym fragmencie?

Kod: Zaznacz cały

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this.

The block index database will now hold headers for which no block is stored on disk, which earlier versions won’t support.

If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.
Notable changes

[pm7]

Technicznie: bloki nie będą przechowywane zgodnie z kolejnością
Praktycznie: jeżeli przewidujesz potrzebę cofnięcia wersji, zrób kopię katalogu z blokami, bo stara wersja nie będzie w stanie odczytać nowej i będzie musiała wszystkie bloki ponownie pobrać (i zweryfikować) z sieci, ponadto, nowa wersja może być niekompatybilna z różnymi programami operującymi na plikach z blokami (block explorery? electrum server?).

[rav3n_pl]

Jeżeli zachce Ci się robić downgrade do wersji <0.10 system się wywali i będzie trzeba na nowo pobierać bloki.
Wcześniejsze wersje pliki z danymi bloków zawierał kolejno pobrane bloki (każdy kolejny blok na dysku miał "punkt zaczepienia" w którymś ze wcześniej zapisanych bloków), wersja 0.10 wprowadza zapis na dysku w momencie ściągnięcia i dopiero analizę/akceptację/indeksowanie zgodnie z pobranym spisem nagłówków.
Generalnie bloki które nie są zawarte w liście nagłówków nie są pobierane i zapisywane - "gubimy" tym samym wszystkie orphany. Baza "historyczna" dzięki temu jest chudsza. Bloki pobierane "na żywo" mogą później zawierać orphany. Ale każdy nowo podłączany węzeł już o nie nie będzie pytał.
Faktycznie, programy które pobierają dane bezpośrednio z pliku danych (a nie po RPC) będą zapewne "zaskoczone" faktem odczytu bloku, który jest orphanem (nie ma pasującego poprzedniego bloku w historii) i mogą się wywalić. Pobierając bloki widzimy też przez to "skoki" podczas analizy (zwłaszcza na początku), gdzie demon pobiera dane cały czas ale nie zawsze ma co analizować (nie ma ciągłości w pobranym łańcuchu).