Kurs18600

Bitmarket

Bitcantor1

 

bitcoincore0.14

 

Pojawiała się kolejna wersja Bitcoin Core oznaczona numerem 0.14. Mimo, iż od wydania poprzedniej wersji minęły raptem dwa miesiące, znajdziemy w niej wiele zmian. Znacznie poprawiono również szybkość działania.

 

1. Wydajność.

Szybkość weryfikacji oraz propagacji danych została znacznie zwiększona, co znacznie zmniejszy czas synchronizacji oraz wstępnego ładowania bloków

- wprowadzono bufor podpisów skryptów w formie „cuckoo cache” co pozwala na buforowanie większej liczby podpisów i szybsze ich odnajdywanie

- wprowadzono określanie „najprawdopodobniej poprawnych” bloków, dla których pełna weryfikacja podpisów nie jest przeprowadzana (więcej poniżej, P 17)

- w pewnych przypadkach „kompaktowe bloki” są przekazywane dalej przed zakończeniem ich pełnej weryfikacji, zgodnie z BIP152

- komunikacja P2P została przepisana pod kątem wydajności i prędkości. Transmisja danych nie jest już blokowana przez weryfikację, w wyniku czego pobieranie danych jest w wielu przypadkach kilka/kilkanaście razy szybsze.

- bufor bazy UTXO (niewydanych wyjść) używa teraz wolnej pamięci bufora mempool (transakcji oczekujących). Pozwala to przyspieszyć pierwszą synchronizację, gdzie zapytania do bazy UTXO są kluczowe, a mempool jest nie używany.

 

2. Ręczne czyszczenie bazy bloków (pruning)

Od wersji v0.11 możliwe jest kasowanie z dysku „starych” bloków które nie są już potrzebne do pracy węzła. Pozwala to zaoszczędzić znaczną ilość miejsca na dysku twardym. Obecnie jest możliwe wykonanie pruningu przez ustawienie „prune=1” w konfiguracji (lub przekazanie parametru „-prune=1” przy uruchomieniu węzła) a następnie wywołanie w konsoli komendy „pruneblockchain”.

 

3. ZMQ pod Windows

System notyfikacji ZeroMQ pod Windows został przywrócony, po usunięciu błędów w ZMQ.

Ogólny opis używania ZMQ https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md

 

4. Możliwość wyłączenia transmisji danych

Wprowadzono możliwość włączenia/wyłączenia transmisji danych używając ikonki sieci lub komendy RPC „setnetworkactive”

 

5. Nakładka modalna o braku synchronizacji

Gdy Bitcoin Core nie jest zsynchronizowany wyświetlana półprzeźroczysta informacja dla użytkownika. Przedstawia ona informację o postępie synchronizacji i planowanym czasie zakończenia. Nakładka może być schowana/pokazana ponownie po kliknięciu.

 

6. Wsparcie dla komend RPC w formie parametr=dane

W komendach RPC można przekazywać dane w formie nazwa=wartość (prócz struktury JSON), wymagane jest przekazanie parametru „-named”

 

7. Włączenie RBF na starcie węzła

Możliwe jest przekazanie parametru „-walletrbf” podczas startu węzła. Spowoduje to generowanie wychodzących transakcji jako RBF i umożliwi wykonanie komendy „bumpfee” zwiększającej opłatę w danej transakcji. Domyślnie opcja ta jest wyłączona.

 

8. Hasła (i inne dane prywatne) nie są zapisywane w historii konsoli

Wcześniej wprowadzone komendy są dostępne przez użycie klawisza „strzałka w górę”. Dane krytyczne (hasła, klucze prywatne itd.) są teraz zastępowane przez (…)

 

9. Zapisywanie danych mempool

Podczas wyłączania węzła aktualny mempool zapisywany jest do piliku mempool.dat

Pozwala to na szybszy restart węzła, zaczytując oczekujące transakcje z dysku zamiast ściągać je ponownie z sieci. Pozwala to też zachować wszystkie zmiany wprowadzone np. przez komendę „prioritisetransaction”.

 

10. Ostateczne ostrzeżenie (Final Alert)

Od wersji 0.12.1 Core nie używa systemu alertów przekazywanych przez sieć P2P. Obecnie wszystkie starsze wersje węzłów otrzymują komunikat o kompromitacji klucza używanego do wysyłania alertów systemowych.

 

11. Zmiany w GUI

- możliwe jest zresetowanie opcji GUI przez przycisk w menu opcji, jak również przez przekazanie parametru „-resetguioptions” podczas startu. Wymusza to również ponowne wybranie katalogu mieszczącego dane bloków;

- możliwość wyboru wielu peerów w opcjach debugowania. Pozwala to na banowanie lub rozłączanie wielu węzłów naraz;

- dodano znacznik informujący o używaniu portfela w wersji HD lub starszej (prawy górny róg aplikacji). Gdy używamy starego formatu pliku portfela ikonka jest szara i przekreślona.

 

12. Niskopoziomowe zmiany w RPC i HTTP REST

Wprowadzono nowe komendy RPC: „importprunedfunds”, „preciousblock”, „importmulti”, „getmemoryinfo”, „bumpfee”.

Drobne zmiany w parametrach: „importprunedfunds”, „getaddednodeinfo”, „getmininginfo”.

Usunięcie komendy „getrawtransaction” dla transakcji spoza mempool, chyba że mamy włączony indeks transakcji („txindex=1”)

Gdy zapytanie REST zawiera błędne parametry zwracany jest błąd 400 (bad request) zamiast 500 (internal server error).

 

13. Zmiana polityki obliczania minimalnych opłat transakcyjnych

Od wersji 0.12 Core automatycznie ogranicza wielkość mempool aby usprawnić generowanie nowych bloków. Obecnie dodatkowym domyślnym limitem jest minimum 1000sato/1kb transakcji aby transakcja była rozgłaszana a efektywnie 3000sato/1kb aby była dołączana do bloku. Górnicy mogą użyć nowej opcji „blockmintxfee” (domyślnie 1000s/kb). Zaleca się nieużywanie opcji „minrelaytxfee” aby nie ingerować w automatyczne obliczanie opłat.

 

14. Zmiany w przewidywaniu koniecznych opłat transakcyjnych

- od wersji 0.13.2 estymacja dla dołączenia do najbliższego bloku została wyłączona, nie można przesunąć suwaka na „1”. Komenda „estimatefee 1” zawsze zwróci „-1” a „estimatesmartfee 1” zawsze szuka dla celu „2”.

- domyślna wartość estymacji została ustalona na 6 bloków (wcześniej 25 dla GUI i 2 dla komend RPC).

 

15. Usunięcie obliczania priorytetu transakcji

- obliczanie priorytetu transakcji zostało całkowicie usunięte. Wywołania RPC są nieaktywne i zwracają odpowiednio „-1” lub „1e24”. Format bazy „fee_estimates.dat” został zmieniony pod tym kątem a plik zostanie automatycznie przekonwertowany na nowy format.

- wsparcie dla sortowania transakcji wg priorytetu (wieku monet) podczas miningu jest uznany za przestarzały i zostanie usunięty w kolejnej wersji.

- komenda „prioritisetransaction” zostaje w użyciu umożliwiając zwiększanie opłat.

W praktyce oznacza to, że nie wyślemy za darmo nawet 100BTC nie ruszanych od 5 lat, co do tej pory dawało wysoki priorytet i umożliwiało wysyłkę bez fee.

 

16. Obsługa połączeń P2P

- węzły dodane ręcznie przez „addnode” mają teraz własny limit 8 prób połączeń, połączenia te nie są liczone do limitu „maxconnections”

- nowe połączenia do ręcznie dodawanych węzłów są teraz wykonywane szybciej

 

17. Wprowadzenie bloków „prawdopodobnie poprawnych”

- większość czasu wstępnego ładowania bloków zajmuje weryfikacja skryptów/podpisów. Weryfikacja oczywiście musi nastąpić, aby zapewnić spójność systemu, jednakże wiedząc, że dany blok jest prawidłowy możemy nie weryfikować dokładnie bloków go poprzedzających

- dodano nową opcję konfiguracyjną „assumevalid” pozwalającą ustalić, do którego bloku przyjmuje się, że wcześniejsze są poprawne. W przeciwieństwie do „punktów kontolnych” (checkpoints) nie wymusza to używania konkretnego łańcucha bloków. Oprogramowanie Core ma oznaczony ostatni poprawny blok przed wydaniem jako „prawdopodobnie poprawny”. Użycie tej funkcji pozwala znacząco przyspieszyć proces pierwszej synchronizacji węzła.

- opcję można wyłączyć przez użycie przełącznika „-assumevalid=0”

 

18. Ponowne użycie adresu przez „fundrawtransaction”

- w poprzednich wersjach użycie „getnewaddress” zaraz po „fundrawtransaction” powodowało zwrócenie adresu reszty użytego w „fundrawtransaction” zamiast kolejnego nowego adresu. W wersji 0.14 zostało to poprawione.

- można wymusić stare zachowanie przez wywołanie opcji „reserveChangeKey=false”

- zalecane jest użycie „getrawchangeaddress” w połączeniu z opcją „changeAddress” funkcji „fundrawtransaction”.

 

19. Nieużywana dotąd pamięć mempool obecnie jest używana przez UTXO

Przed wersją 0.14 pamięć zarezerwowana na mempool (opcja „maxmempool”) była nie używana podczas pierwszej synchronizacji. Obecnie baza UTXO (której wielkość możemy ustalić przez „dbcache”) używa również pamięci mempool, gdy ta jest dostępna. Może więc być zauważalne zwiększone użycie RAM podczas pierwszej synchronizacji. Może to mieć znaczenie na systemach z małą ilością pamięci oraz dla użytkowników polegających na ograniczeniu przez „dbcache”.

 

 

- Nowe węzły powinny synchronizować się znacznie szybciej, dzięki założeniu że bloki przed wydaniem Core nie wymagają już pełnej weryfikacji

- Szybsza komunikacja P2P przez oddzielenie jej od weryfikacji danych

 

 

bitbay 3.0

infobtc-1160x653

BitCoin Reklama GiF 380x280