Lightning Network är mest känt för sina snabba och billiga betalningar. Men Layer 2-protokollet kan också erbjuda mer integritet än betalningar via kedjan, eftersom transaktioner inte publiceras på Bitcoins blockchain, är blockchain-analys i stort sett omöjlig.

Lightning Network presenterar dock sina egna integritetsrisker. Betalningar dirigeras över ett nätverk av användare, och ingenting hindrar spioner från att delta i denna process för vidarebefordran av transaktioner medan man övervakar flöden av medel. På Lightning Network kan blockchain-analys ersättas med nätverksanalys.

Det finns några lösningar för att begränsa dessa risker, som Tor-style lök routing. Dessa hjälper, men beroende på nätverkstopologi och typer av betalningar kan svagheter kvarstå. Bitcoin och Lightning-utvecklaren under pseudonym ZmnSCPxj har under de senaste veckorna publicerat omfattande analys av bestående risker på Lightning-dev-e-postlista (1, 2, 3).

Baserat på sin analys erbjöd ZmnSCPxj också en lösning. I likhet med Payswap – hans förslag om integritet i kedjan, täckt av Bitcoin Magazine för två veckor sedan – tror utvecklaren att ”självbetalningar” kan vara en viktig del av sekretesspusslet..

Förståelse Självbetalning

I en tidigare artikel diskuterade vi Payswap, ett förslag av ZmnSCPxj att förbättra integriteten i kedjan genom att till synes vända förhållandet mellan betalare och betalningsmottagare. ZmnSCPxj kom faktiskt ursprungligen med denna idé i samband med Lightning Network. I själva verket skulle det förmodligen vara ännu bättre för Lightning Network: Några av de avvägningar som är inbäddade i kedjealternativet gäller inte Layer 2-protokollet.

Kort sagt, för Lightning-versionen av Payswap är självbetalningen en del av samma betalningsväg.

För att förklara hur detta fungerar, låt oss titta på en extremt förenklad version av ett Lightning Network. A (löss) har betalningskanaler med B (ob) och C (arol). Bob har kanaler med Alice och D (ave). Carol har kanaler med Alice och Dave. Och Dave har kanaler med Bob och Carol.

A – – B

| |

| |

CD

Om Alice vill betala Dave 3 bitcoin skulle hon normalt dirigera betalningen genom antingen Bob eller Carol. Bob eller Carol skulle ta ut en liten avgift för tjänsten, men för enkelhetens skull kommer vi att ignorera avgifter i det här exemplet. Det faktum att avgifter i verkligheten betalas kommer dock att vara relevant några stycken nedåt, så kom ihåg det.

För tillfället säger vi att Alice väljer Bobs väg för att göra betalningen. Hon skickar tre mynt till Bob, och Bob fortsätter med 3 mynt till Dave. Betalningen är en framgång.

Men tyvärr, i det här exemplet, skulle det vara lätt för Bob att korrekt anta att Alice betalade Dave 3 mynt. Han vet beloppet för att han vidarebefordrade det, medan om Alice ville betala Carol, eller Carol ville betala Dave, kunde de ha gjort det direkt, utan att vara beroende av Bob som mellanhand. Om Bob är en spion som övervakar nätverkstrafik skadar hans korrekta antagande både Alice och Daves integritet.

ZmnSCPxj föreslår därför ett alternativ. Alice kunde dirigera betalningen hela vägen tillbaka till sig själv … en “självbetalning”, med Dave som tog en mycket stor “avgift”. Avgiften skulle faktiskt vara den verkliga betalningen.

För att betala Dave som tidigare skulle Alice till exempel rutt 5 mynt den här gången. Först skulle hon skicka de fem mynten till Bob, som skulle vidarebefordra de 5 mynten till Dave. Då – detta är tricket – skulle Dave fortsätta betalningen till Carol … men han vidarebefordrar bara 2 mynt! Slutligen skulle Carol vidarebefordra de två mynten tillbaka till Alice. I slutändan är Alice 3 mynt fattigare och Dave är 3 mynt rikare. Därför betalade Alice Dave 3 mynt.

Denna självbetalning skulle vilseleda både Bob och Carol. Bob vidarebefordrade 5 mynt och kan logiskt men felaktigt anta att Alice betalade Dave 5 mynt. Under tiden skulle Carol utan tvekan ha det ännu sämre: Hon skulle tro att Dave betalade Alice 2 mynt. Ur Carols perspektiv är betalningsriktningen inverterad.

Om antingen Bob eller Carol i hemlighet spionerade på nätverksaktivitet, skulle de ha blivit vilseledda om betalningens storlek och / eller riktning, vilket gynnar Alice och Daves integritet. Om spioner vilseleds tillräckligt ofta kan det till och med göra en sådan spioneringsaktivitet helt värdelös.

PTLC, standardbelopp och mer

Allt om exemplet ovan är förenklat, från nätverksdiagrammet till transaktionsbeloppen, medan mer subtila integritetsrisker som avgiftsbelopp och tidlås ignoreras helt. Samtidigt antas att även om både Bob och Carol är spioner, samarbetar de inte, eller värre: De är en spion som låtsas vara två användare.

I verkligheten är både integritetsriskerna och integritetsfördelarna med routing större och mer nyanserade samtidigt. Att ta itu med alla dessa finesser ligger utanför denna artikel; ZmnSCPxjs inlägg till Lightning-dev-e-postlistan är en bättre resurs för en mer ingående analys. Och mer allmänt pågår forskning om Lightning-integritet.

Ändå är det värt att påpeka att ZmnSCPxjs förslag för att förbättra Lightning-integriteten går längre än självbetalningar – i vissa scenarier skulle ytterligare protokolländringar faktiskt vara mer eller mindre nödvändiga för att självbetalningar skulle vara effektiva integritetsförbättringar. De två viktigaste ändringarna är en övergång från hashade tidlåskontrakt (HTLC) till offentliga nyckel-tidlåskontrakt (PTLC) och antagande av standardbelopp. Så låt oss titta på dessa två i korthet.

Just nu dirigeras Lightning-betalningar med HTLC. Alla användare längs en rutt vidarebefordrar i huvudsak en kod som garanterar att de kan kräva medel från en motpart om den andra motparten ansöker om medel från dem (så här överförs medel via nätverket). Tyvärr, om samarbetsvilliga spioner är en del av samma rutt, kan de använda HTLC: erna för att berätta att olika humle i själva verket är en del av samma betalning, i viss mån att ångra fördelarna med lökrutt. PTLC skulle utnyttja kryptografiska knep för att förhindra att spioner länkar olika humle till samma rutt.

ZmnSCPxj föreslår också att Lightning-användare antar standardbelopp. Även om det är valfritt skulle plånböcker uppmuntras att dela upp betalningar i mindre (men sammankopplade) betalningar, där varje mindre betalning består av standardbelopp. Om standardbeloppen är till exempel 1, 2 och 5 mynt, skulle Alice i ovanstående exempel göra två betalningar på 1 mynt och 2 mynt, istället för en betalning på 3 (Eller om hon gör en självbetalning kan hon skicka 5 och väg 2 tillbaka till sig själv).

Om tillräckligt många användare skulle begränsa sina (bråkdelar av) betalningar till standardbelopp, kan spioner inte lita på belopp för att länka olika humle till samma betalning. Inom ramen för självbetalningar kan användarna till och med dirigera icke-standardiserade belopp från betalningsmottagaren till sig själva, vilket gör att de ser mer ut som vanliga betalningar.

Självbetalningsnackdelar

On-chain-versionen av ZmnSCPxjs förslag, Payswap, kommer med betydande avvägningar. Jämfört med en vanlig betalning behövs fler transaktioner, vilket innebär högre avgifter. Dessutom kräver Payswap-transaktioner interaktion mellan användare utanför Bitcoin-protokollet. vanliga bitcoin-transaktioner inte.

I Lightning Network håller dessa nackdelar inte – eller de håller i mindre utsträckning. Blixtbetalningar kräver interaktion i båda fallen, så en självbetalning skulle inte förvärra situationen. Och medan vissa extra transaktionshopp är nödvändiga för att göra en självbetalning sker dessa humle utanför kedjan, så de behöver inte extra blockrymd.

Som sagt, självbetalningar har fortfarande några nackdelar, även på Lightning. Medan det är billigare än on-chain avgifter, kostar extra humle lite mer i routingavgifter. När fler humle läggs till en betalning ökar också risken för en misslyckad betalning, och risken för att en spion blir en del av en rutt ökar också (om bara Carol var en spion i exemplet ovan, skulle självbetalningen har gett henne mer information än en enkel väg genom Bob skulle ha).

Slutligen kan det naturligtvis också finnas andra (ännu oförutsedda) avvägningar; självbetalningar är ett relativt nytt förslag. Som ZmnSCPxj avslutade i sina e-postmeddelanden, “Mer analys om användningen av cirkulära betalningar vid betalning kan vara i ordning.”