The Lightning Network er bedst kendt for sine hurtige og billige betalinger. Men Layer 2-protokollen kunne også tilbyde mere privatliv end betalinger via kæden, da transaktioner ikke offentliggøres på Bitcoins blockchain, er blockchain-analyse stort set umulig.

Lightning Network præsenterer dog sine egne privatlivsrisici. Betalinger dirigeres over et netværk af brugere, og intet forhindrer spioner i at deltage i denne proces med videresendelse af transaktioner, mens man overvåger strømmen af ​​midler. På Lightning Network kan blockchain-analyse erstattes af netværksanalyse.

Der er nogle løsninger for at begrænse disse risici, som Tor-style løg routing. Disse hjælper, men afhængigt af netværkstopologi og typer af betalinger kan svagheder forblive. Bitcoin og Lightning-udvikleren, der går under pseudonymet ZmnSCPxj, ​​har i de seneste uger offentliggjort omfattende analyse af vedvarende risici på Lightning-dev mailingliste (1, 2, 3).

Baseret på hans analyse tilbød ZmnSCPxj også en løsning. I lighed med Payswap – hans forslag om on-chain privatliv, der blev dækket af Bitcoin Magazine for to uger siden – mener udvikleren, at “selvbetaling” kunne være en vigtig del af privatlivspuslespillet.

Forståelse Selvbetaling

I en tidligere artikel diskuterede vi Payswap, et forslag fra ZmnSCPxj om at forbedre privatlivets fred ved kæden ved tilsyneladende at vende forholdet mellem betaleren og betalingsmodtageren. ZmnSCPxj kom faktisk oprindeligt op på denne idé i sammenhæng med Lightning Network. Faktisk ville det sandsynligvis være til endnu bedre brug på Lightning Network: Nogle af de kompromiser, der er indlejret i alternativet on-chain, gælder ikke på Layer 2-protokollen.

Kort sagt, for Lightning-versionen af ​​Payswap er selvbetaling en del af den samme betalingsrute.

For at forklare, hvordan dette fungerer, skal vi se på en ekstremt forenklet version af et Lightning Network. A (lus) har betalingskanaler med B (ob) og C (arol). Bob har kanaler med Alice og D (ave). Carol har kanaler med Alice og Dave. Og Dave har kanaler med Bob og Carol.

A – – B

| |

| |

C – – D

Hvis Alice ønsker at betale Dave 3 bitcoin, vil hun normalt føre betalingen gennem enten Bob eller Carol. Bob eller Carol opkræver et mindre gebyr for tjenesten, men for enkelhedens skyld vil vi ignorere gebyrer i dette eksempel. Det faktum, at der faktisk betales gebyrer, vil være relevant et par stykker nede, så husk det.

For nu vil vi sige, at Alice vælger Bobs rute for at foretage betalingen. Hun sender 3 mønter til Bob, og Bob sender videre 3 mønter til Dave. Betalingen er en succes.

Men desværre ville det i dette eksempel være let for Bob at antage korrekt, at Alice betalte Dave 3 mønter. Han kender beløbet, fordi han videresendte det, mens hvis Alice ville betale Carol, eller Carol ville betale Dave, kunne de have gjort det direkte uden at være afhængig af Bob som mellemmand. Hvis Bob er en spion, der overvåger netværkstrafik, skader hans korrekte antagelse både Alice og Daves privatliv.

ZmnSCPxj foreslår derfor et alternativ. Alice kunne dirigere betalingen helt tilbage til sig selv … en “selvbetaling”, hvor Dave tog et meget stort “gebyr”. Gebyret ville faktisk være den reelle betaling.

For at betale Dave som før ville Alice for eksempel rute 5 mønter denne gang. Først ville hun sende de 5 mønter til Bob, som ville videresende de 5 mønter til Dave. Derefter – dette er tricket – ville Dave videresende betalingen til Carol … men han videresender kun 2 mønter! Endelig ville Carol videresende de 2 mønter tilbage til Alice. I sidste ende er Alice 3 mønter fattigere, og Dave er 3 mønter rigere. Derfor betalte Alice Dave 3 mønter.

Denne selvbetaling vil vildlede både Bob og Carol. Bob videresendte 5 mønter og antager logisk, men fejlagtigt, at Alice betalte Dave 5 mønter. I mellemtiden ville Carol uden tvivl være endnu dårligere stillet: Hun ville tro, at Dave betalte Alice 2 mønter. Fra Carols perspektiv er betalingsretningen inverteret.

Hvis enten Bob eller Carol i hemmelighed spionerede på netværksaktivitet, ville de have været vildledt af størrelsen og / eller retningen af ​​betalingen, hvilket gavner Alice og Daves privatliv. Hvis spioner vildledes ofte nok, kan det endda gøre en sådan spioneringsaktivitet ubrugelig helt.

PTLC’er, standardbeløb og mere

Alt om eksemplet ovenfor er forenklet, fra netværksgrafen til de transaktioner, mens mere subtile privatlivsrisici såsom gebyrbeløb og tidslåse ignoreres helt. I mellemtiden antages det, at selvom både Bob og Carol er spioner, samarbejder de ikke, eller værre: De er en spion, der foregiver at være to brugere.

I virkeligheden er både privatlivsrisici og fortrolighedsfordele ved routing større og mere nuancerede på samme tid. Adressering af alle disse finesser ligger uden for anvendelsesområdet for denne artikel; ZmnSCPxjs bidrag til Lightning-dev-postlisten er en bedre ressource til en mere dybdegående analyse. Og mere generelt er forskning i Lightning-fortrolighed i gang.

Alligevel er det værd at påpege, at ZmnSCPxjs forslag til forbedring af Lightning-privatliv går ud over selvbetaling – i nogle scenarier vil yderligere protokolændringer faktisk være mere eller mindre nødvendige for, at selvbetaling er effektive forbedringer af privatlivets fred. De to vigtigste ændringer er en skift fra hashede timelock-kontrakter (HTLC’er) til offentlige nøgle-timelock-kontrakter (PTLC’er) og vedtagelse af standardbeløb. Så lad os se kort på disse to.

Lige nu dirigeres lynbetalinger ved hjælp af HTLC’er. Alle brugere langs en rute videregiver i det væsentlige en kode, der garanterer, at de kan kræve midler fra den ene modpart, hvis den anden modpart hævder midler fra dem (Det er sådan, midler overføres via netværket). Desværre, hvis samarbejdsvillige spioner er en del af den samme rute, kan de bruge HTLC’erne til at fortælle, at forskellige humle faktisk er en del af den samme betaling, i en grad, der fortryder fordelen ved løgrute. PTLC’er udnytter kryptografiske tricks for at forhindre spioner i at forbinde forskellige humle til den samme rute.

ZmnSCPxj foreslår også, at Lightning-brugere vedtager standardbeløb. Selvom det er valgfrit, opfordres tegnebøger til at opdele betalinger i mindre (men sammenkædede) betalinger, hvor hver mindre betaling består af standardbeløb. Hvis standardbeløbene er for eksempel 1, 2 og 5 mønter, vil Alice i ovenstående eksempel foretage to betalinger på 1 mønt og 2 mønter i stedet for en betaling på 3 (Eller hvis hun foretager en selvbetaling, kunne hun sende 5 og rute 2 tilbage til sig selv).

Hvis nok brugere ville begrænse deres (brøkdele af) betalinger til standardbeløb, kan spioner ikke stole på beløb for at linke forskellige humle til den samme betaling. I forbindelse med selvbetaling kunne brugerne endda føre ikke-standardbeløb fra betalingsmodtager tilbage til sig selv, hvilket får disse til at ligne endnu mere som almindelige betalinger.

Selvbetaling ulemper

On-chain-versionen af ​​ZmnSCPxjs forslag, Payswap, kommer med betydelige kompromiser. Sammenlignet med en almindelig betaling er der behov for flere transaktioner, hvilket betyder højere gebyrer. Derudover kræver Payswap-transaktioner interaktion mellem brugere uden for Bitcoin-protokollen; regelmæssige bitcoin-transaktioner ikke.

På Lightning Network holder disse ulemper ikke – eller holder de i mindre grad. Lynbetalinger kræver interaktion i begge tilfælde, så en selvbetaling ville ikke gøre situationen værre. Og mens nogle ekstra transaktionshops er nødvendige for at foretage en selvbetaling, sker disse humle uden for kæden, så de kræver ikke ekstra blockspace.

Når det er sagt, kommer selvbetalinger stadig med nogle ulemper, selv ved Lyn. Selvom det er billigere end on-chain-gebyrer, koster ekstra humle lidt mere i routinggebyrer. Efterhånden som flere humle føjes til en betaling, øges risikoen for en mislykket betaling, og risikoen for, at en spion er en del af en rute, øges også (hvis kun Carol var en spion i eksemplet ovenfor, ville selvbetalingen har givet hende flere oplysninger end en simpel rute gennem Bob ville have).

Endelig kan der naturligvis også være andre (som endnu uforudsete) afvejninger; selvbetaling er et relativt nyt forslag. Som ZmnSCPxj konkluderede i sine e-mails, “Mere analyse af brugen af ​​cirkulære betalinger ved betaling kan være i orden.”