Ontwikkelaar wijst op grote risico's in voorgestelde Bitcoin Reduced Data Soft Fork

Beoordeling van Transactiedata Laat Zien dat RDTS Belangrijke Bitcoin Gebruikstoepassingen Kan Blokkeren

Een nieuw soft fork voorstel dat is ontworpen om overmatige dataopslag op de Bitcoin-blockchain in te perken, krijgt de laatste tijd scherpe kritiek. Op woensdag publiceerde de onafhankelijke analist en mempool.space ontwikkelaar, Mononaut, een beoordeling waarin de potentiële nevenschade van de regelset wordt beschreven.

Het voorstel, bekend als de Reduced Data Temporary Softfork (RDTS), introduceert een reeks consensusniveaubeperkingen die bedoeld zijn om data-intensieve transacties te verminderen—een inspanning die ontwikkelaars noodzakelijk achten na de Bitcoin Core v30 update die de limieten op OP_RETURN data verwijderde.

RDTS zou ongeveer één jaar van toepassing zijn als het geactiveerd wordt, en het zou scriptPubKeys beperken tot 34 bytes, OP_RETURN-uitvoer maximaliseren op 83 bytes, Taproot-controlblokken beperken, niet-gedefinieerde witness-versies verbieden, en hele categorieën van Tapscript-logica uitschakelen. Voorstanders van de BIP beweren dat de maatregelen dienen als een noodrem tegen willekeurige datauploads die node-operators zouden kunnen blootstellen aan juridische aansprakelijkheid als illegaal materiaal in de keten werd ingebed.

Mononaut’s beoordeling kwantificeert echter de praktische schade van die beperkingen door historische blockchain-activiteit te herzien om te zien welke echte transacties de voorgestelde regels zouden hebben geschonden. Zijn bevindingen suggereren een significante verstoring. Onder de scriptPubKey groottebeperking alleen al zouden alle pay-to-public-key (P2PK) en multisig (P2MS) uitvoeringen ongeldig zijn. Die beperking heeft ook invloed op een klein aantal niet-standaard uitvoeringen in eerdere transacties.

Een van de ingrijpendere regels—het ongeldig maken van OP_PUSHDATA operaties met payloads boven 256 bytes—zou geen invloed hebben op inscriptieenveloppen, ervan uitgaande dat alleen uitgevoerde pushes in aanmerking komen. Maar Mononaut benadrukte dat niet-gedefinieerde witness-versies meer dan 54.000 historische transacties zouden beïnvloeden, waarvan velen ongebruikelijke uitvoeringen gebruikten om OP_RETURN data limieten te omzeilen. Omdat witness versie lengtes strikt gedefinieerd zijn in BIPs 141 en 341, zou het voorstel zoals geschreven zelfs enkele geldige moderne formaten zoals P2A ankers blokkeren.

Lees ook: Bitcoin Core Ontwikkelaars Samensmelten Controversiële Beleidswijzigingen: Is een Fork Opkomst?

Mononaut verduidelijkte dat RDTS ook witness-stacks ongeldig maakt die een Taproot-bijlage bevatten. Hoewel zeldzaam, merkt de mempool.space-ontwikkelaar op dat minstens 11 transacties een bijlage hebben gebruikt voor datarijke doeleinden. Een belangrijkere categorie, benadrukte Mononaut, zijn grote Taproot-controlblokken: ongeveer 32.000 eerdere uitgaven omvatten diepte-100+ controlblokken die vaak worden gebruikt voor data-embedding, maar zelfs enkele niet-data-experimenten vertrouwen op kleinere, legitieme configuraties die uitgeschakeld zouden worden. Een actief adres besteedt consequent op control-block diepte 11, wat afgewezen zou worden onder RDTS.

De strengste regels van het voorstel—het verbieden van OP_SUCCESS* en elke Tapscript uitvoering van OP_IF of OP_NOTIF—gaan veel verder dan inscriptieenveloppen. Mononaut wijst op twee historische OP_SUCCESS transacties, inclusief Burak’s lightning-verbrekende transactie, en ongeveer 70 niet-inscriptie OP_IF-gebaseerde Taproot uitgaven. Verschillende hiervan zijn financiële primitieven, inclusief vervallende multisig-sjablonen en hash-time-locked contract (HTLC) ontwerpen. Enkele komen voort uit portefeuilles die opzettelijk hun keypath hebben uitgeschakeld, waardoor script-pad uitgaven de enige manier zijn om fondsen te verplaatsen.

RDTS-voorstanders hebben betoogd dat gebruikers met getroffen scripts zouden kunnen terugvallen op keypath-uitgaven. Toch dagen Mononauts data die veronderstelling direct uit: ongeveer 560.000 historische Taproot uitgaven komen van uitvoeringen waarvan de keypath aantoonbaar was uitgeschakeld, wat OP_IF en soortgelijke functies essentieel in plaats van optioneel maakt.

Voorstanders van de tijdelijke soft fork stellen dat RDTS een kortetermijnbeschermingsmaatregel is die bedoeld is om de monetaire bruikbaarheid van Bitcoin te behouden, juridische risico’s te voorkomen en de belasting van node te verminderen door dataopslag te beperken. Critici daarentegen beweren dat brede beperkingen op Tapscript-gedrag het risico met zich meebrengen om de facto censuur in te voeren, geldige transactietypes uit te schakelen en bestaande applicaties te doorbreken.

Het debat weerspiegelt eerdere geschillen over inscriptiegedreven datagroei, en weerspiegelt diepere meningsverschillen over de vraag of Bitcoin strikt monetair moet blijven of experimentele toepassingen moet blijven accommoderen. Aangezien het voorstel in conceptvorm blijft, vindt de discussie plaats onder ontwikkelaars, onderzoekers en deelnemers aan het ecosysteem.

FAQ ❓

• Wat is RDTS?
  Een tijdelijk soft fork voorstel dat verschillende Bitcoin script- en datafuncties beperkt.
• Waarom wordt RDTS besproken?
  Voorstanders willen datamisbruik inperken, terwijl critici zeggen dat het geldige transacties uitschakelt.
• Wat ontdekte Mononaut?
  Zijn analyse toont aan dat veel historische transacties zouden falen onder RDTS-regels.
• Hoe lang zou RDTS duren?
  Het voorstel schetst een activeringsperiode van één jaar indien aangenomen.