Is het gevaarlijk om meerdere implementaties van Bitcoin te hebben?

Dit is een opinieredactie van Bill Scoresby, een op bitcoin gebaseerde eigenaar van een klein bedrijf en schrijver van verschillende handleidingen voor zelfbewaring van bitcoin.

De bugs die er onlangs voor zorgden dat veel LND-nodes niet meer synchroon liepen met de Bitcoin-blockchain, waren dat wel waarschijnlijk veroorzaakt door een alternatieve implementatie.

Misschien vraagt ​​u zich af: “Wie ter wereld gebruikt er iets anders dan? Bitcoin Core?” Je wist misschien niet dat er andere implementaties van Bitcoin bestonden. Misschien weet u niet zeker wat een andere implementatie eigenlijk betekent.

Bitcoin Core begon als de software die dat deed Satoshi Nakamoto geschreven in C++ en vrijgegeven aan de wereld. Het is bijgewerkt met nieuwe versies die tot op de dag van vandaag leiden. Een alternatieve implementatie is software die hetzelfde doet als Bitcoin Core – dezelfde consensusregels afdwingt – maar anders is geschreven, meestal in een andere codeertaal.

Hoe heeft een alternatieve implementatie knooppunten op het Lightning-netwerk verbroken?

Een van de belangrijkste versies van Lightning Network-knooppunten (LND) is afhankelijk van een alternatieve Bitcoin-implementatie genaamd btcd. Toen een ontwikkelaar een zeer grote multisig-transactie creëerde, beschouwde btcd deze niet als geldig omdat deze te veel getuigengegevens bevatte. Andere Bitcoin-implementaties – vooral Bitcoin Core – hadden een dergelijke limiet niet op de gegevens van Taproot-transacties en accepteerden daarom de transactie en het blok dat deze bevatte als geldig.

Het resultaat was dat mijnwerkers nieuwe blokken aan de keten bleven toevoegen omdat ze geen btcd gebruikten en volgens hun regels was er niets aan de hand, maar LND Lightning-nodes konden deze nieuwe blokken niet herkennen omdat ze bovenop het blok waren gebouwd dat die ene transactie die zij als ongeldig beschouwden.

Toen de bug zich op 1 november opnieuw voordeed, waren niet alleen de LND-nodes getroffen. Sommige electrs-instances (een implementatie van de backend-server voor Electrum Wallet) slaagden er ook niet in consensus te bereiken met de rest van de keten. Terwijl de LND-knooppunten buiten de consensus werden gezet vanwege een soortgelijk probleem in btcd, was het een implementatie van Bitcoin geschreven in Rust die zorgde ervoor dat de elektrs-knooppunten achterop raakten, inclusief enkele zeer zichtbare servers gerund door mempool.space.

Er bestaat een limiet voor de omvang van getuigengegevens om DoS-aanvallen te voorkomen, en maakt ook deel uit van Bitcoin Core (hoewel Core een grotere limiet heeft voor Taproot-transacties). Het lijkt erop dat de andere twee implementaties die niet synchroon liepen, daarvoor code hadden handhaafde de kleinere grens.

Zeer kleine verschillen in implementatie kunnen leiden tot een gebrek aan consensus.

Het hebben van meerdere implementaties van Bitcoin is gevaarlijk

Satoshi hield niet van het idee van meerdere implementaties van Bitcoin. “Ik geloof niet dat een tweede, compatibele implementatie van Bitcoin ooit een goed idee zal zijn.” De reden die hij opgaf was: “Een zo groot deel van het ontwerp hangt af van het feit dat alle knooppunten exact identieke resultaten in lockstep krijgen, dat een tweede implementatie een bedreiging voor het netwerk zou zijn.”

Dreiging? Wat is het probleem?

Je hebt waarschijnlijk gehoord dat de keten met de meeste proof-of-work de echte keten is. Wanneer twee verschillende mijnwerkers tegelijkertijd een blok vinden, splitst de keten zich en beginnen andere mijnwerkers te bouwen op het blok waar ze het eerst over horen.

Zodra een nieuw blok aan de ene kant van de splitsing wordt toegevoegd, accepteren de meeste knooppunten en mijnwerkers dat als de nieuwe echte keten en verlaten ze de andere kant van de splitsing. Deze blokken worden oude blokken genoemd, hoewel sommige mensen ze verweesde blokken noemen.

Aangezien de gemiddelde tijd tussen blokken in Bitcoin 10 minuten bedraagt, is het waarschijnlijk dat het hele netwerk over dit nieuwe blok zal leren voordat er één aan de verliezende kant van de splitsing wordt toegevoegd, en de keten met het meeste werk wint.

“Nodes zullen de geldige keten volgen met het meeste werk…Het sleutelwoord hier is geldig. Als het knooppunt een blok ontvangt waarvan het vaststelt dat het ongeldig is, maakt het niet uit hoeveel werk er bovenop dat blok wordt gedaan, het knooppunt zal die keten niet accepteren.” — Andreas Chow

Het sleutelwoord is ‘geldig’. De dreiging manifesteert zich wanneer een mijnwerker een blok vindt waarvan sommige andere mijnwerkers en knooppunten denken dat het niet geldig is. Mijnwerkers die denken dat het geldig is, zullen proberen nieuwe blokken op die keten te bouwen. Mijnwerkers die denken dat het niet geldig is, zullen proberen voort te bouwen op het laatste geldige blok dat ze kennen. Het resultaat: twee ketens en geen manier om te weten wat waar is.

Hoe zou zoiets in vredesnaam kunnen gebeuren?

Welnu, zoals we zagen in het geval van de recente bug met LND-nodes: als er een bug zit in één implementatie van Bitcoin die niet in andere implementaties voorkomt, kan dit leiden tot een gebrek aan consensus over de vraag of een blok geldig is of niet.

Bitcoin heeft geen mechanisme om dit op te lossen. De gemeenschap buiten het protocol moet beslissen wat er daarna gebeurt. Het klinkt heel onaangenaam.

Zozeer zelfs dat Bitcoin-ontwikkelaar Peter Todd dat heeft gezegd andere implementaties moeten bug-voor-bug overeenkomen met Bitcoin Core.

Daar ga je: meerdere implementaties zijn gevaarlijk!

Wat zijn de andere implementaties van Bitcoin en waarom bestaan ​​ze?

Allereerst gebruikt bijna iedereen Bitcoin Core.

Luke Dashjr ziet ongeveer 43,000 knooppunten, Waarvan 98% Bitcoin Core gebruikt en iets genaamd Coin Dance ziet bijna 15,000 knooppunten, Waarvan 96% Bitcoin Core gebruikt. Op dit moment lijkt het erop dat maar heel weinig mensen alternatieve implementaties gebruiken.

Niettemin zijn er actieve projecten die proberen andere codebases te bouwen en te onderhouden die het Bitcoin-protocol implementeren. Ze bevatten:

Jameson Lopp heeft een uitstekende pagina met een meer uitgebreide lijst en links naar alle andere implementaties.

Bij al deze projecten werken extreem getalenteerde ontwikkelaars, en ze bestaan ​​allemaal al meer dan een paar jaar. Waarom zoveel moeite steken in iets dat zo'n probleem lijkt?

Bitcoin is zonder toestemming. Iedereen kan de keten downloaden; iedereen kan communiceren met het netwerk; en niemand kan je ervan weerhouden een alternatieve implementatie te coderen of uit te voeren.

Toch duidelijk sommige mensen hebben de leiding van het aanbrengen van wijzigingen in de Bitcoin-repository en het proces om deze te kiezen lijkt informeel. Terwijl er de Bitcoin Improvement Proposal (BIP)-proces voor het voorstellen van wijzigingen aan Bitcoin Core is het ook behoorlijk informeel.

Niets van dit alles is een direct probleem. Zoals Marty Bent opmerkt: ruwe consensus kan een kracht zijn. Als het proces van het veranderen van Bitcoin moeilijk en onduidelijk is, betekent dit dat veranderingen grondiger zullen worden doorgelicht.

De volgende stap van ruwe consensus is het hebben van meer dan één populaire implementatie.

Het niet hebben van meerdere implementaties kan gevaarlijker zijn

Er kan geen twijfel over bestaan ​​dat het al een zeer moeilijke klus is om een ​​van de mensen te zijn die toegang heeft tot Bitcoin Core. In een wereld waarin Bitcoin een centrale rol speelt als monetair instrument, zal deze taak veel moeilijker worden. Een kleine groep ontwikkelaars zou een zeer waardevol doelwit kunnen zijn. Op zijn minst zal hun aandacht worden gevraagd om te lobbyen voor verschillende opnames of uitsluitingen in de volgende softwareversie.

Denk eens aan de lobbyindustrie die momenteel in de politiek bestaat. Waarom zou zoiets zich niet ontwikkelen rond de mensen die toegang hebben tot de enige implementatie van het Bitcoin-protocol?

Net als politici nu zal de indruk worden gewekt dat zij toegang hebben tot macht. Als zodanig zullen mensen zich op hen richten, alleen zullen deze ontwikkelaars niet de kracht van een staat hebben om ze te verdedigen. Wat voor leven gaat dat worden? Wie zou er vrijwillig voor kiezen?

Uiteindelijk is het mondiale financiële systeem een ​​behoorlijk zwaar gewicht dat op de schouders rust van de kleine groep mensen die commit-toegang hebben tot één GitHub-repository. Misschien niet zo heel anders dan het mondiale financiële systeem dat we proberen te ontvluchten, waarbij de monetaire toekomst van mensen afhangt van de beslissingen van een paar centrale bankiers.

Meerdere implementaties schieten te hulp!

De aanwezigheid en het wijdverbreide gebruik van meerdere implementaties op het Bitcoin-netwerk kan deze druk verzachten door het voor een kwaadwillende actor veel moeilijker te maken om het Bitcoin-protocol te wijzigen.

Als deelnemers aan het Bitcoin-netwerk gelijkmatiger verdeeld zijn over verschillende implementaties, is er meer ruimte voor goede ideeën. Het voorstellen van wijzigingen in Bitcoin of het afwijzen ervan is veel gedecentraliseerder als het niet allemaal in één kamp gebeurt.

Het is duidelijk dat het gebruik van verschillende implementaties van Bitcoin het risico op een ketensplitsing vergroot. Een catastrofale ketensplitsing – waarbij een aanzienlijk deel van de knooppunten en mijnwerkers per ongeluk afsplitste – zou niet goed zijn voor Bitcoin, en zeker niet voor de prijs ervan. Maar het zou het toestemmingloze karakter van Bitcoin niet bedreigen.

Een gecentraliseerde ontwikkelomgeving waarin iedereen alleen op Bitcoin Core bouwt, zou de toestemmingloosheid kunnen bedreigen. Het gesprek over dit onderwerp moet de risico’s van het zo sterk afhankelijk zijn van Bitcoin Core aanpakken, in plaats van zich uitsluitend te concentreren op de problemen die kunnen worden veroorzaakt door een alternatieve implementatie.

Er is een geweldige, oudere artikel over dit debat van Aäron van Wirdum. U kunt ook een recentere, informatief draadje over.

Dit is een gastpost van Bill Scoresby. De geuite meningen zijn volledig hun eigen meningen en weerspiegelen niet noodzakelijkerwijs die van BTC Inc of Bitcoin Magazine.