Afgelopen maandag deed zich een probleem voor met bitcoin. Of beter gezegd: een probleem voor het lightning netwerk. Door toedoen van één persoon, moesten duizenden mensen in de hele wereld ‘iets’ doen met hun lightningnode. Vandaag lees je meer over deze zogenaamde tapscript-multisig-lnd-struggle:

“Looks like lnd/btcd has a bug in their taproot implementation.”

Wat? Nou, dat is precies wat ik je deze week graag uitleg. Tevens vertelt de Nederlandse lightningfanaat Edward Hollander zijn persoonlijke verhaal over de gebeurtenis.

Deel van lightning plat

Bitcoiners met een eigen lightningnode schrokken even. Iedere bitcoinnode die block 757.921 aan het verifiëren en synchroniseren was én de lnd-software gebruikt, liep tegen hetzelfde probleem aan. Zo ook de node van Edward:

“Mijn node leek zich geen kwaad bewust, want het doen van een betaling lukte wel. Alleen het openen en sluiten van de betaalkanalen ging niet, zo zag ik in posts op sociale media communities.

Daarvoor had ik zelf al allerlei technische stappen doorlopen om het issue te verhelpen. Ik controleerde of de node goed was gesynchroniseerd in verband met de traagheid van het Tor-netwerk, ik probeerde een nieuwe sd-kaart, ik checkte de grootte van het databasebestand van de betaalkanalen. Maar niets hielp, totdat ik een tweet tegenkwam in de Telegram communities.”

Over deze tweet later meer. Eerst even een korte basisuitleg over lightning en lnd.

Lnd staat voor lightning network daemon. Dit is een secundaire laag dat bovenop het bitcoin protocol is gebouwd. De software komt uit de koker van Lightning Labs. Je kunt ook gebruik maken van varianten eclair (van ACINQ) en Core Lightning (van Blockstream). Daarover later meer.

In deze editie van Bitcoin Focus lees je meer over het probleem, de oplossing en de keiharde waarschuwing die de bitcoiner Burak (onbedoeld) gaf aan de bitcoincommunity.

Bijzondere transactie

Terug naar het allereerste begin. Het begon bij de bitcoingebruiker Burak, die een bijzondere transactie deed. Op Twitter deelde hij zijn succes met trots:

“I just did a 998-of-999 tapscript multisig, and it only cost $4.90 in transaction fees.”

Een multisig-transactie is een betaling waarbij je met meerdere private keys de UTXO die je wilt uitgeven ondertekent. In feite verdeel je het eigenaarschap van een coin onder meerdere personen waarbij x-uit-x personen goedkeuring moeten geven alvorens de coins kunnen worden uitgegeven.

In dit geval heeft Burak een Taproot-transactie gedaan waarbij er 998 ondertekeningen (signs) nodig zijn van de 999 die er zijn ingesteld.

Dit zijn bijzondere transacties. Tapscript is de scripting taal die wordt gebruikt voor Taproot scripts. Taproot is de grootste bitcoinupdate die eind vorig jaar is geactiveerd. Met deze softwareverbetering kun je multisig-transacties doen, zonder dat dit op de blockchain zichtbaar is.

Je kunt Burak’s betaling zelf in de mempool/blockchain nakijken (en merken dat dit eruit ziet als een normale bitcoinbetaling).

btcd

Zo’n bijzondere betaling heeft bijzondere gevolgen voor de btcd-versie die lnd standaard gebruikt. Btcd is een bitcoinnode die de gehele transactiegeschiedenis downloadt en verwerkt. Het is de onderlaag voor bitcoin dus, waar de secundaire (lightning) laag dan op voortborduurt.

Draaide je een lnd-node én was jouw bitcoinnode bezig met het synchroniseren van block 757.921, dan stopte de lightningkant van de node ineens (deels) met werken. Niet bij een persoon, maar bij het gros van de gebruikers op het lightning netwerk!

Volgens het Clark Moody Dashboard zijn er nu circa 17.000 openbare nodes. Dat zegt nog niets over het aantal gebruikers, maar geeft enigszins de orde van grootte van het netwerk weer.

Edward vertelt:

“Ja, er was zeker paniek. Eerst viel het nog wel mee, want het was in Europa midden in de nacht. In de LightningNL-community kwam ik één iemand tegen met een soortgelijke issue, daarna ook in de Umbrel-community. “

“In de Plebnet-community kwam ik uiteindelijk die tweet van Burak tegen. En de reacties van VS, Jestopher, Fiatjaf en andere grote namen zorgden er snel voor dat ik gerust gesteld werd. Ik heb direct een Twitterdraadje de wereld ingeslingerd, en mijn bevindingen gedeeld in de Nederlandse groepen en de CTW en SRROF groepen. Amper een uur later was Roasbeef al bezig met een oplossing voor lnd.”

“Helaas zijn er wel al mensen geweest die te snel begonnen waren met troubleshooten en daarbij nog verder gingen dan mijn acties. Dus echt from scratch opnieuw beginnen en backups terugzetten. Zeker in de Umbrel community is advies lastig te peilen op betrouwbaarheid voor niet/minder ervaren gebruikers.”

Op GitHub deelden ontwikkelaars al snel eenzelfde probleem: v0.15.0 van lnd liep vast. Waarom? In de btcd-versie die lnd gebruikt stond een bug. Dat had ontwikkelaar benthecarman al snel door:

“Looks like lnd/btcd has a bug in their taproot implementation.”

Hij had gelijk. In Bitcoin Improvement Proposal (BIP) 342 staat een limiet op de scriptgrootte. Die was ingesteld op 10.000 bytes.

“The maximum script size of 10.000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.”

Wat bleek? De transactie van Burak was dermate groot dat het deze script size limiet overtrof. Het script witness item 33.970, wat groter was dan de maximale toegestane grootte.

Omdat btcd het block 757.921 niet kon verifiëren, kon het ook de alle daarop volgende blocken niet in de blockchain rijgen. En daarom stopte lnd met het ‘verder synchroniseren’.

Men kreeg de melding synced_to_chain=false. Je kunt dit zelf met jouw eigen node checken met het commando lncli getinfo in de cli.

Edward vertelt ons over zijn ervaring met dit probleem:

“Om 23:23 op 09-10 kreeg ik van Lightning.Watch bot een melding (na 5 minuten gracetime) dat mijn node down was, logde ik in op mijn node en merkte ik meteen iets geks. De blockchain was volledig gesynchroniseerd, maar alle connecties met mijn peers en channels waren offline.”

Na het checken van de lnd logs zag ik meldingen als:
– “Waiting for chain backend to finish sync”
– “Unable to complete chain rescan: readScript: script witness item is larger than the max allowed size [count 396669, max 11000]”
– “Server is still in the process of starting”

De lnd-nodes verloren het contact met andere peers. Het gevolg is dat (een deel van) lightning verlamd was, losgeslagen van het netwerk. Want wat niet onbelangrijk is: het gros van álle lightning-nodes gebruikt lnd.

Naar schatting is meer dan 70% van de publieke (routering) nodes gebaseerd op lnd (circa ~11.000 publieke nodes), en de resterende 30% op eclair en Core Lightning. Hoewel hier geen keiharde cijfers van bekend zijn, is deze trend al wel lange tijd zichtbaar.

MyNode en Umbrel zijn de twee bekendste nodesoftwarepakketen die beide automatisch lnd gebruiken. Ook in Raspiblitz en Start9Labs kun je lnd kiezen.

Oplossing en gevolgen

Oplossingen ontstonden er in verschillende vormen en maten. Edward vertelt:

“Sommigen hadden geen problemen, doordat ze een andere versie van lnd draaiden. Maar veel peers/channels waren offline/niet bruikbaar.”

“Ik heb zelf uiteindelijk mijn originele SD-kaart weer teruggeplaatst, en nadat Roasbeef de fix had uitgebracht voor lnd ben ik alle distributies afgegaan. Raspiblitz had snel al de oplossing beschikbaar door de update mogelijkheid naar beta-versies van lnd. Umbrel duurde wat langer, omdat ze eerst wilden testen. Uiteindelijk was het beste advies toch echt wachten. Want channels sluiten in deze status van lnd is niet handig.”

Nu de oorzaak van het probleem bekend is, konden developers met een oplossing komen. Zogezegd was Olaoluwa Osuntokun, ook wel bekend als Roasbeef en CTO van Lightning Labs, er als de kippen bij. Op Twitter deelde hij enkele uren later versie 0.15.2 van lnd.

Wat is er veranderd? De maximale scriptgrootte is opgehoogd van 11.000 naar 4.000.000.

Je kunt de hotfix en/of patch zelf op GitHub teruglezen. Lang verhaal kort: het probleem is opgelost en node-eigenaren kunnen hun software upgraden. Maar intussen was er ook al enige schade geleden. Want véél bitcoiners moésten ineens hun software upgraden.

Zo ook de grote betaalverwerkers binnen de bitcoin industrie, zoals IBEX Mercado (die we een aantal weken geleden nog spraken in een interview) maar ook wallet – en liquiditeitsproviders zoals Breez. Laatstgenoemde kon geen nieuwe betaalkanalen openen voor gebruikers. Hierdoor kon je als nieuwe gebruiker die de Breez-wallet net downloadde dus niet zomaar een lightningbetaling ontvangen.

De rest kun je qua impact zelf wel invullen: een deel van het hele lightning netwerk stond tijdelijk op stand-by.

Lighnting-implementaties

Dit was toch wel bijzondere voorval en het zet een aantal belangrijke dingen op de agenda.

Ten eerste laat deze bug zien dat het lightning netwerk (te) veel leunt op lnd. De software van Lightning Labs is misschien wel te populair geworden. Gelukkig bleven de alternatieven Core Lightning en eclair wél zonder problemen werken. Dit roept om meer alternatieven!

Hoe meer implementaties, hoe minder impact een bug kan hebben. Een implementatie kun je zelf maken: je moet code schrijven die werkt met de opgestelde Basics Of Lightning Technology (BOLT). Naast bovengenoemde zijn er wel een aantal experimentele alternatieve implementaties zoals Peach Daemon, lit, LNP Node, ptarmigan en Rust Lightning. Ze zijn echter nauwelijks in gebruik.

Persoonlijke tips

Voor iedereen die een lnd-node draait, is het belangrijk om te kijken hoe het er voor staat met jouw peers. Osuntokun heeft de verbetering gereleased en ook de meeste software-diensten zoals Umbrel en MyNode hebben de oplossing intussen doorgevoerd.

• Bij Umbrel kun je de lnd-update naar v.0.15.2-beta doorvoeren.
• In MyNode moet je updaten naar v0.3.03.
• Voor BTC Pay Server moet je updaten naar v.0.15.2.
• Raspiblitz kun je de volgende stappen doorlopen.

Een ander essentieel punt is dat dit aantoont dat lightning nog bèta software is. Ondanks dat Twitter, El Salvador en tig van beurzen het gebruiken en er sinds vorige week 5.000 bitcoin ter waarde van $96 miljoen in publieke (!) betaalkanalen zit, blijft lightning nog altijd beta.

Houd dat in je achterhoofd als je met sats speelt op je Raspberry Pi. Het is overigens een goed teken dat dit pas de eerste keer is dat lightning op deze schaal last heeft van een probleem.

Impact voor gebruikers

Het feit dat duizenden node-eigenaren indirect door één persoon (Burak) min of meer verplicht worden om hun software te update, kan voor twijfels zorgen. Is dat wel in lijn met bitcoin? Hard forks (en verplichte node-upgrades) zijn toch uit den boze? Edward vertelt:

“De opmerkingen op Twitter van “bro this broke lnd” en “You took most of the LN down. Which is good, this is why it’s still beta” lijken wel te kloppen. Ja, lightning is in bèta en nog niet 100% betrouwbaar. Dat wil niet zeggen dat dit direct een probleem is.”

“Lightning moet gebruikt worden. Het is nodig om te blijven experimenteren door grote groepen van mensen. Alleen dan is er de mogelijkheid om, gedreven door alle nieuwe innovatieve mogelijkheden die het kan bieden, een betere infrastructuur te worden. Maar feit is wel dat er ook meer ontwikkelaars en onderzoekers nodig om echt op korte termijn te werken aan verbeteringen op het lightning netwerk.”

Edward vervolgt:

“Het hoort zeker bij de fase waarin lightning zich nu bevindt. En de communities kan je ook zien als één grote proefvijver van kritische testers. Uiteindelijk zijn het diezelfde communities waarin duidelijkheid komt en uiteindelijk ook nieuwe ontwikkelaars opstaan die of deel worden van de nieuwe oplossingen.”

Daarbij is er wel één belangrijke notie: deze lnd-upgrade heeft niets te maken met wat bitcoin is en wat de consensusregels zijn. Het gaat niet over ‘de maximale voorraad van 21 miljoen bitcoin’ of ‘het ongeldig maken van Satoshi’s coins’ of iets dergelijks. Bitcoin blijft bitcoin en de regels in het protocol die bitcoin maken wat het is, worden niet door een ander persoon afgedwongen. Het is een implementatieprobleem, niet een consensusprobleem.

Voorzichtigheid

Tot slot nog een afsluiter voor node-eigenaren: door dit protocol brede probleem kon je ook niet vertrouwen op watchtowers. Dit zijn nodes die namens jou de balansen in de betaalkanalen bijhouden in het geval je onverhoopt offline raakt (bij een probleem met jouw internetverbinding of micro-sd/ssd.

Maar wat als ook de watchtowers offline raken? Let goed op en denk aan het geld dat je op jouw eigen lightning node zet! Dat deelt Edward ook:

“Zelf ben ik het zeker eens dat je voorzichtig moet blijven met de hoeveelheid liquiditeit die je vastzet in betaalkanalen. Kies je doel dat je hebt met je node zorgvuldig. Wil je een beetje routen, heel veel of wil je alleen sats uitgeven voor het doen kleine betalingen? Dat vraagt allemaal om een andere strategie, inrichting en keuzes.”

“Ik moet toegeven dat ook ik af en toe wel zenuwachtig wordt van dat soort momenten. En toch is het belangrijk om rust te blijven bewaren, niet te veel risico nemen van tevoren als het gaat om de liquiditeit, maar ook zeker als troubleshooter geen verkeerde dingen doen.”

“Dus voor mij blijft: Verdiep je er in als je bereid bent meer risico wilt lopen. En zorg voor de juiste software en hardware keuze die past bij je strategie. En kijk zeker ook hoe je back-upstrategie in elkaar zit en waar je hulp kan vinden. En natuurlijk ook of de software leverancier adequaat en snel reageert om problemen op te lossen.”

“Blijft over dat ik het zelf eigenlijk alleen maar leerzaam vind. Ieder issue zorgt weer voor nieuwe lessen voor de toekomst!”

Ride the Lightning!
Arnold