Kihagyás

Bitcoin technológia és skálázás

ér - „Örökmozgó”: fizikai világtól elszakadt, alacsony hibatűrésű körkörös logika

Összehasonlítás

Szempont Proof-of-Work Proof-of-Stake
Igazságforrás Energia (fizikai) Érmék (digitális)
Támadás költsége Energia vásárlás (folyamatos) Érmék vásárlása (egyszeri)
Előtörténet Hamisíthatatlan (energia bevitt) Visszafordítható (zero költség)
Áami irányítás Minimalizált Jelentős
Decentralizáció Magas (bárki bányászhat) Alacsony (gazdag validátorok)

Lightning Network

Alapelvek

  • Joseph Poon és Thaddeus Dryja white paper (2016)
  • Második rétegű fizetési protokoll a Bitcoin felett
  • Kétirányú fizetési csatornák → tranzakciók off-chain → csak nyitás/zárás on-chain
  • Hash-time-locked contracts (HTLC) → feltételes fizetés időzárral

Likviditás és hálózati hatások

  • Kis hálózat: nehéz elegendő likviditású útvonalat találni, sok fizetés kudarcba fullad
  • Nagy hálózat: több ezer/millió résztvevő → számos útvonal, megbízható fizetés
  • Nagy összegek: nehezebb elegendő likviditású csatornát találni → fizetés darabolása szükséges
  • Bos Score: node minősítés (kor, üzemidő, közelség jó node-okhoz) – „Google PageRank + Moody's hitelminősítés” (Elizabeth Stark)
  • Nem villanykapcsoló – évek aprólékos felépítése kellett az átlagfelhasználók számára is használhatóvá váláshoz

Fedimint

  • Chaumian e-cash mintát használ (David Chaum eredeti koncepciója)
  • Federációk (megbízható guardian csoportok) kezelik a likviditást
  • Egyszerűbb felhasználói élmény a Lightning-nél
  • Privacy: guardianok nem látják a tranzakció részleteit

Bitcoin és a sebességkülönbség lezárása

  • 1871 óta: információ fénysebességgel, elszámolás fizikai sebességgel → bankok monopóliuma
  • Bitcoin: első rendszer, ahol információ ÉS elszámolás is fénysebességgel
  • Ez a technológiai változás bezárja a rést, amit a bankok/centrális bankok kihasználtak

Lásd még

Bear market = building time: Ark, Cashu, új wallet-ek (RHR #413, 2026-06-11)

A 413-as RHR epizód egyik fő üzenete: a bear market az építés ideje. A "bear markets are for building" mantra kézzelfogható release-ek formáját ölti.

Bark (Ark protokoll) mainnet

  • A Second cég (Ark implementáció) elindította a Bark-ot Bitcoin mainneten
  • A Botanics L2 lehúzása nem jelenti, hogy "nem akarnak DeFi-t Bitcoinon" — a megközelítés volt rossz
  • Bark kifejezetten fizetési use-case-re fókuszál, trust-minimized módon
  • Proof of reserves Cashu mint powered by Ark and Nostr prototípus (Matthew Vook, Second társalapító)
  • Co-szignatúra a Bark kliens és az Ark szerver között kriptográfiailag igazolja egy e-cash mint minimális egyenlegét
  • Out-of-the-box működik mainneten
  • Marty: "Bark hit the main net… bark, they want to do a lot of covenant like, arcade wants to do a lot of covenant like functionality, which would be Bitcoin DeFi"

Noah wallet (Blixt fejlesztők)

  • Hampus és Natesh új walletje, kísérő wallet a Bark-hoz
  • "Feature rich" Lightning wallet, azonnal használható
  • Odell: "One is Noah, which comes from Hampus and Natesh, the guys behind Blixt, which was a great, is a great Bitcoin lightning wallet and has all the features you would expect."

Arky wallet (Kristof Ono)

  • iOS-only, "design-first" megközelítésű Lightning wallet
  • Élő demó a show alatt
  • "It's almost like, yeah, it's like if a Bitcoin wallet was released by like a fashion brand, but it was open source in self custody… You can also like change it into corn, which I thought was fun. You make your units corn, like a savings balance and a payments balance." (Marty)
  • "Very, very early" warninggal indul — pont ez a lényeg, a Lightning wallet-ek 2017-2018-as mainstream fázisához hasonlóan most kell kézzel kipróbálni

Wisp + Darkwisp (UTXO projekt)

  • Wisp: iOS, normie-fókusz, Apple/Google sign-in opció
  • Darkwisp: Android, hardcore privacy funkciók
  • "It's one of the powers of open source." (Marty)
  • Darkwisp 1.0.0 frissítés: private interactions, poor routing, NIP-A3 payments támogatás

BitX ESP 2.14.0

  • Open-source mining firmware release
  • BitX projekt: nyílt forráskódú, Raspberry Pi-formátumú mining hardver
  • "Open source mining hardware and firmware is imperative and is going to be more important as miners, large miners transition to AI compute." (Marty)

Cashu–TEE (Trusted Execution Environment) front

  • On-chain Cashu mint a "legjobb compromise" jelenleg
  • A Lightning node + TEE kombó még nem megoldott
  • Marty: "If you have… multiple semi-trusted options to move between them, it's not the end of the world… you could have, you know, a trusted lightning operator that's not in a T. And there would be a momentary, you know, aspect of trust when you're trying to make a $30 payment between two T mints or whatever. And like in practice, it's still a huge improvement."
  • Bitcoin marad az "open protocol that glues the whole thing together" — submarine swaps, on-chain átutalások a mints között, pay join a fee-efficiency kedvéért

Kapcsolódó

Bitcoin Optech #423: Utreexo IBD, vardiff és Entropy Lab (2026-09-22)

Utreexo IBD: az assumed-valid áttörés

  • A UTXO-készlet növekedése miatt az IBD gyenge hardveren akár egy hónapig tart; ez a valódi kiindulópont, nem elméleti probléma
  • A Bitcoin modellje az egész tranzakció-kimenet készletet tárolja, és a UTXO-készlet ennek részhalmaza (Murch pontosítása); az Utreexo az, ami nem tart ilyet
  • Az Utreexo akkumulátora kevesebb mint 1 KB, elfér a CPU gyorsítótárában; cserébe több sávszélesség és CPU kell a bizonyítékok miatt
  • A naiv Utreexo a legrosszabb esetben 100% bizonyíték-overheadot szenved el: 700 GB blokkhoz 700 GB bizonyíték, ami 5 TB letöltést jelent az IBD alatt
  • A gyorsítótárazás (80% költés az utolsó néhány száz blokkban) 30-40%-ra csökkentette az adatigényt, de ez még mindig 200-300 GB
  • Az áttörés: ha a költési magasság előre ismert (SwiftSync hint map), 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; az IBD végén az akkumulátor megegyezik a szokásos műveletekével
  • Eredmények: 90 perc 45 másodperc gyors gépen, 1 óra 30 perc 800 Mbit/s-en, 3 óra rossz kapcsolaton, 4-5 óra egy Pixel telefonon Wi-Fi-n
  • A rendszer gyakorlatilag a hálózati sávszélesség korlátjáig megy, minden kapcsolatot telít
  • A történelmi bizonyítékok elhagyhatók (túl drágák); a Bitcoin Core plugin ~20 perc alatt szinkronizál, és egy használt minigépen 30 perc alatt építette fel a fát 900 000 magasságig
  • Davidson Souza a Floresta fejlesztője; a BIP-181 újraírásra szorul, a munka következő fázisa a nem assumed-valid verzió
  • "Az IBD végén az akkumulátor megegyezik azzal, amit a szokásos hozzáadás-törlés sorrend adna." (Davidson Souza)

Vardiff: a visszacsatolási hurok csapdája

  • A vardiff a bányászati pool nehézség-szabályozója; célja tipikusan ~6 share/másodperc
  • A hiba ördögi kör: ha egy bányász lassul (áramszünet, napelem termelésesése, hardverhiba), kevesebb share jön, ami kevesebb információt ad a kontrollernek
  • Mivel az állítás 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; a pool leválaszthatja a bányászt, mielőtt rendeződne
  • A megoldás: az ürességet eseményként kell kezelni, az idő múlását bevonni a mérési ablakba
  • Ugyanez a hiba a lánc szintjén: a Luke Dash Jr. fork magas nehézségen ragadt és nem tudta kiváltani a csökkentést; a BCH első hasadásánál akadémiai irodalom is követte
  • A BCH emergency difficulty adjustmentje oszcilláló hashrate-hez vezetett, mert a bányászok szándékosan nem termeltek blokkot
  • Az ASERT (a becslő végső formája) exponenciálisan súlyozott mozgóátlagot használ: 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, amit az exponenciális változat megszüntet
  • Az aszimmetrikus szabály (könnyebb emelni a share-rátát, mint csökkenteni) a gépeket tovább életben tartja; a láncon viszont felgyorsította a BCH kibocsátását, ami konszenzus-szempontból elfogadhatatlan volt
  • A poolban ártalmatlan, mert nincs fix jutalom share-onként, hanem arányos értékű share-ok vannak
  • A nehézség kettő-hatványaira kényszerítése CGMiner-örökség a firmware-ekből, ami rontja a vardiffot és a bányász láthatóságát
  • A Stratum V2 csatlakozáskor átvett nominális hashrate (feed-forward) megszünteti a share-vihart, de lassulásnál az újracsatlakozás visszahozza
  • A curtailmenteknél (energiaszabályozás) nincs részleges korlátozás, pedig a javított vardiff éppen ott hasznos
  • Eric Price (MARA) kutatása; előadás a TabConfon

Entropy Lab: hardveres wallet-validátor AI-val

  • Cél: hardveres tárcák és entrópia-generátorok kimenetének validálása a determinisztikus oldalon
  • Kiindulópont: a Coldcard incidens után a kockadobás lett a divat, de a konverzió helyességét is ellenőrizni kell
  • Nem mainnetre való: valódi seed phrase-t tilos beletenni; csak fedezet nélküli tesztelésre
  • Funkciók: multisig, descriptor-készítő, PSBT-szerkesztő és validátor, BIP-85, silent payments, vanity címek
  • RFC 6979 nonce-ellenőrzés a Dark Skippy típusú kulcsszivárgások szűrésére (Murch: azonos nonce különböző üzenethez = privát kulcs szivárgása)
  • Alap: rust-bitcoin Wasm-re fordítva, libsecp256k1 beépítve; új elem a közvetlen wallet.dat JS library
  • Két hét és ~2000 dollár AI-kredit, szemben a hónapokkal; egy szenior fejlesztőnél ez 1-3 napi munka díja, és még akkor sem lett volna kész
  • Az AI biztonsági elemzése a jól auditált kódbázisokon (Bitcoin Core, libsecp256k1) keveset, a kevésbé átnézetteken sokat talál
  • A fuzzing suite nyílt súlyú modellel (Kimi K2) ~3 dollárból elkészült; a CI-ban is futtatnak fuzzingot
  • A felelősség emberé: "Egy számítógép sosem lehet felelős" (Rob Hamilton); a rossz kódért az felel, aki megírta és kiadta
  • Nincs formális kiadás, csak változó master branch; a licenc unlicense ("Ooga Booga licenc"), no warranty
  • A Coldcard hiba a ragasztóhatáron (glue) volt, nem az entrópia-generálásban (Murch megerősítése)

Unspendable internal keys: draft BIP

  • A javaslat még csak mailing list poszt, a BIP-repóba nem érkezett meg
  • A NUMS-pont ("nothing up my sleeve") 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 adna a tulajdonosnak arra, hogy a pont NUMS-pont volt
  • A kérdés nem a NUMS-pont használata, hanem a belső kulcs hiányának kifejezése deskriptorban vagy wallet-szabályzatban
  • Felhasználási eset: csak script path-okkal lehessen költeni, a kulcsútvonal kizárva
  • A tweakeletlen NUMS-pont minden script path-költést azonosíthatóvá tenne, ezért a BIP-341-ben tweakelt változatot javasoltak
  • Előzmények: Salvatore és Pieter Wuille delving beszélgetése (~283), Andrew Toth kísérlete (338)

BitBoxApp + Spark statechain

  • BitBoxApp 4.52.0 Spark-alapú Lightning-fizetéseket támogat (Breez SDK, Spark statechain)
  • Ez a mobilalkalmazás funkciója: a pénzeszközök a telefon hot walletjében vannak, nem a hardveres tárcán
  • A statechainek félig megbízhatóak: az operátor csalhat egy korábbi tulajdonossal, aki ugyanazt a statecoint birtokolta
  • A titkot a statechain-operátor és az új tulajdonos újra szeleteli; az operátor teljes rálátást kap a fizetésekre
  • A nem-kasztodiális megnevezés félrevezető: a trade-offok adatvédelmi és biztonsági szempontból eltérnek a hagyományos Lightningtól
  • A titok BIP-85-tel származik a hardveres tárcából a helyreállíthatóságért

Covenant-tooling és kódváltozások

  • Covenants.diy: böngészőalapú covenant-script szerkesztő, csak teszthálózatra; CTV, CSFS, OP_CAT, template hash, internal key, TX hash, AnyPrevOut
  • Az AnyPrevOutot (BIP-118) némileg felváltotta a BIP-448 rebindable signatures javaslat (LN-szimmetria)
  • BIP-332 (BIPs #2241): elavult lánccsúcsok opt-in továbbítása, max 10 csúcs az utolsó 1000 blokkból; csak draft, a 33-as vagy későbbi verzióban
  • BIP-93 / codex32 (BIPs #2258): ellenőrzőösszeg-hossz korlátok javítása, rögzített méretek (16/20/24/28/32/64 bájt); Ben Westgate a BIP-85 integráción dolgozik
  • Eclair 0.14.3 patch kiadás, négy biztonsági javítással: zárási díj tárgyalása régi node-okkal, befejezetlen splice lezárása, on-the-fly funding pénzvesztés blinded pathokkal, maximális funding díjráta
  • Bitcoin Core: 7 PR (descriptor-azonosító normalizálás, kombinált PSBT SIGHASH-vesztés, prunolás/index versenyhelyzet, send-side back pressure 32 MB, manuális peer nem leválasztva 2 percre, getmininginfo bestblockhash, malleált tranzakciók összeomlása)
  • LND #11163: replikált HTLC-k helyes kezelése a forward interceptorral
  • BDK #2246/#2263: a visszajárók megbízhatósági osztályozása az ősök ellenőrzésével, ClassifyOutpoints API, ConfirmationsLowerBound

Hírlevél: https://bitcoinops.org/en/newsletters/2026/09/18/ Transcript: Whisper (medium.en), a natív átirat 2026-os medián 5,9 nap késéssel jelenik meg

Bitcoin Optech #424: PQLN és a Bitcoin Core 32.0 (2026-10-01)

PQLN: posztkvantum-biztonság a Lightning off-chain felületein

  • A motiváció kétlábon áll: a Bitcoin posztkvantum-frissítése önmagában nem tenné biztonságossá a Lightningot, mert annak gossipja, transportja, számlái, ajánlatai és fizetési hagymái off-chain felületek; emellett a támadó ma is rögzítheti a forgalmat, és később fejtheti vissza (harvest-now-decrypt-later)
  • Nincs konszenzusváltozás: a csatorna, a commitment és a büntető tranzakciók secp256k1 kulcsaihoz konszenzusváltozás kellene, ezért a PQLN ezeket szándékosan nem érinti, csak az öt tisztán off-chain BOLT-ot (4, 7, 8, 11, 12)
  • Hibrid konzervatív kiterjesztés: minden klasszikus mechanizmus a helyén marad, az ML-DSA és ML-KEM primitívek mellé kerülnek, a meglévő üzenetformátumokba és méretkorlátokba illesztve
  • Gossip (BOLT7): a PQ kulcsok a gossipon terjednek; a node_announcement hordozza az ML-DSA és ML-KEM nyilvános kulcsokat és az aláírást, a channel_update csak az aláírást; a kulcsok rögzítettek (pinned), ezért a csomópont elutasítja a helyettesítési kísérleteket. A channel_announcement szándékosan klasszikus marad, mert négy aláírásából kettő az on-chain funding kulcsoktól függ, és a fele posztkvantum-átállítás nem hozna hasznot
  • Transport (BOLT8): a Noise kézfogás hibriddé válik két ML-KEM beágyazással, az egyik a rögzített statikus kulcshoz, a másik egy ephemér kulcshoz a forward secrecyért. Nincs sávon belüli egyeztetés, mert egy PQ támadó könnyedén hamisíthatná az egyeztetés üzeneteit
  • Számlák (BOLT11): az ML-DSA-44 aláírás 2420 bájt, egy címkézett mező viszont legfeljebb 639 bájt, ezért az aláírás négy címkézett mezőre bomlik. A QR-kód korlátja éppen tartható, nagyjából tíz karakter marad. Falconnal a számla ~1500 karakterre esne, de a Falcon nem NIST-szabványosított
  • Ajánlatok (BOLT12): a gossip-alapú kulcsterjesztés itt nem működik, mert az ajánlat mögötti csomópont gyakran nem hirdetett, és vak útvonal mögött ül. Ezért minden ajánlat 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 elindul
  • Hagyma (BOLT4): a legnehezebb rész. A hagymacsomag 1300 bájt, egy ML-KEM-768 rejtjelezett szöveg 1088 bájt hoponként, ezért két hopnál a korlát már átlépődik. A megoldás: a hagyma formátuma változatlan, a hoponkénti titok válik hibriddé, és a rejtjelezett szövegek a hagyma mellett utaznak az update_add_htlc üzenetben, egy rögzített húsz rekeszes listában. A kihasználatlan rekeszeket álrejtjelezett szöveg tölti fel, hogy ne szivárogjon az útvonal hossza
  • Miért nem növelik a méretkorlátokat: mert akkor a frissített és a klasszikus csomópontok nem tudnának beszélni egymással. Az interoperabilitás volt a fő tervezési megkötés, és a szerző szerint ez vette igénybe a legtöbb időt
  • Implementáció: rust-lightning fork, ~11 000 sor 52 fájlban, egyetlen Cargo-funkció kapcsoló mögött, ~100 teszttel. A szerző asszisztens professzor, és nyíltan kéri a rust-lightning fejlesztők átvizsgálását
  • A mérés két iránya ellentétes: a számítás elhanyagolható (a legdrágább művelet, az ML-DSA aláírás 0,33 ms), a valódi költség a sávszélesség: a friss PQLN csomópont tízszer annyi gossip-adatot tölt le ML-DSA-44-gyel, Falconnal négyszer annyit
  • Interoperabilitási tesztek: klasszikus és PQLN csomópont között fizetésküldés, fogadás, csatornanyitás és -zárás, aszinkron fizetések. Semmi nem tört el. Ha a fizetési útvonalon klasszikus csomópont van, a PQLN visszaesik a klasszikus protokollra; ha a require-PQ kapcsoló be van állítva, a csomópont a HTLC elküldése előtt meghibásodik
  • Három nyitott probléma: a pinning trust-on-first-use jellege (csak a kvantumszámítógép megjelenése előtt találkozott csomópontokat védi); a rust-lightning 1024 bájtos MAX_EXCESS_BYTES_FOR_RELAY korlátja, amely megakadályozza a PQ gossip továbbítását nem PQ csomópontokon; és a feature bitek és TLV-típusok hozzárendelése
  • A szerző Matt Corallóval folytatott beszélgetésre hivatkozik a Rust crate-ek biztonságáról: az fips203 és fips204 csomagokat használják, és nem tudja, hogy ezek auditáltak-e éles használatra

Bitcoin Core 32.0 rc2 és a tesztelési útmutató

  • A főverziók félévente jönnek, és a kiadás időalapú, nem funkcióalapú, ezért nem minden kiadás egyformán súlyos. A 32.0 sok változást hoz, és nem minden kerül be a kiadási jegyzetekbe
  • A végső kiadás október 10-re van kitűzve; az rc2 a korábbi jelölt utáni kisebb hibajavításokat tartalmazza
  • A kiadásjelöltek funkcióteljesek, ezért a közösségi tesztelés célja nem új funkciók keresése. A projekt saját tesztkészlete kiterjedt (egységtesztek, funkcionális tesztek, fuzzing, CI több platformon minden pull requestre), és a red team ma már AI-val is tesztel biztonsági hibák után. A projekt viszont nem tud minden leszármazott beállítást lefedni: minden Lightning-csomópont, blokkfelfedező, tárca, hardvertárca, bányászati pool, operációs rendszer és egy szekrényben futó Raspberry Pi más környezet
  • Az útmutató nem kötelező: aki a jelöltet a megszokott módon futtatja, az is értékes visszajelzést ad, mert így nem a fő funkciókhoz kapcsolódó hiba is előkerülhet, például operációs rendszer kompatibilitásnál. A pozitív visszajelzés is hasznos: ha minden lefutott és működött, azt is érdemes jelezni
  • Az útmutató négy csoportban ~10 tesztet fed le, mind regtesten, ahol nem kell bányászni és nem kell letölteni a teljes blokkláncot
  • Új RPC a géppel olvasható RPC-leírásokhoz: saját leszármazott kliensben használható, és a jövőben a két kimenet összevetésével a változások is könnyen felfedezhetők
  • exportwatchonlywallet: ha valaki csak az egyenleget vagy a beérkező fizetéseket akarja figyelni tranzakcióindítás nélkül, exportálhatja a tárcát és például a telefonján visszaállíthatja
  • PSBT mostantól alapértelmezés szerint a második verzió. A szokásos folyamat (finanszírozás, aláírás, véglegesítés, sugárzás) tesztelt, de aki a saját rendszerében másképp használja, az is teszteljen
  • A HTTP-szerver teljes újraírása, a libevent eltávolításával. Minden RPC/REST kapcsolat ezt használja. A szerver szándékosan szigorúbban követi az RPC/RFC szabályokat, ezért a saját klienssel rendelkezőknek tesztelniük kell
  • Az útmutató ezen kívül lefedi a HD-kulcsok származtatását és hozzáadását (több-aláírásos tárca az új Bitcoin Core tárcában), az új díjbecslőt, és fejlettebb elemként a UTXO-készlet névvel ellátott pipe-ba dumpolását adatbázis-feldolgozáshoz
  • Szándékosan kimaradt az útmutatóból a kisebb TX-index és a párhuzamos blokkletöltés, mert mindkettő nagyobb adathalmazt és mainnet-adat másolását igényelné. A projekt viszont kifejezetten kíváncsi a terepi tapasztalatokra ezeknél

Stack Exchange: három kiválasztott kérdés

A taproot összeg-aláírás kérdése. A hardveres aláíró eszközön nincs blokklánc, csak azt tudja, amit a csatlakoztatott számítógép mond neki; a díj pedig bemenetek mínusz kimenetek. 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 valódi tíz bitcoin helyett egyet mondva a felhasználó jóváhagyja 0,99 BTC elküldését abban a hitben, hogy a díj 0,01, miközben 9,01 megy a bányászhoz. A taproot ezt úgy oldotta meg, hogy minden aláírás az összes bemenet összegéhez köteleződik el. A kérdés az, miért nem elég csak a végösszeg. A válasz: a végösszeg megállítja a díjtámadást, de a rosszindulatú szoftver átcsoportosíthatja az összegeket a bemenetek között, amíg a végösszeg változatlan marad. Egy coinjoin-szerű példában az eszköz jóváhagyhatja azt a változatot, amelyben a felhasználó 0,1 BTC-t kap, a másik fél pedig az egyet

A BIP110 utáni újraszinkronizálás. A kérdező Bitcoin Knots-ot futtatott BIP110-kényszerítéssel; az aktiválási kísérlet augusztusi meghiúsulása után az ilyen csomópontok elutasították az első nem jelző blokkot, és két láncra szakadtak. A BIP110-es lánc viszont csak néhány blokkot ért meg, mielőtt megállt. A pruned csomópont nem tud visszatekerni törölt pontra, ezért felmerült a teljes újratöltés. A válasz: valószínűleg nem kell, mert az elágazás nemrég történt, és a csomópont szinte biztosan tárolja még a két lánc közös utolsó blokkját. A Bitcoin Core telepítése a Knots helyére valószínűleg magától visszaágazik a fő láncra; tartalék megoldás a reconsiderblock futtatása arra az első elutasított blokkra

A részleges UTXO-készlet. A kérdés az, hogy lehet-e csak a legutóbbi blokkokból UTXO-készletet építeni és azzal validálni. Pieter Wuille válasza: a csomópontnak ellenőriznie kell, hogy minden elkötött érme létezik és nincs még elkötve, de részleges készlettel előfordulhat, hogy olyan érméről nem tud. A lényeg a megkülönböztethetetlenség: nem tudja megállapítani, hogy egy hiányzó bemenet már el lett-e költve, vagy olyan blokkban keletkezett, amelyet kihagyott. Ezért nem tud visszautasítani egyetlen tranzakciót sem érvénytelenként, a séma nem végez hasznos validálást, és biztonsági szintje az SPV-vel egyenértékű, amely teljesen a proof of work-re támaszkodik. Az energia jobb helyre fordítható: az Utreexo és a Floresta éppen azt a kompakt reprezentációt adja, amely az összes blokkot figyelembe veszi

Kiadások és kiadásjelöltek

  • Bitcoin Core 32.0 rc2: a második kiadásjelölt, a végső kiadás október 10-re kitűzve
  • Core Lightning 26.06.8: biztonsági kiadás felelősen bejelentett sebezhetőségek javításaival. A forráskód azonnal elérhető, de néhány teszt szándékosan visszatartva maradt, hogy a támadóknak ne legyen könnyű a sebezhetőségek azonosítása. Operátori csapda: aki a fejlesztői buildet használta, nem tud visszalépni, mert az adatbázis-séma újabb volt
  • LDK v0.3-rc2: új az RBF díjnövelés elakadt splice-tranzakcióknál, és 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. A frissítés érvényteleníti a korábban kibocsátott BOLT11 számlákat, mert a fizetési adat szerkezete megváltozott. 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 már ott találhatók

Kód- és dokumentációváltozások

Bitcoin Core #34566: a multi-signet adatkönyvtár. Több signet-hálózat eddig manuális alkönyvtár-építést igényelt, és a láncadatok ütközhettek. Mostantól több egyedi signet közös alapkönyvtárat használhat, de mindegyik négybájtos hálózatazonosítóval címkézett alkönyvtárba kerül. Aki már beállított több signetet, annak manuálisan át kell neveznie a könyvtárait az új formátumra a felesleges újraszinkronizálás elkerüléséhez. Félreértés, amit érdemes eloszlatni: nem egyetlen signet létezik, bárki futtathat sajátot; az alapértelmezett csak a kényelmet szolgálja

BIP-138: tömör titkosítás tárcán kívüli adatokhoz. A probléma a több-aláírásos tárca helyreállítása: hiába elegendő két kulcs a kézből háromból sémában, a descriptor nélkül a tárca nem rekonstruálható. A BIP-138 célja szabványosított biztonsági mentés, amelyet a felhasználó feltölthet felhőmappába, és csak ő tudja visszafejteni. Az ötlet: a kiterjesztett nyilvános kulcsokból származtatott kulcs nyitja a titkosított tárcaleírást, ezért bármelyik társszerző helyreállíthatja a leírást a saját seedjéből. Figyelmeztetés: azok az egyszerű aláírásos tárcák, amelyek egy fiók xpub-já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 az ugyanazt az xpub-ot használó több-aláírásos tárca minden mentését; ezért a BIP olyan fiókokat ajánl (BIP-48, BIP-87), amelyeknek az xpub-ját soha nem osztották meg

BIP-461: determinisztikus ECDSA-aláírás. A cél a kulcskiszivárgás elleni védekezés. Ha rosszindulatú szoftver választja a nonce-ot, a nonce-on keresztül privát kulcs-anyagot szivárogtathat, és ehhez két aláírás elegendő a tárca hozzáféréséhez (Dark Skippy támadás, #315. hírlevél). A BIP-461 egyetlen determinisztikus algoritmust ír elő: a nonce-okat az RFC 6979 szerint származtatja, alkalmazza a low-R grinding technikát (újrapróbálás, amíg az R vezető nulla bájt nélkül kódolható), és az s értéket az alsó alakjára normalizálja. A gyakorlati haszon: mivel a kimenet determinisztikus, ugyanaz a kulcs két független eszközbe tölthető, ugyanaz az üzenet mindkettővel aláírható, és az eredmények összevethetők. Bármilyen eltérés azt jelzi, hogy legalább az egyik eszköz nem követi a specifikációt, ami nonce-választáson keresztüli kulcsszivárgási kísérletre utalhat

Core Lightning: öt javítás a közzétett sebezhetőségek mögött

  • #9507 — díjszabályok és újraindítási ciklus. Három hiba: peer-javasolt splice-nál és kettős finanszírozású RBF-nél nem volt felső díjkorlát, ezért a peer rendkívül magas díjat javasolhatott; a tárolt nagy érték nullázódhatott, ami miatt a tranzakció nem került blokkba; és ugyanez a nagy érték állítási hibát váltott ki a listpeerchannels hívásakor, ami — mivel minden plugin ezt hívja indításkor — végtelen újraindítási ciklust okozott. A javítás 4000 sat/vB abszolút felső korlátot vezet be a peer-javaslatokra és háttér-díjbecslésekre (--ignore-fee-limits mellett is), és 400 sat/vB korlátot a saját nyitásokra, splice-okra, commitment-frissítésekre és RBF-ekre. Az Eclair ugyanezeket a javításokat vezette be, ami közös hiányosságra utal az implementációkban
  • #9508 — splice és csatornanyitás. A Core Lightning a peer splice_locked üzenete előtt már elküldhette az aláírásait, ezért elmulasztotta a peer commitment-sugárzását. A javítás: minden függőben lévő splice funding-kimenetét figyeli, amint elküldte az aláírásait. Emellett ha a peer a tx_abort üzenetet az aláírások elküldése után küldi, a csomópont erőszakos zárást indít, mert a peer már sugározhatta a tranzakciót. A korábbi ellenőrzés azért bukott, mert a rossz splice-ot nézte, és az aláírás elküldését jelző kapcsoló nem őrződött meg az újraindítások között. Új korlát: három folyamatban lévő csatornanyitási egyeztetés után a csomópont bontja a kapcsolatot
  • #9509 — láncon belüli csatornafeloldás (a szerző szerint a legfontosabb). A támadás három lépése: a peer nem köteleződik el előzetes shutdown-script mellett; shutdown üzenetet küld kooperatív zárás látszatával, és abban egy korábban visszavont commitment kimeneti scriptjét nevezi meg; majd feladja a kooperatív zárást és sugározza a visszavont commitmentet. A Core Lightning a shutdown üzenet miatt folyamatban lévőnek hitte a kooperatív zárást, ezért nem válaszolt büntető tranzakcióval. A javítás: a csomópont mostantól a locktime és a sequence kódolás alapján azonosítja a commitment tranzakciókat, mielőtt a kimeneteket ellenőrizné. Javított szélső eset: ha egy commitment vagy leszármazottja átszervezés áldozata lesz, a figyelés mostantól fennmarad
  • #9510 és #9511 — bemenetfeldolgozás és naplózás. Nem pénzügyi manipuláció, hanem összeomlás és adatszivárgás. Puffer-túlcsordulás a connectd-ben nagyon hosszú DNS-gépnév esetén; a JSON beágyazás 256 szintre, a REST-kérések törzse 2 MiB-ra korlátozva; egy BOLT12 TLV-elemzési hiba javítva; és egy veremtúlcsordulás hitelesítés nélküli REST-kérésnél. Adatvédelmi javítás: a nyers I/O naplók eltávolítva a getlog kimenetéből, mert rune-okat (korlátozott RPC-hozzáférést adó tokeneket) tartalmazhattak. A visszatérő minta: a Lightning-hibák jelentős része korlátlan növekedésről vagy hiányzó hosszellenőrzésről szól, aminek mechanikai oka van: 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
  • #9513 — összegellenőrzés az xpay-nél. Az xpay 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 amit a küldő szándékozott. A javítás: a számla vagy egyezik a kért összeggel, vagy ha nem adtak meg összeget, nem haladhatja meg az ajánlat összegét. Emellett a nulla hopos válaszútvonalú hagymaüzenet — amelyet bármelyik csomópont küldhetett, és amelytől a csomópont leállt — mostantól hiányzóként kezelt

LND: három javítás

  • #11198 — AMP-számla törlése. Az AMP az LND saját implementációja (nem azonos a szabványosított, többútvonalas fizetéssel), és újrafelhasználható számlát bocsát ki, amely többször kifizethető. A hiba: 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 egyidejűleg futó kísérletet is elrontott. A javítás: az LND csak 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
  • #11146 — BOLT12 offers folytatása. Validált string kódolók és dekódolók jönnek az ajánlatokhoz, számlakérésekhez és számlákhoz, amelyek a feldolgozást a hálózati, feature-, lejárati és aláírás-ellenőrzésekkel egyesítik. Az új ValidateInvoiceForPayment a számlát az azt kiváltó kéréshez és a várt aláíró csomóponthoz is ellenőrzi: 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. A követési hibajegy az LND #10736; a codec-rész majdnem kész (~10 elem beolvadt, egy maradt), és a mérföldkövek: A codec, B fogadó oldal, C küldő oldal, D több hop, E ajánlat kifizetése, F RPC-paritás
  • #11132 — BOLT1 megfelelés helyreállítása. Az LND a #421. hírlevél szerint bejövő ping-korlátozásokat vezetett be, ami megtörte a BOLT1-megfelelést, amely minden érvényes ping megválaszolását írja elő; egy külön pong-korlátozó csendben elnyomhatta a kötelező válaszokat. A javítás egyetlen, partnerenkénti 200 tokenes bucket 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), ami megőrzi a korábbi sávszélesség-korlátot, és a keret kimerülése a kapcsolat bontását vonja maga után

Hírlevél: https://bitcoinops.org/en/newsletters/2026/09/25/ Transcript: Whisper (medium.en), a natív átirat 2026-os medián 5,88 nap késéssel jelenik meg (n=14, Q1 4,83 / Q3 8,58, csak 21% 48 órán belül); a #424 transcriptionje a felvétel idején még nem létezett

Shielded Bitcoin: privát átutalások Bitcoin L1-en (2026-09-24)

  • Szerzők: Clara Shikhelman, Mikhail Komarov, Aleksei Moskvin ([[alloc] init]), 55 oldal
  • Alapállítás: shielded-note metaprotokoll, amelynek envelope-adatát a Bitcoin L1-en publikálják konszenzusváltoztatás nélkül. Sem soft fork, sem saját lánc, sem külön konszenzus
  • A Zcash-től egy szerkezeti ponton tér el: nincs saját blokklánca. Az állapot az elfogadott envelope-ok determinisztikus újrajátszásából (replay) származik Bitcoin-sorrendben, ezért két helyes implementáció koordináció nélkül ugyanahhoz az állapothoz jut, és nincs szükség kihívásra vagy optimista visszaállításra
  • Három szerep szétválasztva: a Bitcoin publikál és sorrendez (nem validál), az indexerek újrajátsszák és kiszolgálják az állapotot, a tárcák építenek és fogyasztanak. Az indexer nem letétkezelő: tetszőleges gyökeret jelenthet, de nem tudja konzisztenssé tenni egy független újrajátszással
  • Replay-állapot: S = (T, N, R, H), ahol T a csak-hozzáfűző note-leaf Merkle-fa, N az elfogadott nullifier-ök halmaza, R[h] a blokk-szintű gyökér-térkép, H az elfogadott történet. A gyökér rögzítése csak a teljes blokk újrajátszása után történik, ezért minden megtartott magasságnak van jól definiált gyökere
  • Ciphertext-származtatott note-leaf: ℓ_j = H_leaf(const_salt, h_body, j, pk_eph,j, ct_note,j, h_aux,j). A levél nem a privát plaintextből, hanem a publikált mezőkből áll elő, így a titkosított szöveg lesz a híd a plaintext, az állapot és a későbbi költés között
  • A Zerocash serial-number hibájának javítása: a nullifier nf = H_nf(sk_nf, ρ, pos), ahol pos a replay által kiosztott fa-pozíció. Mivel a pozíciót nem a költő választja, két különböző note-nak akkor is különbözik a származtatási bemenete, ha a küldő újrahasználja a note-seedet
  • A sk_nf nem szabad witness-érték: az áramkör a sk_spend-ből származtatja, különben ugyanazt a note-ot több különböző nullifier-rel lehetne elkölteni
  • h_body testkötés: a bizonyítás csak a publikus bemeneti mezőket korlátozza, ezért a header, a h_anchor, a darabszámok és a ct_out egyetlen hash-be kötődnek. A bizonyítás bájtjai kimaradnak a hashelt részből, mert azok a h_body-ból keletkeznek. Replay minden állapotváltozás előtt ellenőrzi a kötést
  • Kulcshierarchia: sk_spend (költés), vk_in (bejövő megtekintés), vk_out (kimenő helyreállítás) külön ágakon, domain-szeparált HKDF-fel. A vk_in a ser(sk_spend) gyermeke, de csak olvasható; a vk_out a master szintjén válik szét. Egyetlen felfedési anyag sem tartalmaz seedet, sk_spend-et vagy sk_nf-et
  • Anchor-ablak: H - W ≤ h_anchor ≤ H - K_min. A profil W = 100, K_min = 1 (körülbelül 16 óra publikációs ablak). A W replay-szabály, nem konfiguráció: eltérő értékek eltérő elfogadási predikátumot adnak, és állapotdivergenciát okoznak
  • Biztonsági korlát (1. tétel): ε_btc(k) + c_H·Adv_cr_H + q·c_K·Adv_ks_Rtr + Adv_aead + Adv_auth. A q extrakciós faktor csak a tudás-tömörségi tagot szorozza; az ütközési és AEAD-redukciók feszesek
  • Malleabilitás: a h_body az egész envelope-ot egységként nem-malleálhatóvá teszi, de a Groth16 bizonyítás-újrandomizálást megenged. Ez nem eredményez kétszeres költést, mert a másolat újrapublikálja a nullifier-vektort, és a replay elutasítja; viszont megváltoztatja a hordozó tranzakció azonosítóját
  • Adatvédelmi tétel (2. tétel): q·Adv_zk + (n_o + q)·Adv_enc + n_i·Adv_prf + (q_nf · 2^-ℓ_nf)/2. Három játék: a bizonyítások szimulálása, a ciphertext-ek nulla-plaintextre cserélése, a nullifier-ök egyenletes sztringre cserélése
  • Amit nem tesz ki egy elfogadott átutalás: a note-plaintexteket, a Merkle-utakat, a sk_spend-et, a sk_nf-et, a viewing kulcsokat, a fogadói pk_d értékeket, és azt, hogy mely levelek szolgáltak bemenetként
  • Megmaradó szivárgás: az átutalás-aritás (1→2 és 2→1 megkülönböztethető), az anchor-kor, az envelope-csoportosítás (egy átutalás kimenetei ugyanazt a h_body-t hordozzák, ezért két fogadó megállapíthatja, hogy közös küldőjük van), és a díjtárca-kapcsoltság
  • A privacy-halmaz mérési fegyelme: egy nagy globális note-fa csak szintaktikai felső korlát. Az effektív halmaz |A_eff| = 2^H(P), ahol P a támadó posteriorja. A szerzők maguk idézik a Zcash empirikus elemzését, ahol a nagy nominális pool ellenére szűk maradt a tényleges halmaz
  • Implementációs profil: Groth16 (körülbelül 192 bájtos bizonyítás), egy OP_RETURN hordozó, 2→2 aritásnál 610 bájtos envelope (625 bájtos Bitcoin kimenet). A witness-hordozó alternatíva két tranzakcióval 438 vB, nagyjából negyed súlyköltségért
  • Standardness-feltevés: az egy-kimenetes OP_RETURN relay nem konszenzusgarancia, hanem a Bitcoin Core v30.0 enyhített -datacarriersize defaultjára épül (83 → 100 000 bájt), amit az operátorok visszaállíthatnak
  • AEAD-követelmény: egy egyszerű AEAD nem elég. A fogadói csatornának elköteleződő AEAD-nak (kulcs-elköteleződő, note-megnyitás-robusztus) és kulcs-privátnak kell lennie
  • Peg-in és peg-out kimarad: külön komponens, PIPE v2 alapú tervezett iránnyal. A tanulmány nem állítja, hogy a belépés vagy kilépés trustless, privát, tranzakció-kapcsolatmentes vagy cenzúra-ellenálló
  • Díjfinanszírozás: a tervezett irány egy PIPE-vezérelt díj-tár, ahol a felhasználó bizonyítja a jogosultságát, és a tár kiadja a hordozó tranzakció finanszírozását. A közzétevő nem ismeri meg a privát átutalás tartalmát, de a tár-hozzáférési minták és az időzítés továbbra is metaadatot adnak
  • A D függelék: opcionális KYC-lineage. Nulla-tudású rekurzív bizonyítás igazolhatja, hogy egy note jóváhagyott Bitcoin-bemenetből származik, és hogy az átutalások hitelesített fogadókon belül maradtak. A valódi evidencia és a dummy payload azonos kódolású és hosszúságú, ezért a láncon nem megkülönböztethető. A lineage csak akkor őrződik meg, ha minden felemésztett bemenet rendelkezik érvényes package-dzsel
  • Státusz: specifikáció és elemzés, nincs telepített hálózat. A PIPEs mögötti witness encryption a szerzők nyilatkozata szerint is kísérleti

Tanulmány: https://www.allocinit.xyz/uploads/shielded-bitcoin.pdf Kapcsolódó: Bitcoin PIPEs v2 (Cryptology ePrint Archive 2026/186), Shielded CSV (2025/068), Zcash protokollspecifikáció

Források

Huszonegy E117: a Bitcoin rétegei — gránittömb, katedrális, zsebpénz (2026-09-25)

Five építészeti hasonlata a Bitcoin rétegszerkezetére: az on-chain Bitcoin az alap, a föld alatti gránittömb (fundamentum), a Lightning a rá épülő kemény katedrális, a Cashu (ecash) pedig az egyszerű, mindennapi aprópénz. Az ecash nem önálló blokklánc, hanem bitcoin-fedezetű réteg a Lightning fölött: minden Cashu mintbe be van építve egy Lightning node, ezért a rendszer leginkább egy custodial Lightning node-hoz hasonlít, azzal a döntő különbséggel, hogy a felhasználó bearer eszközt tart a kezében, nem fiókegyenleget.

  • A Moneróhoz képest fundamentális különbség: a Monero alternatív blokklánc, saját protokollal, míg az ecash bármire ráépülhet, ugyanaz a protokollja. Five szerint a Lightning privátabb a Monerónál (legalábbis a küldő oldalán), az ecash pedig ennél is privátabb
  • A Monero technológiai kritikája: privátabb működéshez több adat és számítási kapacitás kell, a Monerónál körülbelül tízszer akkora a tárolási igény, mint a Bitcoin tranzakcióinál, a verifikáció pedig ennél is többszörös. A teljes készlet elvileg tranzakciónkénti elköteleződéssel igazolható, de volt bug a kódban, amit ki lehetett volna használni
  • A Cashu használati esete a mikrotranzakció: olyan olcsó egy tranzakció, hogy másodpercre lehet fizetni egy szolgáltatásért, és nem kell lejáró krediteket előre feltölteni. A feladott tulajdonság tisztán megfogalmazott: a kibocsátó nem tudja, ki a felhasználó, ezért nem tud szelektíven kizárni senkit
  • A szuverenitás kérdése: a bearer jellegnek ára van, ha elvesznek a tokenek, az olyan, mintha elveszne az aranyhoz szóló cetli. A BIP-39 szavakból generált tokensorozat megoldja a visszaállítást, de ehhez a kibocsátó közreműködése kell, ami privát szféra-veszteség

Elsődleges topic: privacy-tech.md Típus: másodlagos bejegyzés

Bitcoin Brief #92 — Shielded Bitcoin és a Liquid post-mortem (2026-09-28)

Kereszt-referencia a teljes magyar summaryhoz. A Bitcoin-technológiai szálak:

  • Shielded Bitcoin: a Bitcoin nem is látja a tranzakciót. Az árnyékolt tranzakció titkosított adatblokk OP_RETURN vagy witness adatban; a Bitcoin csak sorrendezi és időbélyegzi, az érvényességet külön indexer-szoftver ellenőrzi a full node mellett — az ordinalshoz hasonló meta-protokoll minta. Egy érvénytelen árnyékolt tranzakció bekerülhet egy blokkba: a Bitcoin nem ellenőrzi, az indexer dobja ki, és nem változtat egyenleget
  • Note és nullifier: az UTXO árnyékolt megfelelője. Az érték titkosított note-okban van. Költéskor a wallet egy nullifier-t publikál (egyszeri címke a note-ból és a kulcsból), konkrét zero knowledge prooftal, ami négy dolgot igazol felfedés nélkül: a note létezik a fában, jogosult vagy elkölteni, a nullifier helyes, és nem keletkezett új pénz. A Bitcoinnal szemben semmi nem törlődik — minden note egy örökké növekvő fába kerül, és az indexer csak a nullifier ismétlődését ellenőrzi (double spend védelem)
  • A peg a meg nem oldott rész. Valódi BTC be- és kijutása a rendszerből még nincs megtervezve. A terv a PIPEs v2 witness-encryption séma (federáció és vagyonkezelő nélküli peg), de a witness encryption bizonyítatlan gyakorlat, és a teljes javaslat korai alpha. Q és Max is ezt jelöli meg a bizalmi kérdés helyeként
  • A Liquid post-mortem technikai magja. A Bug A egy 2018 áprilisi rangeproof-cache hiba volt (bejelentve augusztus 2-án, javítva augusztus 11-re); a javítás hozta létre a Bug B-t, ahol a prefix nélküli cache-kulcsok miatt két különböző bizonyíték ütközhetett (a 12+3 és az 1+23 is 123-ként olvasódik). Ez a klasszikus javítás-generálta második hiba minta
  • A federációs bizalmi modell tanulsága. A 11/15 multisig pontosan úgy működött, ahogy tervezték — a hiba a szoftverben volt, ami eldönti, mi számít érvényes tranzakciónak. Max szerint a tervezés a fő pajzsra fókuszál, és nem veszi észre a kisebb rést a páncélon. Nem volt áramlási korlát (nem lehetett volna-e limitálni, hogy egy tranzakcióban ne lehessen a hálózat felét kivenni). A rezerv 4205 BTC-ról 197 BTC-ra esett, 3400 visszatért, körülbelül 602 BTC még a támadónál
  • Két Eclair DoS-hiba és négy LND advisory. Az Eclair 0.13.1 hibáit (túlméretezett feature bit üzenetek → körülbelül 300 MB allokáció az init üzenethez; tömörített channel query-k → 64 KB-ból 64 MB) a 0.14 javította májusban. Az egyiket egy LLM találta, a Project Loupe (Block) AI-támogatott bug huntingjában. Az LND-nél a magasra értékelt hiba: egy számlát elszámoltként lehetett megjelölni, miután az interceptor már törölte a fizetést — érintette a tapd 0.5-öt és korai LND-verziókat. Frissíts 0.21.3-ra vagy újabbra
  • x402: Lightning-fizetés HTTP-n. Szeptember 23-án bemerge-elték a Ben Carmen (Spiral) specifikációját. A HTTP 402 „Payment Required” státuszkódot éleszti fel: a szerver friss Lightning-számlát állít ki, aminek leírása az adott kérésre köteleződik el, az ügyfél visszaadja a preimage-et, a szolgáltató ellenőrzi a payment hash ellen. Q fenntartása: a protokollba merge-elve még semmit nem jelent, ha a weboldalak nem adoptálják
  • Wallet release-ek. SharkTheo 0.81 preview 5 az Ark protokollhoz (payjoin v2 Signeten, csak TOR + fail-closed, silent paymentek, kísérleti post-quantum aláírás, saját GitLab). Zeus 13.2.2 (SAT routing default, kritikus iOS iCloud keychain javítások, duress PIN most mindent töröl). Blockstream Green Android 5.7 és desktop 3.6 (2/2 és 2/3 multisig visszahozva, LNURL pay, konfigurálható Electrum gap limit)
  • SinaOS 1.3 (szeptember 23.): minimál live Linux USB-ről, Tails-szerű, signing device-ként építik. Multisig visszajárócím-ellenőrzés javítva; a több bemenetű tranzakciók elromolhattak vagy hamis visszajáró outputokat mutathattak legitimként. Egy fejlesztő, nagyon kevés független review — Q szerint semmiképp ne használd valódi pénzzel, és nem helyettesíti a Passport Prime-ot vagy a BitBoxot

Elsődleges topic: privacy-tech.md Típus: másodlagos bejegyzés

Huszonegy E118: a BIP-110 kudarca és a node-hatalom tévedése (Karo Zagorus, 2026-10-02)

A HUSZONEGY 118. epizódjában Karo Zagorus a nyár legfontosabb protokoll-szintű eseményét elemzi: a BIP-110-et, amit „brutálisnak” nevez. A szekció a protokoll-kormányzás tanulságait dokumentálja; a wallet-oldali részt a bitcoin-wallet-security.md tartalmazza.

A kezdeményezés tévedése

  • Amit hittek: hogy a Bitcoint úgy lehet módosítani, hogy néhány dolgot kizárunk a tranzakciók közül, amik „nem odavalóak”. A „Bitcoin pleb” társadalom úgy interpretálta a UASF-et (amely 2017-ben a SegWit-et aktiválta), hogy a társadalom képes a Bitcoin funkcióit végigerőszakolni — mert szerintük a node-ok kontrollálják a rendszer működését
  • A psyop Karo szerint: elhitették sok emberrel, hogy ők valakik a rendszeren belül, és rajtuk múlik annak működése. Karo: ha futtatsz egy node-ot, kábé semmit nem tudsz elérni vele
  • A technikai valóság: ha valaki a saját node-jában módosít, új chaint hoz létre, és akkor már nem a Bitcoint futtatja. Ha két egymást követő blokkot nem tud validálni, lekerült a főláncról, és újra kell indítania a blokkvalidációt. A node-on lehet állítani, de ennek limitjei vannak
  • Az aktiválási minta konkrétan: az OP_RETURN méretkorlátját csökkentené (~80 → ~32 byte), de nem állítaná meg a spam-protokollokat — az Ordinals és a Runes eleve felkészültek erre. Az Ocean.xyz alapértelmezett stratum végpontja BIP-110-re volt állítva, amit a felhasználóknak kézzel kellett átállítaniuk
  • A megkérdőjelezhető hátsó indok: a nyilvános érv a szexuális abúzus képek és a spam kizárása volt, mert különben betilthatják a Bitcoint vagy eljárás alá vonhatják a node-futtatókat. Karo szerint ez alapvetően nem igaz

A kudarc megmért eredménye és a konszenzus-mechanizmus

  • A lánc 99,85%-os hashpower-többséggel bukott el — a lázadó lánc nyolc óra alatt két blokkot bányászott, majd megfagyott. A BIP-szerkesztők eltávolították Luke Dashjr-t (Mark „Murch” Erhardt indítványára, mintegy 26 órával a fork elakadása után)
  • A helyes mechanizmus a konszenzus: össze kell hozni mindenkit, aki számít — a bányászoktól a usereken át a filozófusokig, a társadalom több rétegéig. Karo szerint egy nagyon nagy, sürgető probléma esetén ez gyorsan megtörténik, de egy szükségtelen dolgot megkérdőjelezhető indokokból áterőszakolni nem lehet
  • Karo nyíltan megnevezi a személyes motivációt: szerinte Luke elveszítette az összes bitcoinját, utána már mindegy volt, hogy bitcoinozik-e. Luke most a létező Bitcoint is csalásnak, „airdrop scamnek”, „pedócoinnak” nevezi, és csak azt ismeri el, ami a Blake2b-vel van. Karo szerint ez sok celebet behúzott, de nem változtat a technikai valóságon
  • A „Bitcoin plebek” szociális védőháló — amit Karo a szakdolgozatában is lekutatott — szerinte nagyon „perverzálódott” a BIP-110 által

A Liquid-incidens protokoll-oldala

  • A Liquid Networköt 2026. szeptember 6-án érte támadás: az Elements rangeproof-ellenőrző cache-ében lévő hibát kihasználva egyetlen tranzakció átment a validáción úgy, hogy a kimeneti érték nem volt fedezve a bemenetekkel. A támadó mintegy 4 000 fedezet nélküli L-BTC-t vert, és kiürítette a federáció bitcoin-tartalékának nagy részét
  • Feri szerint mintegy 650 bitcoint tartottak vissza; Karo viccelődik, hogy Adam Back kihozza a „retirement fundjából” — Feri szerint már ki is hozta: volt egy mozgás, pontosan 600 bitcoin
  • A Bitcoin kódjának érintetlensége: Karo szerint a Bitcoin a világon a legjobban átvilágított nyílt forráskódú szoftver az interneten. Feri szerint a kód eddig érintetlen maradt az AI korszakában is

Forrás: Epizód • Vendég: Karo Zagorus • Házigazda: Kovács Ferenc (Feri) • Magyar summary: summaries/huszonegy/2026-10-02_e118_kiszedheto_a_12_szo_a_hardvertarcadbol.md Elsődleges topic: bitcoin-wallet-security.md Típus: másodlagos bejegyzés

Vissza a tetejére