Är Channel Jamming ett hot mot Bitcoins Lightning Network?

(Särskilt tack till Antoine Riard och Gleb Naumenko, vars senaste forskningen är grunden för denna artikel.)

Kanalstopp är ett av de utestående problemen med Lightning Network när det gäller saker som kan störa framgången för betalningar som dirigeras över det. Det är ett allmänt känt problem bland utvecklare som har varit förstått sedan innan själva nätverket faktiskt gick live på mainnet och började bearbeta till och med en enda satoshi.

Än så länge har frågan egentligen inte haft några negativa effekter på nätverket, men när man överväger det faktum är det viktigt att komma ihåg att nätverket fortfarande, i det stora hela, är relativt litet. Handlarprocessorer har börjat stödja det, liksom några börser och massor av Lightning/Bitcoin-baserade tjänster och företag, men i verkligheten är det inte mycket. Nätverket är fortfarande väldigt mycket en liten sak som främst används av Bitcoiners, och det är inte en mycket stor del av världen alls.

Ännu vidare är mängden Bitcoiners som regelbundet spenderar och använder sin bitcoin i handelsmiljöer en ännu mindre delmängd av den redan lilla gruppen. Bara för att attacker som är möjliga inte inträffar nu, bör folk inte anta att det betyder att de inte kommer att fortsätta att inträffa när nätverket växer till en större skala. Ju större det blir, desto mer konkurrenskraftigt och motståndskraftigt kommer det att bli.

Vad är Channel Jamming?

Det grundläggande konceptet med kanalstopp är att dirigera betalningar genom en Lightning-kanal som du vill jamma från dig själv till dig själv, och sedan inte slutföra dem genom att släppa förbilden till betalningshashen i hashade timelock-kontrakt (HTLC). Offret/offren kommer inte att kunna ta bort HTLC:erna från sin kanal förrän efter att tidslåset för återbetalningen har löpt ut, eftersom de inte skulle ha något sätt att driva in sina anspråk på pengar de är skyldiga om förbilden släpptes efter att den tagits bort. Om du helt blockerar en kanal genom att göra detta, kommer den kanalen inte att kunna dirigera några betalningar förrän efter att tidslåset löper ut för alla skadliga betalningar.

Det finns två olika strategier som kan användas här för att utföra attacken. Du kan antingen försöka blockera det routbara beloppet som är tillgängligt i en kanal, eller så kan du försöka blockera alla individuella HTLC-platser i en kanal. En Lightning-kanal kan bara ha 483 väntande HTLC:er i varje riktning den kan dirigera - detta beror på att det finns en maximal storleksgräns för hur stor en Bitcoin-transaktion kan vara. Om du lägger till fler än 483 HTLC per riktning i kanalen, blir transaktionen för att stänga kanalen om det behövs för stor och inte giltig för att skickas till nätverket. Detta skulle göra allt i kanalen omöjligt att genomföra i kedjan.

Så en angripare kan antingen försöka låsa upp all likviditet i en kanal, eller försöka låsa alla HTLC-slots i en kanal. Båda strategierna skulle göra kanalen oanvändbar, men slot-jamming kommer i allmänhet att vara billigare än mängd-jamming. Angriparen måste ha mynt på nätverket för att kunna utföra denna attack, så att dirigera det lägsta tillåtna värdet för en HTCL med 483 kapacitet kommer att vara mer kostnadseffektivt än att försöka låsa upp all tillgänglig likviditet i kanalen.

Varför skulle någon vilja jamma en ljuskanal?

Det finns många skäl att utföra denna attack. För det första kan en skadlig enhet som vill attackera själva Bitcoin blockera alla nyckelkanalerna i nätverkets "kärna" för att göra det mesta av nätverket oanvändbart för att dirigera betalningar, förutom noder som är mycket nära kopplade till varandra . Detta skulle kräva mycket fler mynt att prestera i denna skala, men är inte något som bör diskonteras som en möjlighet med ju mer Bitcoin växer och blir ett alternativ till statligt sanktionerade pengar och betalningssystem.

För det andra kan en routingnod, eller handlare, försöka utföra attacken på en konkurrent för att driva avgifter till dem i motsats till konkurrenterna. En handlare som säljer liknande produkter kan störa en konkurrents kanaler för att hindra kunder från att göra inköp där, i hopp om att uppmuntra dem att handla i sin butik istället. En routingnod som har liknande kanalanslutning som en annan nod kan blockera den konkurrerande routingnodens kanaler för att göra dem oanvändbara för routing av betalningar. Med tiden skulle detta förstöra den nodens rykte när det gäller routingtillförlitlighet, och på grund av liknande anslutningar, göra det mer och mer sannolikt att användarnas plånböcker skulle välja angriparens nod för att dirigera betalningar över nätverket.

Dessa attacker kan vara ännu mer kapitaleffektiva för angriparen om de går cirkulärt genom en enda kanal flera gånger. Om de är tillräckligt nära offret på nätverket kan de konstruera en betalningsväg som går runt och fortsätter genom offrets kanal. Det finns gränser för hur lång en betalningsrutt kan vara, så detta kan inte göras i det oändliga, men att göra en looping-betalningsrutt som denna kan drastiskt sänka mängden mynt som angriparen behöver för att helt blockera ett offers kanal(er).

Dämpande kanalstörningsattacker

Vissa grundläggande, partiella begränsningar skulle kunna tillämpas för att öka kostnaderna för angriparna och mildra skadorna för offren. Den första skulle vara en flerstegsprocess för hantering av HTLC:er.

För närvarande lägger varje HTLC individuellt till en ny utdata i åtagandetransaktionen för det aktuella kanaltillståndet. En tvåstegsprocess skulle kunna skapa en enda extra utdata i åtagandetransaktionen och sedan ha en andra transaktion efter den som har den faktiska HTLC lagt till. Detta skulle tillåta maximalt 483 multiplicerade med 483 HTLC-slots per kanal (eller 233,289 XNUMX slots). Detta fixar dock egentligen ingenting av sig självt, och skulle kräva förlängning av tidslåsen eftersom du lägger till en extra transaktion för att upprätthålla saker i kedjan, och skulle faktiskt kunna hjälpa angriparen mer än offret om de använde denna nya transaktionsstruktur och offret gjorde det inte. Det kommer dock att hjälpa i kombination med en annan teknik som förklaras tillfälligt.

Den andra skulle vara en reaktiv strategi, där en nod som har fallit offer för störning helt enkelt kan öppna en ny kanal för samma kamrat som den som fastnar. Detta skulle dock kräva att man har extra kapital för att göra det, fixar inte alternativkostnaden för att den andra kanalen ska ha fastnat och förlora avgiftsintäkter, och den nya kanalen kan senare också blockeras om angriparen har kapitalet tillgängligt för att göra det .

Den tredje tekniken skulle vara att buckla HTLC-slots. För närvarande finns det 483 slots, och detta är en enda slotgräns som tillämpas universellt på alla betalningar oavsett värdet på betalningen. Noder kan skapa separata hinkar med mindre slotgränser och tillämpa dem på betalningar med olika värden, dvs betalningar på 100,000 150 satsar eller mindre kan bara ha tillgång till XNUMX slots. Så routingbetalningar av mindre värde kan inte konsumera alla tillgängliga HTLC-slots.

Betalningar på 100,000 1 sats till 300 miljon sats kan ha tillgång till 1 slots, och 10 miljon sats till 483 miljoner sats kan ha tillgång till hela 483 slots. Detta skulle avsevärt höja kapitalkostnaden för en angripare till slot jam, eftersom de inte längre skulle kunna konsumera alla 546 slots med minsta möjliga värdebetalning. Dessutom, eftersom HTLC-utgångar under dammtröskeln (för närvarande 0 sats) inte ens kan sändas och tillämpas på kedjan, kan allt under denna gräns hanteras som en "XNUMX-hink" eftersom ingen HTLC-utgång skapas ändå. Noder kan helt enkelt genomdriva gränser för dessa transaktioner baserat på använda CPU-resurser eller andra mätvärden för att förhindra att de blir risker för överbelastning av tjänster, beroende på hur mycket de har råd att förlora om de inte avgörs ärligt.

Slot bucketing i kombination med tvåstegs HTLC-hantering kan användas för att optimera tillämpningen av HTLC-gränser, dvs. betalningar med högre värde kan använda tvåstegsstrukturen för att skapa fler slots för dem per kanal eftersom det högre betalningsvärdet ökar kostnaderna för jamming dem för en angripare, vilket gör missbruk av en högre slotgräns för att utföra jamming angripare mindre sannolikt.

I sin forskning som citeras ovan har Riard och Naumenko visat att med den optimala kombinationen av bucketing-slitsar och tvåstegs slitsförlängning kan orsaken till slitsstopp bli lika dyr som att mängden fastnar. Detta skulle inte heltäckande lösa problemet, men det höjer minimikostnaden för att utföra attacken om det implementeras brett av noder över nätverket.

De två heltäckande lösningarna de har tittat på är en förskotts-/hålltidsavgift för att låsa upp likviditet och ett ryktesystem som använder förblindade Chaumian-tokens. Avgiftssystemets TLDR är att en obligation för en förskottsavgift skulle betalas för att dirigera en HTLC som förväntas ta lång tid att avveckla, och ju längre den förblir oreglerad, skulle den frigöra en avgift till varje routingnod per bit av tiden som har gått utan avräkning. Problemet är att upprätthållandet av detta kan leda till behovet av att stänga kanaler om avgifter inte skickas när det krävs, och det kommer att leda till att legitima användningsfall som kräver långa låstider betalar samma högre avgift som en angripare som försöker störa kanal.

Rykteschemat skulle involvera en "insatsobligation" med hjälp av nollkunskapsbevis för att bevisa kontroll över Bitcoin som ett Sybil-försvar, och sedan använda obligationen kopplad till ditt rykte för att skaffa blindade Chaumian-tokens från routingnoder som skulle lösas in och återutges på HTLC:er framgångsrikt lösa på ett integritetsbevarande sätt. Noder skulle utfärda token en gång per identitet, och om en HTLC inte löstes eller återbetalades i tid, kunde noder vägra att återutge token, vilket förhindrar en användare från att dirigera genom sin nod om de inte spenderar tid och pengar på att skapa en ny insatsobligation med olika mynt som ska ges ut i en ny token.

För den som vill läsa mer om dessa två lösningar finns mer information i avsnitt fem och sex i Riards och Naumenkos forskning.

Det är också värt att notera att om routingnoder skulle anta tredjepartsbaserade depositionssystem eller förtroendebaserade kreditlinjer, som jag skrev om här., skulle alla dessa problem relaterade till kanalstopp upphöra att påverka dem. Detta skulle vara en enorm förändring i förtroendemodellen för routing av noder, men det skulle ha noll effekt på människor som använder riktiga Lightning-kanaler för att skicka och ta emot sats, säkerheten för deras pengar eller deras förmåga att upprätthålla det i kedjan.

Folk kanske inte vill höra det, men i slutändan, om lösningarna ovan för att mildra kanalstopp för faktiska kanaler inte räcker, är dessa tredjepartssystem alltid ett potentiellt alternativ.

Detta är ett gästinlägg av Shinobi. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis de från BTC Inc eller Bitcoin Magazine.