I del 1 af denne todelt serie fokuserede vi på en introduktion til blockchain-analyse af offentligt tilgængelige Lightning Network-betalingsanmodninger eller “fakturaer”, der blev foretaget under den anden Lightning Torch relay-begivenhed, der fandt sted i januar 2020. Vi så på at analysere brugen af ​​både depot og ikke-depot mobil tegnebøger.

I denne rate undersøger jeg mulige scenarier, hvor privatlivets fred kan blive kompromitteret, og måder til at mindske risikoen, når du kører en privat node-instans. Denne artikel vil også gøre opmærksom på nye teknikker til transaktion på Lightning Network, herunder Multi-Path Payment og Key Send, og grunden til at disse er især vigtige for Lightning Network’s pålidelighed.

Opsætning af privat knude

Under de “private” tegnebøger klassificerede jeg alle andre knudepunkter, der køres, fra eclair gennem c-lightning, lnd eller endda electrum på backend, og kører i ethvert muligt scenario for at være en plug-and-play-løsning, VPS- vært eller et hacky-projekt på ens bærbare computer eller enkelt bordcomputer. Med hensyn til selvforældremyndighed er brug af en privat node-opsætning den valgmulighed, der anbefales af early adopters.

Jeg vil argumentere med den hardcore mening, at alle skal køre deres egen Lightning Network-knude, i det mindste så længe standardløsninger får nyere og mindre kyndige brugere til at deanonymisere sig utilsigtet. Så længe disse nyankomne ikke er opmærksomme på alle faldgruber og ulemper ved deres handlinger, kan de påføre sig selv skade.

De fleste plug-and-play-noder muliggør Tor-forbindelser, og mange brugere udnytter denne mulighed med åbne arme. Kun en tredjedel af de 51 private noder (online under sampling) blev oprettet ved hjælp af clearnet, hvor størstedelen kørte over Tor. Det er gode nyheder, da udstationering af fakturaer af disse brugere ikke deanonymiserer deres placering.

Hvad vi kan lære om lyn fra # LNTrustChain2: Del 2

Det andet store problem med hjemmeløsninger er behovet for at sikkerhedskopiere kanaltilstande. Selv på en standard ikke-depotopsætning af enten LND eller c-lightning, skulle man bruge noget brugerdefineret script for at eksportere kanaltilstanden efter hver tilstandsændring. I tilfælde af katastrofe skal sikkerhedskopifilen med den nyeste tilstand være eksporteret til en anden maskine og være perfekt til cloud / distribueret lager. Hvis kanaltilstanden viser sig at være anderledes (ældre) end den, der er forhandlet med en peer, ville det resultere i at straffe brugeren ved at tage alle ens midler (via en sanktionstransaktion).

Faktisk har LND en endnu bedre løsning: A Sikkerhedskopiering af statisk kanal (SCB) kræver ikke at gemme den sidste tilstand. I stedet gemmer det kanalinformationen, så efter genstart af noden på en anden maskine er det stadig muligt at informere peer-noder om, at de har brug for at lukke de fælles kanaler med deres sidste tilstand. Peers ville derefter bruge den seneste stat for at undgå risikoen for at miste penge i en bøderetransaktion.

En tredje mulighed involverer brugen af ​​vagttårne, specielle noder, der gemmer information om kanalhistorik. I tilfælde af nedetid under driften af ​​ens knudepunkt vil en vagttårn stå på vagt og (i nogle tilfælde) forhindre snyd under kanalens lukningstrin.

Disse førnævnte sikkerhedskopieringsscenarier er imidlertid komplicerede at implementere, og ingen er i øjeblikket en del af en standardkonfiguration af LND / c-lynknude. Så selvom en strømbruger krydser forhindringen ved kanalsikkerhedskopier og tilslører deres IP-adresse, bliver de næste gang nødt til at prøve at finde den hellige gral: adresse uklarhed.

Hvad vi kan lære om lyn fra # LNTrustChain2: Del 2

PSA: The Lightning Network bliver hårdt udvindet af data lige nu. Åbning af kanaler giver alle mulighed for at samle din tegnebog og knytte dine nøgler til din IP-adresse. Brug Tor, brug private kanaler, brug coinjoins …

– ncklr (@ n1ckler) 29. maj 2019 Jonas Nick, Blockstream-ingeniør, på Twitter

Der er stemmer, der siger, at Lightning Network er en privatlivsløsning forklædt som en betalingsprotokol, men det vedrører aktiviteten inde i netværket.

Et af de største problemer med Lightning Network-brugere, der deanonymiserer sig, vedrører handlingen med at åbne udgående kanaler. Hver offentlig Lightning Network-kanal starter med at oprette en bitcoin-engagementstransaktion, og når vi taler om transaktioner, er der et sted for blockchain-analyse.

Adresser i ens “nøglering” af tegnebøger kan deanonymiseres ved flere heuristikker med fælles inputklynger som den lavest hængende frugt. En måde at bryde disse heuristikker på er at udføre en CoinJoin på de midler, der er beregnet til åbning af kanaler. Åbning af offentlige kanaler ved hjælp af blandede mønter er en god on-chain-løsning og kræver forudgående handling (ved hjælp af en CoinJoin-tjeneste), men der er også en anden løsning – åbning af private kanaler.

Ligesom i tilfælde af ikke-depotmæssige mobile tegnebøger kan man åbne en privat kanal for en velrenommeret peer, så den udgående likviditet altid skjules for resten af ​​netværket. Som i tilfældet med Breez- og Acinq (Phoenix) -noder er kanalerne synlige for dem. Den samme mulighed gælder i forbindelse med enhver anden peer, når man åbner private kanaler, så den sikreste løsning er at lave CoinJoin-blanding efterfulgt af åbning af private udgående kanaler.

Det er ikke så forfærdeligt!

Mens nogle medlemmer af Lightning-samfundet deanonymiserede deres placering og bitcoin-tegnebøger i forbindelse med deres offentlige Twitter-profiler, var der andre, der brugte CoinJoin og / eller private kanaler. Derfor finder jeg det vigtigt at en gang imellem indsamle forskning og kommentere fortrolighedsresultaterne ved specifikke handlinger.

Der var også medlemmer, der brugte de nye funktioner i Lightning Network, specifikt flervejsbetalinger og nøglesending. Disse brugere står i spidsen for vedtagelsen af ​​Bitcoin / Lightning og tester nye grænser for denne nye teknologi.

Multi-Path Payment (MPP) eller Atomic Multi-Path Payment (AMP) er en funktion, der er særlig interessant fra et punkt hos fakturamodtageren, som muligvis ikke har en indgående kanal med tilstrækkelig likviditet til at foretage en betaling. MPP hjælper ved at tillade brugen af ​​flere kanaler og ruter til at rumme hele betalingsbeløbet. Dette er en fantastisk udvikling og en kendsgerning, der vil tavse mange Lightning Network-kritikere og deres argument om begrænsninger i betalingsvolumen relateret til den mindste kanal på ruten.

Da denne ændring rullede ud for c-lyn, Acinq og LND lige før den anden iteration af LN Torch var der mulighed for, at den blev brugt af medlemmer af relæet. AMP er en del af ruteprocessen, så lige fra fakturalæsningen er der ingen måde at gætte på, men når man husker sidste års kamp med fakturaer, der var for store til betalinger, og behovet for at opdele dem i mindre stykker manuelt, var dette års proces meget glattere. Denne forbedring skyldes sandsynligvis bedre LN-infrastruktur med afbalancerede kanaler; brugen af ​​den AMP-funktion, der bruges og det faktum, at mange af fakkelbærerknudepunkterne (mindst en tredjedel) havde “MPP” -funktionen åben.

Key key er en type spontan betaling, hvor der ikke er behov for en faktura. I stedet skal betalingsmodtageren dele nodens offentlige nøgle til afsenderen; derefter kan den afsendende part igangsætte betalingerne uden begrænsninger i en standardfaktura. Det har mange fordele, som evnen til at sende tilbagevendende betalinger uden behov for at bede om en faktura og derved mindske en fakturas udløbstid eller være i stand til at specificere beløbet på afsendersiden. Fra LND version 0.9.0-beta er det stadig en eksperimentel funktion, men den blev brugt af to medlemmer af # LNTrustchain2 til at modtage fakkelen.

Konklusion

Oprettelse af eksperimenter som # LNTrustchain2 er en glimrende måde at få repræsentative prøver af Lightning Network-aktivitet på, hvilket giver os et vindue ind i dets fremtid. Det giver os mulighed for at kvantificere dataene, testfunktioner (key send / MPP) og giver også mulighed for Lightning Network fans til at oprette forbindelse.

Den del af disse forskningsresultater, der slog mig mest, var relateret til den høje procentdel af brugen af ​​frihedsberøvende tjenester. Da Lightning Network vokser både teknisk og med hensyn til bevidsthed og uddannelse, vil forvaringsporteføljer have svært ved at konkurrere med de nye bølger af native Lightning-tegnebøger, som ikke ofrer brugervenlighed til selvforældremyndighed, som Phoenix eller Breez.

Jeg blev positivt overrasket over resultatet af, at to tredjedele af private knudepunkter blev sammenkoblet ikke gennem clearnet, men af ​​Tor. Dette er et meget opløftende resultat, når det kommer til privatlivets fred og nogle aspekter af censurmodstand (relateret til mulige MiTM-angreb). Når alt kommer til alt, kan vi ikke glemme, at mange blockchain-analytiske virksomheder også ser nøje på tilstanden af ​​Lightning Network, og de vil finpudse eventuelle privatlivslækende muligheder for at tilføje til deres profitmodeller..

Ser vi tilbage fra dagens perspektiv, første gang Hodlonaut lancerede relæet i 2019, er Lightning Networks fremskridt med hensyn til både privatliv og brugergrænseflade enorme – og det ser ud til at være klar til at gå ud over sit ry for kun at være tilgængeligt for tekniske brugere.

Anerkendelser:

Forfatteren vil gerne takke Jarret Dyrbye for hans nyttige kommentarer til artiklen og datasættet samlet. Alle indsamlede data og resultater er en del af blockchain-analyse, hvor slutresultatet er sandsynligt og vedrører en type analyse udført på kilden.