Daar zijn we weer! Zoals jullie weten wijden we één keer per maand een aparte editie aan het lightningnetwerk. Deze secundaire laag bovenop bitcoin verdient meer aandacht. In deze Lightning Focus duiken we met name in de problemen rondom lightningadressen, de beloftes van BOLT12 voor betere oplossingen voor lightning native invoices en hoe iemand 4 BTC aan liquiditeit is kwijt geraakt. 

Bestel nu hét bitcoin tijdschrift Bitcoin Focus! Een hoog kwaliteitsmagazine over bitcoin in Nederland; geschreven voor, door, met en over bitcoiners. Ruim 70 pagina’s dik. Bestel nu en ontvang hem nog voor het einde van dit jaar. Met de code BITCOINFOCUS ontvang je 10% korting!

Daarnaast volgen we andere nieuwe ontwikkelingen binnen de lightningwereld, waaronder het sturen van lightningbetalingen naar “gewone” e-mailadressen om het niet-bitcoiners makkelijker te maken om zelf te gaan starten. Tot slot zijn er ook weer een aantal highlights uit de nostr-wereld, die meer dan de moeite waard zijn om zelf te gaan proberen!

Maar laten we het eerst hebben over een voorstel van verbeteringen die de lightningontwikkelaar Bastien Teinturier (Chief Technology Officer bij ACINQ) onlangs gepost heeft in de lightning-dev mailinglijst. Zijn doel is o.a. de privacyproblemen van lightningadressen op te lossen. Het kan namelijk zo maar zijn dat de beheerder van de gekoppelde webserver niet alleen je IP weet, maar ook aan je funds kan komen. 

Lightningadressen 

Een lightningadres ziet eruit als een e-mailadres en is daardoor gemakkelijk te onthouden. In de vorige Lightning Focus #13 editie lees je hoe een non-custodial lightningadres via de app Zeus is aan te maken.

Deze adressen kan je telkens opnieuw gebruiken en zijn dus perfect om te delen en op je website of webshop te plaatsen voor het ontvangen van betalingen en donaties. Klinkt ideaal dus! Maar aan een lightningadres kleven ook nadelen.

Huidige nadelen 

Veel gebruikte lightningadressen zijn gebaseerd op LNURL. Dit vereist dat er constant een webserver beschikbaar is om lightningadressen te koppelen aan lightning invoices. Bastien noemt in zijn bericht een aantal van de huidige problemen: 

• Het IP-adres van zowel de betaler als de ontvanger is door de beheerder van de webserver te achterhalen. 
• Ook kan de beheerder lightning invoices manipuleren om sats te stelen. Dit wordt ook wel een man-in-the-middle aanval genoemd. 

• Tot slot vraagt het runnen van een webserver om kennis en ervaring in het werken met DNS en webhosting. Het is dus complex om zelf op te zetten voor de gemiddelde gebruiker. 

De nadelen zijn voornamelijk gerelateerd aan privacy en gebruiksgemak. En het is duidelijk dat een continu actieve webserver, beheerd door een derde partij, mogelijke beveiligingsrisico’s met zich meebrengt. 

Omdat het gemak van lightningadressen heel aantrekkelijk is voor gebruikers, kiezen deze nu vaak voor een custodialoplossing, wat compleet in tegenstelling is tot de bitcoinethos. De (nog niet perfect doorontwikkelde) technologie duwt de gebruiker echter deze kant op. Of: duwde? 

Statische invoices met BOLT12 

Om het voorstel van Bastien en de discussie die erop volgt goed te begrijpen, is het boeiend om eerst iets meer te weten over wat BOLT12 ook alweer is. En dan met name de voordelen die het kan bieden voor de manier waarop we lightningbetalingen doen, verwerken en ontvangen. 

BOLT’s (Basis of Lightning Technology) definiëren de protocolspecificaties, waardoor lighting implementaties zoals LND, Core Lightning en Eclair allemaal naadloos met elkaar kunnen communiceren. Op dit moment gebruiken we het BOLT11 invoice protocol voor lightningbetalingen. 

BOLT12 is een voorstel van Rusty Russell van Blockstream. Dit nieuwe voorstel maakt het mogelijk dat lightningnodes native statische QR-codes genereren voor zowel het ontvangen als het verzenden van betalingen. Ook maakt BOLT12 gebruik van Onion Messages voor communicatie en coördinatie tussen nodes, waardoor externe servers (die bijvoorbeeld vereist zijn voor het gebruik van LNURL) overbodig worden.

Meer privacy door Onion Messages 

In het lightningnetwerk zijn Onion Messages een soort digitale boodschappen die anoniem zijn te versturen. Stel je voor dat een bericht in lagen (zoals de lagen van een ui) is verpakt. Elke laag bevat instructies voor de volgende ontvanger in de keten.

Wanneer een ontvanger een laag verwijdert, ziet hij alleen naar wie hij het bericht vervolgens moet sturen, zonder te weten waar het oorspronkelijk vandaan kwam of waar het eindigt. Dit zorgt voor meer privacy, omdat niemand de hele route van het bericht kent.

Het is als een geheime boodschappenestafette, waarbij elke deelnemer slechts een klein stukje van het pad kent. Omdat de communicatie, dankzij Onion Messages, tussen lightningnodes direct en privé gebeurt, zijn webservers als tussenpersoon niet meer nodig.  

Offers 

Daarnaast introduceert BOLT12 ook ‘offers’. Eigenlijk is dat een voorstap naar invoice requests, waarmee gebruikers meerdere invoices kunnen aanvragen. Een andere mogelijkheid is het aanmaken van terugkerende invoices, een soort abonnement.

Stel je voor dat Alice een betaling wilt ontvangen van Bob. Met BOLT12 kan Alice een “offer” maken: een verzoek dat alle informatie bevat die Bob nodig heeft om een betaling te starten. Alice’s offer bevat een unieke code en informatie over de betaling, zoals het bedrag en de valuta. Bob ontvangt dit offer, bijvoorbeeld via een QR-code.

Hij gebruikt deze informatie om een factuur aan te maken, die hij terugstuurt naar Alice voor een betaling. Hierdoor kan Alice een betaling ontvangen zonder altijd online te zijn, en het proces is veiliger en privé, omdat de details van de transactie niet openbaar zijn. 

Verschil met BOLT11 

Met het huidige BOLT11 zijn betalingen alleen te starten als de ontvanger een factuur genereert en deze naar de betaler stuurt. Dit vereist dat de ontvanger online is op het moment dat de factuur is aangemaakt en gedeeld.

Bovendien zijn alle betalingsdetails publiekelijk gedeeld, wat privacyproblemen kan opleveren. BOLT11 biedt dus minder flexibiliteit en privacy vergeleken met BOLT12, waarbij een ontvanger een “offer” kan maken dat de betaler kan gebruiken om zelf de factuur aan te maken, zelfs als de ontvanger offline is. 

Lees hier meer verschillen tussen BOLT11 en BOLT12. Okay, en nu terug naar de oplossingen voor een veiliger gebruik van lightningadressen.

Potentiële oplossingen 

Bastien stelt voor om de privacyproblemen aan te pakken zonder in te boeten op de gebruiksvriendelijkheid. Hij geeft uiteindelijk drie ontwerpopties: 

1. Een DNS-record van een domein (bijvoorbeeld bitcoinfocus.nl) koppelen aan een lightningnode identifier. De betaler vraagt dan via een Onion Message een offer aan voor de uiteindelijke ontvanger (bijvoorbeeld [email protected]). Het domein antwoordt met een signed offer en zorgt ervoor dat de betaler later fraude kan bewijzen wanneer de offer niet van Edward was. Voor toekomstige betalingen weet de betaler voortaan dat dit contact te vertrouwen is. 

2. Een lightningnode kan zich voortaan alleen nog maar aankondigen binnen het netwerk, wanneer de aankondiging is voorzien van een SSL certificaat van het domein. De SSL-certificaten tonen dan aan dat een bepaalde node gelinkt is aan een specifiek lightningadres. Dit vereist wel dat SSL-gebaseerde cryptografie is toegevoegd in alle lightning-implementaties. 

3. Domeineigenaren creëren DNS TXT-records voor elke adres in een domein dat een BOLT 12-offer bevat. Elk record is specifiek voor een gebruiker en bevat hun offer, wat de domeineigenaar verplicht om deze records regelmatig bij te werken. Dit is eenvoudig voor de verzender, maar kan leiden tot een groot aantal DNS-records voor de domeineigenaar. 

Bastien benadrukt het belang van eenvoud in implementatie en stelt daarom voor om opties 1 en 3 te combineren, waarbij gebruikt wordt gemaakt van DNS-aanvragen en Onion Messages voor verbeterde privacy en efficiëntie. 

Reacties op zijn voorstel 
In de reacties op het voorstel van Bastien Teinturier is een mengeling van steun, vragen en zorgen te vinden. Sommige ontwikkelaars zijn voorstander van het combineren van opties 1 en 3 vanwege de schaalbaarheid en eenvoud.

Anderen brengen praktische problemen naar voren over het implementeren van miljoenen DNS-entries. Er is discussie over de veiligheid en schaalbaarheid van het gebruik van DNS versus traditionele webservers, met een focus op het minimaliseren van blootstelling van gebruikersgegevens en het vereenvoudigen van het proces voor gebruikers en dienstverleners. 

Dat lightningadressen nog verder zijn te verbeteren, is dankzij dit voorstel weer op de radar gekomen. Wij blijven het in ieder geval volgen en ook de invoering van BOLT12 in de toekomst! 

Overige lightning-actualiteiten

Bitcoiner Hugo Ramos verloor onlangs ongeveer 4 BTC door een beveiligingsprobleem in de LNbank-plugin voor BTCPay server. Hugo gebruikte een oudere versie van LNbank (v1.6.2) om betalingen voor winkeliers in El Salvador te faciliteren. 

Zijn lightningnode werd echter gebruikt door een fraudeur om 998 ongeautoriseerde betalingen uit te voeren naar één wallet, waardoor in totaal 407.361.805 sats (ruim 4 BTC) zijn weggesluisd. Hij bereidt nu een juridische zaak voor bij de autoriteiten in Tsjechië en Moldavië, omdat de IP-adressen die betrokken waren bij de aanval, afkomstig zijn van internetproviders in die landen.

Verder dringt hij aan bij alle LNbank gebruikers om te upgraden naar de nieuwste versie (v1.8.9) om soortgelijke incidenten te voorkomen. Wil je het hele verhaal teruglezen? Check dan het bericht op stacker.news. 
 
Ben je benieuwd hoe het eigenlijk werkt om een lightningnode met een enorme hoeveelheid liquiditeit te beschermen? Lees dan deze boeiende blog geschreven door Acinq. 

Stable Channel

Software ontwikkelaar Tony Klaus heeft onlangs de eerste “Stable Channel” op het bitcoin mainnet geopend. Dit maakt het voor gebruikers mogelijk om blootstelling te krijgen aan stabiele USD of de BTC-prijs, geheel via het lightningnetwerk. 

Zijn uitwerking is gebaseerd op een artikel over het “Rainbow Network”, geschreven door Dan Robinson van Paradigm. Daarin bespreekt hij een ontwerp voor een off-chain, non-custodial uitwisselings- en betalingsnetwerk dat elke vloeibare activa ondersteunt.

Het netwerk bestaat uit rainbowkanalen, een variant van betalingskanalen waarin afwikkelingsbalansen worden berekend op basis van de huidige prijzen van andere activa. 

De stable channel van Tony Klaus heeft twee soorten gebruikers: “Stable Receivers”, die een stabiele USD-waarde wensen, en “Stable Providers”, die hun BTC willen inzetten voor leverage. Ze zetten beiden $100 in bitcoin in een gezamenlijk gefinancierd kanaal, waarbij transacties binnen een uur op de bitcoin blockchain zijn afgewikkeld. 

Bij een dalende bitcoinprijs betaalt de Stable Provider aan de Stable Receiver om de stabiliteit van $100 te handhaven, en vice versa bij een stijgende bitcoinprijs. Sinds de bevestiging zijn er 763 settlements geweest, met in totaal 611 betalingen van $43.90, zonder bijkomende transactiekosten. 

De partijen houden zelf toezicht op hun financiën en betalingen. Als een partij niet op tijd betaalt, stijgt de risicoscore van de tegenpartij. De stable channel biedt voordelen zoals zelfbeheer, financiële privacy en decentralisatie, zonder gebruik van fiat, banken of tokens. 

Tony benadrukt echter ook de uitdagingen, waaronder de noodzaak om een node te draaien, het risico van online key’s en mogelijke hoge transactiekosten. Lijkt het je boeiend om deel te nemen aan dit open-source project, kijk dan hier! Lees Tony zijn hele thread op X.  

AcceptLN

AcceptLN is weer een duidelijk voordeel van een tool dat gemaakt is om de onboarding voor niet-bitcoiners een handje te helpen. Ze zijn gevestigd in El Salvador en maken het mogelijk om op een gebruiksvriendelijke manier lightningbetalingen te ontvangen en te versturen via e-mailadressen.

Gebruikers zonder bitcoin- of lightningwallet kunnen hiermee eenvoudig starten door gewoon hun eigen e-mailadres te gebruiken als een lightningadres. Bij elke betaling die naar dit adres is gestuurd, ontvangt de ontvanger een e-mail met instructies om de betaling te claimen naar hun eigen wallet. 

Dit systeem, ontwikkeld door de Canadese oprichter Jamie Robinson, vergemakkelijkt de toegang tot bitcoin en lightning voor zowel nieuwe als ervaren gebruikers en biedt daarmee een belangrijke stap in de adoptie van bitcoin. 
 
Wil je AcceptLN zelf eens proberen om bijvoorbeeld een betaling te sturen aan een niet-bitcoiner? Check dan de website! 

Dunder LSP

In Lightning Focus #13 kon je al meer lezen over bijvoorbeeld Olympus, een lightning service provider (LSP) van Zeus wallet. Met name voor mobiel gebruik en voor een soepele onboarding is het belangrijk om gebruik te kunnen maken van een goede LSP.

Bitcoin OG Darthcoin heeft een mini-gids uitgebracht voor node-eigenaren om zelf een LSP te worden. Zijn doel is om mobiele lightning gebruikers makkelijker toegang te geven tot het lightningnetwerk op een veilige, private en zelfbeheerde manier. 

Hij beschrijft in zijn uitleg de combinatie van 2 features van de Blixt Wallet, namelijk Dunder LSP en Lightning Box. Dunder LSP is ontwikkeld door lightningontwikkelaar Hampus van de Blixt Wallet en biedt gemakkelijke integratie en verbeterde routing voor mobiele lightninggebruikers. Daarnaast introduceert de Lightning Box-functie in de Blixt Wallet een nieuwe manier voor gebruikers om betalingen direct op hun telefoon te ontvangen via een lightningadres. 
 
De gids, die niet bedoeld is voor beginners en benadrukt het belang van goed onderhouden nodes met genoeg liquiditeit. 
 
Wil je er zelf mee aan de slag? Lees dan hier de hele uitleg! 

Een korte greep uit nieuwtjes rondom nostr! 

• Er is al een tijd gesproken over het gebruik van nostr voor long form content, bijvoorbeeld lange berichten en artikelen. Habla.news en blogstack.io zijn al mooie voorbeelden van blogsites die gebruikmaken van NIP-23 om op een visuele manier lange nostr content weer te geven. 

• YakiHonne is een nieuwe mobiele applicatie voor het publiceren en ontdekken van lange artikelen op nostr en het is nu beschikbaar om mee te testen! Je kan nu ook onderwerpen kiezen die je interessant vindt en artikelen cureren en opslaan als favoriet. 
   
  Bekijk het via https://yakihonne.com/ 

• TrueVote is een open-source stemplatform dat gebouwd is op bitcoin, opentimestamps en het nostr protocol om stemgegevens onveranderbaar vast te leggen. Het platform richt zich op het garanderen van de integriteit van elke democratische stem tijdens verkiezingen, waarbij stemgegevens worden gevalideerd met behulp van opentimestamps hashing op de bitcoin blockchain.
  
  TrueVote belooft gebruiksgemak door stemmen via mobiele apparaten mogelijk te maken en gebruikt nostr voor veilige authenticatie. Met een verwachte “minimum value product” release tegen het einde van 2023, positioneert TrueVote zich als een voorvechter van transparantie en verkiezingsintegriteit. 

Dit is weer een prachtig voorbeeld dat laat zien dat bitcoin en nostr samen de ultieme combinatie om diverse problemen op te lossen. Lees meer op de website van TrueVote en lees hier de hele whitepaper. 

Tot de volgende Lightning Focus in het nieuwe jaar vol nieuwtjes uit de lightningwereld om je weer volledig up-to-date te houden! 

Bestel nu hét bitcoin tijdschrift Bitcoin Focus! Een hoog kwaliteitsmagazine over bitcoin in Nederland; geschreven voor, door, met en over bitcoiners. Ruim 70 pagina’s dik. Bestel nu en ontvang hem nog voor het einde van dit jaar. Met de code BITCOINFOCUS ontvang je 10% korting!