Waarom Bitcoin ertoe deed

Het probleem dat het aanpakte

Digitale informatie laat zich moeiteloos kopiëren. Voor documenten is dat een deugd; voor geld is het een fataal gebrek: als een waarde-eenheid slechts een bestand is, houdt niets je tegen om dezelfde eenheid op twee plaatsen uit te geven. Dat is het dubbeluitgaveprobleem, en elk betaalsysteem moet er op de een of andere manier een antwoord op geven.

Het gebruikelijke antwoord is een beheerder. Een bank, een kaartennetwerk of een betaalbedrijf houdt de gezaghebbende administratie bij en bepaalt welke transactie er het eerst was. Dat werkt goed, en het betekent ook dat die beheerder rekeningen kan bevriezen, boekingen kan terugdraaien, klanten kan weigeren en failliet kan gaan.

Bitcoin stelde een ander antwoord voor: laat een openbaar netwerk transacties ordenen, maak het herschrijven van die volgorde duur met proof of work, en betaal wie dat werk verricht in het activum zelf. Je hoeft niemand persoonlijk te vertrouwen omdat het herschrijven van de geschiedenis meer zou kosten dan de aanval aannemelijk kan opleveren.

Wat er werkelijk nieuw was

Vrijwel alle onderdelen bestonden al vóór Bitcoin. Digitale handtekeningen, hashfuncties, proof-of-workpuzzels, peer-to-peernetwerken en eerdere voorstellen voor digitaal contant geld waren er al. De bijdrage was de samenstelling: een precieze combinatie waarin prikkels, ordeningsmechanisme en verificatieregels elkaar genoeg ondersteunen om zonder beheerder te functioneren.

Die framing is de moeite waard omdat ze de verwachtingen goed afstelt. Bitcoin is een technisch antwoord op een coördinatieprobleem. Het beweert niet dat cryptografie fraude oplost, dat schaarste waarde schept of dat het wegnemen van een beheerder het risico wegneemt.

Het technische document verscheen in 2008 en het netwerk startte in 2009. Dat moment wordt vaak aan de financiële crisis gekoppeld, maar het protocol hoort te worden beoordeeld op zijn gepubliceerde ontwerp en zijn werking, niet op een versimpeld motief dat aan de pseudonieme auteur wordt toegeschreven.

Waar het ontwerp van afziet

Het wegnemen van de centrale beheerder neemt de afhankelijkheden niet weg: het verplaatst ze. Nu hangt het netwerk af van de juistheid van software-implementaties, van een mijnbouw die economisch verspreid blijft, van het vermogen van mensen om hun eigen sleutels te beheren, van connectiviteit, en van een rommelig sociaal proces om het eens te worden over wijzigingen in de code.

Bovendien maakt het bepaalde gemakken per ontwerp onmogelijk. Er is geen wachtwoordherstel, geen terugboeking, geen fraudeafdeling en geen manier om een betaling naar het verkeerde adres ongedaan te maken. Dat zijn geen omissies die later worden hersteld: het is de directe prijs van de eigenschap waardoor het systeem zonder beheerder kan werken.

Gebruik de staat van dienst met zorg

Een lange staat van dienst is echt bewijs van robuustheid. Een netwerk dat jarenlang onder publieke waarneming ononderbroken transacties heeft verwerkt, is beproefd op manieren die een nieuw project niet heeft meegemaakt. Het is redelijk dat mee te wegen.

Het is echter geen bewijs over de prijs en zegt niets over de diensten die rond het activum zijn gebouwd. De meeste mensen die in dit veld geld verloren, verloren het niet door een protocolstoring, maar door een exchange, een bewaarder, een phishingpagina of hun eigen back-up. De staat van dienst van het protocol gaat niet over op het bedrijf dat je rekening beheert.

• Scheid beweringen over het protocol van beweringen over een bedrijf dat het gebruikt.
• Behandel «is nooit gehackt» als een uitspraak over het netwerk, niet over jouw rekening.
• Vraag je af wat een systeem níét voor je kan doen voordat je ervan afhankelijk wordt.