BIP "Reduced Data Temporary Softfork" föreslår att man tillfälligt inaktiverar olika Bitcoin-funktioner i konsensus. Jag har undersökt blockkedjan för att kvantifiera den potentiella effekten genom att identifiera historiska transaktioner som bryter mot var och en av dessa regler. 🧵↓

Regel #1: "Nya utdataskriptPubKeys som överstiger 34 byte är ogiltiga, såvida inte den första opkoden är OP_RETURN, i vilket fall upp till 83 byte är giltiga." Detta påverkar alla P2PK- och P2MS-utgångar, såväl som ett litet antal icke-standardiserade SPK:er.

Regel #2: "OP_PUSHDATA* med nyttolaster större än 256 byte är ogiltiga, förutom redeemScript-pushen i BIP16 scriptSigs." Jag antar att detta endast gäller *utförda* data-push-meddelanden, så jag har uteslutit push-meddelanden inom taproot-inskriptionskuvert, av vilka det finns väldigt många.

Regel #3: "Att spendera odefinierade vittnesversioner (eller Tapleaf) (dvs. inte Witness v0/BIP 141 eller Taproot/BIP 341) är ogiltigt." Det finns drygt 54k transaktioner med odefinierade versionsnummerutgångar (mestadels med falska utdata för att kringgå den op_return gränsen).

Men BIP:erna 141 och 341 definierar specifika längder på vittnesprogram: - v0, längd 20 (P2WPKH) - v0, längd 32 (P2WSH) - v1, längd 32 (P2TR) som skrivet verkar RDTS förbjuda alla andra programlängder, inklusive P2A-ankare (v1, längd 2).

Regel #4: "Vittnesstackar med en Taproot-bilaga är ogiltiga." Hittills har 11 transaktioner bifogat en bilaga till Taproot utgifter, mestadels för jpeg-filer.

Regel #5: "Taproot-kontrollblock som är större än 257 byte (ett merkle-träd med 128 skriptblad) är ogiltiga." Det finns ~32k uppenbart datainbäddande taproot-utgifter med kontrollblocksdjup på 100+ (labitbus och liknande). Men också en handfull "legitima" utgifter på lägre djup.

Regel #6: "Tapscripts inklusive OP_SUCCESS* opcodes var som helst (även okörda) är ogiltiga." Det finns två historiska taproot-utgifter, inklusive OP_SUCCESS opcodes: Buraks blixtbrytartransaktion och den här fåniga OP_CAT-demon

Regel #7: "Tapscripts som utför OP_IF eller OP_NOTIF instruktion (oavsett resultat) är ogiltiga." Detta syftar till att inaktivera "inskriptionskuvertet", som hittills har använts av över 104 miljoner transaktioner.

RDTS går dock längre än att inaktivera inskriptionskuvertet och förbjuder OP_IF och OP_NOTIF helt och hållet. Omkring 70 icke-inskriptionstransaktioner har använt OP_IF i taproot-skript. Många är experiment i bitvm-stil, men det finns också exempel på mer okomplicerad ekonomisk användning.

Till exempel finns det ett par utgifter med den här "förfallna multisig"-skriptmallen, som använder flera OP_IFs

Det mest oroande är att det finns flera utgifter från en plånbok som använder den här HTLC-skriptmallen bakom en bip341 NUMS-punkt (inaktiverar nyckelsökvägen) Skriptet använder OP_IF för att välja mellan en gren som kräver två signaturer och en hash-förbild, eller en signatur efter en relativ tidsgräns

RDTS-förespråkare har avfärdat oro för konfiskering i samband med OP_IF och stora kontrollblock i taproot genom att hävda att användare alltid kan spendera via nyckelvägen istället. Cirka 560 000 transaktioner har dock spenderat taproot-utdata där nyckelsökvägen bevisligen var inaktiverad.