Poza ujawnioną już awarią CVE-2018-17144 pozwalała górnikowi zwiększyć podaż Bitcoina w wersjach od 0.15.X do 0.16.2 przez dwukrotne wydanie wyjścia w jednej transakcji. Deweloperzy wstrzymali się z ujawnieniem tej części, aby dać czas na przejście na 0.16.3 lub 0.17.0rc4. Uważa się, że łatkę ma już ponad połowa mocy obliczeniowej sieci, nie są znane próby wykorzystania luki, a użytkownicy podatnych wersji powinni się zaktualizować.
Przez CVE-2018-17144 Bitcoin Core od 0.14.0 do 0.16.2 wywraca się na bloku z transakcją, która dwukrotnie wydaje to samo wejście, a użytkownicy mają natychmiast przejść na 0.16.3. Taki blok mógłby wyprodukować tylko górnik gotowy zrezygnować z co najmniej 12,5 BTC dozwolonego przychodu.
RPC verifytxoutproof w Bitcoin Core 0.16.2 jest już odporne na kosztowny atak na dowody SPV ujawniony na początku czerwca, ale prawdziwe klienty SPV nadal są narażone. Osobna poprawka sprawia, że abandontransaction porzuca wszystkich potomków transakcji, a nie tylko jej dzieci.
Transakcji z OP_CODESEPARATOR w skryptach podpisów legacy Bitcoin Core 0.16.1 już nie przekazuje. Ta zmiana polityki ułatwi wdrażanie przyszłych poprawek dla bloków wolno przechodzących walidację. Górnicy tracą opcję -blockmaxsize na rzecz -blockmaxweight i dostają poprawkę błędu, który mógł ich kosztować przychody przy dwóch blokach wydobytych w krótkim odstępie.
Segwit staje się domyślny dla portfela w Bitcoin Core 0.16.0: nowe adresy to p2sh-segwit, chyba że -addresstype mówi inaczej, a natywne adresy bc1 z BIP173 można generować i na nie płacić. Nowe portfele są wyłącznie HD i starsze wersje ich nie wczytają, a ekran wysyłania w GUI domyślnie włącza RBF z BIP125.
Na wypadek przyszłych rozwidleń sieci Bitcoin Core 0.15.1 rozłącza podczas początkowej synchronizacji peery oferujące łańcuch poniżej minimum-chain-work oraz peery wychodzące podające nagłówki znane jako nieprawidłowe. Czubek łańcucha stojący w miejscu przez 30 minut uruchamia dodatkowe połączenie wychodzące. Górnicy tracą bezpośredni dostęp do blockmaxsize: opcja jest wycofana i oznacza już tylko limit wagi.
Awaria GUI przy starcie wymusiła wydanie Bitcoin Core 0.15.0.1: część klientów aktualizujących się do 0.15.0 wywracała się na ustawieniu własnej opłaty, którego interfejs już nie oferuje. Nieprawidłową wartość obsługuje minimalna łatka #11332.
Szacunki opłat w Bitcoin Core 0.15.0 sięgają 1008 bloków naprzód zamiast 25, a użytkownicy GUI mogą podnieść opłatę niepotwierdzonej transakcji przez Replace-By-Fee. Baza chainstate oparta na pojedynczych wyjściach przyspiesza początkowe pobieranie bloków o 30–40%. Konwersja odbywa się automatycznie przy pierwszym uruchomieniu i trwa od około 5 do 30 minut.
Stali współtwórcy Bitcoin Core nie mają nic wspólnego z btc1, implementacją Segwit2x, a projekt odrzuca twierdzenia, że to niezbędna aktualizacja, i nazywa ją spornym odejściem od reguł sieci. Segwit, soft fork oczekiwany w ciągu kilku dni, nie ma związku z tym hard forkiem i od większości użytkowników niczego nie wymaga. Oświadczenie ostrzega też, że Segwit2x nie planuje silnej ochrony przed powtórzeniem transakcji.
Każdy, kto włączył UPnP, powinien bezzwłocznie zainstalować Bitcoin Core 0.14.2: błąd znakowości liczby całkowitej w dołączonym miniupnpc, CVE-2017-8798, pozwala napastnikom z sieci lokalnej wywołać odmowę usługi, a być może też inne szkody. UPnP pozostaje domyślnie wyłączone, więc węzłów, które nigdy go nie włączyły, problem nie dotyczy.
Górnicy bez segwita będą mogli po aktywacji nadal używać getblocktemplate, bo Bitcoin Core 0.14.1 usuwa z szablonu transakcje segwit. Domyślne -dbcache wynosi teraz 450 MiB, a limit obowiązuje także w szczytach opróżniania. Zmienione nazwy argumentów w createrawtransaction i disconnectnode psują wywołania używające nazwanych argumentów z 0.14.0.
Portfel nowego węzła mógłby wysyłać i odbierać środki jeszcze przed końcem synchronizacji dzięki hybrydowemu trybowi SPV z pełnymi blokami z mapy drogowej Bitcoin Core. Bloki pobierane są od najstarszego klucza portfela, a pełna walidacja trwa w tle. Wycieki prywatności filtrów Blooma znikają kosztem większego zużycia pasma, a przy płatnościach warto poczekać na 6 lub więcej potwierdzeń.
Zamiana ECDSA na podpisy Schnorra skurczyłaby multisig 50-z-50 do rozmiaru wydatku z jednym kluczem i ukryła jego reguły przed obserwatorami. Mapa drogowa Bitcoin Core wskazuje jako główną przeszkodę atak anulowania, w którym złośliwy sygnatariusz odejmuje klucz innego użytkownika. Odpowiedzią jest delinearyzacja, choć jej dowód bezpieczeństwa wciąż przechodzi recenzję.
Buforowanie podpisów w Bitcoin-Qt 0.7.0, Ultraprune z LevelDB w 0.8.0 i synchronizacja headers-first w Bitcoin Core 0.10 to bohaterowie pierwszej części przeglądu przyspieszeń oprogramowania referencyjnego. Samo równoległe sprawdzanie skryptów dało w testach deweloperów od 35% do 100%.
Nowe węzły kończyły początkowe pobieranie bloków na Bitcoin Core 0.14.0 5,7 raza szybciej niż na 0.13.2 w teście na Amazon EC2 z ustawieniami domyślnymi: 6 godzin 24 minuty wobec 1 dnia 12 godzin 40 minut. Źródłem przyspieszenia są założenie o poprawności bloków i pamięć współdzielona przez mempool i pamięć podręczną UTXO. Portfele dostają też opcjonalne podbijanie opłaty, domyślnie wyłączone.
Wysyłki z portfela, które trafiają na limit niepotwierdzonych łańcuchów, nie zwracają już w Bitcoin Core 0.13.2 błędu RPC. Zgłaszają sukces, a dodanie do mempoolu jest ponawiane przy ponownym rozgłoszeniu, bez potrzeby restartu. Szacunki opłat dla celu 1 bloku są wyłączone, a obsługa nieprawidłowych bloków kompaktowych została poprawiona.
Największy koszt w bajtach niesie opakowanie segwita w P2SH: 19% więcej dla P2WSH/P2SH i 11% dla P2WPKH/P2SH przy transakcji 180-bajtowej, jak wynika z zestawienia Bitcoin Core dotyczącego skutków BIP141. Walidacja wymaga około pięciu dodatkowych haszy SHA256 na transakcję. Jako ryzyka wymieniono błędy, większe bloki i niższe opłaty, a autorzy nie zajmują stanowiska w sprawie aktywacji.
Górnicy dostają w Bitcoin Core 0.13.1 kod do sygnalizowania soft forka segwit, a sygnalizacja rusza od 15 listopada 2016 roku na początku kolejnego okresu przeliczania trudności. Do lock-inu potrzeba 95% bloków w okresie 2016 bloków, a aktywacja następuje okres później. Portfele pozostają zgodne, więc działania mogą wymagać tylko od górników.
Segwit potrzebuje dwóch grup: górników sygnalizujących bit 1 w 95% bloków w okresie przeliczania trudności i wystarczającej liczby pełnych węzłów z Bitcoin Core 0.13.1 lub zgodną implementacją. Sygnalizacja rusza z pierwszym przeliczeniem trudności przypadającym 15 listopada 2016 roku lub później. Osobne kroki opisano dla górników, operatorów węzłów, użytkowników portfeli i deweloperów, także tych, którzy nie chcą się aktualizować.
Kod segwita trafia do Bitcoin Core 0.13.0, ale na mainnecie pozostaje nieaktywny; do użycia będzie potrzebna późniejsza wersja, zapewne 0.13.1. Przekazywanie bloków kompaktowych (BIP152) łagodzi skoki zużycia pasma, a nowe portfele korzystają z kluczy HD BIP32, więc jedna kopia zapasowa obejmuje wszystkie przyszłe klucze prywatne. Do oficjalnych plików dołączają też kompilacje Linux ARM.