Erik Weijers, één jaar geleden
In de Bitcoin community woedt een hevige discussie over een nieuw verbeteringsvoorstel: BIP119. De onenigheid gaat vooral om de vraag hoe snel dit voorstel er doorheen gedrukt mag worden of dat er eerst brede consensus moet ontstaan.
Bij de laatste upgrade van Bitcoin, Taproot, gingen er jaren aan brede discussie en testen vooraf aan de stemming. Er was dus al behoorlijk grote eensgezindheid voordat het activatiemechanisme van de upgrade in gang werd gezet. Die overeenstemming is er in dit geval nog niet. De discussie over BIP119 laait vooral sinds een paar weken flink op. Achter de vraag over de snelheid waarmee het voorstel in stemming moet worden gebracht zit een meer fundamentele vraag. Namelijk de vraag over wat Bitcoin in essentie is.
BIP119 (Bitcoin Improvement Proposal 119) moet Bitcoin meer mogelijkheden geven om smart contract-achtige functionaliteit te draaien. Transacties zouden er meer programmeerbaar door worden. Denk aan:
Om dit alles te kunnen, gebruikt BIP119 covenants (convenanten). Dat zijn restricties in een script die de voorwaarden stellen aan hoe een transactie-output besteed kan worden.
De zorg is dat er door de kracht van convenanten schadelijke bij-effecten optreden. De indiener van BIP119, Jeremy Rubin, claimt dat zijn zogenaamde Check Template Verify een een minimalistische implementatie van covenants is. Juist over dat punt is twijfel, zoals de geweldige Bitcoin-uitlegger Andreas Antonopoulos uiteenzet in deze Q&A.
Want waar stopt de macht van die covenants? Een uitdaging met convenanten is dat ze een hele reeks recursieve en dus moeilijk te overziene restricties mogelijk maken: 'deze transactieoutput kan door dit convenant alleen uitgegeven worden in een transactie die ook een convenant heeft, die ...' etcetera als een reeks Babushka-poppetjes.
En je hoort het al... restricties op transacties. Dat heeft de keerzijde dat - onbedoeld of niet, ver in de toekomst of niet - Bitcoin niet uitgegeven kan worden zonder toestemming van een convenant. In feite zou het kunnen leiden tot een whitelist of blacklist waarnaar Bitcoin wel of niet kan worden verstuurd. Dat is een functie waarvan misbruik zou kunnen worden gemaakt en die we gewoon niet willen: het maakt Bitcoin minder inwisselbaar (fungible). Je zou in dat geval twee soorten Bitcoin creëren: Bitcoin die overal naartoe verstuurd kan worden en Bitcoin die alleen naar een whitelist mag.
Onder de onenigheid over de mogelijke implicaties van BIP119 ligt de diepere vraag van wat Bitcoin moet zijn. Willen we van Bitcoin ook een smart contract-platform maken of moeten we dat overlaten aan Ethereum en co? Is het niet voldoende dat Bitcoin doet waar het de beste is, namelijk simpelweg hard geld zijn? Introduceren we niet allerlei kwetsbaarheden als we te veel programmeerbaarheid toevoegen?
Het punt van onenigheid waarmee we dit artikel begonnen is procedureel maar daarom niet minder wezenlijk voor wat Bitcoin anti-fragile maakt. Jeremy Rubin wil BIP119 in speedy trial bij de miners brengen: dat zou miners vier maanden geven om hun stem uit te brengen. Als minstens 95% vóór is, is de nieuwe feature 'locked in' en wordt weer een paar maanden later geactiveerd. Dat zou ongekend snel zijn.
Mocht deze speedy trial er komen en mocht de meerderheid van de miners vóór stemmen - allerminst waarschijnlijk is - dan kan dit ongetwijfeld rekenen op pushback van node operators. Dat zijn gewone gebruikers die een kopie hebben draaien van de Bitcoin blockchain. Zij hebben minstens zo veel macht als de miners bij het doorlaten of blokkeren van een nieuw BIP. Iedereen die een node draait, zou kunnen beslissen om blokken van miners die vóór hebben gestemd, te weigeren.
Het consensusmechanisme van Bitcoin hangt dus af van de stem van meerdere soorten partijen en is daarom conservatief. Het zal waarschijnlijk niet lukken om BIP119 er snel doorheen te drukken.