Utvecklare påpekar stora risker i föreslaget Bitcoin-reduceringsmjukvarugren

Granskning av Transaktionsdata Visar Att RDTS Kan Blockera Viktiga Bitcoin Användningsområden

Ett nytt förslag till soft fork utformat för att begränsa överdriven databevaring på Bitcoin blockchain har nyligen fått skarp kritik. I onsdags publicerade den oberoende analytikern och mempool.space-utvecklaren, Mononaut, en bedömning som beskriver den potentiella sidoeffekt regeln kan orsaka.

Förslaget, känt som Reduced Data Temporary Softfork (RDTS), introducerar ett antal konsensusnivåbegränsningar avsedda att minska dataintensiva transaktioner—ett försök utvecklare anser vara nödvändigt efter Bitcoin Core v30 uppdateringen som tog bort gränser på OP_RETURN data.

RDTS skulle gälla under ungefär ett år om det aktiveras, och begränsa scriptPubKeys till 34 byte, begränsa OP_RETURN-utgångar till 83 byte, begränsa Taproot-kontrollblock, förbjuda odefinierade vittnesversioner och inaktivera hela kategorier av Tapscript-logik. Förespråkare av BIP argumenterar för att åtgärderna fungerar som en nödbroms mot godtyckliga datauppladdningar som skulle kunna utsätta nodoperatörer för juridiskt ansvar om olagligt material bäddades in i kedjan.

Mononauts bedömning kvantifierar dock de praktiska konsekvenserna av dessa begränsningar genom att granska historisk blockchain-aktivitet för att se vilka verkliga transaktioner som skulle ha brutit mot de föreslagna reglerna. Hans upptäckter antyder betydande störningar. Under scriptPubKey-storleksbegränsningen ensam, skulle alla pay-to-public-key (P2PK) och multisig (P2MS) utgångar bli ogiltiga. Denna begränsning påverkar också ett litet antal icke-standard utgångar i tidigare transaktioner.

En av de mer omfattande reglerna—att ogiltigförklara OP_PUSHDATA-operationer med nyttolast över 256 byte—skulle inte påverka inskriptionskuvert, förutsatt att endast exekverade pushar kvalificerar. Men Mononaut betonade att odefinierade vittnesversioner skulle påverka mer än 54,000 historiska transaktioner, många av vilka använde okonventionella utgångar för att kringgå OP_RETURN datatak. Eftersom vittnesversioners längder är tätt definierade i BIPs 141 och 341, skulle förslaget som det är skrivet även blockera vissa giltiga moderna format som P2A-ankare.

Läs även: Bitcoin Core-utvecklare Sammanfogar Kontroversiella Policysändringar: Är en Fork på Väg?

Mononaut beskrev att RDTS även gör ogiltigförklarar vittnesstackar som innehåller en Taproot-anhang. Även om det är sällsynt, noterar mempool.space-utvecklaren att åtminstone 11 transaktioner har använt ett anhang för dataintensiva ändamål. En mer betydande kategori, betonade Mononaut, är stora Taproot-kontrollblock: cirka 32,000 tidigare utgifter inkluderar djup-100+ kontrollblock som ofta används för datainbäddning, men även vissa icke-datainriktade experiment förlitar sig på mindre, legitima konfigurationer som skulle inaktiveras. En aktiv adress spenderar konsekvent med kontrollblocks-djup 11, vilket skulle avvisas under RDTS.

Förslagets strängaste radpunkter—förbud mot OP_SUCCESS* och alla Tapscript som exekverar OP_IF eller OP_NOTIF—sträcker sig långt bortom inskriptionskuvert. Mononaut lyfter fram två historiska OP_SUCCESS-transaktioner, inklusive Buraks lightning-brytnings-transaktion, och ungefär 70 icke-inskriptionsbaserade OP_IF Taproot-utgifter. Flera av dessa är finansiella primitiv, inklusive multisingel-mallar med upplösning och haschtidslåsta kontrakt (HTLC) konstruktioner. Vissa härstammar från plånböcker som avsiktligt inaktiverade deras nyckelväg, vilket gjorde skriptväg spendering som det enda sättet att flytta medel.

RDTS förespråkare har argumenterat att användare med berörda skript skulle kunna återgå till nyckelväg spendering. Ändå utmanar Mononauts data den antagandet direkt: omkring 560,000 historiska Taproot-utgifter kommer från utgångar vars nyckelväg var bevisligen inaktiverad, vilket gör OP_IF och liknande funktioner essentiella snarare än valfria.

Förespråkare av det tillfälliga soft forken hävdar att RDTS är en kortsiktig skyddsåtgärd utformad för att bevara Bitcoins monetära nytta, förhindra juridiska risker och minska nodbelastningar genom att begränsa databevaring. Kritiker kontrar att breda begränsningar på Tapscript-beteende riskerar att införa de facto-censur, inaktivera giltiga transaktionstyper och bryta befintliga applikationer.

Debatten speglar tidigare dispyter om inskriptionsdriven datatillväxt, vilket återspeglar djupare meningsskiljaktigheter om huruvida Bitcoin bör förbli strikt monetär eller fortsätta att anpassa sig till experimentella användningar. Förslaget finns fortfarande i utkastform, och diskussionen pågår bland utvecklare, forskare och ekosystemdeltagare.

FAQ ❓

• Vad är RDTS?
  Ett tillfälligt soft fork-förslag som begränsar flera Bitcoin-skript och datafunktioner.
• Varför debatteras RDTS?
  Förespråkare vill begränsa dataövergrepp, medan kritiker säger att det inaktiverar giltiga transaktioner.
• Vad fann Mononaut?
  Hans analys visar att många historiska transaktioner skulle misslyckas under RDTS-reglerna.
• Hur länge skulle RDTS vara?
  Förslaget anger ett aktiveringsfönster på ett år om det antas.