Er Channel Jamming en trussel mod Bitcoins Lightning-netværk?

(Særlig tak til Antoine Riard og Gleb Naumenko, hvis nyere forskning er grundlaget for denne artikel.)

Kanaljamming er et af de udestående problemer i Lightning-netværket med hensyn til ting, der kan forstyrre succesen med betalinger, der sendes over det. Det er et almindeligt kendt problem blandt udviklere, der har været forstået siden før selve netværket rent faktisk gik live på mainnet og begyndte at behandle selv en enkelt satoshi.

Indtil videre har problemet ikke haft nogen negativ indvirkning på netværket, men når man tager det i betragtning, er det vigtigt at huske på, at netværket stadig er relativt lille i den store sammenhæng. Merchant-processorer er begyndt at understøtte det, ligesom et par børser og masser af Lightning/Bitcoin-indfødte tjenester og virksomheder, men i virkeligheden er det ikke meget. Netværket er stadig meget en lille ting, der overvejende bruges af Bitcoiners, og det er slet ikke en særlig stor del af verden.

Endnu yderligere er mængden af ​​Bitcoinere, der regelmæssigt bruger og bruger deres bitcoin i handelsindstillinger, en endnu mindre delmængde af den allerede lille gruppe. Bare fordi angreb, der er mulige, ikke finder sted nu, bør folk ikke antage, at det betyder, at de fortsat ikke vil forekomme, når netværket vokser til en større skala. Jo større det bliver, jo mere konkurrencepræget og modstandsdygtigt bliver det.

Hvad er Channel Jamming?

Det grundlæggende koncept for kanaljamming er at dirigere betalinger gennem en Lightning-kanal, du ønsker at jamme fra dig selv til dig selv, og derefter ikke at afslutte dem ved at frigive præbilledet til betalingshashen i hashed timelock-kontrakter (HTLC'er). Ofret/offerne vil ikke være i stand til at fjerne HTLC'erne fra deres kanal, før tidslåsen for tilbagebetalingen er udløbet, fordi de ikke ville have nogen måde at håndhæve deres krav på penge, de skylder, hvis preimage blev frigivet efter at have fjernet det. Hvis du fuldstændig blokerer en kanal ved at gøre dette, vil den kanal være ude af stand til at dirigere nogen betalinger, før tidslåsen udløber for alle de ondsindede betalinger.

Der er to forskellige strategier, der kan anvendes her for at udføre angrebet. Du kan enten prøve at jamme det routbare beløb, der er tilgængeligt i en kanal, eller du kan prøve at jamme alle de individuelle HTLC-slots i en kanal. En Lightning-kanal kan kun have 483 ventende HTLC'er i hver retning, den kan dirigere - dette skyldes, at der er en maksimal størrelsesgrænse for, hvor stor en Bitcoin-transaktion kan være. Hvis du tilføjer mere end 483 HTLC'er pr. retning i kanalen, vil transaktionen for at lukke kanalen om nødvendigt være for stor og ikke gyldig til at sende til netværket. Dette ville gøre alt i kanalen umuligt at håndhæve på kæden.

Så en angriber kan enten prøve at låse al likviditeten i en kanal eller prøve at låse alle HTLC-slots i en kanal. Begge strategier ville gøre kanalen ubrugelig, men slot jamming vil generelt være billigere end mængde jamming. Angriberen skal have mønter på netværket for at kunne udføre dette angreb, så at dirigere den mindst tilladte værdi for en 483-kapacitet HTCL vil være mere omkostningseffektivt end at forsøge at låse al den likviditet, der er tilgængelig i kanalen.

Hvorfor skulle nogen ønske at jamme en lyskanal?

Der er mange grunde til at udføre dette angreb. For det første kan en ondsindet enhed, der ønsker at angribe Bitcoin selv, blokere alle nøglekanalerne i "kernen" af netværket for at gøre det meste af netværket ubrugeligt til routing af betalinger, bortset fra noder, der er meget tæt forbundet med hinanden . Dette ville kræve mange flere mønter at præstere i denne skala, men er ikke noget, der bør udelukkes som en mulighed, jo mere Bitcoin vokser og bliver et alternativ til statssanktionerede penge- og betalingssystemer.

For det andet kunne en routingnode eller en købmand forsøge at udføre angrebet på en konkurrent for at kræve gebyrer til dem i modsætning til konkurrenterne. En købmand, der sælger lignende produkter, kan blokere en konkurrents kanaler for at forhindre kunder i at foretage køb der, i håb om at tilskynde dem til at handle i deres butik i stedet. En routingnode, der har lignende kanalforbindelse som en anden knude, kan blokere den konkurrerende routingknudes kanaler for at gøre dem ubrugelige til routing af betalinger. Over tid ville dette ødelægge den nodes omdømme med hensyn til routingpålidelighed og på grund af lignende tilslutningsmuligheder gøre det mere og mere sandsynligt, at brugernes tegnebøger ville vælge angriberens node for at dirigere betalinger på tværs af netværket.

Disse angreb kan være endnu mere kapitaleffektive for angriberen, hvis de ruter cirkulært gennem en enkelt kanal flere gange. Hvis de er tæt nok på offeret på netværket, kan de konstruere en betalingsrute, der sløjfer rundt og bliver ved med at gå gennem offerets kanal. Der er grænser for, hvor lang en betalingsrute kan være, så dette kan ikke gøres uendeligt, men at lave en looping betalingsrute som denne kan drastisk sænke mængden af ​​mønter, som angriberen har brug for for fuldstændig at blokere et offers kanal(er).

Afbødende kanaljammingangreb

Nogle grundlæggende, delvise afbødninger kunne anvendes for at øge omkostningerne for angriberne og afbøde skaden for ofrene. Den første ville være en flertrinsproces til håndtering af HTLC'er.

I øjeblikket tilføjer hver HTLC individuelt et nyt output i forpligtelsestransaktionen for den aktuelle kanaltilstand. En to-trins proces kunne skabe et enkelt ekstra output i forpligtelsestransaktionen og derefter have en anden transaktion efter den, som har den faktiske HTLC tilføjet. Dette ville tillade et maksimum på 483 ganget med 483 HTLC-slots pr. kanal (eller 233,289 slots). Dette løser dog ikke rigtig noget i sig selv, og det ville kræve at forlænge tidslåsene, fordi du tilføjer en ekstra transaktion for at håndhæve ting i kæden, og det kunne faktisk hjælpe angriberen mere end offeret, hvis de brugte denne nye transaktionsstruktur og offer gjorde ikke. Det vil dog hjælpe i kombination med en anden teknik forklaret et øjeblik.

Den anden ville være en reaktiv strategi, hvor en node, der er blevet offer for jamming, simpelthen kan åbne en ny kanal til samme peer som den, der jammes. Dette vil dog kræve ekstra kapital for at gøre det, og løser ikke alternativomkostningerne ved at have den anden kanal fastklemt og miste gebyrindtægter, og den nye kanal kan efterfølgende også blive blokeret, hvis angriberen har kapitalen til rådighed til at gøre det. .

Den tredje teknik ville være at samle HTLC-slots. I øjeblikket er der 483 slots, og dette er en enkelt slotgrænse, der anvendes universelt for alle betalinger uanset værdien af ​​betalingen. Noder kunne skabe separate buckets med mindre slotsgrænser og anvende dem på betalinger af forskellig værdi, dvs. betalinger på 100,000 sats eller mindre kunne kun have adgang til 150 slots. Så routing af betalinger af mindre værdi kan ikke forbruge alle de tilgængelige HTLC-slots.

Betalinger på 100,000 sats til 1 million sats kunne have adgang til 300 slots, og 1 million sats til 10 millioner sats kunne have adgang til de fulde 483 slots. Dette ville øge kapitalomkostningerne for en angriber til slot jam betydeligt, da de ikke længere ville være i stand til at forbruge alle 483 slots med den mindst mulige værdibetaling. Derudover, fordi HTLC-udgange under støvtærsklen (i øjeblikket 546 sats) ikke engang kan udsendes og håndhæves på kæden, kan alt under denne grænse håndteres som en "0 bucket", da der alligevel ikke oprettes noget HTLC-output. Noder kunne simpelthen håndhæve grænser for disse transaktioner baseret på brugte CPU-ressourcer eller andre målinger for at forhindre dem i at blive denial-of-service-risici, afhængigt af hvor meget de har råd til at tabe, hvis de ikke afregnes ærligt.

Slot bucketing i kombination med to-trins HTLC-håndtering kan bruges til at optimere anvendelsen af ​​HTLC-grænser, dvs. betalinger med højere værdi kan bruge to-trins strukturen til at skabe flere slots til dem pr. kanal, fordi den højere betalingsværdi øger omkostningerne ved jamming dem for en angriber, hvilket gør misbrug af en højere slotgrænse til at udføre jamming angribere mindre sandsynligt.

I deres forskning citeret ovenfor har Riard og Naumenko vist, at med den optimale kombination af bucketing slots og to-trins slot extension, kan årsagen til slot jamming gøres lige så dyr som mængde jamming. Dette ville ikke løse problemet fuldstændigt, men det øger minimumsomkostningerne ved at udføre angrebet, hvis det implementeres bredt af noder på tværs af netværket.

De to omfattende løsninger, de har kigget på, er et up-front/hold-time gebyr for at låse likviditet og et omdømmesystem, der bruger blindede Chaumian-tokens. Gebyrordningens TLDR er, at en obligation for et forhåndsgebyr ville blive betalt for at dirigere en HTLC, der forventes at tage lang tid at afvikle, og jo længere den forbliver uafviklet, vil den frigive et gebyr til hver routingnode pr. stykke tid, der er gået uden afregning. Problemet er, at håndhævelse af dette kan føre til behovet for at lukke kanaler, hvis gebyrer ikke sendes, når det er påkrævet, og det vil medføre, at legitime brugssager, der kræver lange låsetider, betaler det samme højere gebyr, som en angriber, der forsøger kanaljamming, ville.

Omdømmeordningen ville involvere en "indsatsobligation" ved at bruge beviser med nulviden til at bevise kontrol over Bitcoin som et Sybil-forsvar, og derefter bruge obligationen, der er knyttet til dit omdømme til at erhverve blindede Chaumian-tokens fra routing-noder, der ville blive indløst og genudstedt på HTLC'er med succes afvikle på en privatlivsbevarende måde. Noder ville udstede tokens én gang pr. identitet, og hvis en HTLC ikke blev afgjort eller refunderet rettidigt, kunne noder nægte at genudstede tokenet, og dermed forhindre en bruger i at dirigere gennem deres node, medmindre de bruger tid og penge på at oprette en ny indsatsobligation med forskellige mønter, der skal udstedes i en ny token.

For dem, der ønsker at læse mere om disse to løsninger, kan du finde mere information i afsnittene fem , seks i Riards og Naumenkos forskning.

Det er også værd at bemærke, at hvis routing-noder skulle vedtage tredjepartsbaserede escrow-systemer eller tillidsbaserede kreditlinjer, som jeg skrev om link., ville alle disse problemer relateret til kanal jamming ophøre med at påvirke dem. Dette ville være en enorm ændring i tillidsmodellen for routing af noder, men det ville have ingen effekt på folk, der bruger rigtige Lightning-kanaler til at sende og modtage sats, sikkerheden for deres penge eller deres evne til at håndhæve det på kæden.

Folk vil måske ikke høre det, men i sidste ende, hvis løsningerne ovenfor til at afbøde kanaljamming for faktiske kanaler ikke er nok, er disse tredjepartssystemer altid en potentiel mulighed.

Dette er et gæsteindlæg af Shinobi. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc eller Bitcoin Magazine.