za
bitcoincore0.12

Duże zmiany w nowej wersji Bitcoin Core v0.12.0

2016-02-24
Techniczne
Konferencja Kryptoraport

Światło dzienne ujrzała kolejna wersja Bitcoin Core oznaczona numerem 0.12.0. Nowa wersja wprowadza dużo istotnych zmian, również tych wpływających na wydajność i zużycie zasobów.

 

 

Światło dzienne ujrzała kolejna wersja Bitcoin Core oznaczona numerem 0.12.0. Nowa wersja wprowadza dużo istotnych zmian, również tych wpływających na wydajność i zużycie zasobów.

 

Nowy Core zmienia sposób zapisu danych na dysku, przez co zmiana na wersję wcześniejszą będzie wymagać rescanu (v0.10+) lub pobierania bloków (<v0.10).

 

Wersja wprowadza sporo nowości które, bazując na oficjalnym “release note”, postaramy się przybliżyć:

 

1. Zmiana sposobu weryfikacji podpisów.

Ze względu na kolejne zmiany w bibliotece OpenSSL które mogą spowodować brak wymaganej wstecznej kompatybilności Core odchodzi od tej biblioteki, używając w zamian libsecp256k1. Daje to dodatkową korzyść, w postaci znacznego przyspieszenia procesu weryfikacji podpisów: zysk rzędu 5-7x! Oznacza to szybsze weryfikacje nowych transakcji/bloków jak również znaczne przyspieszenie pierwszej synchronizacji nowego węzła – powinna ona przebiegać o połowę krócej.

 

2. Możliwość blokowania transferu wychodzącego.

Sporą część danych wysyłanych przez węzły są dane „starych” bloków przekazywane nowym węzłom w sieci. W niektórych przypadkach łącz o ograniczonej ilości danych mogło to doprowadzać do wyłączania węzła lub obciążania użytkownika dodatkowymi kosztami.

 

Wprowadzony w tej wersji przełącznik -maxuploadtarget pozwala na limitowanie ilości danych jakie są dziennie wysyłane. Nie jest to całkowita blokada („hard limit”), Core zacznie odłączać węzły które żądają „starych” danych gdy transfer zacznie zbliżać się do ustawionego limitu.

 

3. Wprowadzenie rozgłaszania nagłówkami BIP130

Pomiędzy zgodnymi węzłami (czyli v0.12+) możliwa jest wymiana całych nagłówków bloków zamiast samych haszy przy przesyłaniu nowego bloku (używany jest nowy komunikat „headers” zamiast starego „inv”) . Pozwala to ograniczyć ilość wymienianych danych pomiędzy węzłami oraz szybszą propagację nowych bloków.

Równocześnie węzły z włączonym czyszczeniem starych bloków („block pruning”) mogą przesyłać nowe bloki do zgodnych węzłów.

 

4. Ograniczenie ilości transakcji w buforze pamięci.

Wraz z wzrostem ilości transakcji czekających na potwierdzenie powiększanych przez ataki spamujące transakcjami zdarzało się, że węzły nie mające wystarczająco dużo RAM były wyłączane z powodu przepełnienia pamięci. Ta wersja pozwala na ograniczenie pamięci transakcji (mempool), domyślnie do 300MB. Przy przekroczeniu tej wartości w pierwszej kolejności z mempoola znikną łańcuchy transakcji niepotwierdzonych (najczęstszy wzór ataku to kolejka transakcji wzajemnie wydających swoje wyjścia) oraz transakcje z załączonym fee poniżej 1000sato za 1kB transakcji.

 

5. Wprowadzenie mechanizmu RBF (replace by fee) BIP125

Kontrowersyjny Mechanizm RBF pozwala zastąpić transakcję, która „utknęła” nową transakcją z większą opłatą. Wymagane jest jednak, aby „stara” transakcja była oznaczona jako „zastępowalna” a nowa transakcja musi mieć opłatę większą, niż standardowo wymagana.

 

Mechanizm RBF można wyłączyć przełącznikiem -mempoolreplacement=0. Spowoduje to zachowanie Core identycznie z obecnym. Wyłączenie RBF dalej umożliwi nam dokonywanie transakcji bez potwierdzeń w serwisach, które to umożliwiają.

 

6. Autentyfikacja RPC przez „ciasteczko”

Wprowadzono możliwość autentyfikacji komend RPC przez użycie pliku o losowej zawartości. Tak więc nie mając dostępu do pliku nie można przesłać komend RPC. Rozwiązanie takie jest stosowane np. w kliencie TOR.

 

7. Brak przekazywania/wydobywania transakcji używających OP_RETURN do przekazywania danych

Wcześniej dopuszczalne były transakcje przekazujące pojedynczy „pushdata”. Teraz takie transakcje nie są przekazywane ani wydobywane – stały się niestandardowe.

 

8. Zmiana traktowania transakcji priorytetowych.

Nowa wersja wprowadza rewolucję w traktowaniu transakcji o wysokim priorytecie – domyślnie NIE MA już miejsca w bloku na darmowe transakcje o wysokim priorytecie! Dodatkowo transakcje takie nie będą nawet przekazywane gdy mempool jest pełny.

 

Można przywrócić stary mechanizm używając przełącznika -blockprioritysize=<n> (n= wielkość miejsca w bajtach, wcześniej domyślne było 50kB czyli 50000).

Jednocześnie zmieniony (uproszczony) został sposób obliczania priorytetu, przez co transakcje wydające niepotwierdzone wyjścia mają znacznie niższy priorytet niż wcześniej i nie jest on ponownie przeliczany w momencie potwierdzenia transakcji wejściowych.

 

W kolejne wersji 0.13 planuje się całkowicie odejść od obecnego mechanizmu priorytetu transakcji. Nie jest jeszcze ustalone w jakim kierunku pójdzie ten mechanizm. Deweloperzy liczą na głos środowiska.

 

9. Automatyczne włączenie nasłuchiwania na TORze.

Jeżeli TOR jest dostępny w odpowiedniej wersji, Core automatycznie utworzy „hidden service” i będzie nasłuchiwać połączeń przychodzących z TORa. Mechanizm ten jest domyślnie włączony i jest kolejnym krokiem do umożliwienia działania Bitcoina wyłączenie przez TOR (obecnie „gdzieś na świecie” musi istnieć dostępny przez clearnet węzeł Bitcoin).

 

10. Notyfikacje przez ZMQ.

Core opcjonalnie może używać socketów ZMQ do informowania klientów o nowych transakcjach i blokach.

 

11. Opłaty transakcyjne.

Core wprowadza domyślnie automatyczne obliczanie wymaganej opłaty transakcyjnej. Możemy włączyć „stary” mechanizm obliczania opłat przełącznikiem -paytxfee=<n>

 

Obecny model ma sztywne ograniczenia od góry (0.1BTC/kB) i dołu (1000sat/1kB) oraz wartość „bezpieczną” przy braku danych do wyliczenia (0.0002BTC/kB). Domyślnie opłata obliczana jest na wartość pozwalającą potwierdzić transakcję w ciągu kolejnych 2 bloków.

 

12. Transakcje skonfliktowane w portfelu.

Core będzie informować użytkownika o niepotwierdzonych skonfliktowanych transakcjach w portfelu przez podawania ujemnej wartości potwierdzeń informującej, ile potwierdzeń ma transakcja konfliktowa. Może być konieczne wykonanie -rescan aby wykryć konflikty ze starymi transakcjami.

 

Wprowadzone jest też nowe pole „trusted” w informacji o transakcji informujące o ewentualnych transakcjach konfliktowych (wydających te same wyjścia) w mempoolu.

 

13. Odchudzanie portfela.

W portfelu nie są już zapisywane informacje o źródle (merklee) transakcji. Ze względu na zmiany w sposobie zapisu bloków i posiadaniu bazy unspentów nie jest to już potrzebne.

 

14. Używanie portfela w Core z włączonym czyszczeniem bloków.

Core v0.12 umożliwia używanie portfela z włączonym pruningiem, wyłączone są jednak opcje importu portfela, adresu i klucza prywatnego. Przy włączonym pruningu możemy więc używać Core tylko z nową pulą adresów.

 

Używana przestrzeń dyskowa spada z 60GB do około 2GB. Minimalnie trzeba przechować ostatnie 550 bloków, co pozwala na bezpieczne używanie w przypadku powstania „zwykłych” kilku blokowych forków.

 

15. BIP111 – bit serwisowy „NODE_BLOOM”

Nowy Core informuje klienty SPV (oraz inne połączone węzły) o posiadaniu działającej funkcji filtrów Blooma, umożliwiające anonimowe odpytywanie o bazę unspentów dla adresu lub grupy adresów.

 

16. Kolejność przełączników zawsze zgodna z wpisaną

Core zawsze honoruje kolejność wprowadzanych przełączników, wcześniej priorytet miały opcje włączające (np. wpisując „-zX -bezX” wchodziła opcja „-zX”)

 

17. Niskopoziomowe zmiany w API RPC

– wartości monetarne mogą być stringami (wcześniej wymagane było przesyłanie jako liczba)

– własność „asm” każdego skryptu podpisu zawiera teraz zdekodowany typ hasza dla każdego podpisu zawierające poprawny zdefiniowany typ hasza.

– OP_NOP został zmieniony na OP_CHECKLOCKTIMEVERIFY przez BIP65

 

Zmianom ulegają przez to:

  •    RPC getrawtransaction
  •    RPC decoderawtransaction
  •    RPC decodescript
  •    REST /rest/tx/ (JSON format)
  •    REST /rest/block/ (JSON format when including extended tx details)
  •    bitcoin-tx -json

 

18. Usunięcie wsparcia dla RPC przez SSL

Kolejny krok do całkowitego usunięcia OpenSSL z Core.

Można ręcznie skonfigurować dostęp po SSL używając np. „stunnel”

 

19. Zmiany w kodzie tworzenia bloków.

Kod budowania nowych bloków został mocno przebudowany, dzięki czemu tworzenie nowych bloków jest szybsze i wymaga mniej mocy obliczeniowej i pamięci.

 

20. Zapis “czarnej listy” na dysku

Lista peerów które zostały zbanowane jest teraz zapisywana na dysku, przy restarcie klienta bany nie są zerowane. Wprowadzono komendę RPC „clearbanned” do czyszczenia banów raz „setban” do ręcznego banowania lub odbanowania pojedynczego peera.

 

 

Bitcoina i inne kryptowaluty kupisz w prosty i bezpieczny sposób na giełdzie zondacrypto.

Tagi

Newsletter Bitcoin.pl

Więcej niż bitcoin i kryptowaluty. Najważniejsze newsy i insiderskie informacje prosto na Twój email.

Dbamy o ochronę Twoich danych. Przeczytaj naszą Politykę Prywatności