Merkalized Abstract Syntax Tree (deel 2)

In een eerder artikel zijn we ingegaan op de basis van MAST. In dit artikel zullen enkele voordelen van deze ontwikkeling worden belicht.

Een voorbeeld van MAST

We nemen de casus uit het vorige artikel (die met Alice, Bob en Charlie) en splitsen het probleem op in aparte sub-scripts voor elk van de twee uitkomsten:

  1. Alice kan haar bitcoins op elk gewenst moment uitgeven (linksonder in de onderstaande afbeelding)
  2. Na drie maanden waarin Alice haar bitcoins niet zijn uitgegeven, kunnen Bob en Charlie samen beslissen waar Alice haar bitcoins aan uitgegeven dienen te worden (rechtsonder in de onderstaande afbeelding)

De merkle tree op basis van de uitkomsten ziet er als volgt uit:

mast

De merkle root voor deze tree identificeert de volledige encumbrances in slechts 32 bytes. Vervolgens dient er een merkle proof getoond te worden door eenieder die de bitcoins wilt uitgeven. De merkle proof koppelt de merkle root en de scripts waarbij de encumbrances van de scripts 'correct' zullen moeten teruggeven. Alleen hierna kan worden bewezen dat de initiator het sub-script uit zou mogen voeren.

De merkle proof met het sub-script zou gevisualiseerd kunnen worden afhankelijk van welk sub-script er gebruikt moet worden:

mast

Voordeel 1: kleinere transacties

Een van de voordelen van MAST is de mogelijkheid om bepaalde transacties kleiner te maken. In het voorbeeld hierboven gingen we uit van twee sub-scripts; Alice verstuurt haar bitcoins, of Bob en Charlie bepalen waar de bitcoins van Alice heen mogen. Als we deze mogelijkheid nog verder toepassen, dan zouden Daan en Ella de maand daarop weer samen bepalen waar de bitcoins aan besteed worden, gevolgd door Fred en Gert die dat weer een maand later kunnen.

Deze functionaliteiten zouden een enorme hoeveelheid data met zich meebrengen. Elke voorwaarde dient immers opgenomen te worden in de transactie, ook al is de kans groot dat veel van de latere voorwaarden niet gebruikt zullen worden.

Onderstaand een grafiek waarin de grootte van het script met en zonder MAST wordt aangegeven, bij een toenemend aantal sub-scripts.

jqurlqxgggkgatig

Dezelfde grafiek op logaritmische schaal:

mast

Zoals te zien op bovenstaande grafiek start de MAST transactie iets groter – en dus duurder – dan de transactie die geen gebruik maakt van MAST. Echter schaalt de niet-MAST-transactie lineair waarbij de MAST transactie logaritmisch schaalt. Dit betekent dat de MAST transactie exponentieel efficiënter wordt naarmate er meer sub-scripts worden gebruikt, ten opzichte van de gewone transactie.

Als het sparen van data in een transactie het hoofddoel is, kan dit nog verder worden geoptimaliseerd. Bij de meeste encumbrances zullen verzenders vaker een bepaalde voorwaarde gebruiken dan een andere.

Een voorbeeld: Alice gaat er vanuit dat ze nog lang te leven heeft. Ze zorgt er daarom voor dat de voorwaarde waarin zij zelf de bitcoins mag uitgeven bovenaan de merkle tree staat. Eventuele latere voorwaarden hoeven niet te worden aangeroepen zolang Alice nog leeft, hierdoor bevat de transactie dus ook niet elke keer de extra data van de latere voorwaarden.

mast

Hierdoor hebben de MAST merkle proofs twee verschillende grootten. Een van de transacties wanneer Alice leeft en als enige de bitcoins kan versturen, de ander in de gevallen waarbij Alice niet meer leeft (of een lange tijd geen teken van leven heeft getoond) waardoor Bob en Charlie de bitcoins mogen verzenden. Op basis van de eerdere grafiek over de grootte van de MAST- en niet-MAST-transacties is de onderstaande grafiek van toepassing op deze casus.

mast

In de best case scenario is te zien dat Alice altijd hetzelfde aantal bytes gebruikt voor de transactie, onafhankelijk van het aantal extra begunstigden die er in de encumbrance worden meegenomen. Eventuele latere verzenders, zoals Bob en Charlie, hoeven slechts enkele bytes extra aan de transactie toe te voegen wanneer zij de bitcoins willen verzenden.

Hoe Alice het ook regelt met de begunstigden die mogelijk later de bitcoins zouden kunnen versturen, de besparing per toegevoegd sub-script blijkt significant.

Voordeel 2: meer privacy

Omdat we het hele verhaal van Alice uitvoerig hebben behandeld, ken je als het goed is alle details van de encumbrance. Stel je nu voor dat alleen de data die daadwerkelijk nodig is voor de te versturen transactie aan de blockchain wordt toegevoegd wanneer Alice haar bitcoins verzendt (het voorbeeld linksonder), zonder alle volgende voorwaarden:

mast

Met alleen deze informatie zou je niet weten of iemand anders dan Alice toegang zou hebben tot de bitcoins of welke voorwaarden hun uitgaven zouden kunnen beperken. Je zou kunnen raden aan de hand van de MAST dat er andere voorwaarden bestaan, maar dat zou alleen maar een gok zijn; Alice zou net kunnen doen alsof ze zelf aan meerdere voorwaarden dient te voldoen om haar eigen bitcoins te kunnen versturen.

Anderzijds, als je alleen de andere voorwaarden zou zien (rechter voorbeeld hierboven), dan zou je niet weten dat de bitcoins vóór de time-out – na 3 maanden – konden worden besteed of dat een enkele persoon (Alice) deze kon uitgeven. Je zou dus weer kunnen raden dat er andere omstandigheden waren, maar je kunt op basis van de data in de blockchain geen zekere conclusie trekken.

De mogelijkheid om alle voorwaarden van de encumbrance onbekend te laten kan voor sommige gebruikers erg belangrijk zijn, zoals bedrijven die hun smart contracts vertrouwelijk willen houden voor mogelijke concurrenten. Dit staat in contrast met sommige altcoins die specifiek zijn ontworpen voor smart contracts, welke totaal geen privacy voor de smart contract data bieden.

Privacy kan ook een ander voordeel bieden wat van toepassing is op alle bitcoingebruikers, zelfs diegenen die zich niet druk maken om de privacy van de encumbrance zelf. Stel je voor dat Alice de enige persoon is die ooit de niet-MAST-encumbrance gebruikt. Omdat hierbij de volledige encumbrance openbaar wordt gemaakt, kan iedereen alle uitgaven van Alice volgen door slechts te zoeken naar gevallen waarin hetzelfde soort encumburance wordt gebruikt. Hierdoor wordt Alice haar privacy volledig tenietgedaan.

mast

Alles wat het gemakkelijk maakt om bepaalde gebruikers te identificeren, maakt het ook eenvoudig om hun bitcoins anders te behandelen dan bitcoins van anderen; een gebrek aan fungibiliteit. Fungibiliteit houdt de vervangbaarheid van een voorwerp in; de ene bitcoin zou niet anders moeten zijn dan de andere. Als iemand weet hoe Alice's bezittingen eruitzien, kan hij of zij miners omkopen of dwingen die transacties niet te minen om zo te voorkomen dat Alice haar bitcoins zou kunnen uitgeven.

MAST alleen kan dit niet volledig oplossen, omdat Alice (of Bob en Charlie) nog steeds een deel van de encumbrance moet onthullen wanneer de bitcoins worden uitgegeven. Het is echter wel mogelijk dat een groot aantal complexe encumbrances wordt samengevoegd tot een kleiner aantal MAST-encumbrances.

De normale transacties van Alice zien er bijvoorbeeld uit als de normale transacties waarvoor slechts één digitale handtekening vereist is, zodat de op MAST gebaseerde transacties van Alice lijken op alle andere op MAST gebaseerde transacties met één slechts handtekening. Dit geeft de privacy van Alice terug en vergroot zowel haar fungibiliteit als de fungibiliteit van alle anderen die dezelfde transactievorm gebruiken.

mast

Dit specifieke voordeel van MAST zal waarschijnlijk goed samengaan met andere voorgestelde functies die de privacy en fungibiliteit voor bitcoingebruikers verbeteren door bepaalde complexe encumbrances te laten voldoen aan één enkele digitale handtekening. Voorbeelden hiervan zijn de generalized threshold trees van Pieter Wuille en Gregory Maxwell, scriptless scripts van Andrew Poelstra scripts en de discrete log contracts van Thaddeus Dryja.

Maar zelfs als geen van deze ontwikkelingen ooit mogelijk wordt op het bitcoinnetwerk, biedt MAST zelf gebruikers al meer privacy en fungibiliteit voor de complexe encumbrances dan nu mogelijk is.

Voordeel 3: grotere smart contracts

Bitcoin heeft drie verschillende byte limieten die van toepassing zijn op scripts, afhankelijk van hoe een encumbrance is opgesteld: een 10.000-byte limiet voor gewone scripts, een 520-byte limiet voor P2SH (pay-to-script-hash) en een 10.000 byte limiet voor SegWit.

Onderstaande grafiek toont deze limieten op de al eerder gebruikte grafiek.

mast

Te zien is dat MAST het mogelijk maakt om een groot aantal extra conditionele voorwaarden als script toe te voegen ten opzichte van de andere methoden.

Er zijn nog meer limieten omtrent de bitcoinscripts die MAST weet te omzeilen. Full nodes op het netwerk hoeven immers ook niet de ongebruikte sub-scripts te valideren en door te sturen over het hele netwerk. Zo blijft de hoeveelheid van alle data die de scripts behelsen vooral bij de gebruiker, en wordt het netwerk hier niet mee belast. Dit scheelt de nodes zowel bandbreedte, geheugen als rekenkracht.

Het daadwerkelijke voordeel van MAST is dus niet alleen het feit dat men uitgebreidere smart contracts kan creëren met een verhoogde privacy, maar indien men dit doet, dit mogelijk is zonder het netwerk extra te belasten.

Dit artikel is geschreven op basis van een artikel gepubliceerd door David A. Harding. David publiceert documentatie van gratis software en is sinds 2014 gefocust op Bitcoin.

Er waren ooit 184 miljard bitcoins

Een van de redenen dat het belangrijk is dat bitcoin niet zomaar aangepast kan worden is om te voorkomen dat er per ongeluk foutjes of bugs worden doorgevoerd. Alle wijzigingen aan de broncode worden daarom zeer grondig gecontroleerd door een grote groep ontwikkelaars. In het verleden is er echter wel eens wat fout gegaan…

Een overloop aan bitcoins

Op 15 augustus 2010 werd namelijk ontdekt dat block nummer 74638 een transactie bevatte die 184.467.440.737,09551616 bitcoins aanmaakte. De transactie was het gevolg van een fout in de code die verantwoordelijk is voor het controleren van de geldigheid van transacties voordat deze in een block worden opgenomen. Er werd in de code geen rekening gehouden met de mogelijkheid dat de som van twee outputs zo groot is dat deze een overflow veroorzaakt.

Bij een overflow is een getal te groot of te klein om gerepresenteerd te worden door het beschikbare aantal bits, waardoor een incorrect getal wordt doorgegeven. Een overflow is vergelijkbaar met een kilometerteller die overloopt naar 0000 nadat een afstand van 9999 bereikt is.

De fout werd snel ontdekt en binnen enkele uren werd er een nieuwe versie van de software uitgerold waarin de fout gerepareerd werd. De aanpassing zorgde voor een fork in de blockchain, waardoor nodes die nog niet geüpdatet waren nog voortbouwden op de verkeerde blockchain. Vanaf block 74691 zat iedereen weer op de juiste versie van de blockchain.

De fout zoals deze voorkwam is zeer zeldzaam in de geschiedenis van bitcoin en vond gelukkig in de beginjaren plaats. De persoon (of personen) achter de moniker Satoshi Nakamoto heeft aangegeven de code van bitcoin in een periode van zo’n anderhalf jaar geschreven te hebben. Het is aannemelijk dat de focus tijdens deze periode lag op het werkend krijgen van het systeem, en niet op het schrijven van waterdichte code. Deze eerste versies van de broncode bestonden maar uit zo’n 3000 regels code, waar de broncode van bitcoin van vandaag ruim 100.000 regels code bevat. Hoewel de broncode nu uitgebreider is dan voorheen, is er ook veel meer aandacht besteed aan het robuust maken van de code door middel van een langdurig proces met veel verschillende ogen op de code. De kans op een herhaling van het incident is dus zeer klein.

Bitcoin Pizzadag 2018!

Ook al schreven we kortgeleden over de herhaling van bitcoin pizzadag via een lightning-transactie, vandaag 22 mei is nog steeds de officiële bitcoin pizzadag. Wederom een goed excuus om een lekkere pizza te bestellen met bitcoin!

Had jij het kunnen voorspellen?

Acht jaar geleden, op 18 mei 2010, deed Laszlo Hanyecz op het forum Bitcointalk het voorstel om twee grote pizza's te laten bezorgen in ruil voor 10.000 bitcoins. Een paar dagen later, 22 mei 2010, is het hem gelukt pizza's te ontvangen tegen betaling van de (toen nog) bijna waardeloze bitcoins. Het werd een historische dag in de geschiedenis van Bitcoin: voor het eerst hadden bitcoins waarde.

Toen we vorig jaar schreven over bitcoin pizzadag had de koers net zo’n 1900 euro bereikt. Er is sindsdien veel gebeurd en inmiddels zweven we rond de 7000 euro. Met een beetje creatief rekenen komen we daarmee uit op een market cap van dik 5 miljard pizza’s voor bitcoin. Wie had dat gedacht, van een pizza voor 5.000 bitcoins naar duizend pizza’s voor één bitcoin.

Een speciale wallet voor een speciale dag

Er wordt elk jaar weer even stilgestaan bij het historische moment. Dit jaar ook door Ledger, de hardware wallet fabrikant. Zij brengen namelijk een speciale editie van de Nano S uit, speciaal voor pizzadag. De speciale editie is gelimiteerd verkrijgbaar (1337 exemplaren) en kan daarmee mogelijk een collector’s item worden. Wees er snel bij als je er een wil bemachtigen.

ledgerpizza

Trezor doet ook mee

Trezor viert ook met 10% korting op alle producten.

dcbfdaece

De recovery seed, wat moet je ermee?

Elke keer dat je een nieuwe bitcoin wallet aanmaakt word je gevraagd (en sterk aangeraden) om de recovery seed veilig op te bergen, maar wat is die seed precies en wat moet je ermee? In dit artikel gaan we in op de functie van de recovery seed en de best practices voor het opbergen daarvan.

Hoe werkt het?

Zoals onlangs wederom te lezen was in onze review van de Trezor Model T krijg je bij het aanmaken of initialiseren van een nieuwe wallet een lijstje met woorden die je veilig moet bewaren. Maar waarvoor dienen deze woorden precies en welke functie hebben ze?

De recovery seed geeft toegang tot al je bitcoins

De recovery seed dient als de basis voor alle privé-sleutels die je in je wallet gebruikt om bitcoins te versturen. Elke privé-sleutel is gekoppeld aan de bijbehorende publieke sleutel, ook wel bitcoinadres genoemd, welke je kunt gebruiken om bitcoins te ontvangen. Elk bitcoinadres dat je gebruikt is uniek, evenals de bijbehorende privé-sleutel. Dit is goed, want we willen niet voor elke transactie hetzelfde adres gebruiken vanwege de nadelige gevolgen voor onze privacy. Toch zou het onhandig zijn als voor elk bitcoinadres een aparte back-up nodig is om deze veilig te houden. De oplossing hiervoor is om een recovery seed te gebruiken op basis waarvan een oneindig aantal privé-sleutels (en bijbehorende bitcoinadressen) gegenereerd kan worden. We kijken op een hoog niveau naar hoe dit werkt, en hoe privé-sleutels afhankelijk zijn van de recovery seed.

Bij het aanmaken van een nieuwe wallet wordt een groot willekeurig getal gegenereerd op basis waarvan de verschillende privé-sleutels aangemaakt kunnen worden. Het is van belang dat dit getal echt willekeurig is, anders is deze mogelijk makkelijk te kraken. De eerste zin van je favoriete liedje gebruiken is dus niet bepaald een veilige basis voor je privé-sleutels. Het gegenereerde getal wordt omgezet in een reeks woorden. Dit kunnen er 12, 24 of meer zijn. Over het algemeen wordt 24 aangeraden, maar is 12 ook veilig. De woorden dienen als menselijk-leesbare representatie van het grote willekeurige getal waar de software mee rekent. Door de seed weer te geven als woorden wordt het een stuk makkelijker om deze op een veilige manier op te slaan en worden fouten bij het overnemen van de seed voorkomen. De lijst met woorden die hiervoor gebruikt wordt bestaat uit 2048 woorden, waarvan de Engelse variant hier te vinden is. Een seed ziet er bijvoorbeeld zo uit:

runway have rocket foot rally short egg exhibit evidence choice false acquire

Van seed naar privé-sleutel en bitcoinadres

De uitleg die nu volgt is een versimpelde en incorrecte versie van het proces om van seed naar privé-sleutel te komen, maar vergelijkbaar met hoe het echt werkt. Voor de volledige specificatie kun je bijbehorende BIPs lezen (1, 2).

Nu we de seed hebben, zullen we een aantal operaties uit moeten voeren om privé-sleutels en bitcoinadressen te genereren. In de werkelijkheid wordt van de recovery seed een master seed afgeleid, maar deze stap slaan wij voor het gemak en begrip even over. Herinner je je de hashfunctie: een hashfunctie is een algoritme dat, gegeven een bepaalde input, een unieke output genereert. Vanuit de gegenereerde output kan niet terug berekend worden wat de input was, maar het is wel mogelijk om, gegeven de input, te controleren dat de eerder getoonde output klopt door het algoritme nogmaals uit te voeren met de input. Een voorbeeld van zo’n hashfunctie is SHA-256. Wanneer we de seed hierboven eenmaal hashen met SHA-256 komt daar de volgende reeks uit:

D40B48CC06C7895FF44EE5D826E0D07C75DC637E405372CE49322D0E508A629B

Voor het gemak zeggen we dat deze reeks dient als onze privé-sleutel. Onze privé-sleutel is niet zomaar terug te draaien naar onze seed. Uiteraard moeten we onze privé-sleutel wel nog omzetten in een publieke sleutel willen we daadwerkelijk bitcoins kunnen ontvangen. Bitcoin gebruikt hiervoor een aantal stappen, wij doen er voor het gemak even één. Bitcoin gebruikt (vooralsnog) Base58Check als weergave voor bitcoinadressen. Wanneer we deze operatie loslaten op de bovenstaande SHA-256 hash van onze seed komt daar de volgende reeks uit:

FGjQtYShC3PB4zdBBq4vvYCvR6y3wE26HRhACyaWMcxi

Deze reeks lijkt op de bitcoinadressen die we gewend zijn. We hebben nu vanuit onze seed een privé-sleutel en bitcoinadres gegenereerd, maar dit is slechts één set. We willen natuurlijk meerdere (oneindig veel) bitcoinadressen kunnen gebruiken vanuit dezelfde seed. Dit kunnen we bereiken door bijvoorbeeld een nummer toe te voegen aan de originele seed, bijvoorbeeld +1, +2, +3, etc.

runway have rocket foot rally short egg exhibit evidence choice false acquire +1
runway have rocket foot rally short egg exhibit evidence choice false acquire +2
runway have rocket foot rally short egg exhibit evidence choice false acquire +3

Door hier SHA-256 op uit te voeren vertaalt dit zich vervolgens naar de volgende neppe privé-sleutels:

833F53DB674E164D825F22D094B794AF1499CA02033E0AF15D9D6485A5A59437 89DEE319AD81BC7FCAE6751890605C634E5621ACDA73B1A4A79B06F91F773CE6 58A800E42E7492C663773D613E8AA44882C11F257F6F8342C3D155239AEEA588

En bijbehorende neppe bitcoinadressen:

9qLR7AwXiqAFDynkSFhUoyCG6mghewYx6SqWPmnagGHt AHByfumb3NBY74cc6BCcwDRRaCj8dmKgc1S4gG7VyPZF 6y5TiEhXY1vKPQeDnreprj1vJbyoRMp7sJS1WsPrkvRV

Op deze manier kunnen we oneindig veel verschillende privé-sleutels en bitcoinadressen genereren op basis van dezelfde seed. Mochten we de toegang tot onze wallet kwijtraken, dan kunnen we de seed gebruiken om opnieuw alle privé-sleutels te generen en zo wederom toegang te krijgen tot onze bitcoins. Toegang tot je wallet verliezen is dus niet zo erg, maar wanneer je de recovery seed ook kwijt bent is het echt niet meer mogelijk om toegang te krijgen tot je bitcoins. Bewaar deze dus goed.

Wat moet je ermee?

Bij de meeste hardware wallets krijg je kaartjes meegeleverd waar je de 12- of 24-woordige recovery seed op kunt schrijven om deze vervolgens op een veilige plek te bewaren. Het is noodzakelijk om de recovery seed altijd offline te bewaren. Alle informatie die online bewaard wordt kan gehackt worden, waardoor je je bitcoins kunt kwijtraken. Wanneer je een wallet op je computer aanmaakt of een mobiele wallet gebruikt zul je gevraagd worden de recovery seed zelf op een papiertje op te schrijven.

  • Sla je recovery seed niet op in Dropbox. Hiermee is de seed kwetsbaar wanneer een kwaadwillende toegang krijgt tot je dropbox account.
  • Vul je recovery seed nooit in op een computer die mogelijk besmet is of verbonden is met het internet, dit is een veiligheidsrisico.
  • Sla je recovery seed niet op in een e-mail. Net als bij Dropbox is je seed kwetsbaar voor eventuele hackers en meelezers.
  • Maak geen online back-up, deze zijn niet veilig.
  • Maak alleen een digitale back-up als je dit doet op een aparte offline computer die nooit verbonden wordt met het internet.
  • Sla de seed niet op een een versleutelde folder op je computer, ook deze kan gekraakt worden.
  • Bewaar de kaart waar je je recovery seed hebt opgeschreven op een veilige plek en weg van water en vuur, bij voorkeur een vuurvaste kluis.
  • Schrijf de recovery seed niet op papier, maar gebruik een waterdichte en vuurvaste variant zoals Cryptosteel.
  • Bewaar je recovery seed niet op één plek, maar op twee of meer verschillende veilige locaties. Op deze manier weet je zeker dat je nog bij je bitcoins kan, mocht de seed op een van de locaties verloren gaan.
  • Splits je 24-woordige seed op in drie delen: woorden 1-8, 9-16 en 17-24. Sla vervolgens de volgende delen op verschillende locaties op: 1-8 en 9-16 op locatie 1, 9-16 en 17-24 op locatie 2 en 1-8 en 17-24 op locatie 3. Zo kun je met de informatie op twee van de drie locaties bij je seed en is de seed tevens veilig mocht een van de locaties onveilig raken of verloren gaan.

Bedenk dat een papieren back-up niet veilig is tegen waterschade en brand. Daarom zijn er alternatieven, zoals de metalen Cryptosteel, waar je je seed fysiek in op kunt slaan. Daarvan vind je hier een review.

Welke soorten nodes zijn er?

Kortgeleden schreven we over het belang van het draaien van een node. In dit artikel gingen we in op de rol van een full node, maar er zijn verschillende soorten nodes die elk een apart doel dienen. In dit artikel zetten we ze op een rijtje.

Van licht tot zwaar

Het soort node dat je draait heeft invloed op hoeveel functionaliteit en betrouwbaarheid de node je kan bieden, alsmede de mate waarin je bijdraagt aan het netwerk. Elke soort node is goed voor een bepaald doel. Tevens is de keuze voor een soort node afhankelijk van de hoeveelheid opslag en bandbreedte die beschikbaar is. We bekijken de verschillende soorten nodes en hun functionaliteit in volgorde van 'licht' tot 'zwaar'.

De Simplified Payment Verification (SPV) node

Een Simplified Payment Verification (SPV) node download alleen de headers van alle blocks tijdens het synchroniseren. Een block header is de unieke identificatie van een block en wordt gebruik om opvolgende blocks aan elkaar te linken; het nieuwere block verwijst naar de block header van het oudere block.

Wanneer de SPV node alle block headers heeft gedownload vraagt deze vervolgens transactie-informatie op van externe full nodes. De SPV node vraagt informatie over transacties die voor de node zelf van belang zijn; de transacties die bij de wallet van de SPV node horen. Door gebruik te maken van de merkle root van transacties uit de block header en de tak waarin de relevante transactie zit kan aan de SPV node bewezen worden dat een bepaalde transactie inderdaad is opgenomen in een block, zonder dat de SPV node zelf de volledige geschiedenis moet downloaden.

De SPV node is de lichtste soort node die gebruikt wordt en biedt minimale verificatie. De SPV node kan niet controleren of de opgenomen transacties geldig zijn, maar alleen een schatting maken over de hoeveelheid proof-of-work die nodig is om een double-spend uit te voeren. SPV nodes worden veelal gebruikt voor lichte wallets, zoals mobiele wallets, waar er niet genoeg middelen zijn om het draaien van een zwaardere node te ondersteunen.

De SPV node is door de lichte eisen voor het systeem zeer geschikt voor allerlei applicaties, maar niet voor toepassingen waar met grotere bedragen gewerkt wordt. De SPV node kan namelijk voor de gek gehouden worden door de full node waar informatie opgevraagd wordt, zonder dat de SPV node vervolgens zelf in staat is om te verifiëren of de informatie helemaal klopt.

De egoïstische 'pruned' node

De term 'pruned' duidt op het weggooien van oude data. Een pruned node download in eerste instantie alle blockdata en verifieert de geldigheid van van alle blocks en transacties. Wanneer de pruned node up-to-date is, verwijdert deze de oude data en houdt dus geen volledige transactiegeschiedenis bij. Hierdoor wordt opslagruimte bespaard.

De aanduiding egoïstisch betekent dat de node geen informatie over blocks en transacties doorgeeft aan andere nodes in het netwerk; de node is niet geïnteresseerd in bijdragen aan het netwerk en is alleen gericht op informatie die relevant is voor de wallet van de node. Doordat de egoïstische pruned node wel eerst de volledige geschiedenis download is de node wel zeker over de geldigheid van transacties.

Door het weggooien van de oude blockchaindata en het niet doorsturen van de ontvangen blocks en transacties bespaart de egoïstische pruned node opslagruimte en gebruikte bandbreedte. Deze soort node kan zinnig zijn wanneer meer zekerheid over transacties nodig is dan bij SPV-applicaties, maar er niet genoeg middelen beschikbaar zijn om de volledige geschiedenis bij te houden en bij te dragen aan het netwerk.

De egoïstische archiverende full node

De egoïstische archiverende full node slaat wél een volledige geschiedenis van de bitcoin blockchain op, maar stuurt geen informatie over de blockchain door naar andere deelnemers in het netwerk. Hierdoor kan de node lokaal allerlei informatie uit de blockchain opzoeken en wél geheel zeker zijn over de geldigheid van transacties, zonder volledig open te staan voor connecties van buitenaf om informatie over de blockchain door te sturen.

De pruned netwerk node

De pruned netwerk node houdt, net zoals eerder beschreven, geen volledige geschiedenis van de blockchain bij. Wél draagt de node bij aan het netwerk door informatie over blocks en transacties door te geven aan andere nodes in het netwerk, maar de informatie die de node door kan geven is beperkt tot de meest recente 144 blocks.

De node kan een limiet instellen voor de hoeveelheid bandbreedte die dagelijks gebruikt mag worden voor het doorgeven van informatie over de blockchain. Maar omdat de node geen volledige geschiedenis bijhoudt is deze niet in staat bij te dragen aan het netwerk door informatie over de gehele blockchain opvraagbaar te maken.

De archiverende netwerk full node

Een archiverende netwerk full node is een node die een volledige geschiedenis van de blockchain bijhoudt (en verifieert) en ook gehele kopieën van de blockchain door kan geven aan de andere deelnemers in het netwerk. De archiverende netwerk node is een van de 'zwaarste' nodes die men kan draaien, omdat deze de hoogste eisen aan de gebruikte opslagruimte en bandbreedte stelt.

Daartegenover staat dat dit soort node essentieel is voor het netwerk. Dit soort node draagt bij aan een gezond netwerk. De node maakt het mogelijk om nieuwe full nodes van start te laten gaan door informatie over de blockchain door te sturen en dient tevens als node waarmee een SPV node verbinding kan maken om informatie over een transactie op te vragen. Onmisbaar dus.

Economische full nodes

Tot slot zijn er de full nodes die het meeste invloed hebben: de economische nodes. Dit zijn nodes die gebruikt worden om economisch verkeer op te baseren. Dit kan de node van een privé-gebruiker thuis zijn, of de node van een bedrijf dat met bitcoin-betalingen werkt. Zoals beschreven in het artikel over het belang van het draaien van een node, zijn dit de nodes die de meeste invloed op het netwerk uitoefenen.

Economische full nodes bepalen namelijk welke transacties gezien worden als geldige betaling. Hiermee dienen economische full nodes als handhavers van de consensusregels. Als een betaling immers niet door een economische partij geaccepteerd wordt, dan is dit geen geldige transactie voor de consensusregels die de partij in kwestie aanhoudt. Full nodes, en met name economische full nodes, zijn dus uiteindelijk degene die bepalen welke regels het netwerk aanhoudt. Dáárom is het van belang dat iedereen zo’n node kan draaien: elke gebruiker moet in staat zijn bij te dragen aan het handhaven van de regels waar hij of zij voor kiest.

Het Lightning Netwerk groeit snel

Kortgeleden vond de 'officiële' launch van het Lightning Netwerk op het mainnet, het live hoofdnetwerk, van Bitcoin plaats. De launch was vooral symbolisch en een antwoord op de vraag "wanneer is het Lightning Netwerk af?" Er zijn verschillende teams die technologie gaan toepassen op Bitcoin en Lightning is nog volop in ontwikkeling, maar het netwerk groeit al snel. Er zal waarschijnlijk geen moment komen dat het netwerk echt 'af' is, maar wie wil en durft kan het al gebruiken.

Er is natuurlijk geen centrale instantie die een dergelijke aankondiging kan maken; voor de technici was het maanden (of jaren) geleden al mogelijk om een Lightning-achtige betaling uit te voeren en op dit moment is er nog steeds enige handigheid voor nodig, maar in de toekomst zal eenieder Lightning-betalingen kunnen uitvoeren. De launch werd gevierd met de week van de Lapps.

Duizenden payment channels

In deze interactieve Lightning Netwerk explorer is te zien dat het netwerk inmiddels bestaat uit ruim 1700 Lightning-nodes en meer dan 5000 payment channels. De visualisatie laat zien hoe het Lightning Netwerk opereert als 'tweede laag' bovenop Bitcoin en geeft daarmee een krachtig beeld van de snelle groei die plaatsvindt. De nodes en payment channels die te zien zijn in de visualisatie zijn maar een deel van het gehele netwerk.

Op dit moment is de totale capaciteit van alle payment channels nog maar zo’n 15 bitcoins. Dit is uiteraard nog niks; de meeste channels zijn waarschijnlijk bedoeld voor het testen en ontwikkelen van de technologie, of het doen van kleine aankopen zoals stickers in de Blockstream Lightning Store. Het netwerk is in een paar maanden tijd snel gegroeid.

Lightning wallets

Er zijn al meerdere Lightning-ready wallets te downloaden voor gebruik. Verwacht nog geen vlekkeloze ervaring, want het Lightning netwerk is nog altijd in beta. Android gebruikers kunnen meteen van start met mobiele betalingen, welke natuurlijk nodig zijn om het Lightning Netwerk écht levensvatbaar te maken voor dagelijks gebruik. De Eclair Android wallet van Acinq is in de Play Store te downloaden. Ook is de Eclair wallet beschikbaar voor MacOS, Windows en Linux via GitHub. Daarnaast is tevens de Zap wallet 'klaar' voor gebruik. Mobiele wallets voor iPhone volgen als het goed is snel.

Vergeet de koers, word bitcoin-ontwikkelaar!

Voor velen is een van de bekendste en meest aantrekkelijke aspecten van bitcoin de koers, maar de meeste handelaren komen er snel achter dat die koers toch wat lastiger te voorspellen is dan gedacht. Een betere weg naar rijkdom is daarom wellicht om simpelweg wat bitcoin(s) aan te schaffen en vervolgens je tijd te steken in het bijdragen aan de ontwikkeling van bitcoin. Dus, wordt bitcoin-ontwikkelaar!

Handelen is niet voor iedereen

Bitcoin staat al zo lang als het bestaat bekend als een enorm volatiele investering. Bitcoin is en zal daarom ook altijd interessant blijven als handelsproduct. Periodes van euforie die samen gaan met dagelijkse nieuwskoppen over de nieuwe hoogtes die de koers van bitcoin heeft bereikt laten het soms lijken alsof bitcoin een alsmaar in waarde stijgend goed is. Over de lange termijn genomen is bitcoin op zijn zachtst gezegd een succesvolle investering geweest, maar wie verwacht daar op korte termijn zijn voordeel mee te doen kan zijn vingers branden.

Deel uit maken van de groei van bitcoin is een avontuur op zich, gedreven door technologische innovatie en ideologische denkbeelden, maar bitcoin zal niet iedereen van de ene op de andere dag miljonair maken. Zoals we in het verleden al zagen: als men op een verkeerd moment instapt, zonder de vastberadenheid om voor mogelijk vele jaren de investering vast te houden en gedegen begrip van bitcoin als investering, dan kan dat negatief uitpakken. Handelen is daarom niet voor iedereen. Razend interessant blijft die koers natuurlijk wel.

Verder kijken dan de koers verandert hoe je naar de koers kijkt

Gelukkig valt er veel meer te beleven dan de sensatie van koersstijgingen en koersdalingen, maar daarvoor is het wel nodig om iets dieper te kijken naar wat bitcoin ons brengt. Begrijpen waar je in investeert, dat is misschien wel de meest waardevolle tip; alleen dan weet je waar je aan begint. Wanneer je de tijd neemt om je in te lezen over wat bitcoin is, hoe het werkt, en hoe het zich potentieel in de toekomst kan gaan ontwikkelen, zal duidelijk worden dat bitcoin niet simpelweg een investering is: het is een beweging en een nieuwe manier van kijken naar hoe we met geld en vertrouwen omgaan. Een betere weg naar rijkdom is daarom wellicht om simpelweg wat bitcoin(s) aan te schaffen en vervolgens tijd te steken in het bijdragen aan de ontwikkeling van bitcoin.

Wanneer je in deze beweging kruipt verandert je beeld van bitcoin van 'nerdy digitaal e-money' als geldboom naar betaalmiddel dat de potentie heeft de wereld te veranderen en grenzen te laten vervagen. Net als het internet dat heeft gedaan, heeft bitcoin de kans om de wereld nog een stuk kleiner te maken. Pas wanneer je de implicaties van de technologie begint te doorzien kun je een goed beeld vormen van bitcoin als investering. Wanneer je dit doet, dan kan het wel eens zo zijn dat je inziet dat investeren in bitcoin secundair is. Primair staat het gebruik van bitcoin als wereldwijd, vertrouwensloos en decentraal betaalmiddel. En wie weet, misschien besluit je met dit nieuw gevonden inzicht wel een steentje bij te dragen aan de ontwikkeling van het protocol en de infrastructuur daaromheen.

Bekijk de vacatures bij Bitonic als je je geroepen voelt!