Kurs5080

Bitmarket

Bitcantor.com

 

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

 

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!

infobtc-1160x653

BitCoin Reklama GiF 380x280