# Bitcoin Optech. Newsletter #424 Recap (2026-10-01) > **Epizód:** bitcoin_optech #424 > **Dátum:** 2026-10-01 > **Házigazdák:** Mike Schmidt, Gustavo Flores Echaiz > **Vendégek:** Ahmet Kurt (East Texas A&M University, a PQLN szerzője, előre felvett szegmensben), Jan B (Bitcoin Core közreműködő, a 32.0 tesztelési útmutató szerzője) > **Forrás:** https://bitcoinops.org/en/podcast/2026/09/29/ > **Hírlevél:** https://bitcoinops.org/en/newsletters/2026/09/25/ > **Media:** https://anchor.fm/s/d9918154/podcast/play/126643258 > **Transcript:** Whisper (medium.en), 11 852 szó, 7,3 perc wall-time (89:20 audió) > **Auto-review score:** 0.90 (auto_approved) ## Bevezetés és a lényeg A Bitcoin Optech 424-es hírlevelének feldolgozása két érdemi szálat hoz, és mindkettő szokatlan formában. Az első a **PQLN**, a Lightning Network off-chain felületeinek posztkvantum-biztonsági kiterjesztése, amelyet a szerző, Ahmet Kurt **előre felvett szegmensben** mutat be, mert a felvétel idején Washingtonban volt egy műhelyen, és a visszarepülése egybeesett az adással. A második a **Bitcoin Core 32.0 rc2** és a hozzá tartozó tesztelési útmutató, amelyet a szerző, Jan B vezet végig. A PQLN a hírlevél egyetlen híreleme, és ez indokolt: a javaslat nem a Lightning finomhangolása, hanem öt protokollréteg egyidejű átállítása kvantum-ellenálló kriptográfiára úgy, hogy a hálózat **nem szakad szét**. A megoldás lényege a hibrid konzervatív kiterjesztés: minden klasszikus mechanizmus a helyén marad, és a posztkvantum primitívek mellé kerülnek, a meglévő üzenetformátumokba és méretkorlátokba beillesztve. A Bitcoin Core 32.0 szál háttere a projekt kiadási ritmusa: félévente jön főverzió, a kiadás **időalapú és nem funkcióalapú**, ezért nem minden kiadás egyformán súlyos. A 32.0 viszont sok változást hoz, és a közösségi tesztelés most számít, mert a projekt a saját tesztkészletén túl nem tud minden leszármazott beállítást lefedni. A legfontosabb tanulságok: - A PQLN **nem igényel konszenzusváltozást**, és a posztkvantum csomópontok ma is beszélnek a módosítatlan csomópontokkal - Az átállás valódi ára a **sávszélesség**: a friss PQLN csomópont tízszer annyi gossip-adatot tölt le (ML-DSA-44-gyel), Falconnal viszont csak négyszer annyit - A számítási költség elhanyagolható: a legdrágább művelet, az ML-DSA aláírás, **0,33 milliszekundum** - A Lightning összes posztkvantum-sebezhetősége az off-chain felületeken van; a csatorna, a commitment és a büntető tranzakciók kulcsaihoz konszenzusváltozás kellene - A Bitcoin Core 32.0 végső kiadása **október 10-re** van kitűzve, és a kiadás jelöltjei funkcióteljesek - Az új HTTP-szerver szándékosan szigorúbb az RPC/RFC szabályokban, ezért a saját klienssel rendelkező üzemeltetőknek tesztelniük kell - A Core Lightning 26.06.8 mögötti sebezhetőségek most váltak ismertté, és a javítások között volt egy olyan hiba, amely **végtelen újraindítási ciklust** okozott - A Core Lightning javításai feltűnően egybeesnek az Eclair hasonló javításaival, ami közös hiányosságra utal a Lightning-implementációkban - A BIP-461 célja a kulcskiszivárgás elleni védekezés: determinisztikus ECDSA-aláírás, amivel két eszköz eredménye összevethető, és az eltérés támadást jelez ## A PQLN javaslat: miért kell a Lightningot posztkvantum-biztonságossá tenni Ahmet Kurt asszisztens professzor az East Texas A&M University-n. A Bitcoin-útja 2017-ben kezdődött, a tudományos pályája 2019-ben a Florida International University doktori programjával. A doktori témája eredetileg nem Lightning volt, hanem egy titkosított kommunikációs implementáció a Lightning Network fölött. A témaváltás azért történt meg, mert a munkát élvezetesebbnek találta, és a doktori fokozat végén már kifejezetten Lightning-alkalmazások tervezésével és értékelésével foglalkozott. A PQLN ötlete 2025 februárjában merült fel egy társszerzővel, aki maga posztkvantum-kutató. A munkamegosztás kézenfekvő volt: az egyik fél a Lightningban, a másik a posztkvantum-kriptográfiában jártas. Az első nekifutás megmutatta a feladat súlyát. A szerző megfogalmazása szerint túl sok mozgó komponens van a Lightningban, amelyet posztkvantum-biztonságossá kell tenni, és kezdetben úgy tűnt, hogy a feladat nem megoldható. A megvalósítás 2025 decemberében indult a rust-lightning kódbázisán, amelyet a szerző a legalkalmasabb indulópontnak tartott a modularitása miatt. Az intenzívebb munka 2026 áprilisában kezdődött, napi néhány órával, és a teljes implementáció két-három hónapot vett igénybe. A cikk megírása további mintegy másfél hónap volt. A szerző kitér arra is, hogy a cikk tizenhárom oldalas, mert a célzott tudományos fórum oldalkorlátja ennyi volt, holott a munka húsz-harminc oldalt is megérdemelt volna. A javaslat motivációja kétlábon áll. Az első érv az, hogy **a Bitcoin posztkvantum-frissítése önmagában nem tenné posztkvantum-biztonságossá a Lightningot**. A Lightning saját peer-to-peer üzenetei, a gossip, a transport, a számlák, az ajánlatok és a fizetési hagymák a Lightning off-chain felületei, amelyek nem részesülnek a Bitcoin alapszintű frissítéséből. Ezért a Lightningot önmagában is lehet és kell frissíteni. A második érv a már ma is futó támadás: a **harvest-now-decrypt-later** minta. A támadó rögzítheti a Lightning-forgalmat, és később, amikor már létezik elég erős számítógép, visszafejtheti. A szerző óvatosan fogalmaz: nem a teljes hálózat rögzíthető, de annak egy része igen, és ez elegendő indok a munkára. A szerző nyíltan beszél a munka korlátairól is. Megjegyzi, hogy nem szoftverfejlesztő, hanem oktató és kutató, ezért elképzelhető, hogy nem a legjobb kódot írta, és nem a legjobb megközelítést választotta. A saját megítélése szerint az implementáció helyes és nincsenek benne nyilvánvaló hibák, de ezt a közösség visszajelzésére bízza, és kéri a hibajegyek és pull requestek beküldését. Hozzáteszi azt is, hogy korábban még nem tartott fenn GitHub-tárat, ezért ez neki is új terep. ## A gossip: kulcsterjesztés a meglévő csatornán A PQLN első lépése a posztkvantum kulcsok terjesztése. A csomópontoknak a klasszikus identitásuk mellé posztkvantum identitásuk is lesz, és ezek elosztására a gossip szolgál. A szerző megítélése szerint ez hangos megközelítés: a csomópontok a gossip üzeneteken keresztül ismerik meg egymás posztkvantum identitását. A gossipnak három üzenettípusa van, és a PQLN ebből **kettőt tesz posztkvantummá**. A `channel_announcement` szándékosan klasszikus marad. Az indoklás mechanikai: ennek az üzenetnek négy aláírásából kettő az on-chain funding kulcsoktól függ, ezért ha a négyből kettőt posztkvantummá tennénk, a maradék kettő klasszikus maradna, és ez nem hozna érdemi hasznot. A szerző megfogalmazása szerint az üzenet így is „half-forgeable” lenne. Ez a döntés jól mutatja a javaslat alapszemléletét: ahol a posztkvantum-átállítás nem hoz teljes védelmet, ott nem érdemes megbontani a meglévő formátumot. ## A transport: a hibrid kézfogás A transportréteg a BOLT8, és a szerző ezt nevezi a legegyszerűbb és legvalószínűbben helyes résznek. A Noise kézfogás **hibriddé** válik: két ML-KEM beágyazás történik, az egyik a rögzített statikus kulcshoz, a másik egy új, ephemér kulcshoz, ami a forward secrecy-t adja. A kulcsfontosságú tervezési döntés az, hogy **nincs sávon belüli egyeztetés**. Az indoklás támadóközpontú: egy posztkvantum-támadó könnyedén hamisíthatná az egyeztetés üzeneteit, ezért a feleknek nem szabad olyan mechanizmusra támaszkodniuk, amelyet a támadó befolyásolhat. Helyette a felek a rögzített vagy az ajánlatban elkötelezett kulcsokhoz hasonlítják a kapott értékeket, és így szűrik ki a downgrade-támadást. ## A számlák: a méretkorlát és a szétdarabolás A BOLT11 számlák posztkvantummá tétele méretkérdés. Egy posztkvantum aláírás felduzzasztja a számlát, és a szerző szerint majdnem meghaladja a QR-kód korlátját. Az ML-DSA-44 aláírással viszont a korlát még tartható, nagyjából tíz karakter marad. A két érintett számadat: az ML-DSA-44 aláírás **2420 bájt**, a Lightning-implementáció viszont egy címkézett mezőben legfeljebb **639 bájtot** enged. Ezért a PQLN az aláírást **négy címkézett mezőre bontja**, és így viszi át a hálózaton. A szerző megjegyzi, hogy Falconnal az aláírás mérete jelentősen csökkenne, és a teljes számla körülbelül 1500 karakterre esne vissza. Itt érdemes megjegyezni, hogy a Falcon nem NIST-szabványosított eljárás, míg az ML-DSA és az ML-KEM 2024 óta az. A szerző ezt nyíltan kimondja, és hozzáteszi, hogy a Falcon használatához több bizonyosság kellene arról, hogy valóban biztonságos. ## Az ajánlatok: friss kulcs minden ajánlathoz A BOLT12 ajánlatoknál a gossip-alapú kulcsterjesztés nem működik. Az ok konkrét: az ajánlat mögötti csomópont gyakran **befejezetlenül hirdetett, és egy vak útvonal mögött ül**, ezért nem lehet rá hagyatkozni, hogy a gossipban megjelent. Az ajánlatnak saját horgonyt kell hordoznia. A PQLN megoldása az, hogy **minden ajánlathoz friss ML-DSA kulcsot kötelez el**, és a fizető a visszakapott számlát pontosan ehhez a kulcshoz ellenőrzi, mielőtt bármilyen HTLC elindulna. Ez a minta a későbbi LND-fejlesztésekkel is összecseng: az LND #11146-os javítása ugyanezt a logikát erősíti, mert pusztán az érvényes aláírás nem elég, ha a vak útvonal bármely csomópontja a saját kulcsával írhatja alá a számlát. ## A hagyma: a legnehezebb rész A szerző a BOLT4 hagymát nevezi a feladat legnehezebb részének, és elmondja, hogy erre fordította a legtöbb időt. A probléma méretezési: a hagymacsomag **1300 bájt**, és minden fizetéshez egy ML-KEM rejtjelezett szöveg kell **hoponként**. Egy ML-KEM-768 rejtjelezett szöveg **1088 bájt**, két hopnál pedig a korlát már átlépődik. A megoldás meglepő: a hagyma **formátuma változatlan marad**, és a hoponkénti titok válik hibriddé. A küldő minden hop ML-KEM kulcsához beágyaz egy titkot, és azt összekeveri a klasszikus Sphinx-titokkal. A rejtjelezett szövegek a hagyma **mellett** utaznak, az `update_add_htlc` üzenetben, egy rögzített méretű, húsz rekeszes listában. A lista kihasználatlansága nem szivárogtat információt: minden használaton kívüli rekesz **álrejtjelezett szöveggel** töltődik fel, hogy a csomópont ne tudja megállapítani az útvonal hosszát. A szerző ezt a részt külön kiemeli visszajelzésre, mert szerinte helyes, de a legkevésbé bizonyított. A szerző kitér arra is, miért nem növeli egyszerűen a Lightning csomagméret-korlátait. Az indoklás az interoperabilitás: ha a korlátokat megnövelné, a frissített és a klasszikus csomópontok nem tudnának beszélni egymással, vagy összeomlanának a kommunikációban. A PQLN ezért inkább megkerülő megoldásokat keres, és a protokollt változatlanul hagyja. ## Az interoperabilitás mint elsődleges megkötés A szerző többször visszatér arra, hogy az interoperabilitás volt a fő tervezési megkötés, és hogy ez sokkal több időt vett igénybe. A cél az volt, hogy egy posztkvantum csomópontot **ma be lehessen dobni a hálózatba**, és az minden módosítatlan csomóponttal beszéljen. Ha viszont két posztkvantum csomópont találkozik, mindkettő támogatja a posztkvantum módot, és fel tudnak lépni rá. A szerző bepillantást ad a lehetséges bevezetési útra is. A Lightning közösség lassan fogadná be a posztkvantum-frissítést, ezért a mechanizmus kezdődhet opcionális módként, és később válhat kötelezővé. A szerző nyíltan kéri, hogy a közösség ezzel kapcsolatban is adjon visszajelzést. ## Az implementáció és a mérés A rust-lightning módosítása **körülbelül 11 000 sor kódot ad hozzá 52 fájlban**, egyetlen Cargo-funkció kapcsoló mögé rejtve. A csomag körülbelül száz tesztet tartalmaz, amelyek a szerző megfogalmazása szerint a legnyilvánvalóbb támadásokat fedik le, funkcionális és támadói forgatókönyvekben egyaránt. A szerző kéri a rust-lightning fejlesztőit, hogy nézzék át a kódot. A mérés két részből áll, és a két rész iránya ellentétes. A **számítási költség elhanyagolható**. A legdrágább művelet, az ML-DSA aláírás, mindössze **0,33 milliszekundumot** vesz igénybe. A **valódi költség a sávszélesség**. A teszt szerint egy friss PQLN csomópont, amely csatlakozik a hálózathoz, **tízszer annyi gossip-adatot** tölt le, mint egy szokásos csomópont, ML-DSA-44-gyel. Falconnal ez a szám **négyszeresre** csökken, amit a szerző már elfogadhatónak tart. Az adattárolás a hírlevél összefoglalója szerint kilencszeres. A szerző megemlíti, hogy a Falcon előnye a méret, a hátránya viszont a szabványosítás hiánya. ## Az interoperabilitási tesztek és a nyitott problémák A szerző elmondja, hogy az interoperabilitási teszteket módosítatlan és PQLN csomópont között futtatta, és a fő funkciókat gyakorolta: fizetések küldése és fogadása, csatornák nyitása és zárása, aszinkron fizetések. A szerző bizonytalan abban, hogy a splice-t is tesztelte-e. Az eredmény az, hogy semmi nem tört el, a csomópontok végig a protokoll szerint jártak el. A tesztelés eredménye kettős, és mindkét ág fontos. Ha a fizetési útvonalon klasszikus csomópont van, a PQLN csomópont **visszaesik a klasszikus protokollra**. Ha viszont a `require-PQ` kapcsoló be van állítva, a csomópont **a HTLC elküldése előtt meghibásodik**, vagyis nem enged klasszikus útvonalat. A szerző három nyitott problémát sorol fel. Az első a **pinning**: a megoldás trust-on-first-use jellegű, ezért csak azokat a csomópontokat védi, amelyek már találkoztak egymással, mielőtt egy kriptográfiailag releváns kvantumszámítógép elérhetővé vált. A szerző írja, hogy van néhány ötlete a rés bezárására konszenzusváltozás nélkül, és ezek a cikkben is szerepelnek, de előbb a közösség véleményére kíváncsi. A második a rust-lightning **1024 bájtos `MAX_EXCESS_BYTES_FOR_RELAY` korlátja**, amely megakadályozza, hogy a nem posztkvantum csomópontok továbbítsák a posztkvantum gossip-adatot. A harmadik a **feature bitek és TLV-típusok hozzárendelése**, ami még nyitott. A szerző egy beszélgetésre is kitér, amelyet Matt Corallóval folytatott a témáról. A felvetés az volt, hogy a biztonságos Rust crate-ek kiválasztása is kulcskérdés. A PQLN az fips203 és fips204 csomagokat használja, és a szerző nyíltan megjegyzi, hogy nem tudja, ezek auditáltak-e, és használhatók-e éles környezetben. ## Bitcoin Core 32.0 rc2 és a tesztelési útmutató A hírlevél második érdemi szála a Bitcoin Core következő főverziója, amelynek második kiadásjelöltje van éppen tesztelés alatt. Jan B vezeti végig a hallgatót. A fél évente jelentkező főverzióknál a kiadás **időalapú, nem funkcióalapú**, ezért nem minden kiadás egyformán súlyos. A 32.0 viszont sok újítást és javítást hoz, és Jan B külön felhívja a figyelmet arra, hogy nem minden változás kerül be a kiadási jegyzetekbe: a jegyzetek a legjelentősebb változásokat fedik, a kisebb hibajavítások kimaradnak. A kiadásjelöltek funkcióteljesek, és a közösségi tesztelés célja nem az, hogy új funkciókat találjanak. Az indoklás a Bitcoin Core tesztelési helyzetét írja le. A projekt már kiterjedt tesztkészlettel rendelkezik: minden pull requestre egységtesztek, funkcionális tesztek, fuzzing és folyamatos integráció fut több platformon. Ezen felül ma már a **red team is tesztel AI-val** biztonsági hibák után kutatva. A projekt viszont nem tud minden leszármazott beállítást lefedni: minden Lightning-csomópont, blokkfelfedező, tárcaalkalmazás, hardvertárca, bányászati pool, operációs rendszer, sőt egy szekrényben futó Raspberry Pi más környezet. Ezért a közösség feladata az, hogy a saját beállításán futtassa a jelöltet. Jan B fontos részletet emel ki: **a tesztelési útmutató nem kötelező**. Aki nem akarja használni, az is értékes visszajelzést ad, ha a jelöltet a megszokott módon futtatja, mert így olyan hiba is előkerülhet, amely nem a fő funkciókhoz kapcsolódik, hanem például egy operációs rendszer kompatibilitásához. A visszajelzésre két hely van: a tesztelési útmutatóhoz tartozó hibajegy, és a kiadás 32-es verziójához tartozó GitHub-hibajegy. Jan B hozzáteszi azt is, hogy a **pozitív visszajelzés is hasznos**: ha minden lefutott és működött, azt is érdemes jelezni, mert az is információ. Az útmutató négy csoportban körülbelül tíz tesztet fed le: új RPC-ket, frissített RPC-ket, tárca-related kérdéseket és a HTTP-szerver átírását. Minden regtesten fut, vagyis saját privát tesztkörnyezetben, ahol nem kell bányászni és nem kell letölteni a teljes blokkláncot. A futtatás azonnal indul, és csak néhány megabájt tárhelyet foglal. ## Mi van a 32.0-ban Jan B több konkrét elemet emel ki, és ezek közül néhány a tesztelési útmutatóban is szerepel. Az első egy **új RPC-parancs, amely géppel olvasható leírást ad a Bitcoin Core összes RPC-jéről**. Ennek haszna a szerző szerint kettős: saját leszármazott kliensben használható, és a jövőben a két kimenet összehasonlításával könnyen felfedezhetők a változások, ami megkönnyíti a saját kliens frissítését. A második az **`exportwatchonlywallet` parancs**. A használati eset gyakorlati: ha valakinek van egy tárcája a Bitcoin Core-ban, és csak a fizetések beérkezését vagy az egyenleget szeretné figyelni, de tranzakciót nem akar indítani, akkor ezzel a paranccsal exportálhatja a tárcát, és például a telefonján visszaállíthatja. A harmadik a **PSBT-alapú folyamat változása**: a PSBT mostantól alapértelmezés szerint a második verzió. Az útmutató a szokásos folyamatot gyakoroltatja (tranzakció finanszírozása, aláírása, véglegesítése, sugárzása), de Jan B kéri, hogy aki a saját rendszerében másképp használja a PSBT-t, az is teszteljen. A negyedik a **HTTP-szerver teljes újraírása, amely eltávolítja a libevent függőséget**. Minden, ami RPC-n vagy REST-en keresztül beszél a csomóponttal, ezt az új komponenst használja. A szerver szándékosan **szigorúbban követi az RPC/RFC szabályokat**, ezért a saját RPC- vagy REST-klienssel rendelkező felhasználóknak tesztelniük kell. A szerző megjegyzi, hogy sok erőfeszítés történt a kompatibilitás megtartására, de a szigorítás szándékos volt. Az útmutató ezen kívül lefedi a HD-kulcsok származtatását és hozzáadását, ami a több-aláírásos tárca beállításához kapcsolódik az új Bitcoin Core tárcában, és az **új díjbecslőt**, amelyet szintén tesztelnek. Van egy fejlettebb elem is: a **UTXO-készlet névvel ellátott pipe-ba dumpolása**, amivel a készlet streamelhető fájlba, és onnan adatbázisba vagy más rendszerbe vihető. Mike Schmidt visszatekintést ad az egyes elemek korábbi hírlevélszámaira, ami jól mutatja, milyen hosszú a fejlesztési ciklus: az `exportwatchonlywallet` a 413-as hírlevélben és podcastban szerepelt, a libevent eltávolítása a 411-esben (Matthew Zipkin vendéggel), a párhuzamos blokkletöltés a gyorsabb validálásért a 414-esben, a kisebb és gyorsabb TX-index a 419-esben, a mempool-alapú díjbecslő a 420-asban, a tárca migrációja a tárca betöltése nélkül a 416-os Stack Exchange-válaszban, a globális tranzakció-továbbítási korlátok és a 200 kapcsolat alapértéke szintén a 416-osban, a peer feature-egyeztetés pedig a 410-esben. Jan B két elemet emel ki, amelyek **szándékosan kimaradtak a tesztelési útmutatóból**. A kisebb TX-indexet nehéz regtesten tesztelni, mert nagyobb adathalmaz kell hozzá, és a mainnet adatainak másolását igényelné, ami kívül esik a tesztelési kereten. A párhuzamos letöltés ugyanezért maradt ki. A projekt viszont kifejezetten kíváncsi a terepi tapasztalatokra ezeknél a funkcióknál. ## Stack Exchange: három kiválasztott kérdés ### A taproot összeg-aláírás kérdése A hónap három kiemelt kérdése közül az első a taproot aláírás-üzenetére vonatkozik: mi lenne a hátránya, ha az összegek SHA-256-ja helyett az összegek **összege** szerepelne az aláírásban. Mike Schmidt a háttérrel kezdi, és a magyarázat a hardveres aláíró eszközök helyzetéből indul. Egy ilyen eszközön nincs blokklánc, csak azt tudja, amit a csatlakoztatott számítógép mond neki. A tranzakció díja pedig bemenetek mínusz kimenetek, ezért ha a számítógép hazudik egy bemenet értékéről, az eszköz a díjról is megtéveszthető. A példa szemléletes: ha a bemenet valójában tíz bitcoin, de a rosszindulatú szoftver egy bitcoint mond, akkor a felhasználó jóváhagyja 0,99 BTC elküldését abban a hitben, hogy a díj 0,01, miközben valójában 9,01 BTC megy a bányászhoz. Ez a **díjtúlfizetési támadás**. A taproot ezt úgy oldotta meg, hogy minden aláírás elköteleződik **az összes bemenet összege** mellett, ezért ha a számítógép bármelyik összegről hazudik, az aláírás érvénytelen lesz, és a tranzakció nem sugározható. A kérdés felvetője azt kérdezi, miért nem elég csak a végösszeg mellett elköteleződni, hiszen az kevesebb munkával ugyanazt a védelmet adná. A válasz az, hogy a végösszeg valóban megállítja a díjtámadást, mert a bemenetek és kimenetek összege rögzített, **de a rosszindulatú számítógép átcsoportosíthatja az összegeket a bemenetek között**, amíg a végösszeg változatlan marad. A példa egy coinjoin-szerű helyzet. Az egyik fél egy bitcoint tesz be, a másik 0,1-et, a kimenetek pedig 1 és 0,1 BTC-t fizetnek. A rosszindulatú szoftver most azt mondja az eszköznek, hogy az első bemenet 0,1, a második pedig 1, így a végösszeg változatlanul 1,1 marad, és az összeg-ellenőrzés átmegy. Az eszköz viszont boldogan jóváhagyja azt a változatot, amelyben a felhasználó 0,1 BTC-t kap, a másik fél pedig az egyet. Ezért kell megtartani a taproot eredeti tervét, amelyben az eszköz a **saját bemenetének pontos összegéhez** köteleződik el. ### A BIP110 utáni újraszinkronizálás A második kérdés az, hogy a BIP110-es elágazás után szükséges-e a nulladik blokktól újraszinkronizálni. A háttér az, hogy a kérdező Bitcoin Knots-ot futtatott BIP110-kényszerítéssel. Amikor az aktiválási kísérlet augusztusban meghiúsult, az ilyen csomópontok elkezdték elutasítani az első olyan blokkot, amely nem jelzett, és két láncra szakadtak. A hírlevél a 418-as számában foglalkozott a BIP110-vitával. Mike Schmidt megjegyzi, hogy az a lánc valójában csak néhány blokkot ért meg, mielőtt megállt, és azóta több elágazás is megjelent, de a kérdés nem ezekről szól, hanem inkább fogalmi. A kérdező pruned csomópontot futtatott, amely eldobja a régi blokkokat. A gond az, hogy egy pruned csomópont **nem tud visszatekerni olyan pontra, amelyet már törölt**. A jogos aggodalom az volt, hogy most a teljes blokkláncot újra kell-e tölteni. Murch válasza az, hogy valószínűleg nem. Az indoklás időzítési: az elágazás nemrég történt, és a BIP110-es lánc a szabályaival alig adott hozzá blokkokat, mielőtt a csomópontot utoljára futtatták. Ezért a pruned csomópont szinte biztosan **tárolja még a két lánc közös utolsó blokkját**, még akkor is, ha a fő lánc azóta több ezer blokkot haladt előre. A javasolt megoldás az, hogy a Knots helyére Bitcoin Core telepítése valószínűleg elegendő, és a csomópont magától visszaágazik a fő láncra. Van egy tartalék megoldás is: a `reconsiderblock` parancs futtatása arra az első blokkra, amelyet a Knots-csomópont elutasított, mert nem jelzett kötelezően. Ez megmondja a csomópontnak, hogy ne tekintse többé érvénytelennek azt a blokkot, és onnan újraértékelje a láncot. A házigazda hozzáteszi, hogy Murch ezt vélhetően nem próbálta ki személyesen, hanem a Bitcoin Core belső mechanizmusairól beszél. Gustavo Flores Echaiz egyetért, és hozzáteszi, hogy aki ilyen helyzetbe került, annak nem kell elölről kezdenie, mert az új láncon nem történt sok munka. ### A részleges UTXO-készlet kérdése A harmadik kérdés az, hogy építhet-e egy Bitcoin-csomópont részleges UTXO-készletet csak a legutóbbi blokkokból, és validálhat-e azzal új tranzakciókat. Mike Schmidt rekonstruálja a mögöttes szándékot: a kérdező nem akar visszamenni minden blokkhoz 2019-ig, hanem csak az utóbbi néhány hónapot dolgozná fel, abból építene UTXO-készletet, és azzal validálna. A hipotézis egy olcsó könnyű csomópont. A választ Pieter Wuille adta, aki a Stack Exchange-en rengeteg kérdést válaszol meg. A mechanikai érv az, hogy a csomópontnak **ellenőriznie kell, hogy a tranzakcióban elkötött minden érme létezik, és még nem lett elkötve**. Egy részleges UTXO-készlettel viszont előfordulhat, hogy olyan érmét kötnek el, amelyről a csomópont nem tud. A probléma lényege a megkülönböztethetetlenség: a csomópont **nem tudja megállapítani, hogy egy hiányzó bemenet már el lett-e költve, vagy olyan blokkban keletkezett, amelyet kihagyott**. A példa érzékelteti: az érme évekkel korábban keletkezhetett, teljesen érvényes, a hiperpruned csomópont viszont nem tud a létezéséről. A következtetés az, hogy egy ilyen csomópont **nem tud visszautasítani egyetlen tranzakciót sem érvénytelenként**, ezért a séma nem végez hasznos validálást, és biztonsági szintje az SPV-vel egyenértékű, amely teljes egészében a proof of work-re támaszkodik. A házigazdák pozitívan nyilatkoznak a kérdező szándékáról: Gustavo idézi a felvető saját megfogalmazását, miszerint egy könnyű csomópont-tervezeten dolgozik a független ellenőrzés javítására korlátozott tárhely mellett. Mike Schmidt szerint a felvetés jó indulatú, de az energia jobb helyre fordítható: a közelmúltbeli adásokban tárgyalt **Utreexo és Floresta** éppen azt a kompakt UTXO-reprezentációt adja, amely **az összes blokkot figyelembe veszi**, nem csak egy részét. ## Kiadások és kiadásjelöltek A szakasz három elemet tartalmaz. A **Bitcoin Core 32.0 rc2** a második kiadásjelölt, és a végső kiadás október 10-re van kitűzve. A korábbi kiadásjelölt után kisebb hibákat találtak, ezért jelent meg a javított változat. A **Core Lightning 26.06.8** biztonsági kiadás, amely felelősen bejelentett sebezhetőségek javításait tartalmazza. A forráskód azonnal elérhető, viszont néhány teszt **szándékosan visszatartva** maradt, hogy a támadóknak ne legyen könnyű dolga a sebezhetőségek azonosításában. Gustavo felhívja a figyelmet egy operátori csapdára: aki a fejlesztői buildet használta, **nem tud visszalépni erre a kiadásra**, mert az adatbázis-séma újabb volt. A projekt erősen ajánlja a frissítést. A **LDK v0.3-rc2** a második kiadásjelölt, és több új funkciót hoz. Az egyik az **RBF díjnövelés elakadt splice-tranzakcióknál**, ami eddig hiányzott: ha a splice nem tudott megerősítést nyerni, nem lehetett növelni a díjat. Új az is, hogy ugyanabban a splice-ban **pénz adható hozzá és vehető ki**. Az anchor-csatornák mostantól **alapértelmezés szerint egyeztetettek**, és az alkalmazásoknak kifejezetten el kell fogadniuk a bejövő csatornákat. Gustavo két figyelmeztetést emel ki az LDK-nál. A frissítés **érvényteleníti a korábban kibocsátott BOLT11 számlákat**, mert a fizetési adat szerkezete megváltozott, ezért a még nem lejárt számlák inkompatibilissé válnak. Emellett több API- és visszafelé kompatibilitási változás is van, amelyeket az operátoroknak át kell nézniük. A szerző hangsúlyozza, hogy ez még mindig csak kiadásjelölt, és nem tekintendő éles kiadásnak. Gustavo egy szervezeti változást is megemlít: az **LDK-tár elköltözött a GitHubról egy saját hosztolt tükörre** (`git.rust-bitcoin.org`). A pull requestek és a folyamatos munka már nem a GitHubon találhatók, hanem a tükrön, amely viszont a GitHub-tár leírásából könnyen elérhető. Mike Schmidt a szakaszt egy általános figyelmeztetéssel zárja. Az elmúlt hónapokban sok hibajavítás jött a red team és más csoportok munkája nyomán, mert **ténylegesen vannak támadók, akik szoftvereket támadnak**. Ezért mindenkit arra biztat, hogy frissítsen a legújabb verzióra. Hozzáteszi, hogy a következő heti hírlevélben két szolgáltatásmegtagadási sebezhetőség közzétételéről fog összefoglalót írni Lightning-szoftverekben. ## Kód- és dokumentációváltozások ### Bitcoin Core #34566: a multi-signet adatkönyvtár A szokásos kódváltozási szakasz egy Bitcoin Core-elemmel indul. A #34566 a **multi-signet adatkönyvtár támogatást** adja hozzá, és a hírlevél 412-es számában tárgyalt munkára épül. A helyzet az, hogy ha valaki több signet-hálózatot használ, eddig manuálisan kellett több alkönyvtárat építenie. Ez nem volt alapértelmezés szerint támogatott, és a láncadatok ütközhettek. Mostantól a Bitcoin Core lehetővé teszi, hogy több egyedi signet **közös alapkönyvtárat** használjon, de mindegyik **négybájtos hálózatazonosítóval címkézett alkönyvtárba** kerüljön, ami megszünteti az ütközést. A gyakorlati tanács az, hogy aki már beállított több signetet, az a frissítés után **manuálisan nevezze át a könyvtárait** az új formátumra, hogy elkerülje a felesleges újraszinkronizálást. Mike Schmidt egy fogalmi félreértést is eloszlat: sokan úgy gondolják, hogy egyetlen signet létezik, holott **több is lehet**, és bárki futtathat sajátot. Az alapértelmezett signet csak a kényelmet szolgálja. ### BIP-138: tömör titkosítás tárcán kívüli adatokhoz A BIPs-tár két új javaslatot kapott. Az első a #1951-es pull request, amely a **BIP-138-at** vezeti be. A probléma, amelyet megold, a több-aláírásos tárca helyreállításából ered. Tegyük fel, hogy valaki egy kézből háromból aláírásos tárcát állít be másokkal. A helyreállításhoz nem elég a kulcsok megfelelő száma: a **descriptor** vagy tárcafájl is kell. Vagyis hiába mondja a séma, hogy két kulcs elegendő, a harmadik kiterjesztett nyilvános kulcs nélkül a tárca nem rekonstruálható. A kérdés ezért az, hogyan lehet szabványosított **biztonsági mentést** készíteni a descriptorokról és más tárcán kívüli adatokról, például a BIP-388 tárcapolitikákról, amelyet a felhasználó nyugodtan feltölthet a saját gépére vagy felhőmappájába, és **csak ő tudja visszafejteni**. A BIP-138 ötlete az, hogy a **kiterjesztett nyilvános kulcsokból származtatott kulcs** nyissa a titkosított tárcaleírást. Gustavo analógiája szemléletes: van egy titkosított széf, amelyben a descriptor van, és mellette három kisebb szekrény, amelyek mindegyike ugyanazt a kulcsot tartalmazza, de **mindegyik egy adott aláíróhoz tartozik**. Az első aláíró a saját kiterjesztett nyilvános kulcsával kinyitja a saját szekrényét, megkapja a kulcsot, és azzal kinyitja a fő széfet. A következmény az, hogy **bármelyik társszerző képes helyreállítani a leírást a saját seedjéből**, anélkül hogy a többiek kulcsaira szüksége lenne. Mivel a visszafejtés csak nyilvános kulcsú anyagot használ, a tárolt adat nem tartalmazhat privát kulcsokat, és a bizalmasság attól függ, hogy a kiterjesztett nyilvános kulcsok soha nem szivárognak ki. A hírlevél ehhez egy konkrét figyelmeztetést fűz: azok a egyszerű aláírásos tárcák, amelyek egy fiók kiterjesztett nyilvános kulcsát elküldik egy szervernek, például a Ledger és a Trezor asztali alkalmazásai, **lehetővé tennék a szerver számára, hogy megfejtse egy olyan több-aláírásos tárca minden biztonsági mentését, amely ugyanazt a kulcsot használja**. Ezért a BIP azt ajánlja, hogy a több-aláírásos tárcákat olyan fiókokból építsék fel, például BIP-48 vagy BIP-87 szerint, amelyeknek a kiterjesztett nyilvános kulcsát soha nem osztották meg. ### BIP-461: determinisztikus ECDSA-aláírás A második javaslat a #2224-es pull request, amely a **BIP-461-et** vezeti be. A cél a kulcskiszivárgás elleni védekezés. A probléma gyökere a **nonce-választás**. Ha rosszindulatú szoftver választja a nonce értékét az ECDSA-aláíráshoz, akkor a nonce-on keresztül **privát kulcs-anyagot szivárogtathat**, amelyet csak a támadó tud visszafejteni. Gustavo megjegyzi, hogy ehhez mindössze **két aláírás** elegendő annyi kulcs-anyaghoz, hogy a támadó hozzáférjen a tárcához. A hírlevél a 315-ös számában foglalkozott a **Dark Skippy** támadással, amely pontosan ezt a módszert alkalmazza. A BIP-461 megoldása egyetlen determinisztikus ECDSA-aláírási algoritmus, amely biztosítja, hogy **egy adott privát kulcs és üzenet mindig ugyanazt az aláírást adja**. A nonce-okat az RFC 6979 szerint származtatja. Emellett alkalmazza a **low-R grinding** technikát: az aláíró addig próbálkozik új aláírással ugyanarra a tranzakcióra, amíg olyan aláírást nem kap, amelynek R értéke a tartomány alsó felére esik, és így **egy bájttal rövidebben kódolható**. A BIP-461 ezt szabványosítja: mindig retry, amíg az R nem kódolható vezető nulla bájt nélkül, és az s értéket is normalizálja az alsó alakjára. A gyakorlati haszon az összehasonlíthatóság. Mivel a kimenet determinisztikus, egy kulcstulajdonos **ugyanazt a kulcsot betöltheti két független aláíró eszközbe**, ugyanazt az üzenetet aláírhatja mindkettővel, és összevetheti az eredményeket. **Bármilyen eltérés azt jelzi, hogy legalább az egyik eszköz nem követi a specifikációt**, ami a nonce-választáson keresztüli kulcsszivárgási kísérletre utalhat. Gustavo ezt fontos BIP-nek nevezi, mert a felhasználó vagy a fejlesztő ellenőrizni tudja, hogy az implementáció helyes-e. ## Core Lightning: öt javítás a közzétett sebezhetőségek mögött ### #9507: a díjszabályok és az újraindítási ciklus A szokásos kódváltozási szakasz öt Core Lightning-elemet tartalmaz, és ezek most váltak részletesen ismertté, mert a korábbi kiadás forráskódja végre megjelent. Gustavo megjegyzi, hogy az elemek mindegyike több hibát és több javítást tartalmaz. A **#9507** a díjszabályok hiányzó korlátairól és a túlcsordulásról szól. A helyzet háromrészes. Az első hiba az, hogy amikor egy peer splice-ot javasolt, vagy amikor egy kettős finanszírozású nyitást vagy tranzakciót RBF-fel próbáltak növelni, **nem volt felső díjkorlát**, ezért a peer rendkívül magas díjat javasolhatott, és a csomópont elfogadta. A kettős finanszírozású nyitásnál még az alsó korlát is hiányzott. A második hiba a tárolt értékek túlcsordulása. Ha egy nagyon nagy díjérték került a tárolóba, az **nullázódhatott**, ami ahhoz vezetett, hogy a tranzakció nem került be egy blokkba. A harmadik hiba ugyanennek a másik iránya: a nagy érték **állítási hibát váltott ki a `listpeerchannels` RPC hívásakor**, és mivel minden plugin ezt a hívást végzi indításkor, a csomópont **végtelen újraindítási ciklusba** került. Gustavo ezt külön kiemeli, mert az üzemeltető számára ez a legsúlyosabb következmény. A javítás két új korlátot vezet be. A peer-javaslatokra és a háttér-díjbecslésekre **4000 sat/vB abszolút felső korlát** vonatkozik, amely akkor is érvényes, ha az `--ignore-fee-limits` kapcsoló be van állítva. A saját nyitásokra, splice-okra, commitment-frissítésekre és RBF-ekre viszont **400 sat/vB korlát** vonatkozik, amelyet a `--ignore-fee-limits` felül tud írni. A hibás tárolt értékek a frissítéskor javításra kerülnek. Mike Schmidt megjegyzi, hogy a 4000 sat/vB korlát a jelenlegi díjviszonyok mellett a belátható jövőre elegendő, és Gustavo hozzáteszi, hogy az **Eclair implementáció ugyanezeket a javításokat vezette be**, ami hasonlóságot jelez a Lightning-implementációk hiányosságai között. ### #9508: a splice és a csatornanyitás javításai A **#9508** több splice- és csatornanyitási hibát javít, és Gustavo három forgatókönyvet jár végig. Az első az, hogy a Core Lightning a peer `splice_locked` üzenetének megérkezése előtt **már elküldhette a saját aláírásait**. Ha a peer ezután sugározta a függőben lévő splice commitment-tranzakcióját, a Core Lightning **elmulasztotta** ezt a sugárzást, mert nem kapta meg a megerősítést. A javítás az, hogy a Core Lightning mostantól **minden függőben lévő splice funding-kimenetét figyeli**, amint elküldte az aláírásait, és felismeri az elkötést, ha az megjelenik a láncon. Így a peer nem tudja elhitetni a csomóponttal, hogy a splice nem fejeződött be, miközben az már megtörtént. A második forgatókönyv a `tx_abort` üzenet. Ha a peer a splice közben megszakítási üzenetet küld, a splice-ot el kell vetni. **De ha a Core Lightning már elküldte az aláírásait**, a peer már sugározhatta a tranzakciót, ezért a megszakítást nem szabad elfogadni. A javítás szerint a Core Lightning **erőszakos zárást indít**, ha a peer az aláírások elküldése után küld megszakítást. Gustavo kiemeli, hogy a korábbi ellenőrzés azért bukott el, mert a csomópont **a rossz splice-ot nézte**, és nem ismerte fel, hogy az adott splice már aláírásra került. Ráadásul az aláírás elküldését jelző kapcsoló **nem őrződött meg az újraindítások között**, ezért egy újraindítás után a peer ismét elhitethette a csomóponttal, hogy a splice el lett vetve. A harmadik forgatókönyv a nyitási kérelmek korlátozása. Ha egy peer folyamatosan kettős finanszírozású nyitási kérelmeket küld, a csomópont mostantól **bontja a kapcsolatot, ha már három folyamatban lévő csatornanyitási egyeztetés van vele**, az egyszeri finanszírozásúakat is beleértve. A házigazdák azon is elgondolkodnak, hogy a splice és a kettős finanszírozás évekig váratott magára, majd **éppen akkor jelent meg kísérleti formában, amikor a nyelvi modellek elkezdték megtalálni a komplex sémák szélső eseteit**. Mike Schmidt ezt szerencsétlen időzítésnek nevezi. ### #9509: a láncon belüli csatornafeloldás A **#9509** Gustavo szerint a legfontosabb elem, mert a láncon belüli csatornafeloldás hibáit javítja. A fő támadási forgatókönyv az, hogy a támadó **ráveszi a Core Lightningot, hogy egy erőszakos zárást kooperatív zárásként kezeljen**. A mechanizmus három lépésből áll. Az első feltétel az, hogy a peer **nem köteleződött el előzetes shutdown-script mellett** a csatornanyitáskor. Ez opcionális a protokollban. A második lépés az, hogy a peer **shutdown üzenetet küld**, mintha kooperatív zárást indítana, és abban **egy korábban visszavont commitment tranzakció kimeneti scriptjét nevezi meg**. Amint a Core Lightning regisztrálja a shutdown scriptet, a támadó **feladja a kooperatív zárást, és sugározza a visszavont commitment tranzakciót**. A probléma az, hogy a Core Lightning a shutdown üzenet miatt **továbbra is folyamatban lévőnek hitte a kooperatív zárást**, ezért **nem reagált büntető tranzakcióval** a visszavont commitment sugárzására. Gustavo ezt a legfontosabb esetnek nevezi. A javítás az, hogy a Core Lightning mostantól **a locktime és a sequence kódolás alapján azonosítja a commitment tranzakciókat**, mielőtt a kimeneteket ellenőrizné. Korábban csak a kimeneteket nézte, és ha azok egyeztek a kooperatív zárásnál vártakkal, nem reagált erőszakos zárásként. Az új azonosítás felismeri, hogy visszavont commitmentről van szó, és ez teszi lehetővé a büntető tranzakciót. A javítás további szélső eseteket is kezel. Ha egy commitment tranzakció vagy annak leszármazottja megerősítést nyer, majd **átszervezés áldozata lesz**, a Core Lightning korábban abbahagyta a kimenetek figyelését, ezért egy további költés csak az újraindítás után került volna elő. Mostantól a figyelés fennmarad az átszervezés után is. ### #9510 és #9511: bemenetfeldolgozás és naplózás A **#9510** és **#9511** a bemenetfeldolgozás és a naplózás megerősítését szolgálja. Gustavo megjegyzi, hogy ez nem olyan kritikus, mint az előzőek, mert itt nem pénzügyi manipulációról van szó, hanem **összeomlásokról és adatszivárgásról**. Az első hiba egy **puffer-túlcsordulás**, amely a `connectd` démont összeomlaszthatta, ha egy proxy-n keresztül csatlakozva egy csomópont **nagyon hosszú DNS-gépnevet** hirdetett meg. A javítás két oldalon véd: a Core Lightning elutasítja a saját konfigurációjában szereplő érvénytelen gépneveket indításkor, és figyelmen kívül hagyja a hálózati partnerek érvénytelen DNS-címeit a csomópont-hirdetésekben. Emellett a JSON beágyazás **256 szintre** korlátozódik, és a REST-kérések törzse **2 MiB-ra**, mert ezek is összeomlást válthattak ki. Egy BOLT12 TLV-elemzési hiba is javításra került, amely lehetővé tette, hogy egy hibás üzenet összeomlassza a csomópontot. A második pull request egy **veremtúlcsordulást** javít, amelynél egy hitelesítés nélküli REST-kérés nagyon nagy paraméterrel összeomlaszthatta a csomópontot. A naplózási részhez tartozik egy adatvédelmi javítás: a **nyers I/O naplók eltávolításra kerültek a `getlog` kimenetéből**, mert azok **rune-okat** tartalmazhatnak. A rune korlátozott RPC-hozzáférést adó hitelesítési token, ezért a naplóban hagyása szükségtelen hitelesítőadat-szivárgás. A házigazdák egy visszatérő mintát is megvitatnak. Mike Schmidt szerint feltűnő, hogy a Lightning-hibák jelentős része **korlátlan növekedésről vagy hiányzó hosszellenőrzésről** szól. Gustavo egyetért, és mechanikai magyarázatot ad: a Lightningban **nincs közös adat, mint a blokklánc a Bitcoin-hálózatban**, ezért a csomópontoknak mindenről meg kell egyezniük és mindent kommunikálniuk kell, ami számtalan szélső esetet teremt. ### #9513: az összegellenőrzés az xpay-nél A **#9513** egyszerűbb, de gyakorlatilag fontos: az összegellenőrzést javítja, amikor az `xpay` számlát kér le egy BOLT12 ajánlathoz. A hiba lényege az, hogy a Core Lightning **nem ellenőrizte a lekért számla összegét** az engedélyezett összeggel szemben. Ezért a fogadó **nagyobb fizetést kérhetett**, mint amennyit a küldő szándékozott. Ha a küldő nem volt elég körültekintő, egyszerűen többet fizetett a kértnél. A javítás szerint a számlának **vagy egyeznie kell a kért összeggel, vagy ha nem adtak meg összeget, nem haladhatja meg az ajánlat összegét**. A második javított eset a **hagymaüzenet, amelynek válaszútvonala nulla hopból áll**. Ezt bármelyik csomópont elküldhette, és a Core Lightning leállt tőle, mert egy nulla hopos válaszútvonal értelmetlen. Mostantól a csomópont **hiányzóként kezeli** az ilyen útvonalat, és a többi értelmezhetetlen válaszútvonalat is naplózza ahelyett, hogy leállítaná az offers plugint. ## LND: három javítás ### #11198: az AMP-számla törlése A kódváltozási szakasz három LND-elemmel zárul. Az első az **AMP**, vagyis az Atomic Multi-Path Payments, amely Gustavo pontosítása szerint az LND saját implementációja, és nem azonos a több implementáció között szabványosított, többútvonalas fizetéssel. Az AMP sajátossága, hogy a fogadó **újrafelhasználható számlát** bocsát ki, amely **többször kifizethető**. Az AMP-fizetés, akárcsak a többútvonalas, több részre és több útvonalra bomlik, és úgy érkezik meg a fogadóhoz. A hiba az volt, hogy ha **egy fizetési kísérlet egyetlen része meghiúsult**, a fogadó **az egész számlát törölte**, és ezzel **minden más, egyidejűleg futó fizetési kísérletet is elrontott**. A helyes viselkedés az, hogy csak a meghiúsult kísérletet kell elbuktatni. A javítás szerint az LND mostantól az érkező HTLC-t buktatja el, és **csak a meghiúsult készlethez tartozó, korábban elfogadott HTLC-ket** törli. A számla fizethető marad, és a többi elfogadott készlet továbbra is befejeződhet és elszámolható. ### #11146: a BOLT12 offers folytatása Az **#11146** a BOLT12 offers implementációjának folytatása az LND-ben, amelyet a hírlevél több korábbi száma követett nyomon. A 422-es hírlevél a számlakérések és számlák aláírásának és ellenőrzésének támogatását tárgyalta, és most **validált string kódolók és dekódolók** jönnek az ajánlatokhoz, számlakérésekhez és számlákhoz. Ezek a kódolók a feldolgozást a hálózati, feature-, lejárati és aláírás-ellenőrzésekkel egyesítik. Az új `ValidateInvoiceForPayment` funkció ezen felül **a számlát az azt kiváltó kéréshez és ahhoz a csomóponthoz is ellenőrzi, amelyről a fizető azt várta, hogy aláírja**. Gustavo kiemeli ennek fontosságát: **pusztán az érvényes aláírás nem elég**, mert a vak útvonal bármely csomópontja visszaadhat a saját kulcsával aláírt számlát. Mike Schmidt egy követési hibajegy felől érdeklődik, és Gustavo megadja az **LND #10736-ot**, amely a teljes BOLT12-implementáció lépéseit tartalmazza. Az állapot a helyszíni áttekintés szerint az, hogy a codec-rész, vagyis a BOLT12 csomag üzeneteihez és adatszerkezeteihez tartozó rész **majdnem kész**: körülbelül tíz elem már beolvadt, és egy maradt. A következő munka a fogadó oldal, amelyhez már van nyitott pull request, de az a fogadó oldal első eleme csupán. A mérföldkövek felosztása: az A a codec, a B a fogadó oldal, a C a küldő oldal, a D a több hop, az E az ajánlat kifizetése, az F az RPC-paritás. Gustavo megfogalmazása szerint még nagyon hosszú az út, de az első mérföldkő majdnem teljes. ### #11132: a BOLT1 megfelelés helyreállítása Az utolsó elem az **LND #11132**, amely a hírlevél 421-es számában tárgyalt témára épül. Az LND a 421-es hírlevél szerint **bejövő ping-korlátozásokat** vezetett be, kérésekre és válaszokra bontott bucketekkel. Ez viszont **megtörte a BOLT1-megfelelést**, amely előírja, hogy minden érvényes ping üzenetre válaszolni kell. A hiba az volt, hogy egy külön pong-korlátozó **csendben elnyomhatta a kötelező válaszokat**. A javítás helyreállítja a megfelelést: az LND mostantól **minden, a flood-szabályzata által elfogadott érvényes pingre válaszol**. A megvalósítás egyetlen, partnerenkénti bucket, amely **200 tokent** tartalmaz, másodpercenként tíz token feltöltéssel. A nagyobb válaszok több tokenbe kerülnek: egy maximális méretű válasz tíz token, ami **megőrzi a korábbi sávszélesség-korlátot**. A keret kimerülése a kapcsolat bontását vonja maga után. ## Forrás > **Dátum:** 2026-10-01 (a feed pubDate-je) > **Hírlevél:** https://bitcoinops.org/en/newsletters/2026/09/25/ (Newsletter #424, 2026-09-25) > **Epizód oldal:** https://bitcoinops.org/en/podcast/2026/09/29/ > **Transcript:** Whisper (ggml-medium.en), 11 852 szó, 133 szó/perc, 7,3 perc wall-time > **Közvetítő:** anchor.fm → cloudfront.net, M4A (82,7 MB, 89:20), ffmpeg WAV-konverzió után > **Transcript-hiány:** az epizód natív átirata még nem készült el. A podcastoldal forrása a megjelenéskor 20 617 bájt volt, benne „transcription coming soon”. A Bitcoin Optech átiratai 2026-ban medián **5,88 nappal** (n=14, Q1 4,83 / Q3 8,58, tartomány 0,77-16,61 nap) a recap után jelennek meg, és csak 21 százalékuk érkezik 48 órán belül. A #424 transcription commitja a felvétel idején még nem létezett, ezért a Whisper-fallback az alapértelmezett út. > **ASR-torzítások javítva:** „Annette Kirk” / „Omet Kirk” / „Amit” / „Annette” → Ahmet Kurt; „post-condom” / „post-condom security” → post-quantum (visszatérő, minden előfordulás); „Vault 4/8/11/12” / „Vault 11” → BOLT4 / BOLT8 / BOLT11 / BOLT12; „Bold 12” / „Bolt 12” → BOLT12; „MLDSS” / „MLDSA44” → ML-DSA / ML-DSA-44; „MLKEM” / „MLKEM 768” → ML-KEM / ML-KEM-768; „Rust Lightning” → rust-lightning; „Core Liming” / „core lining” → Core Lightning; „L&D” / „LMD” → LND; „archive” → arXiv; „omed-cart/pq-rust-lightning” → ahmet-kurt/pq-rust-lightning; „Amit-Kirch.github.io” → ahmet-kurt.github.io; „Matt Corollo” → Matt Corallo; „Peter Wula” → Pieter Wuille; „dark SCPI” / „dark/skippy” → Dark Skippy; „low error grinding” / „low r grinding” → low-R grinding; „Salvatore Ingalla” → Salvatore Ingala; „Wilder scriptures” → wallet descriptors; „BSBT” → PSBT; „BBSDs” → PSBT; „list pure channels” → listpeerchannels; „ignore fee limits” → --ignore-fee-limits; „get logs” → getlog; „log time” → locktime; „transaction abort” → tx_abort; „splice log” → splice_locked; „comparative close” → kooperatív zárás (cooperative close); „foreclose” → force-close; „reconsider block” → reconsiderblock; „vamping” → bumping; „multi-strick” → multisig; „dump the TX outset” → dumptxoutset; „flock policy” → flood policy; „ballot ping” → érvényes ping; „XPay” → xpay; „YAPs” → Q&A-k; „Annette Kirk, aki... Apula” → a társszerző kiléte a cikkből (Abdul-Salem Beibitkhan, Yacoub Hanna, Abdullah Aydeger) rekonstruálva, a transcriptbeli „Apula” valószínűleg Abdullah Aydeger, de nem megerősített. > **Nem javított, bizonytalan ASR-nevek:** a „VIP434” peer feature-egyeztetés (a hírlevél 410-es számában) azonosítója nem ellenőrizhető innen, ezért a summary nem nevezi meg; az új, géppel olvasható RPC-leírást adó parancs pontos nevét a transcript nem mondja ki, és a hírlevél sem nevezi meg, ezért a summary leírás formájában hozza; a Jan B teljes neve nem derül ki (a transcript „Jan B84”-et mond), ezért rövidítve szerepel. ## Kapcsolódó külső források - **PQLN cikk (arXiv)**: https://arxiv.org/abs/2609.13781 (Ahmet Kurt, Abdul-Salem Beibitkhan, Yacoub Hanna, Abdullah Aydeger) - **PQLN Delving Bitcoin vitaszál**: https://delvingbitcoin.org/t/pqln-post-quantum-security-for-the-bitcoin-lightning-networks-off-chain-surfaces/2893 - **PQLN implementáció**: https://github.com/ahmet-kurt/pq-rust-lightning (rust-lightning fork, ~11 000 sor, 52 fájl) - **Bitcoin Core 32.0 kiadásjelölt és tesztelési útmutató**: a Bitcoin Core Dev Wiki-n - **LDK tükör-tár**: `git.rust-bitcoin.org` (a GitHub-tár leírásából elérhető) - **LND BOLT12 követési hibajegy**: LND #10736 - **Bitcoin Stack Exchange**: a három tárgyalt kérdés forrása (taproot összeg-aláírás, BIP110 újraszinkronizálás, részleges UTXO-készlet) - **roasbeef elemzése**: „Post Quantum Lightning: Layer by Layer” (2026 május, Delving Bitcoin), a PQLN előzménye - **Dark Skippy támadás**: a hírlevél 315-ös számában tárgyalva ## Kapcsolódó belső források - `summaries/bitcoin_optech/2026-09-22_bitcoin_optech_newsletter_423_recap.md` (az előző epizód, ugyanaz a sorozat) - `topics/bitcoin-technology.md` (a wiki Bitcoin-technológiai témaköre, ahova ez a bejegyzés kerül) - A hírlevél 408-as száma, amely a Lightning rétegenkénti posztkvantum-elemzését hozta, és amelyre a PQLN épít - A hírlevél 412-es száma, a multi-signet adatkönyvtárakról - A hírlevél 418-as száma, a BIP110-vitáról - A hírlevél 421-es száma, az LND ping-korlátozásairól - A hírlevél 422-es száma, a BOLT12 aláírás-támogatásról - A hírlevél 351-es száma, a tárcaleírások szabványosított mentésének első felvetéséről - A hírlevél 315-ös száma, a Dark Skippy támadásról - A hírlevél 411-es száma, a libevent eltávolításáról ## Hogyan kapcsolódik a saját rendszerünkhöz Négy ponton érintkezik ez az epizód a saját infrastruktúránkkal és munkafolyamatainkkal. **A posztkvantum-kérdés időzítése és a saját kulcskezelésünk.** A PQLN legerősebb érve nem a jövőbeli kvantumszámítógép, hanem a **ma is folyó rögzítés**: a támadó most gyűjti a forgalmat, és később fejti vissza. Ez a minta közvetlenül érvényes minden olyan kulcsra, amelyet ma hosszú távra használunk. A saját Nostr-kulcsaink és a hozzájuk tartozó titkok ugyanebbe a kategóriába esnek: a mai titkosított csatorna tartalma nem védett a jövőbeli visszafejtés ellen, ha a mögöttes kulcscsere klasszikus. Az epizód nem ad receptet erre, de a kategória felismerése hasznos: **a hosszú életű titok posztkvantum-kitettsége ma is fennáll**, nem csak akkor, amikor a hardver megérkezik. **A konzervatív kiterjesztés mint tervezési minta.** A PQLN alapszemlélete az, hogy minden klasszikus mechanizmus a helyén marad, és az új primitívek mellé kerülnek, hogy a hálózat ne szakadjon szét. Ez pontosan az a minta, amelyet a saját rendszerünkben is követünk: az új rétegek hozzáadása a meglévő működés megbontása nélkül, és a visszafelé kompatibilitás mint elsődleges megkötés. A szerző külön kiemeli, hogy az interoperabilitás volt a legdrágább követelmény, és hogy enélkül az implementáció sokkal hamarabb elkészült volna. Ez hasznos emlékeztető: **a kompatibilitás ára valódi, és érdemes tudatosan vállalni, nem véletlenül fizetni meg**. **A „trust-on-first-use” korlát párhuzama.** A PQLN pinning-mechanizmusa csak azokat a csomópontokat védi, amelyek már találkoztak egymással egy kvantumszámítógép megjelenése előtt. Ez a TOFU-minta pontosan az, amit a saját SSH- és hosztkulcs-kezelésünkben is alkalmazunk, és ugyanaz a gyenge pontja: **az első találkozás nem védett**. Az epizód megfogalmazása szerint a szerző maga is nyitott problémának nevezi, és a közösség véleményét kéri. A saját infrastruktúránkban ez a kérdés konkrétan a Mac mini és a VPS közötti SSH-kapcsolatnál merül fel. **A determinisztikus aláírás és a saját eszközeink ellenőrzése.** A BIP-461 gyakorlati haszna az, hogy **két független aláíró eredményét össze lehet vetni**, és az eltérés támadást vagy hibás implementációt jelez. Ez egy általános ellenőrzési minta, amely túlmutat a kriptográfián: ha ugyanazt a bemenetet két független úton dolgozzuk fel, és az eredmények eltérnek, akkor legalább az egyik út hibás. Ez a saját média-pipeline-unkban is működik: az `output_integrity_gate.py` és az `auto_review.py` két különböző elven méri ugyanazt a kimenetet, és a kettő együtt többet ér, mint bármelyik önmagában. Az epizód ezt a kriptográfiai esetben pontosan így indokolja: az egyetlen eszköz önmagában nem tudja bizonyítani a saját helyességét. **A mérés mint a negatív állítás ellenszere.** Ez az epizód technikailag ugyanabba a csapdába futott, amelyet az előző feldolgozásnál dokumentáltunk: a sorozat korábbi összefoglalója Whisper-rel készült, és a kísértés az volt, hogy ezt a mintát örököljük. A különbség az, hogy most **megmértük a késleltetést a site-repo commitjaiból**, és az eredmény (medián 5,88 nap, a #424 transcription még nem létezik) igazolja a döntést. A negatív állítás tehát nem örökölt, hanem mért: ez az a különbség, ami a helyes döntést a véletlenül helyes döntéstől elválasztja.