Facebook
Twitter
I del 1 av denne todelte serien fokuserte vi på en introduksjon til blockchain-analyse av offentlig tilgjengelige Lightning Network betalingsforespørsler eller “fakturaer” som ble gjort under den andre Lightning Torch relay-hendelsen som fant sted i januar 2020. Vi så på å analysere bruk av både lommebøker for pleie og ikke forvaring.
I denne delen vil jeg undersøke mulige scenarier der personvern kan bli kompromittert og måter å redusere risikoen når du kjører en privat nodeinstans. Denne artikkelen vil også gjøre oppmerksom på nye teknikker for transaksjoner på Lightning Network, inkludert Multi-Path Payment og Key Send, og årsaken til at disse er spesielt viktige for Lightning Network-påliteligheten..
Oppsett av privat node
Under de “private” lommebøkene klassifiserte jeg alle andre noder som kjøres, fra eclair gjennom c-lightning, lnd eller til og med electrum på backend, og kjører i ethvert mulig scenario for å være en plug-and-play-løsning, VPS- vert, eller et hacky-prosjekt på ens bærbare datamaskin eller en enkelt borddatamaskin. Når det gjelder selvforvaring, er bruk av et privat nodeoppsett anbefalt av tidlig adoptere.
Jeg vil argumentere med hardcore-oppfatningen om at alle skal kjøre sin egen Lightning Network-node, i det minste så lenge standardløsninger fører til at nyere og mindre kunnskapsrike brukere deanonymiserer seg utilsiktet. Så lenge disse nykommerne ikke er klar over alle fallgruvene og ulempene ved deres handlinger, kan de skade seg selv.
De fleste plug-and-play-noder tillater Tor-tilkoblinger, og mange brukere benytter seg av denne muligheten med åpne armer. Bare en tredjedel av de 51 private noder (online under prøvetakingen) ble satt opp ved hjelp av clearnet, hvor flertallet kjørte over Tor. Det er gode nyheter, ettersom utlegg av fakturaer fra disse brukerne ikke deanonymiserer plasseringen deres.
Det andre store problemet med hjemmeløsninger er behovet for å sikkerhetskopiere kanaltilstander. Selv på et standard ikke-depotoppsett av enten LND eller c-lyn, må man bruke noe tilpasset skript for å eksportere kanalstatusen etter hver tilstandsendring. I tilfelle katastrofe, må sikkerhetskopifilen med den siste tilstanden være eksportert til en annen maskin og være perfekt til sky / distribuert lagring. Hvis kanaltilstanden viser seg å være annerledes (eldre) enn den som er forhandlet med en likemann, vil det resultere i å straffe brukeren ved å ta alle pengene sine (via en straffetransaksjon).
Egentlig har LND en enda bedre løsning: A Sikker sikkerhetskopi av statisk kanal (SCB) krever ikke lagring av den siste tilstanden. I stedet lagrer det kanalinformasjonen, så etter at noden er startet på en annen maskin, er det fortsatt mulig å informere peer noder om at de trenger å lukke de vanlige kanalene med sin siste tilstand. Jevnaldrende ville da bruke den siste staten for å unngå risikoen for å miste penger i en straffetransaksjon.
Et tredje alternativ innebærer bruk av vakttårn, spesielle noder som lagrer informasjon om kanalhistorikk. I tilfelle nedetid under driften av ens node, vil et vakttårn stå vakt og (i noen tilfeller) forhindre juks under kanalstengningsfasen.
Imidlertid er disse nevnte backup-scenariene kompliserte å implementere, og ingen er for øyeblikket en del av et standardoppsett for LND / c-lynnode. Så selv om en strømbruker krysser hindringen for kanalsikkerhetskopier og tilslører IP-adressen sin, må de neste prøve å finne den hellige gral: adresse uklarhet.
PSA: The Lightning Network blir tungt utvunnet akkurat nå. Å åpne kanaler lar alle klynge lommeboken din og knytte nøklene til IP-adressen din. Bruk Tor, bruk private kanaler, bruk coinjoins …
– ncklr (@ n1ckler) 29. mai 2019 Jonas Nick, Blockstream-ingeniør, på Twitter
Det er stemmer som sier at Lightning Network er en personvernløsning forkledd som en betalingsprotokoll, men den er relatert til aktiviteten i nettverket.
Et av de største problemene med Lightning Network-brukere som deanonymiserer seg, er knyttet til handlingen med å åpne utgående kanaler. Hver offentlige Lightning Network-kanal starter med å lage en bitcoin-forpliktelsestransaksjon, og når vi snakker om transaksjoner, er det et sted for blockchain-analyse.
Adresser i en «nøkkelring» av lommebøker kan deanonymiseres av flere heuristikker, med vanlig inngangsklynging som den lavest hengende frukten. En måte å bryte disse heuristikkene på er å utføre en CoinJoin på midlene som er ment for å åpne kanaler. Å åpne offentlige kanaler ved bruk av blandede mynter er en god løsning på kjeden og krever forhåndshandling (ved hjelp av en CoinJoin-tjeneste), men det er også en annen løsning – å åpne private kanaler.
Akkurat som i tilfelle ikke-depotmobil lommebøker, kan man åpne en privat kanal for en anerkjent jevnaldrende, slik at den utgående likviditeten alltid er skjult for resten av nettverket. Som i tilfelle Breez og Acinq (Phoenix) noder, er kanalene synlige for dem. Det samme alternativet gjelder for å håndtere andre jevnaldrende når du åpner private kanaler, så den sikreste løsningen er å gjøre CoinJoin-miksing etterfulgt av å åpne private utgående kanaler.
Det er ikke så forferdelig!
Mens noen medlemmer av Lightning-samfunnet deanonymiserte sin plassering og bitcoin-lommebøker i forbindelse med deres offentlige Twitter-profiler, var det andre som brukte CoinJoin og / eller private kanaler. Derfor synes jeg det er viktig å en gang i blant samle forskning og kommentere personvernresultatene til spesifikke handlinger.
Det var også medlemmer som brukte de nye funksjonene i Lightning Network, spesielt flerveisbetalinger og nøkkelsending. Disse brukerne står i forkant av adopsjonen av Bitcoin / Lightning, og tester nye grenser for denne nye teknologien.
Multi-Path Payment (MPP) eller Atomic Multi-Path Payment (AMP) er en funksjon som er spesielt interessant fra fakturamottakerens punkt, som kanskje ikke har en inngående kanal med nok likviditet til å foreta en betaling. MPP hjelper ved å tillate bruk av flere kanaler og ruter for hele betalingsbeløpet. Dette er en fantastisk utvikling og et faktum som vil stille mange Lightning Network-kritikere og deres argument om begrensninger i betalingsvolum knyttet til den minste kanalen i ruten..
Da denne endringen rullet ut for c-lyn, Acinq og LND like før den andre iterasjonen av LN Torch, var det muligheten for at den ble brukt av stafettmedlemmene. AMP er en del av rutingsprosessen, så bare fra fakturalesningen er det ingen måte å gjette, men når man husker fjorårets kamp med fakturaer som var for store for betalinger og behovet for å dele dem opp i mindre biter manuelt, var årets prosess mye jevnere. Denne forbedringen skyldes sannsynligvis bedre LN-infrastruktur med balanserte kanaler; bruken av AMP-funksjonen som brukes; og det faktum at mange av fakkelbærernodene (minst en tredjedel) hadde “MPP” -funksjonen åpen.
Nøkkelsending er en type spontan betaling der det ikke er behov for faktura. I stedet må betalingsmottaker dele nodens offentlige nøkkel til avsenderen; deretter kan avsenderen sette i gang betalinger uten begrensninger fra en standard faktura. Det har mange fordeler, som muligheten til å sende tilbakevendende betalinger uten å måtte be om en faktura, og dermed redusere utløpstiden for en faktura, eller å kunne spesifisere beløpet på avsendersiden. Fra og med LND versjon 0.9.0-beta er det fortsatt en eksperimentell funksjon, men den ble brukt av to medlemmer av # LNTrustchain2 for å motta fakkelen.
Konklusjon
Å lage eksperimenter som # LNTrustchain2 er en utmerket måte å få representative eksempler på Lightning Network-aktivitet, noe som gir oss et vindu inn i fremtiden. Det lar oss kvantifisere data, teste funksjoner (key send / MPP) og tillate også Lightning Network fans å koble til.
Den delen av disse forskningsresultatene som slo meg mest, var relatert til den høye prosentvise bruken av forvaringstjenester. Ettersom Lightning Network vokser både teknisk og med tanke på bevissthet og utdannelse, vil forvaringslommebøker ha vanskelig for å konkurrere med de nye bølgene av innfødte Lightning-lommebøker som ikke ofrer brukervennligheten for selvforsyn, som Phoenix eller Breez.
Jeg ble positivt overrasket over resultatet av at to tredjedeler av private node-forekomster ikke var sammenkoblet gjennom clearnet, men av Tor. Dette er et veldig oppløftende resultat når det gjelder personvern og noen aspekter av sensurmotstand (relatert til mulige MiTM-angrep). Vi kan tross alt ikke glemme at mange blockchain-analytiske selskaper også ser nøye på tilstanden til Lightning Network, og de vil finpusse på eventuelle personvernlekkende muligheter for å legge til sine profittmodeller..
Ser vi tilbake fra dagens perspektiv første gang Hodlonaut lanserte stafetten i 2019, er Lightning Network fremgang når det gjelder både personvern og brukergrensesnitt enorm – og det ser ut til å være klart å gå utover sitt rykte om å være tilgjengelig bare for tekniske brukere.
Anerkjennelser:
Forfatteren vil takke Jarret Dyrbye for hans nyttige kommentarer til artikkelen og datasettet samlet. Alle dataene og resultatene som er samlet er en del av blockchain-analysen der sluttresultatet er sannsynlig og relaterer til en type analyse utført på kilden.