Zmiany w konsensusie i warstwie peer-to-peer stojące za segwitem obejmują 1486 wierszy kodu, do tego 3338 wierszy testów. Testy szły od wersji Pietera Wuille'a na sidechainie Elements w 2015 roku, przez segnet, po zwykły testnet Bitcoina w maju 2016 roku. Podpisy Schnorra i MAST wymieniono jako późniejsze aktualizacje, które segwit by ułatwił.
Górnicy mają czas do bloku 419328: soft fork CSV osiągnął lock-in w bloku 417312, po tym jak 1946 z 2016 bloków (96,53%) zasygnalizowało BIP68, BIP112 i BIP113. Wszystkie węzły wydobywcze i zapasowe muszą działać na Bitcoin Core lub Knots 0.12.1, a kto ma wersję bloku zapisaną na sztywno, musi wyzerować bit 0.
BIP9 pozwala górnikom sygnalizować gotowość na maksymalnie 29 równoczesnych soft forków za pomocą bitów w nagłówku bloku. Propozycja osiąga lock-in, gdy sygnalizuje 95% bloków w oknie 2016 bloków, i aktywuje się jedno przeliczenie trudności później, chyba że wcześniej upłynie jej limit czasu. W odróżnieniu od IsSuperMajority nie osieroci bloku bez sygnału, który przestrzega nowych reguł.
Peery korzystające z przekazywania bloków kompaktowych (BIP152) wymieniają szkic każdego nowego bloku, około 9 KB dla przeciętnego bloku 1 MB, plus narzut na transakcje, których odbiorca nie ma. W eksperymentach na żywo w trybie wysokiej przepustowości, z maksymalnie 6 wstępnie wypełnionymi transakcjami, znacznie ponad 90% bloków rozeszło się bez dodatkowego żądania.
Sygnalizacja soft forka CSV rusza o północy 1 maja 2016 roku wraz z Bitcoin Core 0.12.1, pierwszym wdrożeniem przez bity wersji BIP9. Obejmuje BIP68, BIP112 i BIP113; OP_CHECKSEQUENCEVERIFY pozwala zamrozić monety na określony czas po potwierdzeniu, na czym będzie się opierać Lightning Network. System alertów p2p jest teraz domyślnie wyłączony.
Marco Falke został w Bitcoin Core nowym opiekunem działu Testing & QA, ogłosił Wladimir van der Laan. Będzie odpowiadać za scalanie pull requestów do frameworka testowego, co jest naturalnym krokiem po roku pracy nad testami jednostkowymi, pokryciem i recenzowaniem kodu innych współtwórców.
Problemy z bezpieczeństwem i nowe wydania mają już własną listę ogłoszeń Bitcoin Core, na którą trzeba się zapisać i na której pojawiają się wyłącznie komunikaty. Użytkownicy prosili o sposób otrzymywania samych krytycznych powiadomień, a projekt spodziewa się bardzo małej liczby wiadomości.
Rozwiązanie sudoku 16x16 sprzedano za 0,10 BTC w pierwszej udanej płatności Zero-Knowledge Contingent Payment w sieci Bitcoin, pokazanej na żywo na konferencji Financial Cryptography 2016 na Barbadosie. Sprzedawcą był Sean Bowe z zespołu Zcash, który wykonał niemal całą pracę inżynierską. W tym protokole dane zmieniają właściciela tylko wtedy, gdy zapłata dojdzie do skutku, bez arbitrażu strony trzeciej.
OpenSSL znika ze sprawdzania podpisów w Bitcoin Core 0.12.0. Zastępuje go libsecp256k1, co skraca reindeksację i walidację nowych bloków do mniej niż połowy dawnego czasu. Mempoole dostają domyślny limit 300 MB, który zamyka atakującym drogę do wywracania węzłów z małą ilością RAM. Nowe są też opt-in Replace-by-Fee (BIP 125) i -maxuploadtarget do ograniczania ruchu wychodzącego.
Strona, na której pierwotnie opublikowano dokument Bitcoina, nie jest powiązana z projektem Bitcoin Core, który ma własną oficjalną witrynę, informują deweloperzy. Prace toczą się na IRC, GitHubie i liście mailingowej bitcoin-dev. Projekt nie bierze odpowiedzialności za inne fora i prosi członków społeczności, by nie urządzali nalotów ani ataków typu odmowa usługi.
Plastyczność wywoływana przez strony trzecie kończy się dla transakcji, których wszystkie wejścia to wydatki segwit, bo podpisy przechodzą do witnessa, który nie wpływa już na txid. Korzystają na tym autorzy portfeli i Lightning Network. Haszowanie podpisów staje się też liniowe, a każdy bajt jest haszowany najwyżej dwa razy; w starym schemacie walidacja jednego bloku zajęła już 25 sekund.
Deweloperzy mogą już testować Segregated Witness we własnej sieci: wystarczy skompilować gałąź segwit i dodać -segnet do bitcoind i bitcoin-cli. Ledger, Trezor, Electrum i Bitgo zapowiedziały obsługę segwita, a mSIGNA i Green Address oferują wczesne wersje poglądowe.
Film pokazuje aktywność commitów w repozytorium Bitcoin Core w 2015 roku, gdy ukazały się 2 główne wersje i 5 wydań serwisowych, a aktywowano dwa soft forki: BIP66 i BIP65, przy czym ten drugi dodał CHECKLOCKTIMEVERIFY. Projekt zwraca uwagę, że recenzenci, testerzy i tłumacze nie pojawiają się w danych o commitach.
O regułach konsensusu nie decyduje zespół Bitcoin Core, twierdzą jego współtwórcy; decydują użytkownicy, wybierając oprogramowanie, i dlatego program nie ma automatycznych aktualizacji. Autorzy wolą soft forki, a hard forki rezerwują na rzadkie przypadki niemal powszechnej zgody. Drogę do bardzo dużej skali widzą w dodatkowych warstwach nad protokołem.
Bloki pod nowym limitem kosztu segwita mogą osiągnąć nieco poniżej 4 MB, ale według obliczeń Anthony'ego Townsa blok z jednopodpisowymi transakcjami P2PKH to około 1,6 MB, a z multisigiem 2-z-2 około 2,0 MB. Wstępny harmonogram z FAQ zakłada wdrożenie segwita w 0.13.1 w październiku 2016 roku, a w 2017 roku słabe bloki, IBLT lub Lightning.
Pod planem zwiększania przepustowości podpisało się 57 osób, wśród nich Pieter Wuille, Gregory Maxwell i Wladimir J. van der Laan, uznając go za najlepszą kontynuację ich prac nad skalowalnością w Bitcoin Core. Lista pozostaje otwarta na kolejne podpisy.
Plan Gregory'ego Maxwella, wysłany na listę bitcoin-dev pod koniec Scaling Bitcoin w Hongkongu, opiera się na libsecp256k1, bitach wersji BIP9 i Segregated Witness Pietera Wuille'a. Autor podaje, że ConnectTip działa w 0.12 siedem razy szybciej, a segwita opisuje jako soft fork wyprowadzający podpisy poza obecny limit rozmiaru bloku, co w najgorszym razie równa się wzrostowi do 4 MB.
Współtwórcy techniczni, wśród nich Wladimir J. van der Laan i Pieter Wuille, podpisali list z apelem do społeczności, by nie przesądzać z góry o propozycjach skalowania. Zamiast tego wskazują proces konsensusu i dwa otwarte warsztaty Scaling Bitcoin: w Montrealu 12–13 września i w Hongkongu 6–7 grudnia.