Iceberg: Threshold Custody a Lightning Networkhöz - nested threshold multi-signatures¶

Forrás: Paul Gerhart (TU Wien), Nadav Kohen (Chaincode Labs), Jesse Posner (Vora), Matias Furaszyfer (Chaincode Labs): Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures, IACR ePrint 2026/1757.

Összegzés¶

A "Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures" című IACR 2026/1757 paper (Gerhart, Kohen, Posner, Furszyfer) egy régóta nyitott problémát old meg: bemutatja az Iceberg sémát, amellyel a Lightning Network egyik fele a channel fennmaradó részének és a Lightning protokollnak a módosítása nélkül üzemeltethető t-of-n threshold csoportként. A megoldás alapja egy új kriptográfiai primitív, a nested threshold multi-signature, amely egy külső multi-signature (MuSig2) session belsejében teszi lehetővé a résztvevők egyikének t-of-n threshold aláírását. A szerzők formálisan definiálják a primitívet, megalkotják az első konstrukciót (Iceberg) MuSig2-re, bizonyítják a séma unforgeability tulajdonságát, és egy éles Lightning node-ba integrálva mérik a teljesítményt. A mérési eredmények szerint egy 2-of-4 threshold csoport 6.7%-os overheadet jelent aláírásonként (3.8 ms), és a threshold csoport az eredeti single-key végpont áteresztőképességének több mint 93%-át tartja fenn, miközben a counterparty felé a node teljesen szabványos MuSig2 résztvevőnek látszik.

Bevezetés: Lightning csatornák, valódi érték, valódi kockázat¶

A Bitcoin Lightning Network mára intézményi méretű fizetési infrastruktúrává vált. A publikus csatornákban zárolt érték 2025 decemberében elérte a rekordot jelentő körülbelül 5 600 BTC-t, ami nagyjából 490 millió dollárnak felelt meg. Az érték körülbelül 15 000 publikus node és több tízezer csatorna között oszlik el, és mivel a csatornák többsége privát, ezek a számok alsó becslések. A nagy tőzsdék (Bitfinex, OKX, Kraken, Binance, Coinbase) ma már a Lightningön keresztül egyenlítik ki az ügyfélbefizetéseket és -kifizetéseket, mivel ez olcsóbb és gyorsabb, mint az on-chain settlement, és egyre inkább ezt várják el az ügyfelek.

Egy Lightning csatorna működését az 1. ábra szemlélteti. Két fél (Alice és Bob) úgy nyit csatornát, hogy egy közös output alá közösen zárolják a bitcoint, és ezt az outputot a modern taproot csatornákon egyetlen aggregált MuSig2 kulcs védi, X̃ = KeyAgg({XA, XB}). A csatorna megnyitásához az Alice, Bob → X̃ funding tranzakciót használják. Ezt követően minden egyenlegfrissítés és a csatorna lezárása ugyanannak a funding outputnak az újrafelhasználásával történik, és minden lépés egyetlen 2-of-2 MuSig2 aláírás a két fél parciális aláírásából (sA és sB). A csatorna élete során csak a funding tranzakció és a lezáró tranzakció (X̃ → Alice, Bob) kerül a láncra, minden más off-chain és privát marad. Az output az aggregált kulcs miatt on-chain megkülönböztethetetlen egy hagyományos single-key címtől, így a külvilág számára a csatorna léte láthatatlan.

A probléma: egykulcsos Lightning végpontok sebezhetősége¶

Ugyanakkor minden egyes payment channel törékeny alapokon nyugszik. Mindkét oldalon egyetlen online kulcs tartja a végpontokhoz tartozó összeget, és ez az egyetlen kulcs egyetlen meghibásodási pont. Az egykulcsos működés kétféleképpen bukhat el. Egyrészt a kulcs kompromittálódhat: 2019-ben a támadók egyetlen tőzsde hot walletből 7 000 BTC-t vittek el egyetlen, minden biztonsági ellenőrzésen átjutó tranzakcióban. Másrészt a kulcs elveszhet: több százmillió dollár értékű bitcoin rekedt örökre elérhetetlenül egy titkosított meghajtón, amelynek tulajdonosa elfelejtette a jelszót. Egyik eset sem visszafordítható, és a Bitcoin történetében mindkét hibatípus rendre megismétlődik. A Bitcoin-custody számára ez önmagában is komoly probléma, a Lightningben viszont még élesebb, mert a csatorna életben tartásához és a fizetések továbbításához a kulcsnak online kell maradnia, ami kizárja a cold storage védelmét.

On-chain az egykulcsos single point of failure nagyrészt megoldott: a threshold signing (t-of-n) a teljes aláírási jogosultságot n darab fél között osztja el úgy, hogy közülük bármely t darab alá tud írni, és egyetlen kulcs kompromittálása sem végzetes, mert t − 1 részesedés kompromittálása nem tesz lehetővé hamisítást, és n − t részesedés elvesztése is túlélhető, amíg t részesedés megmarad. A threshold custody intézmények és komoly self-custodianok körében bevált gyakorlat. A Bitcoin natívan támogatja Scriptben (több kulcs felsorolásával és quorum aláírás megkövetelésével), a modern Schnorr-alapú sémák (MuSig2, BIP 327-ben szabványosítva, valamint FROST) pedig kompaktabban és privátban érik el ugyanezt, egyetlen aggregált kulccsá és aláírássá vonva össze az egész csoportot. Ám ez a védelem, amelyet az on-chain custody magától értetődőnek vesz, a Lightning csatornákból mindeddig hiányzott.

A csatorna struktúrája több ponton is akadályozza a thresholdizálást. A régi típusú (legacy) csatornákon a 2-of-2 funding output egy Bitcoin Script, és Alice elvileg kiterjeszthetné a saját felét egy threshold scriptté, de ezt nem teheti meg egyedül, mert ehhez a Lightning protokollt mindkét félnek módosítania kellene. Ráadásul minden csatornyitásnál nem szabványos scriptet kellene tárgyalni, minden tranzakció és annak díja megnőne, és on-chain lábnyom maradna, amely Alice kulcskezelési megoldását hirdetné - nem kívánatos privacy szivárgás. A taproot csatornákon, amelyeket az ökoszisztéma ma a jobb privacy és kisebb tranzakciók miatt átvesz, a helyzet még bonyolultabb: a két fél egyetlen MuSig2 kulcsba aggregálódik, amelyet egyetlen szokásos aláírás költ, és a MuSig2-ben mindkét fél pontosan egy kulcsot ad, így nincs látható pont, ahol szélesíteni lehetne. Akárhogy is, amíg a Lightning taproot csatornákra áll át, a valóban használható threshold Alice-nak egyetlen szokványos kinézetű MuSig2 kulcson belül kell megvalósulnia. Ráadásul Alice csak akkor használhat threshold megoldást, ha az általa eszközölt változtatások nem igénylik Bob, a protokoll vagy a lánc módosítását. Ezért Alice oldalának thresholdizálásához olyan séma kell, amely egy külső MuSig2 session belsejében hoz létre threshold parciális aláírásokat, és ez az új primitív, amelyet a szerzők nested threshold multi-signature néven formalizálnak.

A MuSig2-ben megvalósított nested threshold multi-signature konstrukciók keresése régóta nyitott probléma a Bitcoin közösségben. A fő nehézség a Schnorr aláírás (R, s) nonce-ának, a MuSig2 által számolt R-nek a sajátosságaiból fakad. A Lightning az R session nonce-t egy teljes round-trip-pel korábban rögzíti, mielőtt az aláírandó tranzakció egyáltalán létezne, és amint Alice elküldte a saját részét Bobnak, már nem módosíthatja. Ez addig rendben van, amíg Alice egyetlen aláíró, de ha thresholdizálva van, az aláíró készlete (signer set) a körök között megváltozhat. Bármelyik online aláíró készlet, amely a tranzakció megérkezésekor elérhető, egy olyan nonce alatt kell hogy befejezze az aláírást, amelyet a tranzakció létezése előtt rögzítettek, és amelyet egy másik aláíró készlet választott. Az irodalomban ezt a problémát stateless threshold signaturekkel, így Arctic-tal, determinisztikus nonce-okkal és replikált secret sharinggel oldják meg. A stateless Schnorr aláírások (köztük az Arctic) azonban a nonce-ot tipikusan az aláírandó üzenetből és az aktuális aláírási sessionből származtatják, hogy elkerüljék a key leakage-t, ha két különböző üzenetet ugyanazzal a véletlennel írnak alá. A Lightning környezetben viszont Alice sem az aláírandó üzenetet, sem a végleges aláírási sessiont nem ismeri, amikor az R nonce rá eső részét ki kell adnia. Másrészt, ha a signerek stateless-ek lennének, rávehetők lennének egy elavult csatornaállapot aláírására, ami a Lightning punishment mechanizmusainak tenné ki őket. Ezért bármely, a Lightning-re szánt threshold megoldásnak legalább a legfrissebb csatornaállapotot biztonságosan kell továbbítania ahhoz, hogy értelme legyen.

A cikk központi kérdése: üzembe helyezhető-e a threshold custody a mai Lightning Networkben?

Iceberg fő hozzájárulás¶

A cikk erre a kérdésre igenlő választ ad. A szerzők bevezetik a nested threshold multi-signature fogalmát, egy új kriptográfiai primitívet, amely egy adott multi-signature séma parciális aláírásainak t-of-n threshold aláírására szolgál. Ezután bemutatják az első ilyen konstrukciót, az Iceberg-et, amely t-of-n threshold aláírást tesz lehetővé MuSig2 parciális aláírásokhoz (BIP 327 alapján). Az Iceberg a MuSig2-től elvárt optimális küszöbértékekkel bizonyíthatóan unforgeable: a séma biztonságos marad akkor is, ha a támadó legfeljebb t − 1 aláírói kulcsrészesedést kompromittál, és 2t − 1 aláírói részesedés elegendő érvényes aláírás előállításához. A cikk ezen paraméterek optimalitását a 2. szakaszban tárgyalja.

A gyakorlati oldal kulcsa, hogy az Iceberg drop-in csere a MuSig2-re egy Lightning végponton: az első kör outputja pontosan az az üzenet, amelyet egyetlen MuSig2 résztvevő küldene, és az általa finanszírozott csatorna egy szokványos single-key Taproot output. Más szóval egy Iceberg végpont teljes mértékben kompatibilis a jelenleg üzemelő Lightning protokollal. Ennek köszönhetően a threshold custody egyoldalúan, a Bitcoin, a protokoll vagy a counterparty módosítása nélkül bevezethető.

Végül a szerzők az Iceberg-et integrálják egy éles Lightning node-ba, és taproot csatornákon mérik. Ha az egyik végpontot 2-of-4 csoporttá alakítják, az fizetésenként 3.8 ms többletidőt jelent, ami a fizetés amúgy is elvégzendő munkájának 6.7%-a. Ez a csoport 260 fizetés/másodperc értéknél telít egy további processzormagot, tehát a thresholdizálás csupán szerény többletterhelést okoz, és a threshold csoport az eredeti single-key végpont áteresztőképességének több mint 93%-át fenntartja.

Kapcsolódó munka: threshold signatures, MuSig2 és a nesting problémája¶

A threshold signaturek a digitális eszközök elosztott letéti őrzésének bevált megoldásává váltak, és modern konstrukciók hatékony aláírási protokollokat kínálnak Schnorr aláírásokhoz (FROST és változatai) és ECDSA-hoz. A meglévő threshold sémák azonban feltételezik, hogy a threshold csoport maga a teljes aláíró, és a threshold csoport teljes mértékben helyettesíti a single signert. A Lightning alapvetően más beállítást teremt: a meglévő MuSig2 végrehajtásnak csak az egyik résztvevőjét thresholdizáljuk, míg a másik résztvevő és a teljes aláírási protokoll változatlan marad. Ehhez a threshold aláírásnak egy meglévő multi-signature protokollon belül kell működnie, nem pedig annak helyettesítőjeként. Egyetlen létező threshold konstrukció sem támogatja ezt a beállítást, mert vagy a nonce generációt kötik az aláíró készlethez, vagy magas round complexity-vel járnak, vagy megkövetelik, hogy az üzenet a nonce létrehozásakor már ismert legyen.

A FROST család a quorum által aláírt tagok hozzájárulásából építi fel az aggregált nonce-t, ami a nonce-ot az adott quorumboz köti, és kizárja a nested végpontoknál való használatot. A stateless sémák (GKMN21, KOR23, FYZ+ 25) ezt a kötést a nonce determinisztikus származtatásával oldják fel, de ennek ára, hogy az üzenetet inputként használják; az Arctic (KG25) ezek legfrissebbike, és MuSig-DN, valamint GLRS26 ugyanebbe az akadályba ütközik. Ahogy a bevezetőben tárgyaltuk, a teljesen stateless signerek nem használhatók a Lightning thresholdizálásához, mert egy régi csatornaállapot aláírása az aláíró készlet büntetéséhez vezetne. Az Iceberg ugyanakkor követi az Arctic mintáját (determinisztikus nonce-ok replikált publikusan ellenőrizhető secret sharing felett), de a származtatást a csatorna állapotával seed-eli, nem pedig az üzenettel és az aláíró készlettel, és ezzel feloldja a problémát.

Mivel az Iceberg egy multi-signature protokollon belül működik, a multi-signature irodalom is releváns. Bellare és Neven vezette be az első Schnorr multi-signature-t a plain public-key modellben, MuSig (MPSW19) pedig hozzáadta a key aggregation-t, amivel egy aláíró csoport a láncon egyetlen aláíróként jelenik meg. A kétkörös Schnorr multi-signature-ek elérése nehéznek bizonyult: Drijvers et al. kimutatták, hogy a természetes konstrukciók sebezhetők, míg a MuSig2 (NRS21), BIP 327-ben szabványosítva (NRJ22), valamint a DWMS (AB21) kétkört érnek el úgy, hogy minden aláíró ν = 2 nonce commitmentet bocsát ki. A MuSig-DN (NRSW20a) a nonce-okat determinisztikusan, publikus ellenőrizhetőséggel származtatja, de ennek ára, hogy minden aláíráshoz zero-knowledge proof kell. A későbbi munkák az elemzést javítják vagy a rewinding-alapú bizonyításokat kerülik el. A Lightning a MuSig2-t használja aláírási protokollként, és nem teszi lehetővé annak egy másik multi-signature sémával való helyettesítését. Az Iceberg ezért nem helyettesítheti a MuSig2-t egy másik alapkonstrukcióval, hanem magán a MuSig2 végrehajtáson belül kell működnie.

A MuSig2 csatorna egyik oldalának thresholdizálását Seurin egy nem publikált jegyzetben informálisan felvázolta. A multi-signature MuSig2-be ágyazásának első formális tárgyalása Kohentől (Koh26) származik, ám ő multi-signature-t (n-out-of-n) ágyaz MuSig2-be, nem threshold signature-t (t-out-of-n). Ebben a beállításban minden signernek részt kell vennie minden aláírási sessionben, az aláíró készlet rögzített, és sem a rendelkezésre állás, sem a kompromittálás problémája nem oldódik meg, amelyek a Lightning custody motivációi.

A cikk 1. táblázata az Iceberg-et a legrelevánsabb threshold-Schnorr és nesting sémákkal hasonlítja össze hét szempont szerint: MuSig2-be ágyazhatóság, dinamikus online signerek, state-aware működés, determinisztikus nonce-ok, honest majority feltételezés, teljes és bizonyított konstrukció, valamint a mai Lightning-ben való telepíthetőség. Ezen szempontok közül egyetlen másik séma sem felel meg egyszerre a "nestable in MuSig2", a "deployable in today's Lightning" és a "complete, proven construction" követelménynek; az Iceberg az egyetlen, amely mind a hét szempontnak megfelel.

Eredmények áttekintése: teljesítmény, 93%-os throughput, 6%-os overhead¶

A teljesítménymérés az Iceberg gyakorlati értékét mutatja. A 2-of-4 threshold csoport egy fizetésre 3.8 ms többletidőt jelent, ami az eredeti fizetési munkafolyamat 6.7%-a. A csoport másodpercenként 260 fizetésnél telít egy további processzormagot. Mivel a threshold csoport a nem módosított single-key végpont áteresztőképességének több mint 93%-át tartja fenn, a threshold custody gyakorlatilag azonnal bevezethető intézményi méretben anélkül, hogy a fizetési teljesítmény érdemben csökkenne. A séma ezzel egyesíti a Bitcoin Script-alapú threshold custody privacy és gazdaságossági előnyeit a MuSig2 láthatatlan, aggregált kulcsának láncszintű megjelenésével, miközben a Lightning punishment mechanizmusaihoz szükséges state-aware viselkedést is megőrzi a determinisztikus nonce-ok csatornaállapottal történő seed-elésével.

Iceberg / Threshold Custody IACR 2026/1757 - Section 2 Technikai összefoglaló¶

A cél és a thresholdizált csatorna nagy képe¶

A Lightning csatorna két résztvevője a coinjaikat egy 2-of-2 multisignature alá helyezi (funding output), majd commitment tranzakciók sorozatát írják alá, ahol minden újabb tranzakció visszavonja az előzőt (revoked state). Ha valaki megpróbálna egy régi, már visszavont állapotot lezárni, a counterparty a penalty mechanizmussal az egész csatorna pénzét igényelheti, és ez a fenyegetés tartja mindkét felet a legfrissebb egyenlegnél. A Taproot upgrade után ez a 2-of-2 MuSig2 [NRS21] segítségével aggregálható egyetlen nyilvános kulcsba (aggregated key), így a lánc felé a teljes csatorna egy single-key-szerű kulcsszignatúrás költésként jelenik meg.

A cél pontosan az, hogy az A oldalt egyetlen aláíró helyett egy n tagból álló csoportra cseréljük, ahol bármely 2t-1 online tag elegendő az aláíráshoz, és a csoport biztonságosan működik mindaddig, amíg kevesebb mint t tag kompromittálódik. Ez a kívánalom kizárólag a csoport oldalán hajt végre változtatást: B továbbra is közönséges kétfős MuSig2-t futtat, és a Bitcoin lánc továbbra is egyetlen Schnorr aláírást ellenőriz az aggregated key alatt. Az A oldal ezért a saját kulesaggregációs slotját tölti ki, és minden üzenetváltásnál pontosan azt az egy kulcsot, egy nonce-t és egy partial signature-t mutatja, amit egy magányos MuSig2 résztvevő is mutatna.

A Figure 2 a teljes csatornát három fázisban ábrázolja: a KeyGen (egyszer, a csatorna megnyitásakor) rögzíti a group key X-et, ami a B oldali XB-vel aggregálva adja az on-chain funding kulcsot (X~). Az első menet (PreRound) offline, az üzenet előtt fut, és a session identifierből (sid) előállítja a csoport nonce-ját (RA), amit B saját RB nonce-ával egyesítve R = RARB néven rögzít. A második menet (SignRound) akkor indul, amikor az üzenet m már ismert, az online kvórum partial signature-eket ad le, a SignAgg aggregálja ezeket sA-ba, majd a végső aláírás σ = (R, sA + sB) formájában kerül a láncra. A két menet között bármelyik aláíró kikapcsolhat, vagyis a PreRound-ban részt vevő kvórum nem feltétlenül ugyanaz, mint a SignRound-ban aláíró kvórum.

A környezet megszorításai és a threshold paraméterek¶

A szerzők öt megszorítást (C1-C5) azonosítanak, amelyek együttesen határozzák meg, milyen threshold séma illeszthető egyáltalán a Lightning-be.

C1: Aláírók kikapcsolhatnak. A kulcsok gyakran cold storage-ban vannak, így egy tisztességes tag rendszeresen hiányzik (jellemzően ártalmatlan, nem rosszhiszemű okokból). A kvórum, amelyik elindítja az aláírást, nem biztos, hogy be is fejezi, és a távollevőket nem szabad egyszerűen korruptnak tekinteni.

C2: A nonce megelőzi az üzenetet. Az egyszerűsített taproot-csatornák protokolljában (simple taproot channels protocol) mindkét fél egy teljes round-trip idejével a commitment tranzakció előtt cseréli ki a MuSig2 nonce-ait. A csoportnak ezért a message m ismerete előtt kell elköteleznie magát egyetlen RA nonce mellett, és mivel ekkor még a signing kvórum sem feltétlenül rögzített, a nonce nem függhet attól, hogy ki fog végül aláírni.

C3: A nonce nem változhat. Ha az RA egyszer elment a counterpartyhoz, az adott sessionre rögzített. A külső MuSig2 session módosítatlan BIP 327, ezért a csoport utólag nem szolgáltathat másik nonce-t. Ha a SignRound kvóruma eltér a PreRound kvórumától, a korábban B-nek elkötelezett nonce-ot akkor is tartani kell.

C4: A csoportnak egyet kell értenie az aktuális állapotról. Ha akár csak t-1 korrupt tag is meggyőzne egy tisztességes tagot egy már elavult commitment tranzakció aláírásáról, a counterparty a penalty mechanizmussal az egész csatorna pénzét lehívhatja. A csoportnak ezért az aláírás előtt konszenzusra kell jutnia a commitment számról.

C5: A csoport mérete kicsi. A jellemző csoport egy felhasználó néhány eszköze vagy egy tőzsde néhány kulcsa a személyzet és szerverek között, és az ennél nagyobb méret üzemeltethetetlen. A szerzők n-re legfeljebb egy tucatot várnak.

Ezekből a megszorításokból két fontos következmény adódik. Egyrészt a C4 feltétel a Byzantine agreement egy formáját írja elő, amely szigorú tisztességes szupertöbbséget követel meg, vagyis n ≥ 3t - 2. Másrészt a C1 miatt a signing kvórum mérete 2t - 1 online tag, és n - (2t - 1) tag távol lehet. A Table 2 ezt a kapcsolatot foglalja össze az Iceberg által támogatott küszöbértékekre:

Threshold t	Tolerált korrupció	Signing kvórum (2t-1)	Minimális csoportméret (3t-2)
2	1	3	4
3	2	5	7
4	3	7	10
5	4	9	13

A strawman megközelítések és a tanulságok¶

A szerzők két természetes, de hibás megközelítést vizsgálnak meg, és ezekből vezetik le a három tervezési döntést.

Az első kísérlet a MuSig2 közvetlen beágyazása (nested MuSig2 in MuSig2, [Koh26]). A trükk elvben működik: a belső MuSig2 aggregate key egy közönséges publikus kulcs, és elfoglalhatja az A oldali slotot, miközben a csoport belül MuSig2-t futtat. Ez a felállás viszont csak n-of-n sémát ad, ahol minden aláíráshoz minden tagnak online kell lennie. A cold storage-ban lévő eszközök és a kulcskezelés javítása viszont pont azt követelné, hogy t-of-n küszöböt kapjunk, tehát a nested MuSig2 önmagában nem elég.

A második kísérlet a FROST [KG20a], a Schnorr alapú threshold aláírás standard sémája. FROST-ban minden aláíró két nonce commitmentet (Di, Ei) küld, a signing kvórum C ezekből D és E szorzatot, valamint egy binding factor b-t (amely a kvórumot és az üzenetet hash-eli) állít elő, az R = DE^b aggregált nonce így függ a kvórum összetételétől, és a partial signature-eket Lagrange-interpolációval kombinálják. Ez a tulajdonság nem specifikus FROST-ra: a Shamir-féle secret sharingra [Sha79] épülő threshold Schnorr sémák többsége friss, aláíró-specifikus Ri hozzájárulásokból rakja össze az aggregált nonce-t, amelynek diszkrét logaritmusát csak az adott hozzájárulás küldője ismeri. Más kvórusz tehát más R-t jelent, és a C3 megszorítás miatt ez a Lightning kontextusban elfogadhatatlan: ha a PreRound kvóruma más, mint a SignRound kvóruma, a második menetben reconstruált RA nem egyezne meg azzal, amit B-nek a PreRound-ban ígértek.

FROST és rokonai [KG20b] két ponton sértik a beágyazás nonce-követelményeit. Először, a nonce-nak azonosnak kell lennie, bármelyik kvórum állítja is elő, különben a SignRound ellentmondana a PreRound-ban már elkötelezett RA-nak (C3). Másodszor, a nonce-nak akkor is előállíthatónak kell lennie, ha egy tag az első menetben offline volt, mert a befejező kvórum nem feltétlenül ugyanaz, mint a kezdő (C1). Ha a nonce-okat az első menetben osztják szét, egy távol lévő tag nem kap semmit, és a második menetben nem tud aláírni. A megoldás mindkét problémára az, hogy a nonce-t determinisztikusan, a tárolt share-ekből származtatjuk.

A replicated secret sharing [ISN87] a titkot nem mezőelemekre bontja, hanem minden (t-1)-méretű részhalmazhoz (a) hozzárendel egy ϕa fix summandot, és ϕa-t minden, a-n kívüli tagnak kiosztja. A titok ezek összege: sk = Σa ϕa. A (t-1)-nél kisebb halmazok egyetlen summandot sem látnak, tehát a titokról semmit nem tudnak meg, míg minden tagnál nagyobb halmaz az összes summandot megkapja, és rekonstruálja a titkot. A titok egyetlen fix összeg, és minden érvényes kvórum ugyanazokat a summandokat birtokolja, a rekonstrukció tehát nem függ a jelenlévők kilététől, ellentétben a FROST vagy Sparkle per-signer összesítésével.

A nonce-származtatás pseudorandom secret sharing [CDI05] módjára történik: minden tag egy fix álvéletlen függvényt (PRF) értékel ki a session inputján, minden saját ϕa share-jével, és a kapott értékekből állítja elő a két nonce-share-jét (R1,k, R2,k). A jelenlévő kvórum ellenőrzi a ϕa-k replikált másolatainak konzisztenciáját, majd összegzi a share-eket a csoport két nonce-ává. Mivel a nonce-share-ek kizárólag sid-től függenek, és minden ϕa replikálva van, bármely érvényes kvórum ugyanazt az RA-t rekonstruálja. A kulcs- és nonce-share-eket ugyanaz a tárolt struktúra szolgálja ki, és egy PreRound-ban távol lévő tag a SignRound-ban share-jeiből újra előállítja a saját hozzájárulását.

Az elsődleges trade-off a tárolás: minden tag pontosan (n-1 választ (t-1)) share-et tárol, és ez a szám n-ben gyorsan nő. A szerzők ezt azzal hárítják el, hogy a C5 miatt a csoportméret kicsi, tehát a share-szám kezelhető marad.

2. tervezési döntés: Determinisztikus pre-message nonces¶

A determinisztikus nonce-ok kulcskérdése a seed: minden nonce-követelmény seed-követelmény. Egy determinisztikus nonce csak akkor biztonságos, ha két különböző üzenet alatt soha nem használják fel újra. Ha ugyanazzal az R nonce-szal a csoport két üzenetet írna alá, a partial signature-ek s = r + c x és s' = r + c' x formájúak lennének (c ≠ c' kihívásokkal), és a Schnorr két-special-soundness tulajdonsága miatt az aláíró kulcs x = (s - s') / (c - c') formában kiszivárogna.

Az irodalomban a nonce-ot jellemzően magából az üzenetből származtatják [KG25], így azonos üzenet azonos nonce-ot jelent, és ugyanannak az üzenetnek a kétszeri aláírása legfeljebb egy ismételt aláírást ad, nem kulcsszivárgást. Ez a megoldás a Lightning esetében nem használható, mert a nonce a C2 miatt az üzenet előtt, tehát a commitment tranzakció összeállítása előtt rögzül. A szerzők ezért a Lightning protokoll állapotát vonják be a seedbe: minden commitment tranzakció hordoz egy commitment számot (commitment number), amely egyedi és szigorúan monoton növekvő a csatorna élete során, és a tranzakció összeállítása előtt már ismert. A nonce seed-jébe a session identifier részeként ez a szám kerül, így a nonce továbbra is az üzenet előtt rögzül, de csatornaállapotonként garantáltan változik, és mindezt külön költség nélkül.

A származtatás kizárólag sid-től függ, ezért ha két commitment tranzakció ugyanazt a commitment számot hordozza, a nonce-uk is azonos, és a fenti kulcsszivárgás visszatér.

3. tervezési döntés: Konszenzus az aktuális állapotról¶

A determinisztikus nonce-ok által hagyott rést az a tény jelenti, hogy ugyanaz az sid két üzenettel is használható: a származtatás nem akadályozza meg, hogy a csoport két különböző commitment tranzakciót írjon alá ugyanazzal a commitment számmal. Ha ez megtörténik, a két partial signature ugyanazt az R nonce-ot használja, de más-más kihívásokat, és a kulcs ismét kiszivárog.

A beágyazás ezt tovább súlyosbítja, mert a külső MuSig2 session aláírókéntént ν = 2 nonce-ot használ. Két aláírás ugyanazzal az sid-vel nem egyszerű ismétlés, hanem a támadót a concurrent ROS [BLL+21] támadási környezetbe helyezi, amely ellen a ν = 2-es választás eredetileg véd. A védekezés több nonce lenne, de ezt a szerzők nem tehetik meg, mert a külső session módosítatlan BIP 327. A konstrukció tehát a nonce-újrafelhasználást nem tudja a saját mechanizmusaival megakadályozni.

A megoldás egy olyan mechanizmus, amelyre egyébként is szüksége van egy thresholdizált csatornának. A C4 miatt a csoportnak minden esetben meg kell egyeznie az aktuális commitment számban, hiszen egy elavult állapot aláírása a counterparty-t a penalty mechanizmus alkalmazására jogosítja fel. Egy tisztességes tag tehát bármely adott sid alatt legfeljebb egy üzenetet ír alá. A Byzantine agreement n ≥ 3t - 2-es korlátja biztosítja a tisztességes szupertöbbséget, amely megakadályozza, hogy egy korrupt kisebbség egy második aláírásra kényszerítse a csoportot, és így a nonce-újrafelhasználás nem következhet be. Ha egy implementáció a külső MuSig2 szintjén egy sikertelen aláírást újra szeretne próbálni, akkor az sid-et megváltoztató protokollüzenetekről is konszenzusra kell jutnia. Ez a megállapodás amúgy is a csatorna működésének a része, így a determinisztikus nonce-ok biztonsága nem jelent többletköltséget a konstrukció számára.

Az Iceberg protokoll: KeyGen, PreRound, SignRound¶

A három tervezési döntés együttesen adja az Iceberg protokollt, amely a külső session felé pontosan úgy viselkedik, mint egyetlen MuSig2 résztvevő.

A KeyGen fázis egyszer fut le, a csatorna megnyitásakor. A csoport titkos kulcsa (sk) replicated secret sharing [ISN87] sémával van szétosztva: az n tag közül minden (t-1)-méretű részhalmazhoz tartozik egy ϕa ∈ Zp summand, és sk = Σa ϕa. Minden tag pontosan azokat a summandokat kapja meg, amelyeknek a részhalmaza nem tartalmazza, vagyis mindenkinél (n-1 választ (t-1)) share ül. Bármely t tag együttesen az összes summandot birtokolja, és rekonstruálni tudná a titkot, míg bármely t-1 tag a saját részhalmazához tartozó summandot nem ismeri, tehát a titokról semmit nem tud meg. A share-ek meghatároznak egyetlen csoportkulcsot X = g^sk, amely az A oldali slotot tölti ki a funding 2-of-2-ben. A share-eket egy trusted dealer vagy egy elosztott kulcsgenerálás (DKG) hozza létre, és ugyanazok a share-ek szolgálnak ki a későbbi kulcs- és nonce-lekéréseket.

A PreRound a session identifier sid ismeretében, az üzenet előtt, offline fut. Mindkét nonce-slotra (i ∈ {1, 2}) minden tag kiértékeli a Hprf(ϕa, i||sid) pseudorandom függvényt a saját ϕa share-jein, és a kapott értékekből összerakja a két nonce-share-jét (R1,k, R2,k), amelyeket kiajánl. A jelenlévő kvórum először ellenőrzi, hogy a ϕa replikált másolatai konzisztens értéket adnak-e, majd összegzi a share-eket a csoport két nonce-ává, és ezeket összekötve (bindingelve) kapjuk meg a counterparty számára átadott RA nonce-ot. Mivel a nonce-share-ek kizárólag sid-től függnek, és minden ϕa replikálva van, bármely érvényes kvórum ugyanazt az RA-t rekonstruálja, tehát egy PreRound-ban távol lévő tag nem zárja ki magát a következő menetből.

A SignRound az üzenet m és a counterparty nonce-jának ismeretében indul. Minden tag kiszámolja a binding factor b-t és a challenge c-t, mindkettőt kizárólag a publikus tranzakcióból. Ezután visszaadja a saját partial signature-jét, ahol ri,k az első menet nonce-share skalárjai, xk pedig a saját kulcs-share-e. A quorum felett végzett Lagrange-interpoláció a {sk} értékekből előállítja az A oldal egyetlen sA partial signature-ét, amit a külső MuSig2 session a B oldali sB-vel összeadva a végső σ = (R, sA + sB) Schnorr aláírást adja. A protokoll két menetes, és az első menet az üzenet előtt kiszámítható, vagyis pontosan ugyanaz a struktúra, mint a MuSig2-é: a csoport egyetlen kört sem ad hozzá a csatornaprotokollhoz.

A 3-5. szekciók technikai összefoglalója: Preliminaries, Nested Threshold Multi-Signatures és az Iceberg séma¶

Jelölés és kommunikációs modell¶

Az értékadás jele x ← y, egyenletes mintavétel jele x ←$ X. Egy ciklikus csoport leírása (G, p, g) egy G csoportot jelöl p prím renddel és g generátorral. n ∈ N esetén [n] = {1, ..., n}. A ∥ operátor bitfüzér-konkatenáció. |S| halmaz számossága. n tagú, t küszöbű csoportnál az A = t-1 halmazcsalád az összes (t-1)-részhalmazt tartalmazza [n]-ből, és A_k = {a ∈ A : k ∉ a} azon részhalmazok, amelyekben k nincs benne, vagyis ezekhez a részhalmazokhoz tartozik a k tag által birtokolt komponens.

A kommunikációs modell szinkron. A magasabb szintű multi-szignatúra végpontjai pairwise authentikált csatornákon kommunikálnak. A threshold-izált végpont tagjai ugyanígy pairwise authentikált csatornát használnak, valamint egy untrusted aggregator csomópontot, amely lehet bármelyik résztvevő vagy egy harmadik fél, amely a kommunikációt facilitálja. Ez utóbbi esetben privacy-szivárgás léphet fel.

Multi-szignatúra és MuSig2¶

Egy multi-szignatúra séma n aláíró közös munkájával egyetlen, egy aggregált kulcs alatt ellenőrizhető aláírást állít elő. A séma komponensei: KeyGen, amely egy aláíró kulcspárját generálja; KeyAgg, amely a publikus kulcsok listáját egy X̃ aggregát kulcsra képezi; egy interaktív aláírási protokoll; és Verify, az ellenőrzés. Az aggregát kulcs X̃ egy hagyományos publikus kulcs, így a csoport on-chain megkülönböztethetetlen egyetlen aláírótól.

A MuSig2 [NRS21] ezt a primitívet Q_G felettpéldányosítja, és ezt használja a Lightning. Az i. aláíró X_i = g^xi kulcsot birtokol, és KeyAgg a kulcslistát L = (X_1, ..., X_n) X̃ = Π_i X_i^ai formában aggregálja, ahol a_i = H_agg(L, X_i) együtthatók az egész listához kötik az egyes kulcsokat. Az aláírás kétfordulós. Az első forduló message-independent: minden aláíró ν darab noncot mintavételez és R_{i,j} = g^{r_{i,j}} értékeket küld j ∈ [ν] esetén (BIP 327-ben ν = 2), a noncek slot-onként aggregálódnak R_j = Π_i R_{i,j}. A második forduló az m üzenet ismeretében indul: a b = H_non(X̃, (R_1, ..., R_ν), m) kötési tényező R = Π_j R_j^{b^{j-1}} session noncot adja, és minden aláíró c = H_sig(X̃, R, m) kihívás mellett az s_i = c · a_i · x_i + Σ_j r_{i,j} · b^{j-1} részleges aláírást küldi vissza. A részlegek s-be összegződnek, és σ = (R, s) Schnorr-aláírásként verifikálható X̃ alatt. Mivel X̃ maga egy hagyományos publikus kulcs, egy MuSig2 aggregát kulcs elfoglalhatja egy másik MuSig2 aláíró slotját, ami a nested MuSig2 [Koh26] szerkezet, és ezt használja az Iceberg, hogy egy küszöb-csoportot rejtse a csatorna egyik oldalába. A nested séma NestedMuSig2 pszeudokódja a paper A. függelékében, Figure 10 alatt található.

Unforgeability (nem-hamisíthatóság)¶

A (nested) multi-szignatúra EUF-CMA biztonságú, ha nincs hatékony támadó, amely az összes aláíró felett kontrollt szerez az egyetlen őszinte aláíró kivételével, és tetszőleges konkurrens aláírási sessiont indíthat, és hamisítani tudna az őszinte kulcsot tartalmazó aggregát kulcs alatt olyan üzenetre, amelyet az őszinte aláíró soha nem írt alá. A formális játék a Figure 6-ban (A. függelék) van felidézve. A biztonság a NestedMuSig2 EUF-CMA biztonságára redukálódik, amely [Koh26] alapján standard feltételezések mellett teljesül, és a 6. szakasz teszi precízzé a redukciót és annak példányosítását.

A VPSS [KG25] egy t-of-n titokmegosztás, amelynek hosszú-idejű részesedéseiből (shares) a tagok ismételten, interakció nélkül tudnak w publikus tag-enként ál-véletlen értékek megosztásait származtatni. A séma komponensei: KeyGen(n, t, µ), amely hosszú-életű sk_1, ..., sk_n részesedéseket oszt szét az sk titokból; Gen(k, sk_k, w), amely a k tag w tag-hez tartozó részét adja; valamint VPSS1.Verify, Agg és Recover algoritmusok, amelyek egy kvórum részeit ellenőrzik, illetve a származtatott értéket interpolálják kitevőben vagy skalárban; µ kvórum-paraméter rögzíti, hány rész kell az ellenőrzéshez. Három tulajdonság kell: verifiability (a kvórum ellenőrizni tudja a részek konzisztenciáját), uniqueness (minden minősített kvórum ugyanazt az értéket kapja minden tag-re), és pseudorandomness (a származtatott értékek egy t-1-es koalíció számára megkülönböztethetetlenek a véletlentől).

A [KG25] szerinti, replikált titokmegosztáson alapuló VPSS-t használja a séma. A titok sk = Σ_{a ∈ A} φ_a alakú, ahol minden a ∈ A részhalmazhoz egy φ_a ←$ Zp összetevő tartozik, és a tagok a saját, a-hoz tartozó (a, φ_a) párokat kapják minden a ∈ A_k halmazra, vagyis sk_k = {(a, φ_a)}_{a ∈ A_k}. A Gen egy H_prf pszeudorandom függvényt értékel ki minden birtokolt összetevőre, és az eredményeket kombinálja. A tagok részei Shamir-részek, amelyek egy Σ_a H_prf(φ_a, w) érték fok-(t-1) polinomját alkotják. A Gen determinisztikus, tehát egy tag bármikor, önmagából levezetheti a w tag-hez tartozó részét. µ >= 2t-1 kvórum-paraméternél a verifiability és uniqueness information-theoretikus, mert a µ méretű kvórum legalább t őszinte részt tartalmaz, és ezek meghatározzák a polinomot, és minden inkonzisztens rész felszínre kerül. Amikor VPSS1.Verify elfogad, Agg determinisztikusan visszaadja g^{Σ_a H_prf(φ_a, w)} értéket, amely azonos minden minősített kvórumra. A VPSS1 séma a Figure 8-ban van felidézve, a VPSS0 változat (részkonverzió nélkül) a 6. szakaszban jelenik meg.

Nested threshold multi-signatures: az új primitív¶

A hagyományos threshold aláírás egy teljes aláírót cserél le egy küszöb-csoportra. A nested threshold multi-signature ezzel szemben lehetővé teszi, hogy egy t-of-n tagú csoport egy outer multi-szignatúra protokoll egyetlen aláíró slotját foglalja el. Így threshold aláírás végezhető egy meglévő multi-szignatúra futtatáson belül, az outer protokoll változtatása nélkül. A primitíve egy kétfordulós multi-szignatúra sémára épül (3. szakasz) KeyAgg aggregációval és Verify ellenőrzéssel; az outer session az aláírási session. A szintaxis és biztonság egy szintű nestingre van megadva, de a mélyebb nestings [Koh26] alapján általánosíthatók.

A nested threshold multi-signature kiterjeszti a kétfordulós threshold aláírást [CKK+25] és a multi-szignatúrát [NRSW20b] formalizmusaival. A nesting három interfész-ponton változtat. Először: minden forduló végén egy aggregációs algoritmus tömöríti a tagok részeit abba az egyetlen üzenetbe, amelyet az outer session a csoport slotjától vár. Másodszor: az aláírási forduló megkapja az outer teljes kontextust. Harmadszor és legfontosabbként: a két forduló nem oszt per-tag állapotot, csak egy sid session azonosítón keresztül kapcsolódnak, így egy tag, aki az első fordulóban hiányzott, a másodikban még részt vehet (C1 megszorítás). A séma hat algoritmusból áll: (Setup, KeyGen, PreRound, PreAgg, SignRound, SignAgg).

A hat algoritmus interfésze a következő. Setup(1^λ) → par: beolvassa a biztonsági paramétert, és előállítja a par publikus paramétereket, amelyek rögzítik a SID session-azonosító teret, és implicit inputjai az összes többi algoritmusnak. KeyGen(k, n, t, A) → (pk, sk_k): a k tag futtatja, n csoportmérettel és t küszöbbel, az A interfészen keresztül a többi taggal interaktálva. Kimenete a csoport publikus kulcsa pk, amely az outer kulcslistán a csoport slotját tölti ki, és a k tag titkos része sk_k. PreRound(k, sk_k, sid) → out_k: az első, message-independent forduló, amely a sid ∈ SID session azonosítót olvassa, és a k tag out_k részét adja a csoport első fordulós üzenetéhez. PreAgg(pk, C, {out_j}{j∈C}) → out: egy C kvórum első fordulós részeit verifikálja és aggregálja a csoport első fordulós üzenetévé, az outer session számára. SignRound(k, sk_k, pk, sid, m, out, ctx) → s_k: a második forduló, amely az m üzenetet, a csoport aggregát első fordulós üzenetét out-ot, és az outer kontextust ctx-et olvassa (a ctx tartalmazza a csoport pozícióját az outer kulcslistán, a társ-aláírók publikus kulcsait, és az outer session aggregát első fordulós üzenetét). Kimenete a k tag részleges aláírása s_k. SignAgg(C, {s_k}) → s: egy C kvórum részleges aláírásait kombinálja a csoport második fordulós üzenetévé.

A nested threshold multi-signature sémának nincs saját verifikációs algoritmusa. Amikor az outer session a csoport második fordulós üzenetét a társ-aláírókéival kombinálja, az eredmény az outer séma hagyományos aláírása X̃ aggregát kulcs alatt, és a Verify ellenőrzi.

Helyesség és biztonsági játék¶

A helyesség µ >= t kvórum-méretet feltételez. Azt követeli meg, hogy egy őszinte outer session érvényes aláírást adjon X̃ alatt. Minden µ-nyi vagy annál nagyobb őszinte tagú C kvórumra a PreAgg és SignAgg olyan első és második fordulós üzeneteket produkál, amelyeket a pk titkos kulcsát birtokló, az outer séma szerinti egyetlen aláíró is produkálhatott volna, és ezek az üzenetek azonosak minden minősített kvórumra (C3 megszorítás).

A nem-hamisíthatóság a TS-MS-EUF-CMA kísérlettel van definiálva, a jelölés [Koh26]-t követi. A támadó statikusan korrumpál kevesebb mint t tagot, kontrollálja az outer session összes aláíróját, és a hálózatot az őszinte tagok interaktív kulcsgenerálása alatt. A támadó három orákulumon keresztül interaktál az őszinte tagokkal: OKeyGen (kulcsgenerálás), OPreRound (egy tag első fordulós része egy sid session azonosítóhoz, a támadó választja), és OSignRound (egy tag részleges aláírása egy üzenethez és egy outer kontextushoz). Az összes őszinte tag között minden session azonosító legfeljebb egy üzeneten ír alá, ami a live state konszenzusát modellezi (C4 megszorítás). A támadó akkor nyer, ha kiad egy friss hamisítványt, vagyis az outer séma által verifikált aláírást X̃ aggregát kulcs alatt, ahol a kulcslista tartalmazza a csoportkulcsot, olyan m* üzenetre, amelyre minden sid esetén kevesebb mint t - |corrupt| őszinte tag fejezte be a második fordulót. Az Adv^{TS-MS-EUF-CMA}_{A,Σ}(λ) a támadó nyerési valószínűsége, és a formális kísérlet a Figure 3-ban van. Mivel az n/t kicsi (C5 megszorítás), egy teljesen adaptívan korrumpáló támadó egy standard guessing argumentummal visszavezethető statikus biztonságra.

Iceberg: a formális konstrukció¶

Az Iceberg a nested threshold multi-signature séma. Setup és kulcsgenerálás: a Setup kiválasztja (G, p, g) csoportleírást, a H_prf, H_agg, H_non, H'non, H_sig hash függvények az outer session-ből jönnek ({0, 1}* → Zp). A session azonosítók rögzített hosszúságú bitfüzérek, SID = {0, 1}^ℓ, és a kulcshoz használt w_0 tag az SID-en kívül van választva. A kulcsgenerálás becsomagolja a VPSS1.KeyGen-t, µ = 2t - 1 kvórum-paraméterrel; a tagok sk_k replikált részt kapnak az sk = Σ formájában interpolálja. Ez a kulcs tölti ki a csoport slotját az outer kulcslistán, így az outer session számára a csoport úgy néz ki, mint egyetlen hagyományos aláíró.} φ_a titokból, akár egy trusted dealertől, akár distributed key generation-ből. Minden tag a w_0 rögzített publikus tag-en (xk, Xk) ← VPSS1.Gen(k, sk_k, w_0) kulcsrészt származtatja, egy C kvórum részeit VPSS1.Verify verifikálja, és Agg a csoportkulcsot X = g^{sk

A nonce precomputation: az első forduló az üzenet előtt fut, és a sid session azonosítóhoz rögzíti a csoport nonce-át. Minden i ∈ [ν] nonce-slotra a k tag (r_{i,k}, R_{i,k}) ← VPSS1.Gen(k, sk_k, i ∥ sid) értéket származtat, és a group elementumokat szétszórja. A PreAgg a C kvórum részeit VPSS1.Verify-jel ellenőrzi, minden slotot a pre-nonce R'_i értékre interpolál, a b_1 ← H'_non(pk, (R'_1, ..., R'_ν)) kötési tényezőt származtatja, és a kötött R_i ← (R'_i)^{b_1^{i-1}} nonce-okat adja ki. Ez a NestedMuSig2 SignAgg és SignAggExt lépéseit tükrözi, így a kimenet pontosan az a first-round üzenet, amelyet egy MuSig2 résztvevő küldene. Mivel Gen determinisztikus és minden összetevő replikált, minden minősített kvórum ugyanazt a nonce-ot számolja, és egy tag, aki ebben a fordulóban hiányzott, később önmagából, sk_k-ból újraszámolja a részeit.

Az aláírás: a második forduló az m üzenet és az outer ctx kontextus ismeretében indul. A ctx tartalmazza a csoport j pozícióját az outer kulcslistán, a társ-aláíró {pk_i} kulcsokat, és az outer aggregát (R_i) nonce-okat. A k tag a Gen-en keresztül újraszámolja a kulcs- és nonce-részeit, az L outer kulcslistát a pk-val a j pozícióban formálja, kiszámolja az X̃ ← KeyAgg(L) aggregát kulcsot és az a ← KeyAggCoef(L, pk) aggregációs együtthatót. Két kötési tényező lép be: a belső b_1 ← H'non(pk, (R'_1, ..., R'_ν)) és a külső b_0 ← H_non(X̃, (R_1, ..., R_ν), m). A b ̌ = b_1 · b_0 kombinált kötési tényezővel, a session nonce R = Π_i R_i^{b_ ̌_0^{i-1}} kifejezéssel, és a c = H_sig(X̃, R, m) kihívással a k tag a

s_k ← Σ_{i ∈ [ν]} r_{i,k} · b_ ̌^{i-1} + c · a · x_k

részleges aláírást adja ki.

Aggregáció és verifikáció: a SignAgg a C kvórum részleges aláírásait Lagrange-interpolációval kombinálja, s ← Σ_{k ∈ C} s_k · λ_k, és (R, s) párt ad ki. Az s a csoport második fordulós üzenete az outer session-ben. Az outer session a társ-aláírók részleges aláírásaival kiegészítve az eredményt X̃ alatti hagyományos Schnorr-aláírásként verifikálja. A Lightning esetén a séma ν = 2 és nesting depth Λ = 2 paraméterekkel példányosul, így az outer session a ma futó, módosítatlan BIP 327 MuSig2, és a counterparty a ma futó protokollt futtatja.

Az Iceberg és a MuSig2* kapcsolata¶

A paperben MuSig2 néven hivatkozott séma a MuSig2 optimalizált verziója, és az Iceberg szerves építőköve. A MuSig2 abban tér el a vanilla MuSig2-től, hogy a második forduló üzenetfüggetlen előkészítést kap: a kihívás c és az R aggregát nonce számítása elkülönül a belső nonce-októl, és a SignAgg lépés egy SignAggExt kiterjesztéssel kiegészül, hogy a második forduló csupán a már kiszámolt R és c felhasználásával dolgozzon. Az Iceberg a PreAgg lépésben pontosan ezt a SignAgg + SignAggExt mintát tükrözi: a pre-nonce-okból R'i-t interpolál, a b_1 belső kötési tényezővel ellátja az R_i kötött nonce-okat, és az output pontosan az az üzenet, amelyet egy MuSig2 aláíró a saját slotjából küldene. A SignRound-ban az outer b_0 kötési tényező és a c kihívás MuSig2 szerint jön létre, és a b ̌ = b_1 · b_0 szorzat biztosítja, hogy a belső és külső kötés egyetlen, kompatibilis értékké álljon össze. Ez a kétlépcsős kötés a MuSig2*-ból öröklődik, és a nested struktúra kulcsa: a belső csoport a saját kötésével elrejti a belső struktúrát, míg az outer kötés biztosítja, hogy a kimenet az outer séma szabályainak megfelelő legyen.

A nesting másik fontos aspektusa, hogy a Gen determinisztikus, és a VPSS1 replikált struktúrája miatt minden minősített kvórum ugyanazt az R_agg session nonce-ot és ugyanazt a c kihívást kapja, függetlenül attól, hogy melyik t-1+1 tag vett részt az adott fordulóban. Ez a C1 megszorítást (first-round és second-round állapotfüggetlensége) és a C3 megszorítást (a kvórumok outputja azonos) egyaránt teljesíti, és ez teszi lehetővé, hogy a threshold-csoport valóban beépüljön egy külső MuSig2 futtatásba úgy, hogy a counterparty számára semmi ne változzon.

Iceberg - 4. rész: Biztonsági bizonyítás, prototípus és teljesítmény (Section 6-8)¶

A biztonsági bizonyítás vázlata¶

A szerzők az Iceberg biztonságát két lépésben bizonyítják, és mindkét lépés egy-egy formális reductio.

Theorem 1: Iceberg → Icebergbase¶

Az Icebergbase (Figure 9) az Iceberg egy egyszerűsített változata, amelyben a VPSS1 verifiable pseudorandom secret sharing sémát a VPSS0 váltja fel. A VPSS0 nem végez share-konverziót, és minden tag minden summandhoz egyetlen contribution-t ad ki, az aggregáció pedig az ismétlődő másolatok deduplicálásával dolgozik az interpoláció helyett. A Theorem 1 reductio azért működik, mert a két séma ugyanazokat a kulcsokat, nonce-okat és signature-öket állítja elő. A reductio algoritmusa (B wrapper) egy TS-MS-EUF-CMA támadót szimulál Iceberg ellen, miközben a lekérdezéseket továbbítja az Icebergbase oracle-ek felé, és a VPSS0 share-ből VPSS1 share-t készít, illetve fordítva. A reductio information-theoretically tökéletes, mert a VPSS0 és VPSS1 egyaránt information-theoretically verifiable és unique.

Theorem 2: Icebergbase → NestedMuSig2¶

A második reductio egy egyenes-vonalú (straight-line) szimuláció, amely soha nem tekeri vissza a támadót, és nem használ a NestedMuSig2 biztonságán túli feltételezést. A reductio kiindulópontja az a felismerés, hogy egy Icebergbase csoport úgy viselkedik, mint egy depth-two NestedMuSig2 session. A csoport kulcsa a summand-kulcsok szorzete (minden részhalmazra egy summand), tehát a summandok tekinthetők a nesting belső szintjének signereinek. A reductio ezt a nézetet szó szerint valósítja meg a Hagg kulcsaggregációs oracle programozásával úgy, hogy a summand-kulcsok aggregátuma megegyezzen a csoport kulccsal. Az EUF-CMA challenge kulcsot pontosan egyetlen summandba rejti, és annak a PRF kulcsát a korrupt tagok nem ismerik. A nonce-share-ek az OPreRound oracle-ből jönnek, a partial signature komponensek pedig az OSignRound oracle-ből. A csalás átfordítható, mert ha minden session azonosítóra kevesebb, mint t − |korrupt| becsületes tag írta alá az m* üzenetet, akkor a challenge summand egyetlen komponensét sem szabadították fel, és a hamisított aláírás érvényes NestedMuSig2 hamisítás.

Corollary 3: a gyakorlati biztonsági állítás¶

A Corollary 3 a Theorem 2-t és a NestedMuSig2 biztonságát ötvözi. Azt állítja, hogy ha a GrGen csoport-generáló algoritmus mellett az algebraic one-more discrete logarithm probléma nehéz, akkor az Iceberg[GrGen, ν = 2, t] egy módosítatlan BIP 327 session-be ágyazva TS-MS-EUF-CMA biztonságos az algebraic group model és a random oracle model mellett a Hagg, Hprf, Hnon, Hnon, Hsig hash-függvényekre. A reductio költsége τ' = τ + O(N) · τexp, ahol N = binom(n, t-1) a summandok száma, τexp pedig egy G-beli exponentiation ideje.

A prototípus implementáció¶

A prototípus a secp256k1 görbére implementálja az Iceberg sémát, BIP 340 x-only kulcsokkal és BIP 327 kulcsaggregációval. A külső session egy módosítatlan BIP 327 ν = 2 session, tehát a counterparty az egész folyamat során stock MuSig2-t lát. A prototípust az eclair nevű termelési Lightning implementációba portolták, és a secp256k1-kmp bindings-on keresztül érik el, amelyen keresztül az eclair az összes taproot csatornához szükséges MuSig2 hívást intézi. Az Iceberg ezen az interfészen mögé ül, tehát az eclair ugyanott kap egy publikus kulcsot, egy publikus nonce-t és egy partial signature-t, ahol korábban egyetlen signertől kapta. A mérések egy dedikált AMD EPYC 7543 CPU-n futottak, tíz mag és 4 GB heapméret mellett, húsz konfiguráción a t ∈ {2, 3, 4, 5} és n ≤ 10 paraméter-családon.

Micro benchmark eredmények¶

Az egy résztvevős MuSig2 partial signature 42,0 µs ideig tart, 5,4 µs szórással a húsz konfigurációban, 200 iteráció átlagában. Ez a viszonyítási alap: az Iceberg-csoport költségeit ehhez a 42,0 µs-hoz méri a szerzőpáros. Egy csoport ugyanezt a partial signature-t 1 042 és 7 358 µs közötti idő alatt állítja elő a konfigurációtól függően: a (2, 3)-nál 1 042 µs, a (3, 5)-nél 2 138 µs, a (4, 7)-nél 3 685 µs, az (5, 9)-nél 6 240 µs, a (4, 10)-nél pedig 4 557 µs. A (3, 7) konfigurációban a második körben részt vevő tag 14,4-szer annyi munkát végez, mint egy résztvevős MuSig2 tag, míg az első körben részt vevő tag 1,5-szer annyit. Az aggregáció ezen felül 392 µs-t ad aláírásonként. A vezetéken a csoport továbbra is egyetlen signer képében jelenik meg: az első körben 66, a másodikban 32 byte-ot küld a counterparty felé, a BIP 327-nek megfelelően. Ez azért fontos, mert a counterparty számára az Iceberg teljesen átlátszó, és a Lightning hálózati forgalom nem növekszik a thresholdizáció miatt. A csoporton belüli forgalom 2 208 byte aláírásonként a (3, 7) konfigurációban: hat első kör és két második kör nonce-share-ek és signature-share-ek formájában. Minden share-en felül egy byte-os tagindex található. Hosszú távú share-anyag tárolása 100 byte a (2, 4), 484 byte a (3, 7) és 2 692 byte a (4, 10) konfigurációban. A share-anyag mérete a tagok által tartott share-ek számával skálázódik, és ez a (4, 10) konfigurációban kezd dominálni.

A drop-in integráció validációja¶

A prototípust az eclair 473 channel tesztje változtatás nélkül futtatja le, és a build, amelyen a timing mérések futottak, a tizenhét correctness check-ből mindegyiken átment. A validáció három szinten működik: (1) a channel commitment tranzakcióját a Bitcoin script interpreter futtatja a valódi funding output ellen mindkét oldalon, tehát minden mért payment egy valódi aggregate Schnorr signature aláírással settlement-el; (2) a prototípus replay módon, adott seed-ek és session azonosító mellett, byte-ról byte-ra reprodukálja a referencia implementáció kimenetét; (3) a kulcsaggregáció két lehetséges sorrendjét is teszteli, mivel a kulcsaggregáció a kulcsokat rendezi, és a csoport nagyjából az esetek felében kerül előre. A tesztek kiterjednek az (2, 3), (3, 5), (3, 7), (4, 7) és (5, 9) konfigurációkra, valamint tíz szekvenciális payment-re egy csatornán, és a csoportot a channel-nyitó és a channel-elfogadó fél szerepében egyaránt tesztelik. A C1 és C3 constraint-eknek való megfelelést is ellenőrzik: a csoport akkor sem revideálja a korábban küldött nonce-t, ha a signing quorum megváltozik.

Thresholdized Lightning throughput¶

Az Iceberg csoporttal thresholdizált eclair csatorna fenntartható payment rátáját három telepíthető konfigurációban mérték. A (2, 4) konfiguráció egy payment-hez 3 844 µs-t ad hozzá a csatorna alap 57 599 µs-os költségéhez, ami 6,7%-os többlet. A (3, 7) konfiguráció 8 246 µs-t ad hozzá, ami 14,3%. A (4, 10) konfiguráció 16 786 µs-t ad hozzá, ami 29,1%. Az egy magra eső throughput-táblázat azt mutatja, hogy a bare MuSig2 csatorna 17,4 payment/másodpercet ér el, a (2, 4) csoport 16,3-at, a (3, 7) 15,2-t és a (4, 10) 13,4-et. A bare rátával való egyenlőség eléréséhez tehát 6,7% és 29,1% közötti géptöbblet szükséges, illetve 9,9% és 38,0% közötti, ha a tagok egymás partial signature-it is verifikálják. A paper absztraktjában említett 93%-os arány a (2, 4) konfigurációra vonatkozik: 16,3 / 17,4 = 93,7%. A költség növekedése a telepíthető családon kvadratikus.

A rendszer szűk keresztmetszetének azonosítása¶

A rendszer szűk keresztmetszetének azonosításához a szerzők szétbontják egy payment számítási költségét. Az 500 iterációval, meleg JVM-en mért payment 59,7 ms ideig tart, és a két commitment update teszi ki ennek 59,6%-át, a feladó onion konstrukciója 17,5%-ot, a saját írásait validáló teszt-adatbázis újabb 17,5%-ot. A két fél funding signature-je a teljes idő 5,1%-a, és ennek is csak a fele, átlagosan 1 517 µs, tartozik ahhoz a félhez, amelyet egy csoport helyettesít. Az Iceberg tehát a payment egy negyvened részéből indul, és a commitment update-eken belül a MuSig2 aláírás néhány mikroszekundum. A fennmaradó rész a tranzakció-konstrukció, az HTLC-nkénti aláírás, a per-commitment kulcs deriváció, az állapot-perzisztencia és a két channel state machine közötti üzenetváltás. A csoport kriptográfiáját és a helyettesített single-key signert ugyanazon a payment-en belül mérve, a kettő különbsége 350 µs-on belül megegyezik a csatornán mért lassulással, tehát a csoport nem kerül többe, mint az általa hozzáadott kriptográfia. A micro benchmark és a payment-decompozíció naiv kombinációja nagyobb lassulást jósolna: a payment negyvenedét a micro benchmark 53-szoros faktorával skálázva a payment ideje több mint duplájára nőne, de a mért növekedés csak 14,3%. Ennek oka a secp256k1-kmp bindings fix overheadje, amely mindkét signert érinti, és a live payment flow-ban a csoport csak 6,5-szer annyi ideig fut, mint az általa helyettesített signer, nem 53-szor.

A scope korlátai¶

A szerzők szándékosan kizárják a tagok közötti hálózatot a benchmarkból. Mivel egy csoport egy felhasználó eszközeit vagy egy vállalat gépe reprezentálja, a benchmark low-latency lokális hálózatra épít. Egy payment ettől függetlenül hat első és két második kört hajt végre a csoporton belül, tehát minden ilyen kör egy-egy round trip-et ad a deployment költségeihez. A prototípus kizárólag az aktív payment utat fedi le: a mutual close, a force close, a splicing és a channel announcement még nem csatlakozik threshold signer-hez. A channel announcement különösen problematikus, mert a funding kulcs felett ECDSA signature-t igényel, és az Iceberg nem ECDPA, hanem Schnorr aláírásokat állít elő. A benchmarkok csak egyetlen HTLC-t viselő payment-eket mérnek, és mivel a csoport oldalán minden kulcs csoportkulcs, és minden HTLC saját aláírást igényel, a költség a flight HTLC-k számával nő.

Következtetések és nyitott kérdések¶

Az Iceberg lehetővé teszi, hogy egy signer-csoport közösen működtessen egy MuSig2 session résztvevőt úgy, hogy a másik résztvevő az egész üzenetáramlás során egyetlen signert lát. Egy Lightning csatorna bármelyik végpontja (vagy mindkettő egymástól függetlenül) threshold custody-t használhat anélkül, hogy a Bitcoin, a Lightning protokoll vagy a counterparty módosulna. A 2-of-4 végpont a nem thresholdizált végpont elméleti maximumának több mint 93%-át fenntartja, ami jelentős tartalékot hagy a jelenlegi Lightning payment ráták felett. A gyakorlati implikációk három szinten jelentkeznek. Először, a custody szolgáltatók és exchange-ek mostantól anélkül thresholdizálhatják a Lightning hot walletjeiket, hogy az on-chain BTC custody megoldásaikkal kompromisszumot kötnének, mert az Iceberg kizárólag a Lightning csatorna végpontját érinti. Másodszor, az intézményi Lightning üzemeltetők (node-as-a-service szolgáltatók, fizetési processzorok) anélkül oszthatják meg az aláírási felelősséget több biztonsági zóna vagy földrajzi hely között, hogy a partnereik bármit is tudnának erről. Harmadszor, a 6,7-29,1%-os CPU-többlet, illetve a 6,3-22,6%-os throughput-csökkenés elfogadható trade-offnak tűnik a threshold custody-ból származó biztonsági nyereségért cserébe, különösen ha a channel announcement-ek és a multi-HTLC payment-ek költsége a jövőben tovább csökken.

Tágabb értelemben az Iceberg megmutatja, hogy a thresholdization elérhető egy meglévő multi-signature protokollba ágyazással, nem pedig annak leváltásával. Ez a nested threshold multi-signature primitive egy általános építőelem, amely más protokollokra is alkalmazható lehet, és a paper egyik fontos nyitott kérdése, hogy mely más multi-signature protokollok teszik lehetővé ezt az ágyazást. A sikeres ágyazás feltétele, hogy a külső protokoll nonce-exchange és üzenetfolyama ne függjön a belső résztvevő struktúrájától, és a belső threshold séma outputjai (aggregált kulcs, aggregált nonce, partial signature) megfeleljenek a külső protokoll input-elvárásainak. A MuSig2 ezt a tulajdonságot teljesíti, mert az aggregált kulcs és az aggregált nonce a résztvevők egyedi közreműködéséből származik, és a külső counterparty-nak nem kell tudnia, hogy ez egy egykulcsos vagy egy t-of-n csoport.

A Lightning esetében további nyitott kérdés, hogy egy csoport mennyit változtathat magán a csatorna nyitva tartása alatt: proaktív share-frissítés (proactive secret sharing), egy elveszett share-t birtokló tag megmentése (share recovery), vagy a tagság és a threshold változtatása (dynamic threshold). Ezek mindegyikének meg kell őriznie az aggregált kulcsot, mert ez a kulcs a csatorna funding outputja, és a kulcs változása a csatorna bezárását és újranyitását jelentené. A proaktív share-frissítés különösen fontos a hosszú életű csatornák esetében, mert egy hónapokig vagy évekig nyitva tartott csatornánál a share-ek kompromittálódásának valószínűsége monoton nő. A share-recovery egy olyan forgatókönyvet kezelne, amikor egy tag véglegesen elveszti a share-jét (például egy disaster recovery esemény során), és a t threshold fenntartásához egy másik tagot kell bevonni. A dynamic threshold lehetővé tenné, hogy a felhasználó fokozatosan növelje vagy csökkentse a t értéket a csatorna kockázati profiljának megfelelően.

Forrás¶

Paper: "Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures", Paul Gerhart (TU Wien), Nadav Kohen (Chaincode Labs), Jesse Posner (Vora), Matias Furaszyfer (Chaincode Labs), IACR ePrint 2026/1757.
A rész forrása: 3 765 szó, 25 064 karakter
A summary a Section 6 (Security - Theorem 1, Theorem 2, Corollary 3), Section 7 (Prototype and Evaluation - Tables 3-7, Figure 5) és Section 8 (Conclusion and Future Work) szakaszokat öleli fel.
A 93%-os throughput-arány a (2, 4) konfigurációra vonatkozik (16,3 / 17,4 = 93,7%), nem az absztrakt-párhuzamban gyakran idézett (3, 7) konfigurációra, amely 87,4%-os arányt ér el.
A rész-ot saját magam summarioztam (4. rész a 4-ből), a másik három rész párhuzamos subagent által készül.

Forrás és feldolgozás¶

Paper: IACR ePrint 2026/1757, 2026. A teljes PDF 1,0 MB, 22 oldal.
Szerzők: Paul Gerhart (TU Wien), Nadav Kohen (Chaincode Labs), Jesse Posner (Vora), Matias Furaszyfer (Chaincode Labs).
Kulcsszavak: Lightning Network, Threshold Custody, Nested Threshold Multi-Signatures, MuSig2, Schnorr Signatures, BIP 327, BIP 340, eclair.
A summary 4 chunkból áll, párhuzamos subagent-ek által írva: Abstract + Introduction (chunk1, 1996 szó), Technical Overview (chunk2, 2798 szó), Preliminaries + Our Scheme (chunk3, 2678 szó), Security + Prototype + Conclusion (chunk4, 2125 szó). A chunk-summaryk a /tmp/iacr_2026_1757/chunks/summary_chunk{1,2,3,4}.md fájlokban találhatók.
Prototípus referencia: [Fur] - a szerzők nyilvánosan elérhető implementációja, amelyet az eclair Lightning node-ba portoltak.