BIP 110

Wyobraź sobie dwóch operatorów węzłów, którzy otrzymują ten sam blok. Jeden przyjmuje go według dotychczasowych zasad, drugi odrzuca z powodu nowego ograniczenia. Tak głęboko sięgał BIP 110: zmieniałby ważność bloków, a nie tylko gotowość węzła do przekazania transakcji lub trzymania jej w mempoolu, lokalnej poczekalni niepotwierdzonych płatności. Podczas kontroli 2026-10-23 specyfikacja w wersji 1.0.1 miała status Closed, czyli zamknięta. Numer BIP ani opublikowany program nie potwierdzają przyjęcia zmian przez sieć. Rejestr przechowuje dokument i jego historię; nie przełącza zdalnie reguł poszczególnych węzłów. [1] [2]

Każde nowe wyjście transakcji ma scriptPubKey, czyli skrypt określający warunki późniejszego wydania środków. Projekt dopuszczał najwyżej 34 bajty lub 83 bajty, jeśli skrypt zaczyna się od OP_RETURN, instrukcji tworzącej wyjście, którego w sposób dowodliwy nie da się wydać. Liczy się cały skrypt. Osobny limit 256 bajtów dotyczył pojedynczych danych OP_PUSHDATA* oraz argumentów w witness, danych towarzyszących weryfikacji wydania. Wyjątkiem jest wstawienie redeemScript, ujawnionego skryptu warunków, do scriptSig zgodnie z BIP16. Same witness scripts i Tapleaf scripts nie są takimi argumentami, lecz ich instrukcje wstawiania danych nadal podlegają ograniczeniu. To limity konkretnych części, a nie całej transakcji czy całego witness. [1]

Ograniczenia obejmowały także Taproot, sposób zapisywania warunków wydania. Zabronione byłoby wydawanie niezdefiniowanych wersji witness lub Tapleaf, ale nie tworzenie takich wyjść. Projekt odrzucał annex, dodatkowe pole, oraz control block powyżej 257 bajtów, czyli zbyt długi dowód przynależności skryptu do zadeklarowanej struktury. Tapscript nie mógłby zawierać OP_SUCCESS* nawet w niewykonywanej części ani wykonywać OP_IF lub OP_NOTIF niezależnie od wyniku warunku. Dla technicznego porównania zdefiniowane formaty obejmują P2WPKH, P2WSH, P2TR z wersją Tapleaf 0xc0 i P2A z programem 0x4e73, ten ostatni tylko z pustym stosem witness. To precyzyjne nazwy formatów, nie pola, które zwykły użytkownik musi wypełniać w portfelu. [1]

UTXO to niewydane wyjście: określona kwota wraz z warunkami jej użycia. Projekt zwalnia z nowych reguł wejścia wydające UTXO potwierdzone przed aktywacją. Nie daje to jednak swobody nowym wyjściom tej samej transakcji. Podpis przygotowany wcześniej również nie chroni wyjścia utworzonego dopiero w okresie aktywnym. W niektórych wcześniej podpisanych konstrukcjach Taproot specyfikacja dopuszcza zamrożenie lub utratę środków, jeśli ograniczenia unieważnią przewidziane ścieżki i nie pozostanie dostępna alternatywa. Dotyczy to też możliwych skutków dla Miniscript, narzędzia budującego warunki wydania, oraz BitVM, konstrukcji do weryfikacji obliczeń. Nie można więc obiecywać, że zmiana dotknie tylko treści niepieniężnych. [1] [3]

Górnik może umieścić w bloku sygnał poparcia: tutaj bit 4, przy progu 1109 z 2016 bloków, czyli około 55 procent. Projekt nie kończył się jednak na dobrowolnym sygnale. Jeśli próg nie został osiągnięty wcześniej, wymagał sygnalizacji na wysokościach 961632–963647, następnie LOCKED_IN od 963648 i ACTIVE od 965664, o ile dany łańcuch dotrze do tych wysokości. Wysokość to pozycja bloku w łańcuchu. LOCKED_IN oznacza ustalone przejście, ACTIVE rzeczywiste egzekwowanie ograniczeń danych. Klient odrzucałby bloki bez sygnału już podczas obowiązkowej sygnalizacji, więc węzły mogłyby się rozdzielić przed uruchomieniem limitów. Te miały obowiązywać przez 52416 bloków od rzeczywistej aktywacji, a następnie wygasnąć w stanie EXPIRED; nie jest to dokładnie odmierzony rok kalendarzowy. [1] [4]

Zwolennicy chcieli obniżyć koszty węzłów, presję na zbiór UTXO i ilość niechcianych treści, dając pierwszeństwo płatnościom. To wyjaśnia cel, lecz nie dowodzi rezultatu. Krytycy wskazywali wpływ na użyteczne skrypty, przyszłe rozszerzenia i ryzyko podziału sieci. Dane można też rozbić na mniejsze fragmenty: w początkowej dyskusji Peter Todd pokazał transakcję zawierającą w ten sposób całą ówczesną propozycję. Nawet specyfikacja nie obiecuje całkowitego wyeliminowania steganografii, czyli ukrywania informacji w innych danych. Podniesienie kosztu zapisu i zupełne uniemożliwienie zapisu to różne efekty. Podobnie obawa przed odpowiedzialnością prawną za treści sama nie wykazuje konkretnego obowiązku prawnego. [1] [3]

Zapis PR 2247 opisuje podział dnia 2026-08-08 na wysokości 961632. Główny łańcuch zawierał blok bez wymaganego sygnału, a OCEAN wydobył sygnalizującą alternatywę. Dnia 2026-08-09 Murch podał, że mniejszościowa gałąź uzyskała tylko 2 bloki i stanęła, podczas gdy główna posunęła się o ponad 100 bloków. Taką relację należy czytać wraz z datą i nazwiskiem autora: nie jest niezależnym odtworzeniem blockchainu wykonanym na potrzeby tego artykułu ani opisem dzisiejszego stanu mniejszościowej gałęzi. Pokazuje też, dlaczego podział wskutek sygnalizacji nie dowodzi osiągnięcia ACTIVE i uruchomienia samych ograniczeń danych. [5] [6]

Dokument przeszedł przez Complete, czyli ukończoną specyfikację, i zakończył ze statusem Closed. PR 2245 zamykający propozycję przyjęto 2026-08-10; dziennik zmian specyfikacji podaje 2026-08-09. Daty odnoszą się do różnych zapisów, nie do kolejnej aktywacji. Wydanie klienta v0.4.1 opisuje EXPIRED oraz vbrequired, pole szablonu bloku wskazujące obowiązkowy bit sygnalizacji. Istnienie tego klienta nie oznacza przyjęcia propozycji w Bitcoin Core. Są też test vectors, przykładowe transakcje z oczekiwanymi wynikami, i testy funkcjonalne. Artykuł ich nie uruchamia ani nie sprawdza obecnego mniejszościowego łańcucha. Wyjaśnia projekt i jego udokumentowaną historię, zamiast przedstawiać dawny dokument jako dzisiejsze wspólne reguły sieci. [7] [1] [4]