Nowa wersja Bitcoin Core - v0.13

Kolejne wydanie Core oznaczone numerem v13 kończy właśnie 3-cią i ostatnią wersję RC (release Candidate – kandydat do wydania). v13 wprowadza kilka długo oczekiwanych zmian.

 

 

Kolejne wydanie Core oznaczone numerem v13 kończy właśnie 3-cią i ostatnią wersję RC (release Candidate – kandydat do wydania). v13 wprowadza kilka długo oczekiwanych zmian.

 

Największe i najważniejsze z nich to:

 

• zmiana formatu nowych portfeli na HD (hierarchical deterministic, BIP32) dzięki czemu backup będzie wymagał jedynie zapisania „seeda” w formie słów i jednorazowo będzie zawierał wszystkie możliwe przyszłe adresy ujęte w portfelu. UWAGA! Jeżeli używamy portfela w formie nie zaszyfrowanej i go zaszyfrujemy to wymagany jest kolejny backup seeda, ponieważ będzie on generowany na nowo!). Można wyłączyć tą funkcjonalność przełącznikiem -usehd=0, nie zadziała to oczywiście jak mamy już portfel HD
•  wprowadzenie kodu segwit BIP141, 143, 144 i 145. NIE wprowadza się jednak kodu głosowania/uruchomienia tej funkcjonalności w sieci głównej
• porzucenie Windows XP – działanie Core nie jest już testowane w tym środowisku, zgłoszenia błędów nie będą rozpatrywane
• zwiększenie domyślnej ilości RAM przeznaczonej na transakcje czekające na zatwierdzenie w bloku (mempool) z 100 do 300MB
•  „prywatyzacja” wprowadzanie komend przez bitcoin-cli (przełącznik -stdin)
• zwiększenie wymaganej wersji kompilatora do C++11 (gcc 4.7+, clang 3.3+), wersji Python do 3.4 dla testów
• dołączenie binariów zbudowanych pod ARM 32/64 do oficjalnych wydań (Linux na ARM, NIE Adroid!)
• uruchomienie BIP152 – Compact Blocks. Zmiana ta znacznie poprawi propagację nowych bloków w sieci – nie będzie konieczności przekazywania całego bloku pomiędzy kompatybilnymi węzłami
• wprowadzenie logiki liczenia opłat w łańcuchu transakcji zgodnie z logiką „dziecko płaci za rodzica” (child pays for parrent) co oznacza, że będzie można „przyspieszyć” dołączenie do bloku transakcji która „utknęła” przez wydanie jej w kolejnej transakcji z dołączoną większą opłatą transakcyjną obejmującą wszystkie jeszcze nie zatwierdzone wcześniejsze transakcje w łańcuchu.
• rozdzielenie procesów weryfikacji i indeksowania bloków. Pozwoli to przyspieszyć operację „-reindex” i daje możliwość tylko odbudowy uszkodzonej bazy UTXO (niewydanych wyjść) bez faktycznego reindeksowania bloków (-reindex-chainstate). 
• usunięcie z kodu wbudowanego programu do wydobywania bloków (minera). Jako że przy obecnej trudności nie da się w skończonym czasie wydobyć bloku za pomocą CPU funkcja ta oraz wywołania RPC jej dotyczące zostały usunięte. 
• zmiana implementacji funkcji bytespersigop obsługującej adresy multisig na bezpieczniejszą

 

zmiany w protokole P2P:

• usunięcie funkcji „alert”, 
• wprowadzenie filtra transakcji po opłacie transakcyjnej BIP133, 
• przy przesyłaniu grup transakcji transakcje grupowane są w łańcuchy aby uniknąć ciągłej ich reorganizacji oraz ogranicznyć pojawianie się transakcji osieroconych (z nieznanymi wejściami)
• zwiększenie ilości transakcji osieroconych przechowywanych w pamięci z 5kb do 100kb – pozwoli to ograniczyć przesyłanie łańcuchów transakcji czekających na zatwierdzenie 
• niskopoziomowe zmiany w komunikatach RPC 
• zmiany w przekazywaniu transakcji w komendach getmempoolentry, getmempoolancestors, getmempooldescendants.
• zmiana hasza funkcji gettxoutsetinfo na zgodną w wersjach x32 i x64
• pełne wsparcie UTF-8 w API RPC
• zmiany nazwy OP_NOP2 na OP_CHECKLOCKTIMEVERIFY (BIP 65)
• zmiany nazwy OP_NOP3 na OP_CHECKSEQUENCEVERIFY (BIP 112)
• zmiana sortowania w getrawmempool
• wprowadzenie nowych wywołań: generatetoaddress, importprunedfunds, removeprunedfunds, signmessagewithprivkey, getmempoolancestors, getmempooldescendants, getmempoolentry, createwitnessaddress, addwitnessaddress.
• usunięcie wywołań: setgenerate, getgenerate.
• nowe opcje w: fundrawtransaction: includeWatching, changeAddress, changePosition i feeRate.
• wywołania i odpowiedzi ZMQ są numerowane, co pozwoli uniknąć/wykryć brakujące komunikaty

 

Niestety, pomimo zawarcia w kodzie funkcji obsługi SW (segregated witness – oddzielenia podpisów) nadal nie ma określonego terminu wdrożenia tej funkcji do sieci Bitcoin. Nadal nie ma również żadnego podejścia do zwiększenia wielkości bloku, które powinno być priorytetem wprowadzonym najpóźniej w kolejnym wydaniu. Samo zwiększenie domyślnej ilości pamięci przeznaczonej na mempool (zweryfikowane transakcje oczekujące na zatwierdzenie w bloku) wpływa na wydajność sieci (węzły będą mniej razy przesyłać transakcje) ale w żaden sposób nie wpłynie na przepustowość, czyli ilość transakcji możliwych do zatwierdzenia w jednostce czasu.

 

Zanim ściągiesz wersję wykonywanlną sprawdz autentyczność pliku poprzez weryfikację podpisu!