BIP "Reduced Data Temporary Softfork" proponuje tymczasowe wyłączenie różnych funkcji Bitcoin w konsensusie. Przeprowadziłem badanie blockchaina, aby oszacować potencjalny wpływ, identyfikując historyczne transakcje, które naruszają każdą z tych zasad. 🧵↓

Zasada #1: "Nowe skrypty scriptPubKey przekraczające 34 bajty są nieważne, chyba że pierwszy opcode to OP_RETURN, w takim przypadku do 83 bajtów jest ważnych." Dotyczy to wszystkich wyjść P2PK i P2MS, a także niewielkiej liczby niestandardowych SPK.

Zasada #2: "OP_PUSHDATA* z ładunkami większymi niż 256 bajtów są nieważne, z wyjątkiem push redeemScript w skryptach BIP16." Zakładam, że dotyczy to tylko *wykonanych* pushów danych, więc wykluczyłem pushy w ramach kopert inskrypcyjnych taproot, których jest bardzo wiele.

Zasada #3: "Wydawanie niezdefiniowanych wersji świadków (lub Tapleaf) (tj. nie Witness v0/BIP 141 ani Taproot/BIP 341) jest nieważne." Jest nieco ponad 54 tys. transakcji z niezdefiniowanymi numerami wersji (głównie wykorzystujących fałszywe wyjścia, aby obejść limit op_return).

Jednakże, BIP 141 i 341 definiują konkretne długości programów witness: - v0, długość 20 (P2WPKH) - v0, długość 32 (P2WSH) - v1, długość 32 (P2TR) jak napisano, RDTS wydaje się zakazywać wszystkich innych długości programów, w tym kotwic P2A (v1, długość 2).

Zasada #4: "Stosy świadków z annexem Taproot są nieważne." Jak dotąd, 11 transakcji dołączyło annex do wydatków taproot, głównie dla jpegów.

Zasada #5: "Bloki kontrolne Taproot większe niż 257 bajtów (drzewo merkle z 128 liśćmi skryptów) są nieprawidłowe." Jest około 32k oczywiście wydatków taproot z osadzeniem danych z głębokością bloku kontrolnego wynoszącą 100+ (labitbus i podobne). Ale także garstka "legitymnych" wydatków o niższej głębokości.

Zasada #6: "Tapscripty zawierające opkody OP_SUCCESS* w dowolnym miejscu (nawet niewykonane) są nieważne." Istnieją dwa historyczne wydatki taproot zawierające opkody OP_SUCCESS: transakcja Buraka z lightning-breaker oraz ten głupi demo OP_CAT.

Zasada #7: "Tapscripty wykonujące instrukcję OP_IF lub OP_NOTIF (bez względu na wynik) są nieważne." Celem jest wyłączenie "koperty inskrypcyjnej", która została wykorzystana w ponad 104 milionach transakcji do tej pory.

Jednak RDTS wykracza poza wyłączenie koperty inskrypcyjnej, całkowicie zakazując OP_IF i OP_NOTIF. Około 70 transakcji nieinskrypcyjnych wykorzystało OP_IF w skryptach taproot. Wiele z nich to eksperymenty w stylu bitvm, ale są też przykłady bardziej bezpośrednich zastosowań finansowych.

Na przykład, istnieje kilka wydatków wykorzystujących ten szablon skryptu "decaying multisig", który używa wielu OP_IF.

Najbardziej niepokojące jest to, że z portfela korzystającego z tego szablonu skryptu HTLC dokonano wielu wydatków za pomocą punktu bip341 NUMS (wyłączając ścieżkę klucza) Skrypt używa OP_IF, aby wybrać między gałęzią wymagającą dwóch podpisów i preobrazu hasza, a jednym podpisem po względnym czasie oczekiwania.

Zwolennicy RDTS odrzucili obawy dotyczące konfiskaty związane z OP_IF i dużymi blokami kontrolnymi w taproot, twierdząc, że użytkownicy zawsze mogą wydawać środki za pomocą keypath. Jednak około 560 tys. transakcji wydało wyjścia taproot, gdzie keypath był udowodnione, że był wyłączony.