Bitcoin Optech. Newsletter #423 Recap (2026-09-22)

Epizód: bitcoin_optech #423 Dátum: 2026-09-22 Házigazdák: Mark "Murch" Erhardt, Gustavo Flores Echaiz, Mike Schmidt Vendégek: Davidson Souza (Utreexo, Floresta fejlesztő), Eric Price (MARA, bányászati pool kutatás), PortlandHODL (AnchorWatch, Bitcoin oktató) Forrás: https://bitcoinops.org/en/podcast/2026/09/22/ Hírlevél: https://bitcoinops.org/en/newsletters/2026/09/18/ Media: https://anchor.fm/s/d9918154/podcast/play/126159237 Transcript: Whisper (medium.en), 17 916 szó, 13,5 perc wall-time Auto-review score: 0.90 (auto_approved)

Bevezetés és a lényeg

A Bitcoin Optech 423-as hírlevelének feldolgozása három vendéggel, három egymástól független technikai száron. A leghosszabb és legfontosabb szál a Utreexo IBD-gyorsítás: Davidson Souza bemutatja, hogyan lehet a kezdeti blokklánc-letöltést a korábbi öt terabájtos sávszélesség-igényről néhány órára, sőt telefonon is elvégezhetővé tenni. Ez nem finomhangolás, hanem a probléma újratervezése: a bizonyítékok ellenőrzését teljesen elhagyják az IBD alatt, és a validálást a SwiftSync-re bízzák.

Eric Price (MARA) a vardiff problémáját tárgyalja: a bányászati poolok nehézség-szabályozója ördögi körbe kerül, amikor egy bányász lassulni kezd, mert a kevesebb share kevesebb információt jelent a kontrollernek. A megoldás az idő múlásának bevonása a mérésbe, és az aszimmetrikus szabály, amit a Bitcoin Cash korábban megpróbált és visszavont. Érdekes módon a pool kontextusában ugyanez a technika biztonságos, mert nincs fix jutalom share-onként.

PortlandHODL az Entropy Lab eszközt mutatja be: hardveres wallet-ek és entrópia-generátorok kimenetének validátorát, amit gyakorlatilag AI-val építettek meg két hét alatt, körülbelül 2000 dollár kreditből. Ez a projekt szándékosan vállalja az AI-vezérelt fejlesztést és biztonsági átvizsgálást, és ezzel a hozzáállással a saját fejlesztési gyakorlatunkra is tanulságos.

A hírlevél hátralévő része a szokásos: az unspendable internal keys draft BIP, a BitBoxApp Spark-integrációja (a statechain trade-offokkal), a Covenants.diy szerkesztő, és egy kifejezetten biztonsági javításokban gazdag hét az Eclair, a Bitcoin Core, az LND és a BDK körül.

A legfontosabb tanulságok:

• Az Utreexo IBD-je az assumed-valid SwiftSync-kel 90 percre szorítható egy jó gépen, és 4-5 órára egy Pixel telefonon
• A törlési overhead trükkje: ha előre ismert a költési magasság, a törlés már a hozzáadáskor alkalmazható, és csak a root állapotot igényli
• A vardiff ördögi köre: kevesebb share, kevesebb információ, lassabb reakció. Az idő bevonása töri meg
• Az aszimmetrikus nehézség-szabály a láncon megnövelte a BCH kibocsátását, a poolban viszont ártalmatlan
• A Stratum V2 csatlakozáskor átadható nominális hashrate megszünteti a share-vihart
• Az Entropy Lab két hét alatt, ~2000 dollár AI-kreditből készült el, emberi fejlesztővel ez hónapok lettek volna
• Az AI biztonsági átvizsgálása a jól auditált kódbázisokon nem talált sokat, a kevésbé átnézetteken annál többet
• Az Eclair 0.14.3 patch kiadás többek között egy on-the-fly funding pénzvesztési forgatókönyvet javít

Összegzés

A 423-as epizód technikailag a Utreexo körüli áttörésről szól, és a többi szál ehhez képest másodlagos. Davidson Souza azt mutatja meg, hogy a kezdeti blokklánc-letöltés költsége nem természeti adottság, hanem a bizonyíték-ellenőrzési döntés következménye. Ha a bizonyítékokat elhagyjuk az IBD alatt, és a validálást a SwiftSync-re bízzuk, akkor a letöltés a hálózati sávszélesség korlátjáig gyorsítható. Ez a Bitcoin node-ok hozzáférhetőségét változtatja meg: olyan eszközökön is fut, ahol eddig reménytelen volt.

A második tanulság a vardiff esete, és módszertanilag érdekesebb, mint amennyire a téma súlya indokolná. Eric Price nem egy új algoritmust talált ki, hanem észrevette, hogy a kontroller egy visszacsatolási hurok, ami akkor válik önmaga ellenségévé, amikor a bemenete megritkul. A megoldás az üresség eseményként való kezelése. Ugyanezt a problémát a Bitcoin Cash már végigjárta a lánc szintjén, és a tanulságok közvetlenül átvihetők. Az aszimmetrikus szabály viszont a láncon káros volt, a poolban ártalmatlan, és ennek az oka a share-elszámolás arányos volta.

A harmadik tanulság az Entropy Lab, és ez a saját munkánk szempontjából a legérdekesebb. PortlandHODL nyíltan vállalja, hogy a projektet AI-val építették, és a biztonsági átvizsgálást is nagyrészt AI-ra bízták. Az indoklás nem ideológiai, hanem költség- és időalapú: két hét és 2000 dollár kredit szemben a hónapokkal. A projekt emellett explicit módon kitér a felelősség kérdésére is, és nem mainnetre szánja az eszközt.

A hírlevél kódrovata szokatlanul gazdag: hét Bitcoin Core PR, köztük két descriptor-kompatibilitási hiba, egy prunolási versenyhelyzet és egy wallet-összeomlás javítása. Az Eclair 0.14.3 pedig négy elkülöníthető biztonsági javítást tartalmaz, amelyek közül az on-the-fly funding CLTV-hibája a legfigyelemreméltóbb.

Utreexo: az IBD áttörése és a SwiftSync-átállás

Davidson Souza a Floresta fejlesztője, és az epizód első, leghosszabb szakaszát a Utreexo kezdeti blokklánc-letöltés (IBD) körüli fejlesztéseinek szenteli. A beszélgetés a legalapvetőbb fogalmak tisztázásával indul, mert a téma könnyen félreérthető.

A Bitcoin node-nak minden blokk ellenőrzésekor tudnia kell, hogy a bemenetek korábbi tranzakciókban létrehozott kimenetek voltak-e, és addig nem költötték-e el őket. Erre szolgál a UTXO-készlet, ami csak az élő, el nem költött kimeneteket tartalmazza. Ez a készlet a fő szűk keresztmetszet: ahogy nő, az IO-műveletek száma is nő, és a gyenge SSD-vel vagy kevés memóriával rendelkező eszközökön a szinkronizálás akár egy hónapig is eltarthat. Davidson szerint ez ma valós panasz a felhasználóktól, nem elméleti probléma.

Murch itt pontosítást kér, és ez a pontosítás fontos. Davidson azt mondta, hogy a Bitcoin nem tart UTXO-készletet. Murch szerint ez így nem igaz: a Bitcoin modellje az egész tranzakció-kimenet készletet tárolja, és a UTXO-készlet ennek részhalmaza. Tehát a Bitcoin rendelkezik UTXO-készlettel, csak sokkal több adatot is tárol mellette. Az Utreexo viszont tényleg nem tart ilyet, és ez a megkülönböztető jellemzője. Davidson elfogadja a korrekciót, és a pontos megfogalmazás az, hogy a Bitcoin nem rendelkezik explicit UTXO-készlet absztrakcióval, de a kimenetek és bemenetek tábláinak különbsége kiadja azt.

Az Utreexo megoldása az, hogy a teljes készlet helyett egy akkumulátort tart, ami a készlet tömör reprezentációja. Ez kevesebb mint egy kilobyte, jelenleg inkább a fele, és elfér a processzor gyorsítótárában. A trade-off világos: több sávszélességet és több CPU-t használ, mert minden tranzakcióhoz bizonyítékot kell fogadni arról, hogy a hivatkozott kimenetek léteznek az akkumulátorban. Cserébe nem kell a teljes UTXO-készletet tárolni, ami a Bitcoin Core-nál jelenleg körülbelül 11 gigabájt, és nem kell gyors SSD vagy sok memória. A jelenlegi kód már fut okostelefonon és egykártyás számítógépeken is, mert az IO-szűk keresztmetszet megszűnt.

A probléma a bizonyítékok méretével van. A régi Utreexo minden blokkhoz bizonyítékot kért minden elemre, és a legrosszabb esetben az overhead eléri a száz százalékot: hétszáz gigabájt blokkhoz hétszáz gigabájt bizonyíték tartozik, amiből az IBD alatt több mint öt terabájt letöltés adódik. Ez elfogadhatatlan, különösen ott, ahol a sávszélesség drága.

Az első próbálkozás a gyorsítótárazás volt, kézenfekvő módon. A UTXO-knak van egy kellemes tulajdonságuk: exponenciálisan valószínűbb, hogy nem sokkal a létrehozásuk után költik el őket. Ha csak az utolsó néhány száz blokk UTXO-it tartod meg, az már lefedi a költések mintegy nyolcvan százalékát. A kísérlet az adatigényt a lánc méretének harminc-negyven százalékára csökkentette, ami fejlődés, de még mindig kétszáz-háromszáz gigabájt. Tovább javítani csak még több memóriával lehetett volna, ami egy ponton túl értelmetlenné teszi a Utreexo használatát.

Az áttörés egy 2025-ös személyes találkozón született, ahol a csapat mellett időnként külső közreműködők is jelen voltak. A kérdés az volt, hogy a törlést már a hozzáadáskor figyelembe lehet-e venni. Az Utreexo fák halmaza, és a törlés úgy működik, hogy a testvér-csomópontot felmozgatjuk a szülő helyére. Ha tudod, hogy egy UTXO-t egy adott blokkmagasságnál el fognak költeni, akkor ezt a műveletet már a hozzáadásnál alkalmazhatod, és az elem egyenesen arra a helyre kerül, ahol a szokásos hozzáadás-törlés sorozat után lenne. A trükk kulcsa, hogy a hozzáadási műveletek csak a root állapotot igénylik, tehát elég a kevesebb mint egy kilobyte-os gyökér, és a költési információ birtokában a végeredmény előre kiszámítható.

Murch rögtön rákérdez a látszólagos ellentmondásra: ha a fa tartalmát megváltoztatjuk, a belső csomópont hasítja és ezzel a gyökér is változik, tehát az átmeneti állapotokra adott bizonyítékok érvénytelenné válnak. Davidson egyetért, és ez a lényeg: az átmeneti állapotok érvénytelenek, de nem is kell őket ellenőrizni, mert ebben a fázisban éppen a bizonyítékokat akarjuk kihagyni. Amit garantálni kell, az az, hogy az IBD végén, az utolsó blokk elérésekor az akkumulátor megegyezik a szokásos műveletekkel kapottal.

Ehhez a SwiftSync-re van szükség, mert az már megmondja, hogy a költések érvényesek voltak-e. A SwiftSync az úgynevezett hint map-ből szolgáltatja azt az információt, hogy egy kimenetet mikor költöttek el, és Davidson algoritmusai ezt az információt veszik át, hogy a hozzáadáskor már elvégezzék a frissítéseket. Az IBD alatt a validálás garanciája a SwiftSync-től származik, a steady state elérése után pedig a Utreexo veszi át ezt a szerepet.

Az eredmények figyelemreméltóak. Egy gyors gépen a párhuzamosított implementációval a szinkronizálás kilencven perc alatt lefutott, egészen pontosan kilencven perc és negyvenöt másodperc alatt. A Jose által készített implementáció nyolcszáz megabit/másodperces kapcsolaton egy óra harminc percet vett igénybe, Davidson saját, rosszabb kapcsolatán három órát, és egy Pixel telefonon Wi-Fi-n keresztül négy-öt órát. A rendszer gyakorlatilag a hálózati sávszélesség korlátjáig megy, és a megfogalmazás szerint minden elérhető hálózati kapcsolatot telít.

A bridge node-ok kérdése külön szál. A történelmi bizonyítékok tárolása nagyon drága, és a csapat azzal a feltevéssel dolgozik, hogy ezekre senkinek nem lesz szüksége. Davidson egy Bitcoin Core plugint készített a Bitcoin Kernel használatával, ami körülbelül húsz perc alatt szinkronizál, és egy régi, használt irodai minigépen is harminc perc alatt felépítette a fát kilencszázezer magasságig. Az érvelés szerint a régi úton haladva semmi nem nyerhető, mert a SwiftSync validációs szempontból ugyanazt adja, csak több sávszélességet, több számítást és több IO-t igényel.

Ezért a projekt nem alternatív szinkronizációs módként kezeli az új megközelítést, hanem teljes újraírást hajt végre, amelybe az assumed-valid feltevés beépül. Ez magyarázza azt is, hogy miért nem frissültek a BIP-javaslatok egy évig: Davidson a 181-est jelentős részben újra kell írja, a 182-eshez és 183-ashoz kisebb frissítései vannak, de a közösségi átvizsgálás még hátravan. A munka következő fázisa a nem assumed-valid verzió, ami lényegesen nehezebb, különösen a memóriaigény alacsonyan tartása miatt, de az architektúra már megvan a blokkok párhuzamos feldolgozásához.

Ahol be lehet kapcsolódni: a Floresta repóban van egy pull request, ami az assumed-valid részt implementálja, és a következő hetekben egy nem valid verzióra is nyílik draft PR. A Bitcoin Core plugin a saját PR-jában található, a GetFloresta blog pedig a közeljövőben technikai posztokat közöl, köztük Jose beszámolóját az assumed-valid tapasztalatairól.

• A UTXO-készlet növekedése miatt az IBD gyenge hardveren akár egy hónapig tart, ez a valódi kiindulópont
• Az Utreexo akkumulátora kevesebb mint egy kilobyte, elfér a CPU gyorsítótárában
• A naiv Utreexo a legrosszabb esetben száz százalékos bizonyíték-overheadot szenved el, ami öt terabájt letöltést jelent
• A gyorsítótárazás harminc-negyven százalékra csökkentette az adatigényt, de ez még mindig kétszáz-háromszáz gigabájt
• Az áttörés: a költési magasság ismeretében a törlés már a hozzáadáskor alkalmazható, és csak a root állapotot igényli
• Az átmeneti állapotok érvénytelenek, de nem kell őket ellenőrizni, mert az IBD alatt a SwiftSync validál
• 90 perc 45 másodperc gyors gépen, 4-5 óra egy Pixel telefonon Wi-Fi-n
• A történelmi bizonyítékok elhagyhatók, a bridge node húsz perc alatt szinkronizál

A lényeg az, hogy az IBD végén az akkumulátor megegyezik azzal, amit a szokásos hozzáadás-törlés sorrend adna. Az átmeneti állapotok érvénytelenek, de nem is ellenőrizzük őket, mert ebben a fázisban éppen a bizonyítékokat hagyjuk ki.

Murch pontosítása: a Bitcoin modellje az egész tranzakció-kimenet készletet tárolja, a UTXO-készlet ennek részhalmaza. Tehát a Bitcoin rendelkezik UTXO-készlettel, az Utreexo az, ami nem.

Vardiff: a lassuló bányászok és a visszacsatolási hurok csapdája

A második szál Eric Price (MARA) kutatása a vardiffról, ami a bányászati poolok nehézség-szabályozója. Az epizódban ez a hírlevél első hírként szerepel, bár a felvételen a Utreexo-szakasz előbb került sorra Davidson menetrendje miatt, amit a házigazdák nyíltan el is ismernek.

Eric először a kontextust rakja le, mert a téma a legtöbb hallgatónak idegen. A bányászati pool blokkokat próbál termelni a láncra, és ehhez egy csomó közreműködő dolgozik kisebb részfeladatokon, amelyek potenciális blokkok lehetnek. A bányászok feladatokat oldanak meg, és a pool folyamatos share-áramlást kap tőlük. A pool célja egy egyenletes ütem, tipikusan másodpercenként körülbelül hat share. Mivel a bányászok különböző teljesítményűek, bevezetnek egy közvetett réteget, a nehézséget, ami megváltoztatja, mennyi idő alatt születik megoldás. A pool méri, milyen gyorsan kap válaszokat, összeveti a kívánt gyakorisággal, és aszerint állítja a feladat nehézségét. A lánc szintjén hasonló a helyzet, csak ott tíz percenkénti blokk a cél, és kéthetente történik az állítás.

A probléma akkor jelentkezik, amikor egy bányász lassulni kezd. Ennek lehet áramszünet az oka, napelemes telepnél a termelés esése, hardverhiba, vagy szándékos hashrate-csökkentés. A kontroller ilyenkor kevesebb share-t lát, ami kevesebb információt jelent a valódi hashrate-ről. Mivel a nehézség állítása adott számú share után történik, a lassulás megnöveli a következő állításig tartó időt, miközben a becslő bizonyossága csökken. Ez ördögi kör: az eseményeknek kellene kihúzniuk a rendszert a problémából, de éppen az események ritkulnak. Ha a bányász folyamatosan csökkenő hashrate-tel fut, előfordulhat, hogy nem ér össze annyi share-t, amennyi az állításhoz kell, és a pool leválasztja, mielőtt a helyzet rendeződne.

Eric szerint a megoldás az idő múlásának érzékelése a cikluson belül. Az egyetlen mód erre az, hogy ürességet injektálunk a mérési ablakba: észre kell venni, hogy vannak rések az események között, és az események hiányát magát is eseményként kell kezelni. Ez a gondolat vezet el a lánc szintjére, ahol ugyanez a hiba már többször megjelent. A legfrissebb példa a Luke Dash Jr. fork: a hasadáskor a fork magas nehézségen ragadt, a bányászok nem tudtak blokkot termelni, és éppen ezért nem tudták kiváltani a nehézség csökkentését. Ugyanez történt a Bitcoin Cash első jelentős hasadásánál, amit akadémiai irodalom is követett, és ahol több éven át többször módosították a nehézség-szabályozót.

A BCH első próbálkozása az emergency difficulty adjustment volt, egy hard fork, ami bizonyos várakozási idő után automatikusan csökkentette a nehézséget. Ez működött, de súlyos mellékhatása volt: a bányászok szándékosan nem termeltek blokkokat, hogy kiváltsák a csökkentést, ami oszcilláló hashrate-hez vezetett. A pool kontextusában ez a fajta ellenséges viselkedés nem fenyeget, mert a bányász és a pool ugyanazon az oldalon áll.

A BCH történetének végső fejleménye az ASERT nevű algoritmus, amit a becslő végső formájaként írnak le. Eric három részre bontja a vardiffot: a becslőre, amelynek a bányász valódi hashrate-jét kell megtippelnie, a küszöbre, ami eldönti, kell-e állítani, és az állítás mértékére. A BCH-irodalom a becslő részre fókuszált, és arra jutott, hogy az idő bevitelének legjobb módja az exponenciálisan súlyozott mozgóátlag. Ez egyszerre oldja meg a rövid és a hosszú ablak problémáját: a hosszú ablaknál sok adat van, ezért nincs visszaverődés, a rövid ablaknál gyors a reakció, de nem tudni, hogy a változás forrása a bányász-e vagy a becslő saját korábbi döntései. Murch egy szemléletes példát ad: ha egyszerű átlagot használsz, és ötven gyors blokk után ötven lassú jön, a visszatérés is ugyanilyen lassú, mert előbb egy lassú és kilencvenkilenc gyors, majd kettő és kilencvennyolc lesz az arány. Az exponenciális mechanizmus a régi minták hatását csillapítja, miközben az ablak tartalma korlátlanul nő, de az ablak mérete rögzített marad. Ez azért fontos, mert az SV2 vardiffjában ma is él egy hiba, ami a korlátlan ablakkal függ össze, és az exponenciális változat ezt megszünteti.

Az aszimmetrikus szabály külön szál. Eric felfedezte, hogy ha a szabály könnyebben emeli a share-rátát, mint csökkenti, akkor a gépek tovább maradnak életben. Ez elsőre ellentmondásosnak tűnt, de a mechanizmus érthető: a cél alatti share-rátánál a kontroller kevesebb információval dolgozik, és nehezebben látja, mi történik. A lánc kontextusában ugyanez a szabály viszont káros volt, mert állandó eltolódást hoz létre, ahol a share-ok rendre gyorsabban jönnek a kelleténél, ami a BCH-nál a kibocsátási ütem felgyorsulását eredményezte. Ez konszenzus-szempontból elfogadhatatlan volt. A poolban viszont az elszámolás arányos értékű share-okkal történik, a magasabb nehézségű share többet ér, és nincs fix jutalom share-onként, ezért az aszimmetria nem jár ezzel a következménnyel. Eric megfogalmazása szerint ugyanaz a technika, amit a BCH-nál megpróbáltak és visszavontak, a pool kontextusában nyugodtan alkalmazható.

Murch összegzése szerint a megoldás azért nem működött a BCH-nál, mert ott a share-ok maguk termelték a blokkjutalmakat, így a kibocsátási ütem megváltozott. A poolban viszont minden share csak a saját nehézségének súlyával számít, ezért az aszimmetrikus megoldás minden itteni problémát megold.

A gyakorlati hatás: reszponzívabb bányászok és kevesebb akadozás, amikor valami történik a bányászflottával. A pooloknak nincs konszenzusuk, tehát egyszerűen frissíthetik a szoftvert az új számítási sémára.

A beszélgetés második fele két konkrét üzemeltetési tapasztalatra tér át. PortlandHODL felveti, hogy a MARA-nál a vardiff leginkább indításkor okoz gondot, amikor egy telephely nagy számú bányásszal egyszerre csatlakozik és elárasztja a forgalomirányítókat. Emellett rákérdez a nehézségek értékére: a firmware-ek gyakran csak kettő hatványait engedik beállítani, ami megnehezíti a pontos cél elérését. Eric megerősíti, hogy ez valós jelenség, és úgy tűnik, a CGMiner nyílt forráskódú bányászati szoftverből ered, ami a firmware-ek belsejében fut. A poolok ehhez alkalmazkodtak és konzerválták a korlátot, ami viszont rontja a vardiffot, mert elveszi a variabilitást és rontja a bányász láthatóságát. Eric szerint ez örökölt hiba, amit fel kell számolni, és az SV2-ben már nem látja.

A share-vihar problémájára az SV2-nek van beépített megoldása: a csatlakozáskor át lehet adni a nominális, úgynevezett matricás hashrate-et, ami feed-forwardként működik, és így a konvergenciaidőre sincs szükség. Ha viszont a lassulás miatt újracsatlakozásra kerül sor, a share-vihar visszatér, ezért a természetes hashrate betáplálása kulcsfontosságú.

A curtailment esetét Portland és Eric részletesen kivesézi. Az energiaszabályozási korlátozásoknál egyetlen kapcsolóval több ezer gép esik ki, és mivel a proxy egy kapcsolatba aggregálja őket, a csökkenés hirtelen és nagymértékű lesz, ami pontosan az a forgatókönyv, ahol a javított vardiff értéket ad. A korlátozások mérete változó, öt százaléktól akár kilencven-kilencvenöt százalékig terjedhet. Eric szerint a mai rendszerekben nincs mód részleges korlátozásra, a gépeket egyszerűen lekapcsolják és visszakapcsolják, holott részleges megoldás is lehetséges lenne.

• Az eseményvezérelt hurok a lassulásnál önmaga ellen dolgozik: kevesebb share kevesebb információt ad
• A megoldás az üresség eseményként kezelése, az idő múlásának bevonása a mérésbe
• A Luke Dash Jr. fork és a BCH hasadása ugyanezt a hibát mutatta a lánc szintjén
• A BCH emergency difficulty adjustmentje oszcilláló hashrate-hez vezetett a szándékos nem-termelés miatt
• Az ASERT az EWMA-t használja, ami a rövid ablak gyorsaságát és a hosszú ablak kontextusát ötvözi
• Az SV2 vardiffjában ma is él a korlátlan ablak hibája
• Az aszimmetrikus szabály a láncon felgyorsította a kibocsátást, a poolban viszont ártalmatlan
• A kettő hatványaira kényszerített nehézség CGMiner-örökség, ami rontja a vardiffot
• A Stratum V2 csatlakozáskor átvett nominális hashrate megszünteti a share-vihart
• A curtailmenteknél nincs részleges korlátozás, pedig a vardiff éppen ott hasznos

Az eseményeknek kellene kihúzniuk a rendszert a problémából, de éppen az események ritkulnak. Ezért kell az ürességet is eseményként kezelni.

Ugyanaz a technika, amit a Bitcoin Cashnél megpróbáltak és visszavontak, a bányászati pool kontextusában nyugodtan alkalmazható, mert nincs fix jutalom share-onként.

Entropy Lab: hardveres wallet-validátor AI-val építve

PortlandHODL (AnchorWatch) mutatja be az Entropy Lab eszközt, ami a szakasz címében offline kulcskalkulátorként szerepel. A projekt kiindulópontja egy gyakorlati bizalmi probléma: hogyan lehet validálni és ellenőrizni a különböző hardveres tárcák és entrópia-generátorok kimeneteit a determinisztikus oldalon. A hardveres tárcák például kockadobást kínálnak a felhasználóknak, de honnan tudod, hogy a konverzió helyes, és hogy a kapott seed szavak valóban a dobott értékeknek felelnek meg?

Portland összeköti ezt a Coldcard incidenssel: miután kiderült, hogy a véletlenszerűség nem garantált, természetes reakcióként mindenki a kockadobás felé fordult. A következő logikus kérdés viszont az lett, hogy a hardveres eszközben végzett konverzió helyes-e. Az eszköz célja tehát a viselkedés ellenőrzése.

A projekt eredete Mr. Hodl az X-en, aki Portland szavai szerint nem programozó, hanem egyszerűen Claude-ot használta, és egy HTML fájlt generáltatott magának a kockadobás-seed konverzióhoz. Innen indult a terjedés: mi mást lehet még ellenőrizni? A PSBT-ktől kezdve a különböző entrópia-formákon át a wallet.dat fájl generálásáig, ami lehetővé teszi a pub kulcsok ellenőrzését és a BlueWallet helyettesítését helyreállítási eszközként.

Portland itt egy nagyon határozott figyelmeztetést tesz, és ezt érdemes szó szerint venni: az eszköz száz százalékosan nem mainnet Bitcoinhoz készült. TPUB-okat és XPUB-okat számol, de kizárólag létező dolgok ellenőrzésére való. Senki ne tegyen bele valódi seed phrase-t vagy valódi Bitcoint érintő adatot. Új hardveres tárca tesztelésénél, valódi fedezet nélküli kockadobások kipróbálásánál elfogadható, de a seed phrase-t utána törölni kell.

A funkcionalitás később jelentősen kibővült: multisig, descriptor-készítő, PSBT-szerkesztő és validátor, BIP-85, silent payments, vanity address generátor. Ehhez jön az RFC 6979 szerinti nonce-ellenőrzés, amivel a PSBT-aláírásokról lehet megállapítani, hogy determinisztikusan generálódtak-e és nem szivárogtatnak-e információt. A Dark Skippy volt erre a példa. Murch itt egy pontosítást fűz hozzá: azonos nonce-t azonos üzenethez használni biztonságos, azonos nonce-t viszont különböző üzenethez használni a privát kulcs kiszivárgását jelenti.

A technológiai alap rust-bitcoin, ami Wasm WebAssembly-re fordítható, így a libsecp256k1 kód közvetlenül beépíthető a weboldalba. Portland külön kiemeli Jonas Nick és munkatársai libsecp256k1 munkáját, amit kiválónak nevez. Az AI ezeket a kötéseket illesztette össze a specifikációknak megfelelően. Egy új eredmény a közvetlen Bitcoin Core wallet.dat JavaScript library, amivel mnemonikból vagy deskriptorból wallet.dat fájl állítható elő.

A legérdekesebb rész az AI szerepének indoklása. Portland szerint a döntés költség és hozzáférhetőség alapján született. Az eszköz funkcionalitását kézzel begépelve hónapokig tartott volna, ehelyett két hét alatt készült el. A teljes eszközkészlet költsége körülbelül kétezer dollár AI-kredit volt, míg egy szenior fejlesztőnél ez egy-két napi munka díja, és még akkor sem lett volna kész. Portland emellett hivatkozik a Bitcoin Red Team eredményeire, amelyek szerint az AI biztonsági szempontú kódelemzése nemhogy felveszi a versenyt az emberrel, hanem jelentős mértékben felül is múlja. A hosszú ideje gondozott, tehetséges fejlesztőkkel dolgozó kódbázisok, mint a Bitcoin Core vagy a libsecp256k1, jól bírták az AI-elemzést, a kevésbé átnézett, kevesebb tehetséghez jutó projektek viszont nem.

Murch itt egy másik szempontot emel be: az átvizsgálás mellett a tesztelési stratégiák is fontosak, és a Bitcoin Core kifinomult tesztelési eszközkészletet épített ki. Szerinte ezeket AI-val sokkal könnyebb bootstrappelni, így aki eddig nem foglalkozott fuzz testinggel, annak most érdemes elkezdenie. Portland megerősíti, hogy az Entropy Lab a CI-ban is használ fuzzingot, külső futtatókkal, és hogy egy nyílt súlyú modell (Kimi K2) segítségével gyakorlatilag három dollárért építettek teljes fuzzing suite-ot. Az emberi átvizsgálás továbbra is szükséges, de Portland szerint az AI elegendő alternatívát nyújt a biztonsági átvizsgálásra és a tesztkeretrendszer generálására, különösen olyan nyílt forráskódú projekteknél, amelyek nem férnek hozzá a legjobb szakértőkhöz.

A csapat ezt a hozzáállást félig viccesen "Team Ooga Booga"-ként nevezi el, utalva arra, hogy ők az egyszerű primitív lények, az AI-modellek pedig a munka érdemi részét végzik. Az egyik házigazda meg is jegyzi, hogy akkor hústestű proxyk. Portland erre azt válaszolja, hogy azok már korábban is voltak, de a megjegyzés komolyabb rétege az, hogy más projektek (reardoncode az rbitcoin.org-gal, az Ibis wallet) is ebbe az irányba mennek.

Portland elhatárolja magát a szélsőségektől: szerinte nem minden útvonalra jó ez a modell, és egy éles, termelési környezetben nem feltétlenül bölcs döntés száz százalékban az AI-ra támaszkodni, különösen ha a csapatban nincs technikai kompetencia. Az Entropy Lab esetében viszont a szűkös költség- és időkeret gyakorlatilag kényszerítette ezt a döntést.

A beszélgetés végén a felelősség kérdése kerül elő, és ez a szakasz filozófiailag a legérdekesebb. Portland elmondja, hogy ő maga használta az Entropy Labot mainnet Bitcoinnál, egészen pontosan akkor, amikor a Luke Dash Jr. forkról származó érméket próbálta szétválasztani, és ellenőrizni akarta, hogy a PSBT bemenete a TXID az új láncból származik-e. Az eszköz jelezte a problémát, amit ő megoldott, és ezért hálás. Ennek ellenére nem ajánlja senkinek a mainnet használatot, mégpedig azért, mert nem akar felelősséget vállalni, ha probléma adódik. Hivatkozik Rob Hamilton posztjára, miszerint egy számítógép sosem lehet felelős, és a rossz kódért végső soron az felel, aki megírta és kiadta. Portland szerint minden környezetben szükség van arra, hogy valamire rá lehessen mutatni: ez volt a probléma.

Emellett technikai okot is ad: nincs formális kiadás, nincs v0.x verzió, csak egy folyamatosan változó master branch, ahol naponta mozognak a dolgok. Murch ehhez hozzáteszi, hogy a nyílt forráskódú licencek többsége eleve kizárja a garanciát, és ez szándékos, mert a felhasználó nem fizet érte, viszont cserébe a felhasználónak is részt kell vennie az ellenőrzésben és az auditban. Portland megerősíti: a projekt az unlicense-t használja, amit egy időben "Ooga Booga licencre" neveztek át tematikus okokból, de a no warranty és a teljes saját felelősség elve változatlan.

A Coldcard-incidens kapcsán Portland egy tanulságos technikai megfigyelést tesz: a hiba a ragacs-határon, azaz a komponensek összekapcsolásánál keletkezett, nem az entrópia-generálásban. Murch ezt megerősíti. Portland hozzáteszi, hogy ez az eszköz viszonylag kis projekt, és a biztonsági garancia annyiban áll, hogy a belső logika rust-bitcoinra épül, tehát a minőség a ragasztókódon múlik.

• Az Entropy Lab a hardveres tárcák és entrópia-generátorok kimenetének validátora
• A Coldcard incidens után a kockadobás lett a divat, de a konverzió helyességét is ellenőrizni kell
• Az eszköz nem mainnetre való, valódi seed phrase-t tilos beletenni
• Funkciók: multisig, descriptor-készítő, PSBT-szerkesztő, BIP-85, silent payments, vanity címek
• Az RFC 6979 nonce-ellenőrzés a Dark Skippy típusú szivárgásokat szűri
• Két hét és körülbelül kétezer dollár AI-kredit, szemben a hónapokkal
• Az AI biztonsági elemzése a jól auditált kódbázisokon keveset, a kevésbé átnézetteken sokat talál
• A fuzzing suite nyílt súlyú modellel körülbelül három dollárból elkészült
• A felelősség emberé, nem a modellé, és a szerző ezt nyíltan vállalja
• A Coldcard hiba a ragasztóhatáron volt, nem az entrópia-generálásban

Senki ne tegyen valódi seed phrase-t vagy Bitcoint érintő adatot ebbe az eszközbe. Új hardveres tárca tesztelésénél, fedezet nélküli kockadobásoknál elfogadható, de a seed phrase-t utána törölni kell.

A rossz kódért végső soron az felel, aki megírta és kiadta. Egy számítógép sosem lehet felelős.

Unspendable internal keys: a draft BIP és a NUMS-pont kérdése

A hírlevél második híre a nem elkölthető belső kulcsokról szóló draft BIP, és ezt Murch mutatja be. A tétel jelenleg csak mailing list poszt formájában létezik, a BIP-repóba még nem érkezett meg, ezért Murch fenntartja a részletesebb véleményét. Az előzmények viszont régebbre nyúlnak vissza: korábban már volt egy-két kísérlet annak meghatározására, hogyan lehet olyan deskriptort vagy wallet-szabályzatot definiálni, amelyben a belső kulcs nem elkölthető.

A megoldás alapja az úgynevezett NUMS-pont, a "nothing up my sleeve" pont, ami azt jelenti, hogy létezik, de a diszkrét logaritmusa nem ismert. Ezért a kimeneti szkript készítője sem tud a belső kulccsal költeni. Ez egy pay-to-taproot kimenetet eredményez, amelynek kulcsútvonala emberi beavatkozás nélkül letiltott. Murch rögtön hozzáteszi a kvantumszámítógépes kitételt is: ha és amikor ilyen gépek léteznek, visszafejthetik a logaritmust és költhetnek. Érdekes mellékhatás, hogy ez bizonyítékot is adna a kimeneti szkript tulajdonosának arra, hogy a pont valóban NUMS-pont volt, és hogy valaki megtörte a diszkrét logaritmus feltevését.

A javaslat lényege tehát nem az, hogy használjunk NUMS-pontot, hiszen az a BIP-341-ben már benne van, hanem hogy miképpen lehet a belső kulcs hiányát kifejezni egy deskriptorban vagy wallet-szabályzatban. A koncepció legalább 2022 óta napirenden van, korábban Salvatore és Pieter Wuille delving beszélgetésében merült fel, majd Andrew Toth kísérelte meg, amit a 338-as hírlevél tárgyalt.

Az indoklás a felhasználási eset: ha valaki csak script path-okkal akar költeni, akkor egy olyan szkriptfát épít, amelyben több alternatív költési feltétel van, de a kulcsútvonal ki van zárva, mert kizárólag a script-levelekből szeretne költeni.

A beszélgetés egyik legérdekesebb pontja az adatvédelmi vetület. Ha mindenki ugyanazt a NUMS-pontot használná tweakeletlenül, akkor minden script path-ból történő költésnél felfedné ugyanazt a belső kulcsot, és ezáltal minden ilyen kimenet azonosíthatóvá válna. Murch itt óvatosan fogalmaz, mert nem száz százalékig biztos benne, de emlékei szerint a BIP-341-ben eleve egy tweakelt NUMS-pontot javasoltak, éppen azért, hogy elrejtse, melyik pontról van szó. A tweak ismeretében később bizonyítani lehet, hogy a pont a NUMS-pontból származik, de mások számára ez nem felismerhető.

PortlandHODL ezen a ponton átadja, mondván, hogy nincs elegendő ismerete a konkrét javaslatról. A hallgatókat Murch a hírlevél összefoglalójához és az NTL által írt alapul szolgáló poszthoz irányítja.

• A draft BIP még nem került a BIP-repóba, csak mailing list poszt
• A NUMS-pont diszkrét logaritmusa nem ismert, ezért a belső kulccsal nem lehet költeni
• A kvantumszámítógép visszafejtheti a logaritmust, de ez bizonyítékot is ad a tulajdonosnak
• A kérdés nem a NUMS-pont használata, hanem a belső kulcs hiányának kifejezése deskriptorban
• A felhasználási eset: csak script path-okkal lehessen költeni
• A tweakeletlen NUMS-pont minden script path-költést azonosíthatóvá tenne, ezért tweakelik
• Az előzmények: Salvatore és Pieter Wuille delving beszélgetése, Andrew Toth kísérlete

Ha mindenki ugyanazt a NUMS-pontot használná tweakeletlenül, minden script path-ból történő költés felfedné ugyanazt a belső kulcsot, és ezáltal minden ilyen kimenet azonosíthatóvá válna.

Kliens- és szolgáltatásfrissítések: BitBoxApp, Spark és Covenants.diy

A hónap kliens- és szolgáltatásfrissítései közül kettőt tárgyalnak részletesen, az Entropy Lab mellett. Az első a BitBoxApp, amely a 4.52.0 verzióban Spark-alapú Lightning-fizetéseket támogat. A megvalósítás a Breez SDK-ra épül, és a Spark statechaint használja.

Murch itt több pontosítást fűz hozzá, és ezek a szakasz legértékesebb részét adják. Először is kiemeli, hogy ez a mobilalkalmazás funkciója, nem a hardvereszközé, tehát a pénzeszközök a telefonon lévő hot walletben vannak, nem a hardveres tárcán. Amikor az egyik házigazda rákérdez, hogy akkor az aláírás sem a BitBox-szal történik-e, Murch bizonytalanná válik, és elismeri, hogy nem nézett utána, az alaptevékenysége az volt, hogy a BitBoxot a titokkezelésre használják, a mobilalkalmazást pedig az életképességre.

A második, fontosabb pontosítás a statechainek megbízhatósági modelljéről szól. A statechainek félig megbízhatóak abban az értelemben, hogy a statechain-operátor csalhat egy korábbi tulajdonossal, aki ugyanazt a statecoint birtokolta. Amikor a pénzeszköz átkerül egy statechainben, a titkot a statechain-operátor és az új tulajdonos újra szeleteli, tehát ugyanazon titok különböző felosztásait használják, és elvileg egy korábbi tulajdonos visszamenve elköltheti ugyanazt az érmét. Ehhez az kell, hogy a statechain-operátor hűen végrehajtsa a protokollt. Emellett az operátor teljes rálátást kap a fizetésekre.

Murch szerint ezek a trade-offok adatvédelmi és biztonsági szempontból is eltérnek a hagyományos Lightningtól, és bár a kényelem nyilvánvaló, a marketing egy részében a megoldást egyszerűen nem-kasztodiálisnak nevezték, ami szerinte erősen félrevezető. Az egyik házigazda egyetért, és hozzáteszi, hogy ez a fajta árnyalatgyalulás visszatérő minta: a marketing elkeni a részleteket, a technikai vita pedig a háttérben folyik.

Murch abban is igazat kap, hogy a titok BIP-85-tel származik a hardveres tárcából, a Spark wallet egy hot wallet, ami a hardveres tárca titkából származik. A megoldás előnye a helyreállíthatóság: a hardvereszköz egy másik eszközhöz csatlakoztatva helyreállíthatja a statechain-hozzáférést. Az egyik házigazda megjegyzi, hogy ez kicsit ijesztő, hiszen privát kulcsok exportálását jelenti.

A második frissítés a Covenants.diy script szerkesztő, amit a hírlevél korábban már említett. Ez egy böngészőalapú szerkesztő covenant-szkriptek építéséhez és végrehajtásuk lépésenkénti áttekintéséhez. Az opkódok, amelyeket tartalmaz: CTV, checksigfromstack, OP_CAT, template hash, internal key, pair commit, TX hash és AnyPrevOut. Murch figyelmeztet, hogy a felhasználó saját felelősségére használja, és csak teszthálózaton, mivel ezek nincsenek aktiválva.

Murch technikai értékelése szerint a szerkesztő a LNhance és a rebindable signatures javaslatokat teljesen lefedi, az OP_TXHASH a script restoration javaslat része vagy önállóan is létezik, az OP_CAT pedig különálló, de korábban volt iránta kereslet. Az AnyPrevOut a BIP-118, amit szerinte némileg felváltott a BIP-448, mert a rebindable signatures javaslat megismétli mindazt, amire az AnyPrevOut-ot kérték, nevezetesen az LN-szimmetriát. Aki covenant-kutatással foglalkozik, annak ez az eszköz hasznos lehet az Inquisitionon.

• A BitBoxApp 4.52.0 Spark-alapú Lightning-fizetéseket támogat a Breez SDK-val
• Ez a mobilalkalmazás funkciója, a pénzeszközök a telefon hot walletjében vannak
• A statechainek félig megbízhatóak: az operátor csalhat egy korábbi tulajdonossal
• A titkot a statechain-operátor és az új tulajdonos újra szeleteli
• Az operátor teljes rálátást kap a fizetésekre, ami eltér a hagyományos Lightningtól
• A nem-kasztodiális megnevezés félrevezető, a trade-offok eltérnek
• A titok BIP-85-tel származik a hardveres tárcából a helyreállíthatóságért
• A Covenants.diy böngészőalapú covenant-szerkesztő, csak teszthálózatra
• Az AnyPrevOutot (BIP-118) némileg felváltotta a BIP-448 rebindable signatures javaslat

A statechainek félig megbízhatóak: az operátor csalhat egy korábbi tulajdonossal, aki ugyanazt a statecoint birtokolta. A marketing egy része mégis egyszerűen nem-kasztodiálisnak nevezte, ami erősen félrevezető.

Kiadások és nevezetes kódváltozások: biztonsági javítások hete

Gustavo Flores Echaiz vezeti a záró szakaszt, ami szokatlanul gazdag. Az egyetlen kiadás az Eclair 0.14.3, ami patch kiadás és fontos biztonsági javításokat tartalmaz, ezért a felhasználóknak érdemes frissíteniük, hogy elkerüljék a rosszindulatú csomópontok által kihasználható hibákat. Az új konfigurációs paraméter a maximális funding díjráta, ami a funding- és splicing-tranzakciókra fizetett maximális díjráta, és védelmet nyújt a díjbecslő manipulációja ellen. A trade-off nyilvánvaló: bizonyos helyzetekben valóban magasabb díjat szeretnél fizetni, de a paraméter korlátot szab.

A Bitcoin Core hét PR-je közül az első a #35445, ami kompatibilitási hibát javít. Ha egy deskriptor-wallet miniscript kifejezése a hardnend származtatás jelölésére a h szintaxist használta az aposztróf helyett, akkor a 31-es verzióra frissítés után a wallet nem töltődött be. Murch hátteret ad: a Bitcoin Core RPC-ivel, különösen az alkalmazás konzolján keresztül, sok escaping szükséges, ezért a korábbi aposztróf-jelölést felváltották a h betűvel, ami egyszerű karakter. A hiba gyökere az volt, hogy a deskriptor azonosítóját a deskriptor szövegéből számolták, így a szintaxisváltozás más azonosítót eredményezett. A javítás normalizálás bevezetése és a szövegek összehasonlítása lett. Az azonosítót továbbra is használják belső azonosításra, például multisig-konfigurációknál a kulcskifejezések azonosítására.

A #36076 szintén hibajavítás, ami a kombinált PSBT RPC-t érinti. Két PSBT összefésülésekor elveszhetett a második fájl SIGHASH-típusa, ha az elsőben nem szerepelt az a mező. Murch kifejti, hogy az aláíró választja meg a SIGHASH-típust, ami meghatározza, hogy a tranzakció mely részeire köteleződik el az aláírással: az összes bemenetre vagy csak az általa aláírtra, az összes kimenetre vagy csak az azonos pozíciójúra, vagy ezek kombinációira, illetve akár egyikre sem. A probléma a mező hiányának és az alapértelmezett értéknek az összemosásából eredt, és a javítás után a fájlok sorrendje már nem számít.

A #36150 egy versenyhelyzetet javít. Ha egy archív, azaz nem prunolt node-ot prunolásra állítasz át, és egyidejűleg engedélyezed a compact block filter indexet vagy a UTXO statisztikai indexet, akkor a prunolás megelőzte az indexet, és a blokkfájlok eltűntek, mielőtt az index zárolta volna őket. Az eredmény az volt, hogy az index hibát adott, mert a blokkfájlok nem voltak meg. A javítás egy zár elhelyezése a nulla magasságon, hogy az index előbb felépüljön. Az egyik házigazda rákérdez, hogy a node automatikusan újraindexel-e, és a válasz az, hogy nem, az index egyszerűen nem indul el és újraindexelést kér. Gustavo hozzáteszi, hogy ez a hiba csak akkor áll elő, ha nem prunolt node-ot prunolsz, ami első olvasásra nem volt nyilvánvaló.

A #36174 az új HTTP szervert érinti, ami a libevent-alapú szervert váltja fel. A 422-es hírlevélben a receive-side védelmet tárgyalták, most a send-side védelem, azaz a back pressure következik. A probléma az, hogy egy sok kérést küldő kliens nem olvassa a válaszokat, így a sorba állított válaszadatok mérete korlátlanul nő. A javítás egyszerűen szünetelteti a további kérések feldolgozását, ha a send buffer meghaladja a 32 megabájtot, és akkor folytatja, amikor a kliens elkezdi kiolvasni a válaszokat.

A #34743 a manuálisan kiválasztott peer-eket érinti. Ha egy ilyen peer akadályozza a blokklekérést az IBD alatt, korábban a node egyszerűen leválasztotta. Mostantól inkább más peerektől kéri le ugyanazokat a blokkokat, és két percre szünetelteti az új blokkkéréseket az akadályozó peertől. Ez a viselkedés kizárólag az akadályozás esetére vonatkozik, a szokásos időtúllépéseknél továbbra is leválasztás történik.

A #36081 a getbányászatinfo RPC válaszát bővíti egy bestblockhash mezővel. A probléma az volt, hogy a következő nehézségi cél lekérdezéséhez és az aktuális csúcshash-re építéshez két külön kérés kellett, ami versenyhelyzetet teremtett, mert a csúcshash közben változhatott. Mostantól a csúcshasht ugyanaz a válasz adja.

A #35975 potenciális wallet-összeomlást javít. Ha a tárcában ugyanazon tranzakció két malleált verziója volt, és csak az egyik díját emelted, a másik nem jelölődött azonnal lecseréltnek. Ha ezután a másik díját is emelni próbáltad, assertion failure és node-összeomlás következett. A javítás egyszerű: ha az egyik verzió díjemelése után az lecserélődik, a másikat is lecseréltként kell jelölni, és a másik verzió díjemelése hibát ad vissza összeomlás helyett.

A BIP-repóhoz tartozó tételek közül az első a #2241, ami a BIP-332-t adja hozzá. Ez a BIP-434 peer feature negotiation keretében egy új üzenetet specifikál az elavult lánccsúcsok opt-in továbbítására. Murch háttere szerint a Bitcoin hálózatában időnként két versengő blokk jelenik meg a lánc csúcsán, és ilyenkor általában csak az egyikről értesülsz, mert a másodikat letöltöd, de nem továbbítod. Ez repedést hoz létre a hálózatban: az egyik oldal az egyik, a másik oldal a másik blokkot kapta meg először, a határon lévő node-ok pedig mindkettőt ismerik, de a második csúcsról nem továbbítanak információt. Ez átszervezésnél azért fontos, mert ha már ismered a másik lánccsúcsot, gyorsabban tudsz átszerveződni a győztes csúcsra. Kutatók számára pedig az elavult blokkok arányának követése miatt érdekes, mert ez a blokk-továbbítási késleltetés mértéke, és jelezhet önző bányászati támadásokat is. A javaslat első csatlakozáskor legfeljebb tíz lánccsúcsot propagál az utolsó ezer blokkból, ami a gyakorlatban kevés adat. Murch megjegyzi, hogy csak draft létezik a Bitcoin Core-hoz, és ha bekerül, az nem a 32-es, hanem a 33-as vagy későbbi verzióban lesz.

A #2258 a BIP-93, azaz a codex32 specifikáció ellenőrzőösszeg-hossz korlátait javítja. A prefixet nem vették figyelembe, ezért egyes sztringek meghaladták az ellenőrzőösszeg hibafelismerési garanciáit. Emellett az kódolások mostantól rögzített méretűek, tizenhat, húsz, huszonnégy, huszonnyolc, harminckettő vagy hatvannégy bájt, a korábbi rugalmas tartomány helyett, ami jobban kiszűri a gépelési hibákat. Murch hozzáteszi, hogy ez egy nagyobb BIP-93-javítási sorozat része, amely egyetlen nagy változtatásból hat kisebb pull requestre bomlott. A BIP-93 a codex32, ami rendkívül munkaigényes módja a kulcsok kézi, papíron és tollal történő szeletelésének. Ben Westgate azon dolgozik, hogy a BIP-93 támogatását bevezesse a BIP-85-be egy dedikált származtatási útvonalon. A BIP-93 továbbra is draft státuszban van, annak ellenére, hogy a közösség már hat éve használ táblázatokat a workshopokon.

Az Eclair három PR-je közül az első a #3380, ami egyszerű. Az Eclair mostantól elutasítja azokat az API-kéréseket, amelyek origin fejlécet tartalmaznak. Ilyen fejlécet általában a böngészők küldenek, tehát a változás lényege, hogy böngészőalapú frontend többé nem hívhatja közvetlenül az Eclaire-t, hanem saját backendet kell használnia. Ez a cross-site request forgery elleni védelem a gyorsítótárazott HTTP basic hitelesítési adatokkal szemben. A curl és az Eclair CLI érintetlen, hacsak nem állítja be valaki explicit módon a fejlécet.

A #3376 a kiadás fő biztonsági eredménye, négy elkülöníthető javítással. Az első a zárási díj tárgyalása: ha az Eclair fizeti a díjakat, és a peer a beállított maximális zárási díjráta felettit javasol, miközben a peer nem támogatja a fee range-eket, ami a díjtárgyalási protokoll fejlettebb változata, akkor a node véletlenül elfogadhatta a peer javaslatát. Egy régi verziót futtató támadó így rábírhatta a node-ot túlzott díj fizetésére. Mostantól az Eclair soha nem fogad el a díjtartományán kívüli díjrátát.

A második a splicing-hoz kapcsolódik. Ha az Eclair egy splicing-tárgyalásban vesz részt, de a csatornát egy befejezetlen splice közben kell lezárnia, akkor a splice utáni állapotra már kicserélte a kötelezettség-aláírásokat, de maga a splice nem fejeződött be. Korábban ilyenkor a splice utáni kötelezettség-tranzakciót próbálta volna sugározni, ami viszont a befejezetlen splice-tól függ, tehát nincs értelme. A javítás szerint az Eclair a legutóbbi olyan kötelezettség-tranzakciót sugározza, amelynek funding-tranzakciója teljesen aláírt. Emellett, ha a peer mégis sugározza a splice-tranzakciót és az megerősítést nyer elsőként, az Eclair azonnal lezár a splice-t követő kötelezettséggel.

A harmadik rész egy pénzvesztési forgatókönyv on-the-fly funding esetén blinded pathokkal. Az Eclair általában gondoskodik arról, hogy a kimenő HTLC CLTV lejárati deltája alacsonyabb legyen, mint a bejövőé. Az on-the-fly funding blinded pathokkal viszont kivétel: az Eclair építi a kimenő HTLC-t, de a kimenő peer építi a blinded pathot az invoice-ában, és az utasítások megadják a CLTV lejárati deltát. Az Eclair nem támaszkodhat ezekre az utasításokra, hanem magának kell eldöntenie. Ebben az esetben viszont nem ellenőrizte megfelelően, és elfogadott bármilyen megadott deltát, ami nem biztonságos továbbításhoz vezethetett: a downstream peer igényelhette a fizetést, miközben a bejövő HTLC lejárt, mielőtt az Eclair behajthatta volna, így mindkét élen pénzt veszített. A negyedik rész a korábban említett maximális funding díjráta konfigurációs beállítás.

A #3372 esetében az Eclair trampoline node-ként viselkedett, és túl sok díjat tartott meg, amitől a fizetés végül meghiúsult, mert a downstream útválasztásra fenntartott díjkeret nem volt elegendő. Ez különösen akkor fordult elő, ha a fogadó fél LSP-t használt, és az LSP továbbítási díjat számolt fel. Az új beállítás lehetővé teszi, hogy a trampoline node meghatározza a megtartott minimális díjat, így csökkentheti a saját díját, és a keret fedezheti a downstream díjakat. Emellett a PR megnövelte az alapértelmezett minimális teljes díjkeretet is.

Az LND #11163 a replikált HTLC-k kezelését javítja a forward interceptor használatakor. A forward interceptor lehetővé teszi, hogy egy külső folyamat késleltesse a fizetés továbbítását és döntsön róla. A hiba az volt, hogy ha a peer újracsatlakozott vagy a node újraindult, az LND esetleg újra feldolgozta a már továbbított bejövő HTLC-t, és új elfogásnak tekintette. Ha a lejárat túl közeli volt, egyszerűen elutasította, pedig korábban már elfogadta. A javítás szerint az LND ellenőrzi a meglévő továbbítási rekordokat, és engedi, hogy a replika az eredeti fizetés feloldásán keresztül folytatódjon, új döntés meghozatala nélkül.

A BDK két PR-je, a #2246 és a #2263 a wallet-egyenlegek osztályozását javítja. Korábban, ha a visszajáró egy nem megerősített bejövő fizetés elköltéséből származott, akkor a visszajáró megbízhatónak számíthatott, mintha a saját tárcádtól érkezett volna, pedig egy nem megerősített bejövő fizetésből származott. A BDK nem ellenőrizte megfelelően a kimenet el nem rendezett tranzakció-ősét. A javítás szerint a BDK minden UTXO őseit ellenőrzi, hogy megfelelően osztályozza megbízhatóként vagy nem megbízhatóként. Emellett egy új API, a ClassifyOutpoints teszi lehetővé, hogy a felhasználó maga osztályozza az outpointokat, és egy ConfirmationsLowerBound nevű metódus segít az alkalmazásoknak az elszámolási szabályok meghatározásában, például hogy egy kimenet hat megerősítés után számítson rendezettnek.

• Az Eclair 0.14.3 patch kiadás, négy biztonsági javítással, frissítés javasolt
• A maximális funding díjráta véd a díjbecslő manipulációja ellen
• A Bitcoin Core #35445 a deskriptor-azonosító szövegalapú számítását javítja normalizálással
• A #36076 a kombinált PSBT RPC SIGHASH-elvesztését javítja, a sorrend már nem számít
• A #36150 a prunolás és az indexépítés versenyhelyzetét javítja
• A #36174 send-side back pressure-t vezet be 32 megabájtos korláttal
• A #34743 nem választja le az akadályozó peert, hanem két percre szünetelteti
• A #36081 a getbányászatinfo válaszába teszi a bestblockhash-t
• A #35975 a malleált tranzakciók díjemelésénél fellépő összeomlást javítja
• A BIP-332 az elavult lánccsúcsok opt-in továbbítását specifikálja
• A BIP-93 javítja az ellenőrzőösszeg-hossz korlátait és rögzített méreteket vezet be
• Az Eclair #3376 harmadik része egy on-the-fly funding pénzvesztési forgatókönyvet javít
• Az LND #11163 a replikált HTLC-k helyes kezelését biztosítja
• A BDK a visszajárók megbízhatósági osztályozását javítja az ősök ellenőrzésével

Az Eclair nem támaszkodhat a peer utasításaira, hanem magának kell eldöntenie a CLTV lejárati deltát. Ebben az esetben nem ellenőrizte megfelelően, ami nem biztonságos továbbításhoz vezethetett.

Forrás

• Epizód webpage: https://bitcoinops.org/en/podcast/2026/09/22/
• Spotify podcaster: https://podcasters.spotify.com/pod/show/bitcoin-optech/episodes/Bitcoin-Optech-Newsletter-423-Recap-e3p8iu5
• Tárgyalt hírlevél: https://bitcoinops.org/en/newsletters/2026/09/18/
• Media fájl: https://anchor.fm/s/d9918154/podcast/play/126159237
• Transcript: Whisper (ggml-medium.en), 17 916 szó, 138 szó/perc, 13,5 perc wall-time
• Közzététel: 2026-09-22 20:26 UTC (a feed pubDate-je)
• Transcript-hiány: az epizód natív átirata még nem készült el. A podcastoldal forrása a megjelenéskor csupán 699 bájt volt, benne "transcription coming soon". A Bitcoin Optech átiratai 2026-ban medián 5,9 nappal (141,9 óra) a recap után jelennek meg, ezért a Whisper-fallback az alapértelmezett út.
• ASR-torzítások javítva: "OpTech" → Optech; "Florasta" → Floresta; "Maro" → MARA; "Vardif" / "VARDIF" / "var diff" / "Fardifs" → vardiff; "sweet sync" / "Swift sync" / "SwissSync" / "Swiftink" → SwiftSync; "Mirchi" / "Merch" / "Marsh" / "Mers" / "Burch" / "Mirj" → Murch; "Nick Jonas" → Jonas Nick; "Peter Woolley" / "Peter Woole" → Pieter Wuille; "clawed" → Claude; "bit baby five" → BIP-85; "Kimmy K3" → Kimi K2; "Jameson Lop" → Jameson Lopp; "cold card" → Coldcard; "Breeze SDK" → Breez SDK; "stratum SV2" → Stratum V2; "L&D" → LND; "a cert" → ASERT; "CG miner" → CGMiner; "mini script" → miniscript; "Testnet 5" → testnet5; "nums point" → NUMS-pont; "PS BT" → PSBT; "codex 32" → codex32; "sighash" → SIGHASH; "lived event" → libevent; "add node" → addnode; "get bányászat info" → getbányászatinfo; "malleated" → malleált; "T pubs" / "X pubs" → tpub / xpub.
• Bizonytalan ASR-nevek, nem javítva: "Taj" / "Tajik" (feltehetően Tadge Dryja, de nem megerősített); "Colvin" (a Floresta/Utreexo csapat tagja, a kontextusból nem azonosítható); "Salvatore" (feltehetően Salvatore Ingala, de a konkrét hivatkozás a 283-as hírlevélre nem ellenőrizhető innen); "NTL" (a draft BIP poszt szerzője); "Nicholas Geger" (feltehetően Niklas Gögge, de nem megerősített); "Mr. Hoddle" (X-felhasználó, nem megerősített); a Bitcoin Core plugin PR-száma ("ARG PC, U3X2") értelmezhetetlen volt.

Kapcsolódó külső források

• Floresta (Utreexo-alapú könnyű kliens): https://getfloresta.org, GitHub: getfloresta/floresta
• Delving Bitcoin vitaszálak a Utreexo IBD-javításról és a NUMS-pontokról: https://delvingbitcoin.org
• Entropy Lab: hardveres wallet-validátor, nem mainnetre, nyílt forráskód (unlicense)
• Covenants.diy: böngészőalapú covenant-script szerkesztő, tesztnetre
• BitBoxApp 4.52.0: Spark-alapú Lightning-fizetések Breez SDK-val
• BIP-332: elavult lánccsúcsok opt-in továbbítása (stale tip relay)
• BIP-93 / codex32: kézi kulcsszeletelés ellenőrzőösszeg-javításokkal
• BIP-448: rebindable signatures, az AnyPrevOut (BIP-118) részleges felváltója
• Dark Skippy: a nemcekkel kapcsolatos kulcsszivárgási támadás
• TabConf: konferencia, ahol a vardiff-kutatásról előadás lesz
• Nikkel Gögge blogposztja az AI-asszisztált tesztelési stratégiákról (a Whisper "Nicholas Geger"-ként írta)
• Bitcoin Red Team: az AI biztonsági átvizsgálásának eredményei

Kapcsolódó belső források

Ez az első Bitcoin Optech epizód a saját feldolgozásunkban, így közvetlenül kapcsolódó korábbi epizód-összefoglaló nincs. A tartalom a következő belső tudásbázis-elemekhez kapcsolódik:

• topics/bitcoin-technology.md (a wiki Bitcoin-technológiai témaköre, ahova ez a bejegyzés kerül)
• A 422-es hírlevél HTTP-szerver javításai, amelyekre az epizód visszautal a send-side védelem kapcsán
• A hírlevél 411-es száma, ahol a libevent-alapú HTTP szerver cseréjét bemutatták
• A 338-as hírlevél, amely Andrew Toth unspendable internal key kísérletét tárgyalta
• A 283-as hírlevél, a Salvatore és Pieter Wuille közötti delving beszélgetéssel
• A 104-es hírlevél, ahol a forward interceptor először szerepelt

Hogyan kapcsolódik a saját rendszerünkhöz?

Három ponton érintkezik ez az epizód a saját infrastruktúránkkal és munkafolyamatainkkal.

A node-ok hozzáférhetősége. Az Utreexo IBD-je azzal, hogy a szinkronizálást telefonon néhány órára szorítja, olyan eszközökön teszi lehetővé a validáló node futtatását, amelyek eddig kiestek a körből. Ez közvetlenül érinti a saját self-hosted szemléletünket: a Bitcoin node futtatása a saját hardveren nem elvi állásfoglalás, hanem a tranzakciók önálló ellenőrzésének feltétele. Ha a belépési küszöb egy olcsó minigépre vagy egy használt telefonra süllyed, az a privacy és a szuverenitás szempontjából valódi előrelépés.

Az AI-vezérelt fejlesztés és a felelősség. Az Entropy Lab esete figyelemre méltó párhuzam a saját munkánkkal: kétezer dollár kredit és két hét, szemben a hónapokkal. A különbség viszont tanulságos. Portland nyíltan kimondja, hogy nem ajánlja a mainnet használatot, és a felelősséget nem hárítja a modellre. Ez pontosan az a határvonal, amit a saját rendszerünkben is tartunk: a generált kimenet nem válik hitelessé attól, hogy AI készítette, és az ellenőrzés költsége nem tűnik el, csak átkerül. A fuzzing példája viszont közvetlenül hasznos: három dollárból teljes fuzzing suite, ami a mi esetünkben a saját scriptjeink robusztusságára fordítható.

A visszacsatolási hurkok. A vardiff ördögi köre, ahol a bemenet ritkulása éppen az információt vonja el, amivel a rendszer kilábalhatna, ismerős minta. Ugyanez a szerkezet jelenik meg a p2pband-monitor trendgyűjtésénél is: a néma futásokat is naplózni kell, különben a "csendes piac" összemosódik a "leállt a monitor" esettel. Az események hiányát eseményként kezelni nem csak bányászati kontrollereknél helyes elv.

A transcript-késleltetés, mint mérési eredmény. Ez az epizód adta az alkalmat annak megmérésére, mennyi idő telik el a podcast publikálása és az átirat megjelenése között. Az eredmény: 2026-os medián 5,9 nap, 48 órán belül csak az esetek tizenkét százaléka. Ez a szám a saját feldolgozási döntésünket igazolja vissza, és egyben azt a munkamódszert, hogy a natív forrásra várás helyett mérni kell, mennyit kellene várni.