Tips & tricks voor bitcoin privacy
Het laatste deel van je Privacy Special! Volgende week weer de nieuws-samenvattingen die je gewend bent, maar nu: dingen die je actief kan doen voor betere privacy, en inzoomen op privacy op Lightning!
Deze week een aantal oplossingen voor on-chain-security voor de geavanceerde gebruiker, en een Focus op Lightning. We beginnen!
De aanval is de beste verdediging
Deze Bitcoin Focus heeft twee delen:
Oplossingen
- Mixen
- Sidechains
- Tweede lagen
- Payjoin
Lightning
- Datalekken
- Privékanalen
- Hops, hops, hops
- Balansen
Oplossing: ‘Mixen’ van je munten
Wat is het: Voorbeeld: jouw Albert-Heijn-bonuskaart is gekoppeld aan jouw identiteit. Bij het aanvragen moest je mogelijk je adres invullen. En je hebt betalingen gedaan met je PINpas waardoor ook op die manier je identiteit gekoppeld is. Wat je kan doen is met een aantal bonuskaarthouders samen komen, die kaarten in een hoge hoed doen, en er een willekeurige uit halen.
Datzelfde kan ongeveer met bitcoin. Je komt samen met 50 gebruikers, gooit allemaal (bijv) 0.01 bitcoin in één transactie, en krijgt er weer 0.01 bitcoin uit. Dat doe je een paar keer achter elkaar, steeds met transacties met 50 inputs en 50 outputs.
Voordelen: Door het mixen raakt de historie weg. De link tussen input en output is niet meer te maken. Dus als je bitcoin kocht met je identiteits-informatie, dan kan je ze mixen, en is die informatie niet meer gekoppeld.
Wasabi en Joinmarket zijn twee mix-implementaties. Zorg dat je niet bij gecentraliseerde diensten uitkomt, daar gaat het vaak mis. Bij zowel Wasabi als Joinmarket geef je de controle over je bitcoin niet weg.
Nadelen: Het is vaak relatief eenvoudig om te detecteren of je bitcoin gemixt zijn. Als je bijvoorbeeld bitcoin naar een exchange stuurt uit zo’n mix (van een transactie met 50 in- en outputs), dan ziet een exchange dat ook, en die wil je bitcoin dan misschien niet meer.
De mensen bij Wasabi hebben daar een ‘oplossing’ voor. Ze checken de inputs van de coinjoins tegen lijsten, en als er een criminele historie is, dan mogen ze niet meedoen. Dat leverde ook veel kritiek op van bitcoiners: die vinden dat ze iedereen moeten laten meedoen.
Oplossing: Sidechains en 2e lagen
Wat is het: De meeste aanvallen, vooral die we vorige week zagen, hebben te maken met onchain transacties. Sidechains (zoals spacechains) en 3e lagen zoals Lightning zorgen dat je bitcointransacties kan doen, zonder on-chain transacties te doen.
Voordelen: Simpel: zonder on-chain-transacties ook geen on-chain-analyse!
Nadelen: Het is wat lastiger, en er is niet altijd ondersteuning door alle wallets. Zeker sidechains zoals spacechains worden actief ontwikkeld maar nog niet veel gebruikt.
Lightning is al vrij populair, daar lees je in deze Bitcoin Focus meer over!
Oplossing: Payjoin en andere slimme transactie-opties
Wat is het: Dit zijn ook opties om on-chain transacties anoniemer te maken.
Stel je even een transactie voor aan een winkel. Je koopt bijvoorbeeld een broodje. Je gebruikt wat bitcoin uit je wallet, dat zijn de inputs, en stuurt naar de winkel, dat zijn de outputs (en wisselgeld).
De aanname die analysebedrijven doen is dat alle inputs van dezelfde gebruiker zijn. Door de ONTVANGER ook inputs te laten leveren, kan die aanname uit het raam.
Voordelen: Het is lastiger voor analysebedrijven om inputs te koppelen aan personen, doordat ze minder zeker zijn dat alle inputs altijd van dezelfde persoon zijn!
Nadelen: Er is meer coördinatie nodig van betalingen, de ontvanger moet het ondersteunen en meehelpen met de transactie. Het is technisch dus wat lastiger, en de ontvanger moet altijd wat bitcoin beschikbaar hebben voor deze joins.
Lightning: Koppelingen met on-chain
De rest van deze Bitcoin Focus gaat over Lightning.
Hoe zit het met privacy op Lightning? Het is een tweede laag, dus je doet minder 1e-laag (on-chain) transacties.
Toch heb je voor Lightning nog wat on-chain-transacties nodig. Als je slechts een wallet gebruikt, dan heb je een on-chain-transactie nodig om geld op de wallet te zetten, en daar gelden dezelfde ‘problemen’ voor als we de afgelopen weken zagen: koppelen van historie en (mogelijk) identiteit.
Als Lightning-nodebezitter doe je meer transacties. Je opent kanalen met on-chain bitcoin, en als je kanalen sluit komt het weer in jouw wallet.
De kanalen zijn gekoppeld aan de on-chain transactie. Iemand die wat weet over jouw on-chain transactie (bijvoorbeeld identiteitsinformatie) ziet dus ook dat het kanaal bij jou hoort. En de rest van de kanalen van/naar jouw node misschien ook.
Er wordt gewerkt door ontwikkelaars om de kanalen los te trekken van de transacties, maar dat zal nog even duren. Je zou kunnen overwegen je bitcoin te mixen voordat je een kanaal opent. En bij sluiting ook die transacties te mixen.
Lightning: Zelf Lightning-data lekken
Misschien wil je niet dat jouw Lightning-node aan jouw identiteit wordt gekoppeld, omdat je niet wil laten weten aan mensen dat je bitcoin hebt. Toch is het makkelijk om data te delen:
- Simpelste is als je je node ID in een chatgroep zet, en je chat met jouw echte naam. Je wil misschien wat inkomende kanalen, en vraagt mensen naar jouw node te openen. Nu weten mensen dat die node bij jou hoort.
- In Lightning kan je aliassen zetten voor nodes. Ik heb mensen hun eigen naam zien gebruiken als nodenaam. Dan is het meteen klaar natuurlijk.
- Er zijn sites waar je kan inloggen met je Lightningnode, bijvoorbeeld op amboss.space. Hier teken je een bericht en kan je inloggen. Node –> Gekoppeld! Er wordt gewerkt aan het anoniem inloggen (via lnurl-auth). Misschien iets voor een volgende Bitcoin Focus.
- Als je een invoice stuurt naar een tegenpartij, dan staat in die invoice de begunsdigde: het ID van jouw node.
Je kan nog zo veel technische stappen nemen… Als je de data gewoon vertelt, dan hebben technische stappen ook minder zin natuurlijk!
Lightning: Privekanalen zijn niet prive
Je zou denken: ik open wat privékanalen. Die kanalen worden niet (zoals normale kanalen) aangekondigd aan het netwerk, en doorgegeven tussen nodes.
Je zou nu ook kunnen denken dat er geen link is tussen die privékanalen en jouw on-chain bitcoin.
Dat is niet helemaal waar: want ook privékanalen worden, samen met de link naar de on-chain-transactie soms wel doorgegeven.
Als je een invoice stuurt, dan staat er in die invoice informatie over het privékanaal, om te zorgen dat de betaler een route kan vinden naar jouw node.
Niets houdt de ontvanger van die invoice tegen om de informatie over dat kanaal op te slaan…
Ik ben tegen de term privékanaal, wat mij betreft hadden ze het nooit zo moeten noemen. Misschien was “niet-aangekondigd kanaal” beter geweest: deze kanalen worden niet doorgegeven aan het netwerk.
Lightning: Je betalingen gaan door hops
Betalingen op Lightning nemen stappen. Als Alice een betaling wil doen naar Dave, dan gaat de betaling bijvoorbeeld via Alice naar Bob, van Bob naar Charlie en van Charlie naar Dave.
Al deze tussenpersonen krijgen informatie. Bob ziet bijvoorbeeld een betaling van Alice, en dat de betalingen naar Charlie moet.
De tussenpersoon kan niet zien wat voor (extra) informatie er in de betaling staat, puur dat er een betaling is van een node, naar een andere node.
Bob zag dat de betaling naar Charlie ging, maar weet niet of het de eindbestemming is.
In het Lightningprotocol wordt gebruik gemaakt van Onion-pakketten. De betaling wordt ingepakt in schilletjes. Binnenin alleen de informatie die Dave kan zien. Een versleuteld laagje er omheen dat alleen Charlie kan zien, en weer een versleuteld laagje dat alleen Bob kan zien.
Als Bob dus een pakketje ontvangt, “pakt hij een schil uit” en daar leest (alleen) hij waar de betaling naartoe moet: naar Charlie. Hij ziet niet dat Charlie hem weer moet doorsturen, want dat kan alleen Charlie lezen.
Door die encryptie ziet daar wat minder risico, maar als je meerdere nodes draait als aanvaller, waar betalingen doorheen gaan, kan je wel timing-aanvallen doen. Als je dezelfde seconde een (ongeveer) even grote betaling ziet door twee van je nodes, kan je al meer aannames doen over de route!
Lightning: Balansen zijn niet heel privé
In principe zijn (in het netwerk) alleen de capaciteiten van kanalen bekend: hoeveel hebben de twee kanten van het kanaal samen hebben vast gezet. Er is bijvoorbeeld een kanaal van 100 000 sat tussen Alice en Bob. Er is alleen bekend dat er een kanaal tussen die twee is, van 100 000 sat.
Binnen dat kanaal zal het balans verschillen. In dit voorbeeld staan alle sats bij Alice. Dus het balans is: 100 000 sat voor Alice, en 0 voor Bob.
Buitenstaanders zien/weten dat in principe niet.
Toch kan er worden geprobeerd achter te komen hoe het zit met de balansen, en als je dat met meerdere kanalen doet, dan kan je uit gaan rekenen hoe veel geld Alice totaal heeft in haar kanalen.
Door “balance probing” kan dit worden uitgezocht. Iemand probeert een betaling van 50 000 sat te routeren door de node van Alice, naar Bob. Hij zorgt dat de betaling (uiteindelijk) mislukt, maar laat de nodes van Alice en Bob wel doorgeven óf de betaling mogelijk is (dat is mogelijk in het protocol).
Alice en Bob geven groen licht voor de routering van 50 000 sats van Alice naar Bob.
Nu weet de aanvaller dat er minstens 50 000 sat aan de kant van Alice staat. De aanvaller probeert het nog eens met 75 000 sat, en ziet dat ook dat mogelijk is: conclusie: er staat zelfs 75 000 sat aan Alice haar kant!
Als de aanvaller het omgekeerd probeert: een betaling van Bob naar Alice, dan zal hij een rood sein krijgen: dat gaat niet! En als de aanvaller het maar vaak genoeg doet kan hij vanzelf genoeg conclusies trekken!
Laatste gedachten over privacy
Er is een hoop om over na te denken, en je kan een hoop mis doen.
Als je je echter aan de basisveiligheidsprincipes houdt, kan je bitcoin al snel veilig gebruiken.
En met de zaken als mixen en Lightning kan je actief aan de slag om alles nog veiliger te maken. Heb je vragen over de serie? Mail me even: [email protected] en ik zal kijken of ik eea nog duidelijker kan maken!
