BIP "Soft fork temporar cu date reduse" propune dezactivarea temporară a diferitelor funcții Bitcoin în consens. Am studiat blockchain-ul pentru a cuantifica impactul potențial, identificând tranzacțiile istorice care încalcă fiecare dintre aceste reguli. 🧵↓

Regula #1: "Noile scriptPubKeys de ieșire care depășesc 34 de octeți sunt invalide, cu excepția cazului în care primul cod de operare este OP_RETURN, caz în care până la 83 de octeți sunt validi." Acest lucru afectează toate ieșirile P2PK și P2MS, precum și un număr mic de SPK-uri non-standard.

Regula #2: "OP_PUSHDATA* cu sarcini mai mari de 256 de octeți sunt invalide, cu excepția push-ului redeemScript din BIP16 scriptSigs." Presupun că acest lucru se aplică doar push-urilor de date *executate*, așa că am exclus push-urile din plicurile de inscripție taproot, care sunt foarte multe.

Regula #3: "Cheltuirea versiunilor martore nedefinite (sau Tapleaf) (adică, nu Witness v0/BIP 141 sau Taproot/BIP 341) este invalidă." Există puțin peste 54 de tranzacții cu ieșiri nedefinite ale numărului de versiune (în mare parte folosind ieșiri false pentru a ocoli limita de op_return).

Cu toate acestea, BIP 141 și 341 definesc lungimi specifice ale programelor martor: - v0, lungime 20 (P2WPKH) - v0, lungime 32 (P2WSH) - v1, lungime 32 (P2TR) așa cum este scris, RDTS pare să interzică toate celelalte lungimi de programe, inclusiv ancorele P2A (v1, lungime 2).

Regula #4: "Stivele de martori cu o anexă Taproot sunt invalide." Până în prezent, 11 tranzacții au atașat o anexă la cheltuielile principale, majoritatea pentru jpeg-uri.

Regula #5: "Blocurile de control Taproot mai mari de 257 de octeți (un arbore merkle cu 128 de frunze de script) sunt invalide." Există ~32k cheltuieli evident de încorporare a datelor cu adâncimea blocului de control de 100+ (labitbus și similare). Dar și o mână de cheltuieli "legitime" la adâncime mai mică.

Regula #6: "Scripturile tap, inclusiv codurile de operare OP_SUCCESS* oriunde (chiar și neexecutate) sunt invalide." Există două cheltuieli istorice, inclusiv OP_SUCCESS coduri de operație: tranzacția spărgător de fulgere a lui Burak și această demonstrație prostească OP_CAT

Regula #7: "Scripturile tact care execută instrucțiunile OP_IF sau OP_NOTIF (indiferent de rezultat) sunt invalide." Acest lucru are ca scop dezactivarea "plicului de inscripție", care a fost folosit de peste 104 milioane de tranzacții până acum.

Cu toate acestea, RDTS merge dincolo de dezactivarea plicului de inscripție, interzicând OP_IF și OP_NOTIF în întregime. Aproximativ 70 de tranzacții fără inscripție au folosit OP_IF în scripturi taproot. Multe sunt experimente în stil bitvm, dar există și exemple de utilizare financiară mai simplă.

De exemplu, există câteva cheltuieli folosind acest șablon de script "multisig în descompunere", care folosește mai multe OP_IFs

Cel mai îngrijorător este că există mai multe cheltuieli dintr-un portofel care utilizează acest șablon de script HTLC în spatele unui punct NUMS bip341 (dezactivând calea cheii) Scriptul folosește OP_IF pentru a alege între o ramură care necesită două semnături și o preimagine hash sau o semnătură după un timp de expirare relativ

Susținătorii RDTS au respins preocupările legate de confiscarea blocurilor de control OP_IF și mari din taproot, susținând că utilizatorii pot cheltui oricând prin calea cheie. Cu toate acestea, aproximativ 560 de tranzacții au cheltuit ieșiri taproot în care calea cheie a fost dezactivată.