The Lightning Network er best kjent for sine raske og billige betalinger. Men Layer 2-protokollen kan også tilby mer privatliv enn betalinger via kjeden, siden transaksjoner ikke blir publisert på Bitcoins blockchain, er blockchain-analyse stort sett umulig.
Lightning Network presenterer imidlertid sin egen personvernrisiko. Betalinger sendes over et nettverk av brukere, og ingenting hindrer spioner i å delta i denne prosessen med å videresende transaksjoner mens de overvåker strømmen av midler. På Lightning Network kan blockchain-analyse erstattes av nettverksanalyse.
Det er noen løsninger for å begrense disse risikoene, som Tor-stil løkruting. Disse hjelper, men avhengig av nettverkstopologi og betalingstyper, kan svakheter forbli. Bitcoin og Lightning-utvikleren under pseudonymet ZmnSCPxj har de siste ukene publisert omfattende analyse av vedvarende risiko på Lightning-dev-postliste (1, 2, 3).
Basert på analysen hans tilbød ZmnSCPxj også en løsning. I likhet med Payswap – hans forslag om personvern i kjeden, dekket av Bitcoin Magazine for to uker siden – mener utvikleren at “egenbetaling” kan være en viktig del av personvernpuslespillet..
Forståelse Selvbetaling
I en tidligere artikkel diskuterte vi Payswap, et forslag fra ZmnSCPxj om å forbedre personvernet i kjeden ved å tilsynelatende invertere forholdet mellom betaleren og betalingsmottakeren. ZmnSCPxj kom faktisk først på denne ideen i sammenheng med Lightning Network. Faktisk vil det sannsynligvis være til enda bedre bruk på Lightning Network: Noen av kompromissene som er innebygd i alternativet på kjeden, gjelder ikke på Layer 2-protokollen.
Kort sagt, for Lightning-versjonen av Payswap, er selvbetalingen en del av samme betalingsrute.
For å forklare hvordan dette fungerer, la oss se på en ekstremt forenklet versjon av 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 vil betale Dave 3 bitcoin, vil hun normalt føre betalingen gjennom enten Bob eller Carol. Bob eller Carol tar et lite gebyr for tjenesten, men for enkelhets skyld vil vi se bort fra gebyrene i dette eksemplet. Imidlertid vil det faktum at det faktisk betales avgifter være relevant noen få stykker nede, så husk det.
For nå vil vi si at Alice velger Bobs rute for å utføre betalingen. Hun sender tre mynter til Bob, og Bob viderefører 3 mynter til Dave. Betalingen er en suksess.
Men dessverre, i dette eksemplet, ville det være enkelt for Bob å anta riktig at Alice betalte Dave 3 mynter. Han vet beløpet fordi han videresendte det, mens hvis Alice ville betale Carol, eller Carol ville betale Dave, kunne de ha gjort det direkte, uten å være avhengig av Bob som mellommann. Hvis Bob er en spion som overvåker nettverkstrafikk, skader hans riktige antagelse både Alice og Daves privatliv.
ZmnSCPxj foreslår derfor et alternativ. Alice kunne føre betalingen helt tilbake til seg selv … en “egenbetaling”, med Dave som tok en veldig stor “avgift”. Gebyret vil faktisk være den virkelige betalingen.
For å betale Dave som før, ville Alice for eksempel rute 5 mynter denne gangen. Først ville hun sende de 5 myntene til Bob, som ville videresende de 5 myntene til Dave. Så – dette er trikset – ville Dave fortsette betalingen til Carol … men han videresender bare to mynter! Til slutt ville Carol videresende de to myntene tilbake til Alice. Til slutt er Alice 3 mynter fattigere, og Dave er 3 mynter rikere. Derfor betalte Alice Dave 3 mynter.
Denne selvbetalingen ville villede både Bob og Carol. Bob videresendte 5 mynter og antar logisk, men feilaktig at Alice betalte Dave 5 mynter. I mellomtiden ville Carol uten tvil ha det enda verre: Hun ville tro at Dave betalte Alice 2 mynter. Fra Carols perspektiv er betalingsretningen invertert.
Hvis Bob eller Carol i hemmelighet spionerte på nettverksaktivitet, ville de blitt villedet om størrelsen og / eller retningen på betalingen, til fordel for Alice og Daves privatliv. Hvis spioner blir villedet ofte nok, kan det til og med gjøre en slik spioneringsaktivitet ubrukelig helt.
PTLC, standardbeløp og mer
Alt om eksemplet ovenfor er forenklet, fra nettverksgrafen til beløpene som er inngått, mens mer subtile personvernrisikoer som gebyrbeløp og tidslåser blir ignorert helt. I mellomtiden antas det at selv om både Bob og Carol er spioner, samarbeider de ikke, eller verre: De er en spion som later som om de er to brukere..
I virkeligheten er både personvernrisikoen og personvernfordelene ved ruting større og mer nyansert på samme tid. Å adressere alle disse finessene er utenfor omfanget av denne artikkelen; ZmnSCPxjs innsendinger til Lightning-dev-postlisten er en bedre ressurs for en mer inngående analyse. Og mer generelt pågår forskning om lynets personvern.
Det er likevel verdt å påpeke at ZmnSCPxjs forslag om å forbedre Lightning-personvernet går utover egenbetaling – i noen scenarier vil ytterligere protokollendringer faktisk være mer eller mindre nødvendig for at selvbetalinger skal være effektive personvernforbedringer. De to viktigste endringene er en bytte fra hashede tidslåsekontrakter (HTLC) til offentlige nøkkel tidslåsekontrakter (PTLC), og vedtakelse av standardbeløp. Så la oss se på disse to kort.
Akkurat nå rutes lynbetalinger ved hjelp av HTLC. Alle brukere langs en rute gir i hovedsak en kode som garanterer at de kan kreve midler fra en motpart hvis den andre motparten krever penger fra dem (Dette er hvordan midler videresendes over nettverket). Dessverre, hvis samarbeidende spioner er en del av den samme ruten, kan de bruke HTLC-ene til å fortelle at forskjellige humle faktisk er en del av den samme betalingen, til en viss grad angre fordelen med løkruting. PTLC-er ville utnytte kryptografiske triks for å forhindre at spioner knytter forskjellige humle til samme rute.
ZmnSCPxj foreslår også at Lightning-brukere vedtar standardbeløp. Selv om det er valgfritt, vil lommebøker bli oppfordret til å dele opp betalinger i mindre (men sammenkoblede) betalinger, der hver mindre betaling består av standardbeløp. Hvis standardbeløpene er for eksempel 1, 2 og 5 mynter, vil Alice i eksemplet ovenfor foreta to betalinger på 1 mynt og 2 mynter, i stedet for en betaling på 3 (Eller hvis hun gjør en egenbetaling, kan hun sende 5 og rute 2 tilbake til seg selv).
Hvis nok brukere vil begrense (brøkdeler) av betalinger til standardbeløp, kan ikke spioner stole på beløp som knytter forskjellige humle til samme betaling. I forbindelse med selvbetaling kan brukerne til og med rute ikke-standardbeløp fra betalingsmottaker tilbake til seg selv, slik at disse ser enda mer ut som vanlige betalinger.
Selvbetaling ulemper
Kjedenversjonen av ZmnSCPxjs forslag, Payswap, kommer med betydelige avveininger. Sammenlignet med en vanlig betaling er det behov for flere transaksjoner, noe som betyr høyere avgifter. På toppen av det krever Payswap-transaksjoner interaksjon mellom brukere utenfor Bitcoin-protokollen; vanlige bitcoin-transaksjoner gjør det ikke.
På Lightning Network holder disse ulempene seg ikke – eller de holder i mindre grad. Lynbetalinger krever samhandling i begge tilfeller, så en selvbetaling vil ikke gjøre situasjonen verre. Og selv om noen ekstra transaksjonshumler er nødvendige for å foreta en selvbetaling, skjer disse humlene utenfor kjeden, slik at de ikke krever ekstra blokkeringsplass.
Når det er sagt, kommer selvbetaling fremdeles med noen ulemper, selv på Lyn. Mens det er billigere enn on-chain avgifter, koster ekstra humle litt mer i rutinggebyrer. Når flere humler blir lagt til en betaling, øker også risikoen for en mislykket betaling, og risikoen for at en spion blir en del av en rute øker også (Hvis bare Carol var en spion i eksemplet ovenfor, ville selvbetalingen har gitt henne mer informasjon enn en enkel rute gjennom Bob ville ha).
Til slutt kan det selvfølgelig være andre (som ennå uforutsette) kompromisser også; egenbetaling er et relativt nytt forslag. Som ZmnSCPxj konkluderte i e-postene sine, “Mer analyse av bruken av sirkulære betalinger når du betaler kan være i orden.”