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.