---
title: Bitcoin technológia és skálázás
category: topic
sources:
- (file not found — rabbit hole 411)
- 2026-06-12_rabbit_hole_recap-413_brave_new_world.md
- books/BROKEN-MONEY-FULL.md
- 2026-05-12_tftc_a_bitcoin_podcast_744_you_cannot_av.md
- 2026-09-22_bitcoin_optech_newsletter_423_recap.md
- 2026-09-24_shielded_bitcoin_private_transfers.md
- 2026-09-25_e117_lehet_a_bitcoin_olyan_privat_mint_a_keszpenz.md
- ungovernable_misfits/2026-09-28_bitcoin_brief_ep92_did_bitcoin_just_go_dark.md
- bitcoin_optech/2026-10-01_bitcoin_optech_newsletter_424_recap.md
- 2026-10-02_e118_kiszedheto_a_12_szo_a_hardvertarcadbol.md
created: 2026-04-21
updated: '2026-10-02'
tags:
- bitcoin
- lightning-network
- proof-of-work
- proof-of-stake
- cryptography
- scaling
- fedimint
- privacy
- digital-identity
- did
- verifiable-credentials
- ark
- bark
- cashu
- noah-wallet
- arky-wallet
- bitx-esp
confidence: high
summary: 'Bitcoin technológiai részletek Lyn Alden Broken Money alapján: blokklánc
  kompromisszumok, Lightning hálózat, likviditás/hálózati hatások, PoW vs PoS, kriptográfiai
  előzmények, Fedimint, digitális identitás (DID, verifiable credentials)'
---
é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

- [Bitcoin bányászat és energetika](bitcoin-mining-energy.md) — PoW energiafogyasztás
- [Privacy tech](privacy-tech.md) — Lightning privacy, Fedimint
- [Pénzügyi rendszer kockázatok](financial-system-risks.md) — fiat rendszer vs Bitcoin
- [Pénztörténet](monetary-history.md) — kriptográfiai előzmények kontextus

## 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 settlement networks](bitcoin-settlement-networks.md) — Bitcoin settlement vs FedWire
- [privacy tech](privacy-tech.md) — Cashu trust-minimization, Mullvad
- [bitcoin pleb values](bitcoin-pleb-values.md) — self-custody misszió, "stay humble, stack sats"
- [nostr ecosystem](nostr-ecosystem.md) — NIP-A3 payments, Nostr DMs



## 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](../ungovernable_misfits/2026-09-28_bitcoin_brief_ep92_did_bitcoin_just_go_dark.md). 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](https://huszonegy.world/podcast/kiszedheto-a-12-szo-a-hardvertarcadbol-igy-vedd-meg/) • 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