Miękki fork to skoordynowane przejście ze zbioru ważności V (stary) do jego podzbioru V (nowy). Aktywacja określa blok, z którego zaktualizowane pełne węzły wymuszają ograniczenie. Sygnalizacja górnicza może koordynować gotowość, ale o ważności decyduje reguła uruchamiana w węzłach; projektowanie, wdrażanie, wdrażanie, aktywacja i adopcja to nie to samo.
Oznaczmy V(old) wszystkie bloki zaakceptowane przez zasady przed aktualizacją. Zmiana jest miękkim forkiem tylko wtedy, gdy V(nowy) leży wewnątrz V(stary): nowy węzeł odrzuci następną klasę bloków, ale blok zgodny z nowymi regułami również przejdzie stare kontrole. Nazwa mówi o zgodności zasad ważności, a nie o wielkości, bezpieczeństwie czy zgodności społecznej zmiany. Zwiększenie limitu widocznego dla starego węzła lub zezwolenie na wcześniej nieprawidłowe wydatki powiększa pulę i zwykle wymaga hard forku. [Przewodnik programisty Bitcoin – Zmiany zasad konsensusu] [Bitcoin Optech – Aktywacja miękkiego forka]
Stary pełny węzeł może nadal podążać za łańcuchem, ponieważ zaktualizowani górnicy rutynowo tworzą rozpoznawane przez siebie bloki. Ale nie sprawdza dodanego warunku. Jeżeli gałąź z większą ilością pracy naruszy nową regułę, stary węzeł może to zaakceptować, natomiast zaktualizowany odrzuci. Ci, którzy potrzebują nowej gwarancji, muszą zaktualizować własne oprogramowanie sprawdzające; zdolność portfela do akceptowania płatności, zgodność formatów i pełna weryfikacja konsensusu to różne rzeczy. [Przewodnik programisty Bitcoin – Zmiany zasad konsensusu] [BIP 341 – Wdrożenie Taproot]
Bitcoin utworzył podzbiory przy użyciu kilku technik. BIP66 zakazał nierygorystycznych podpisów DER, które akceptowały stare zasady. BIP65 i BIP112 dodały warunki do rozkazów NOP, które stary interpreter uznał za pomyślne nierobienie niczego. SegWit i Taproot nadali znaczenie zarezerwowanym wersjom programu-świadka, który według starego węzła jest dostępny dla każdego. Jednocześnie projekt musi uniemożliwiać obejście nowej kontroli; Dlatego SegWit przekazał dane świadków za pośrednictwem bazy monet i zachował stare podstawowe zasady blokowania. [BIP 66 — Ścisłe podpisy DER] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Oddzielny świadek] [BIP 341 — Wdrożenie Taproot]
Kod może zawierać nieaktywną regułę na długo przed jej wejściem w życie w sieci głównej. BIP i sprawdzona implementacja nie są wdrożeniami, parametry wdrożenia nie są blokowane, blokowanie tylko planuje przyszłe egzekwowanie, a tylko stan AKTYWNY oznacza sprawdzenie danego bloku. Każdy węzeł oblicza stan na podstawie przodków swojej własnej gałęzi. Reorganizacja na granicy może to przeliczyć, a oprogramowanie o innych parametrach może zacząć wymuszać niezgodne reguły. [BIP 9 — Bity wersji z limitem czasu i opóźnieniem] [Bitcoin Core — wersjabits.cpp]
BIP9 przypisuje nazwę, wersję bitową, czas rozpoczęcia i limit czasu do wdrożenia. Oryginalny wariant sieci głównej ocenia okresy po 2016 blokach: po co najmniej 1916 blokach sygnalizacyjnych, tj. 95%, przechodzi od STARTED do LOCKED_IN, czeka przez jeden okres, a następnie jest AKTYWNY; w przeciwnym razie może zakończyć się to NIEPOWODZENIEM. Pełna sekwencja to ZDEFINIOWANA, ROZPOCZĘTA, ZABLOKOWANA, AKTYWNA i NIEUDANA. Stan bloku zależy od jego przodków, a nie od jego własnej nVersion, a sygnalizacja po zablokowaniu nie zmienia już wyniku. [BIP 9 — Bity wersji z przekroczeniem limitu czasu i opóźnieniem]
Bity wersji wskazują gotowość górnika i koordynują przejście; nie przyznają górnikom stałej własności konsensusu. BIP8 wykorzystuje wysokości, a przy blokadzie czasu trwania blokady może wymusić sygnalizację w ostatnim oknie. Z drugiej strony BIP148 nakazał uczestniczącym węzłom odrzucanie bloków sygnalizacyjnych innych niż SegWit; BIP91 obniżył próg wydobycia, aby skoordynować się z tą presją. Obowiązkowa aktywacja może podzielić łańcuch, jeśli węzły, współczynnik mieszania i stopień wykorzystania ekonomicznego różnią się, więc nawet metoda aktywacji stanowi zagrożenie dla bezpieczeństwa. [BIP 8 – Bity wersji z blokadą według wysokości] [BIP 148 – Obowiązkowa aktywacja SegWit] [BIP 91 – Obniżony próg SegWit MASF] [Bitcoin Optech – Aktywacja miękkiego forka]
P2SH w ramach BIP16 został aktywowany w 2012 roku przez sygnalizację bazy monet i ograniczenie czasowe. BIP34 użył wersji blokowej i progu obowiązkowej wysokości w bazie monet. Ta sama procedura liczbowa uruchomiła ścisłe DER w BIP66 i CHECKLOCKTIMEVERIFY w BIP65, ale zużyła wartości wersji i nie mogła wykonywać równoczesnych wdrożeń. Dlatego BIP9 wprowadził niezależne bity. BIP68, BIP112 i BIP113 następnie aktywowano razem jako względny czas blokady i CSV na wysokości 419 328 w 2016 r. [BIP 16 — Pay to Script Hash] [BIP 34 — Block v2, wysokość w bazie monet] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Ścisłe podpisy DER] [BIP 112 — SPRAWDŹ KOLEJNOŚĆ WERYFIKUJ]
SegWit aktywowano pod numerem 481 824 w sierpniu 2017 r. Stary węzeł widzi transakcję bez danych świadka i uważa świadka v0 za osobę, którą każdy może wydać; zaktualizowany dowód weryfikacji, nowe podsumowanie podpisu i zasady zapobiegające plastyczności. Zaangażowanie Merkle w monitorowanie danych w bazie monet uniemożliwia górnikowi zmianę lub pominięcie danych bez wykrycia. Naliczanie wag zwiększało efektywną pojemność bez widocznego dla starego węzła podstawowego bloku, przekraczając stary limit jednego megabajta. [BIP 141 – Świadek odizolowany]
BIP341 i BIP342 monitorują wydatki na ścieżkę klucza i ścieżkę skryptu w wersji 1 z podpisami Schnorra i Tapscriptem. Stary węzeł ponownie traktuje zarezerwowany program w taki sposób, w jaki każdy może go wydać: podzbiór zostaje zachowany, a pełna walidacja nie. W sieci głównej zastosowano zmodyfikowaną wersję próbną BIP9 Speedy Trial z progiem 1815 z 2016 bloków, czyli 90%, i minimalną wysokością aktywacji wynoszącą 709 632. Taproot aktywował się w nim 14 listopada 2021 r.; Reguły Taproot i sposób ich aktywacji to dwa osobne pytania kontrolne. [BIP 341 — Wdrożenie Taproot] [BIP 342 — Tapscript] [Informacje o wersji Bitcoin Core 0.21.1 — Wdrożenie Taproot]
Kiedy w lipcu 2015 r. aktywowano BIP66, niektórzy górnicy zasygnalizowali nową wersję, ale nie zweryfikowali w wystarczającym stopniu bloku nadrzędnego, na którym wydobywali. Przedłużyli nieprawidłowy blok i 4 lipca utworzyli nieprawidłowy oddział składający się z sześciu bloków; kolejny krótszy incydent nastąpił następnego dnia. Zaktualizowane węzły sprawdzające odrzuciły obie gałęzie. Numer wersji lub bit jest twierdzeniem górnika, a nie dowodem na to, że on sam zweryfikował szablon, rodziców i transakcje. [BIP 66 — Ścisłe podpisy DER] [Bitcoin.org — Alert dotyczący rozwidlenia łańcucha BIP66 z lipca 2015 r.]
W stanie AKTYWNYM zaktualizowane węzły odrzucają naruszający blok niezależnie od udziału szybkości mieszania; To, czy powstanie trwały podział, zależy od pracy oddziałów i ich gospodarczego wykorzystania. Samo usunięcie ograniczenia ponownie umożliwiłoby dzisiejsze nieprawidłowe bloki i dlatego stanowi hard fork; parametry lub kod można zastąpić skoordynowaną wersją przed aktywacją. Operator weryfikuje własną wersję, getdeploymentinfo lub getblockchaininfo, dokładne parametry, wysokość aktywacji i logi. Ani wykres sygnalizacyjny, ani etykieta eksploratora nie mogą zastąpić lokalnej walidacji. [Przewodnik programisty Bitcoin — zmiany zasad konsensusu] [Bitcoin Core — wersjabits.cpp] [Informacje o wydaniu Bitcoin Core 0.21.1 — wdrożenie Taproot]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Reguły konsensusu, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. Do tego hasła prowadzą również odsyłacze z Hard Fork, BIP (Bitcoin Improvement Proposal), Reguły konsensusu, Reorg.