Vad händer när din Lightning Network-routningsnod matas med skräptransaktioner som aldrig löser sig? Kort sagt, det orsakar mycket sorg för dirigeringsnoder. Det som en gång var ett smidigt, globalt betalningssystem kan spärras med triviala ansträngningar från en skicklig manusförfattare.

Arbetade i ett litet team av routningsnoder, körde vi framgångsrikt ett test av attacken med riktiga medel och demonstrerade “sorg”Attack beskriven av Joost Jager. Attacken kallas en sorgattack eftersom det inte är en stöld av medel, men det gör att offrets blixtfonder fryses: en stor upprördhet. Vad vi upptäckte är att sorg är ett allvarligt hot mot stora “wumbo” -kanaler som förväntar sig att tjäna en avkastning på sin bitcoin, bara för att deras medel ska frysas under en tidsperiod.

Detta är mestadels en sorgattack: ingen förlust av medel, men offret kan tvingas betala för en dyr kanalstyrka nära. Detta är en känd sårbarhet på mainnet Lightning och det måste förstås och prioriteras, särskilt i detta tidiga marknadsskede av Bitcoins Lightning Network.

Tack till Clark Burkhardt och Phillip Sheppard för deras vilja att delta i detta test och till Jager för hans outtröttliga arbete för att uppmärksamma och prioritera denna sårbarhet. Jager spelade rollen som angriparen för vår demonstration, medan Burkhardt och Sheppard anslöt mig som anslutna offer routing noder.

Hur attacken fungerar

Angriparen mättar en (eller flera) kanaler med Hashed Time Locked Contracts (HTLC) som inte löses som en slutgiltig betalning. Dessa är en speciell typ av HTLC: er som kallas HODL-fakturor. Endast 483 av dessa olösta HTLC: er krävs för att överväldiga en kanal per riktning. När dessa HTLC: er är i kanalen är alla transaktioner som använder samma kanalriktning omöjliga, inklusive en transaktion för att kooperativt stänga den kanalen.

I teorin kan en angripare kontakta offret (kanske via ett nyckelsändmeddelande eller i en “lökblob”) och kräva att en lösen betalas för att stoppa attacken. När lösen har betalats kan angriparen ta bort de olösta betalningarna och avsluta attacken. Attacken kan hållas på obestämd tid och stoppa all routing och betalningsaktivitet i den kanalen. Detta fryser medlen i Lightning-kanalen.

Båda betalningsriktningarna kan stoppas i en kanal genom att använda 483 HTLC i varje riktning, både inkommande och utgående.

Thunderhub-vy över min balanserade kanal till Burkhardt under attack. Kanalen visas som “Inte aktiv”, som om Burkhardt var offline, men det gjorde han inte. Mängden i blått är den lokala saldot i sats, mängden i grönt är fjärrbalansen i sats som ägs av Burkhardt. Källa: Thunderhub.

Varför skulle en angripare göra något liknande detta??

Det första motivet som kommer att tänka på är att kräva en lösen. Denna attack orsakar offret smärta och att betala en lösen kan vara attraktivt för offret, även utan försäkran om att attacken skulle stoppa. Att kontakta offret kan vara riskabelt för en angripare, men en lösenutbetalning är kanske inte den enda anledningen till att någon skulle göra det.

Ett sekundärt incitament för att starta en sorgsattack skulle vara att störa routingkonkurrensen. Att fastna i en konkurrents rutt kan skapa mer efterfrågan på en rutt som ägs av en angripare.

Tänk som ett riktmärke att Lightning Labs Loop-nod har en kontinuerlig efterfrågan på likviditet för vilken den ibland kommer att betala 2500 delar per miljon av avgiftssatsen för betalning (ppm) (0,25 procent). Enligt min erfarenhet skulle de normalt tömma 16 miljoner sats likviditet på cirka två veckor (5,2 procent årlig procentsats), men det är med konkurrens närvarande.

Om en angripare kunde inaktivera någon konkurrerande rutt med lägre avgiftssatser, kan Loop vara villig att betala en högre avgiftssats (eftersom tillgången på likviditet nu minskas). Låt oss säga att Loop skulle betala 3000 ppm (0,3 procent), samt använda den likviditeten snabbare eftersom inga andra kanaler fungerar. Loop kan använda den likviditeten på halva tiden, säg en vecka. Angriparen skulle mer än fördubbla sin vanliga avkastning till 15,6 procent i april i detta exempel. Den enda kostnaden för angriparen är kostnaden för att köra ett skript på en befintlig kanal och den psykologiska kostnaden för att göra något omoraliskt / skadligt för Lightning Network. Med en enda angriparkanal kan en skadlig skådespelare knäcka omkring nio kanaler (se Jager’s tweets om detta).

Vad skulle offret för denna attack uppleva?

Offret för denna attack skulle inte riktigt veta att denna attack inträffade om de inte hade några speciella varningar inställda för väntande HTLC. För Thunderhub-användare (ett starkt rekommenderat verktyg) kommer startskärmen att visa ett diagram över väntande HTLC: er samt en varning om att kanaler endast kan innehålla 483 väntande HTLC: er.

Källa: Thunderhub

I praktiken blev min nod snabbt opålitlig och upplevde flera appkrascher, inklusive Thunderhub, som var den enda appen som meddelade mig om problemet. Tack vare min “Balance of Satoshis” Telegram-bot fick jag en kanalavslutningsmeddelande. Kanalen under attack tvingade sig själv! Det skulle inte vara en del av experimentet. (För mer teknisk information om den ofrivilliga kraftstängningen, se nedan för ytterligare kraftstängningsdata.)

En testbetalning med kanalen med Burkhardt (salmiak) misslyckades på grund av attacken. Denna varning rapporterar att Burkhardts nod är offline, även om den var online. Källa: Thunderhub.

Vad kan offret göra för att stoppa en sorgsattack?

När en attack startar kan ett offer i princip inte göra något för att stoppa det. De enda tillgängliga alternativen för att stoppa en pågående attack skulle vara att tvinga stänga kanalen som attackeras, vilket innebär att terroristerna vinner.

För att förolämpa skadan kommer tvångsstängning av kanalen att driva de olösta betalningarna till transaktionsdata på kedjan, vilket utlöser sekundära transaktioner i kedjan för initiativtagaren till styrkan. Vid 50 sats / vbyte och 483 transaktioner i kedjan är det enkelt en 1 miljon prislapp för att tvinga stänga en enda kanal under attack (en avgift på 368 dollar för stängning till dagens priser). De flera on-chain transaktionerna sker endast om produktionen överstiger minimidammens “damm” -gräns. (Ser detta exempel på testnet.)

Initiativtagaren för en blixtkanal betalar stängningsavgiften.

En annan anledning till att du kanske inte vill ha 483 (icke-damm) htlcs är att en potentiell kraftstängningstransaktion vid 50 sat / vB ser ut så här: https://t.co/z6mAGZxvrC.

Stängningsavgiften blir dyrare på över 1 miljon lördag.

– Joost Jager (@joostjgr) 28 september 2020

Hur man förhindrar en sorgsattack

Jager har arbetat med ett proof-of-concept-program för att isolera och bekämpa angripare. Han kallar sitt program “Strömbrytare.”Circuitbreaker arbetar på nätverksnivå, vilket tyvärr innebär att alla måste delta för att det ska bli effektivt.

Utöver detta behöver denna fråga prioritering och uppmärksamhet från dedikerade ingenjörer / utvecklare för att hitta bättre lösningar. Det har också funnits några bra diskussioner om att ändra protokollet i Bitcoin Optech nyhetsbrev (nummer # 122 eller # 126).

Denna attack kan utföras idag. Det är ett mirakel att det inte redan har använts skadligt. Det återspeglar incitamenten för dem som använder Lightning idag så att det kan bli ett öppet, universellt betalningsnätverk. Vänligen dela det här inlägget som du anser lämpligt för att uppmuntra och inspirera till mer arbete för att lösa problemet innan det orsakar verklig skada.

Ytterligare teknisk information om ofrivillig stängning

Här är loggarna från min nod som kör LND 0.11 just nu när ovannämnda ofrivilliga kraftstängning inträffade:

2020/11/26 21: 24: 47,374 [ERR] HSWC: ChannelLink (657.759: 561: 0): felande länk: ChannelPoint (c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c: 0): mottagna felet från kamrat: chan_id = 7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3, err = avvisade engagemang: commit_height = 455, invalid_commit_sig = 3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1581dfa2383e0b4e06c8ad4f718ab5c434d8cf5, commit_tx = 02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008a792e8002210d0000000000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042bef58b71783ae1a44834a902a8f2d542ca720, sig_hash = 4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5 med fel: fjärr error

Loggarna visar ett “invalid_commit_sig” vilket är ett känt problem i LND. Förmodligen kan detta hända vid återanslutning och är inte ett direkt resultat av kanalstopp. Volymen av väntande HTLC: er gör tyvärr mer sannolikt att det händer. Jager hjälpte till att förklara processen som kanalstopp -> oändlig betalningsslinga (bug) -> nod ner -> återanslut -> ogiltig commit sig (bug) -> kanal tvångsstängning.

Den “ändlösa” loopbuggen är en känd bugg som uppstår när HTLC-gränsen uppnås och ytterligare HTLC skickas. Istället för att sluta med ett betalningsfel fortsätter LND att försöka göra betalningen i en slinga. För att hjälpa till med detta fel, se LND-nummer # 4656.