# Shielded Bitcoin: privát átutalások a Bitcoin L1-en > **Tanulmány:** Shielded Bitcoin: Private Transfers on the Bitcoin L1 > **Szerzők:** Clara Shikhelman, Mikhail Komarov, Aleksei Moskvin ([[alloc] init], allocinit.xyz) > **Intézmények:** [[alloc] init] > **Dátum:** 2026-09-24 > **Oldalak:** 55 (fő szöveg 22 szekció + A-D függelék + irodalomjegyzék) > **Forrás:** > **Kinyerés:** `pdftotext` (29 358 szó; a PDF szöveges réteggel rendelkezik) > **Téma:** Shielded-note metaprotokoll Bitcoin L1-en, konszenzusváltoztatás nélkül > **Alkalmazhatóság a saját rendszerünkre:** KÖZEPES (lásd a dedikált szekciót) --- ## Bevezetés és a lényeg A Bitcoin tranzakciós gráfja véglegesen nyilvános. Az álneves címek ellenére a gráfelemzés, a címklaszterezés és a lánc-metaadatok együtt gyakran kikövetkeztetik a tulajdonviszonyokat. A meglévő megoldások a probléma egy-egy szeletét kezelik: a CoinJoin és a PayJoin a heurisztikákat teszi megbízhatatlanabbá, a Silent Payments az címismétlést kerüli, a nagyobb kifejezőerejű konstrukciók viszont konszenzusváltoztatást igényelnek. Az összegek és a tranzakciószerkezet mindeközben nyilvános marad. A **Shielded Bitcoin** egy shielded-note átutalási metaprotokoll, amelynek burkológép-adatát (`envelope`) a Bitcoin L1-en lehet publikálni **ma**, konszenzusváltoztatás nélkül. A szerzők három kutató a [[alloc] init] cégtől, a tanulmány 2026. szeptember 24-én jelent meg. A design a Zcash és a korábbi shielded-note rendszerek architektúrájából kölcsönöz: az érték titkosított note-okban van, a költést nyilvános nullifier-ök jelölik, az érvényességet nulla-tudású bizonyítások igazolják. A Zcash-től **egy szerkezeti ponton** tér el: nem vezet be saját blokkláncot és saját konszenzust. Minden protokoll-adat a Bitcoinon jelenik meg, az átutalás érvényességét a PIPEs v2 mechanizmus kényszeríti ki, a shielded állapot pedig az elfogadott átutalások determinisztikus újrajátszásával (`replay`) áll elő, Bitcoin-sorrendben. A legfontosabb állítások: - **Nincs konszenzusváltozás.** Sem soft fork, sem új lánc, sem külön konszenzus. A Bitcoin csak publikációs és sorrendezési réteg. - **Az állapot újrajátszásból származik.** Két helyes implementáció, ugyanazon a Bitcoin-előtagon futva, koordináció nélkül ugyanahhoz a shielded állapothoz jut. Ezért nincs szükség kihívásra, vitarendezésre vagy optimista visszaállításra. - **A nullifier a replay által kiosztott pozícióhoz kötődik.** Ez az egyik legfontosabb technikai döntés: a Zerocash eredeti konstrukciójában a serial number a fogadó kulcsából és a küldő által választott randomitásból állt, ezért randomitás-újrahasználatnál ütközött. Itt a pozíciót a replay osztja ki, ezért két különböző note-nak akkor is különbözik a nullifier-származtatási bemenete, ha a küldő újrahasználja a note-seedet. - **A költési jogosultság a felhasználónál marad.** A metaprotokoll szintjén az átutalás nem kasztodiális: az indexerek és a replay réteg olvasási jogot kapnak, költési jogot nem. - **A `h_body` a teljes testre ható kötés.** Enélkül bármelyik nem korlátozott envelope-mezőt át lehetne írni a bizonyítás után. A bizonyítás bájtjai kimaradnak a hashelt részből, mert azok a `h_body`-ból keletkeznek. - **Az adatvédelem mérési kérdés, nem állítás.** A szerzők explicit szivárgási függvényt (`Leak`) definiálnak, és a fő adatvédelmi tétel ehhez képest fogalmaz. A nominális privacy-halmaz és a tényleges, entrópia-alapú halmaz nem ugyanaz. - **A be- és kilépés nincs benne.** A peg-in és a peg-out külön komponens, külön bizalmi és élősségi feltételekkel, és a tanulmány szándékosan nem állítja róluk, hogy trustless, privát vagy cenzúra-ellenálló. - **Egy konkrét implementációs profil rögzített**, hogy a független implementációk interoperáljanak: Groth16 bizonyítás, egy OP_RETURN hordozó, 2 bemenet 2 kimenet esetén 610 bájtos envelope, `W = 100` és `K_min = 1` anchor-ablak. A profil bármely elemén eltérő implementáció **nem** ugyanazon a hálózaton működik. ## Összegzés A tanulmány egy olyan shield-ed note metaprotokollt ír le, amely a Bitcoint kizárólag publikációs és sorrendezési rétegként használja, a shielded állapotot pedig az elfogadott envelope-ok determinisztikus újrajátszásából származtatja. Az architektúra három felelősséget választ szét: a Bitcoin rögzíti a bájtokat és azok sorrendjét, az indexerek újrajátsszák és szolgálják ki az állapotot, a tárcák építik az envelope-okat és fogyasztják az állapotot. Ez a szétválasztás az, ami a Zcash-szerű shielded konstrukciót konszenzusváltoztatás nélkül teszi lehetővé. A technikai mag két döntés körül forog. Az első a **ciphertext-származtatott note-leaf**: a levél nem a privát plaintextből, hanem a publikált `h_body`, kimeneti index, `pk_eph` és `ct_note` mezőkből áll elő, így a titkosított szöveg lesz a híd a privát plaintext, az újrajátszott állapot és a későbbi költés között. A második a **replay által kiosztott pozíció** bevonása a nullifier-származtatásba, ami a Zerocash serial-number újrahasználati hibáját zárja ki. A biztonsági elemzés formális: nyolc cél, öt lemma és egy összegzett korlát, amely a Bitcoin közös-előtag feltevéséből, a hash-ütközésből, a bizonyítási rendszer tudás-tömörségéből és az AEAD-ból áll össze. Az adatvédelmi elemzés ugyanilyen fegyelmezett: a szerzők előbb definiálják a szivárgási függvényt, majd játékok sorozatával mutatják meg, hogy a publikált tranzkriptum csak a `Leak`-en keresztül függ a privát történettől. A legfontosabb fenntartások: a rendszer **nincs telepítve**, a tanulmány specifikáció és elemzés, nem működő hálózat. A be- és kilépési mechanizmus (PIPEs v2 alapú peg) külön tanulmány tárgya, és a PIPEs mögötti witness encryption a szerzők saját nyilatkozata szerint is kísérleti. A nominális privacy-halmaz mérete nem garantálja a tényleges adatvédelmet: a tanulmány maga idézi a Zcash empirikus elemzését, ahol a nagy pool ellenére szűk maradt a tényleges halmaz. ## A probléma és a pozicionálás A szerzők a bevezetőben leszögezik, hogy a Bitcoin tranzakciós gráfja véglegesen nyilvános, és hogy az álneves címek ellenére a gráfelemzés, a címklaszterezés és a kiegészítő metaadatok együtt gyakran kikövetkeztetik a tulajdonviszonyokat. Ez a kiindulópont, nem mellékes megjegyzés: a tanulmány egésze erre a tényre épül. A kapcsolódó munkák négy csoportra bomlanak, és a szerzők mindegyiknél megmondják, hol a határ. **Adatvédelem a Bitcoin UTXO-modellen belül.** A CoinJoin, a PayJoin, a címrotáció és a Silent Payments javítják az adatvédelmet, de nem változtatják meg azt a tényt, hogy a Bitcoin tranzakciók átlátszóak. Az összegek, az időzítés, a díjak, a bemeneti és kimeneti szerkezet és a gráf nagy része látható marad. Ezek a technikák a klaszterezést nehezítik, de nem adnak shielded átutalási modellt, ahol a küldő, a fogadó, az összeg és a note-plaintext egy közös titkosított állapoton belül titkos marad. **Saját konszenzussal rendelkező shielded kriptovaluták.** A Zerocoin úttörő volt a mint és spend műveleteknél, a Zerocash általánosította nulla-tudású bizonyításokra, a Zcash Sapling és Orchard protokollcsaládja pedig ezt telepítette. A Monero más úton jár: ring aláírások, stealth címek és confidential transaction technikák kombinációja. A szerzők mindkettőnél ugyanazt a megkülönböztetést teszik: ezek saját láncuk natív konszenzusszabályaival kényszerítik ki az érvényességet, a Shielded Bitcoin viszont változatlanul hagyja a Bitcoin konszenzusát, és az állapotot a Bitcoinon publikált envelope-okból származtatja. Az Aztec a programozható adatvédelem irányába visz tovább, ami fontos, de a privát átutalásokhoz képest lényegesen összetettebb. **Bitcoinhoz horgonyzott overlay-ek kliensoldali adattal.** A legközelebbi rokon a **Shielded CSV**, amely szintén soft fork nélküli privát Bitcoin-átutalást céloz, és a proof-carrying data hagyományára épül. A szerzők itt fontos különbséget tesznek: a Shielded CSV jelenleg elméleti protokolljavaslat, nem telepített rendszer, és a Bitcoin-denominált érték használatához hídmechanizmusra (BitVM-stílusú konstrukciókra) támaszkodik. A döntő trade-off viszont az adatelérhetőségi modell: a Shielded CSV nem publikál minden információt, ami a privát rendszerállapot Bitcoin-történelemből való rekonstrukciójához kell, hanem az érmetulajdonosnak kell megtartania a kliensoldali állapotot és bizonyítási adatot. Ha ez a helyi állapot elveszik, a privát tranzakciótörténet a nyilvános láncból általában nem állítható helyre. Az RGB és a Taproot Assets ugyanebbe a családba tartozik: a Bitcoin publikációs, sorrendezési vagy elköteleződési réteg, az eszköz-specifikus jelentést pedig a konszenzuson kívül értelmezik. **Hídolt végrehajtási környezetek.** A föderált sidechainek, az EVM-kompatibilis hálózatok és a BitVM-stílusú mechanizmusok lényegesen gazdagabb szemantikát tudnak támogatni, de a Bitcoinhoz való kapcsolatukat a híd közvetíti, ezért öröklik a híd letétkezelési, bizalmi és élősségi feltevéseit. A Shielded Bitcoin szerzői szerint ez nem ugyanaz a viszony, mint amikor a felsőbb réteg állapota a Bitcoin saját publikációs és sorrendezési tulajdonságaiból **folyamatosan származik**. A pozicionálás lényege egy mondatban: a determinisztikus újrajátszás a kanonikus Bitcoin-történelem fölött az, ami az egészet lehetővé teszi. Minden helyes implementáció ugyanazt a shielded állapotot rekonstruálja ugyanazokból a publikált átutalásokból, ezért eltérő privát állapotok nem keletkezhetnek, és az átutalási rétegnek nem kell saját kihívás-válasz vagy visszaállítási mechanizmus. ## Architektúra: publikáció, újrajátszás, tárca A rendszer három felelősséget választ szét élesen. A **Bitcoin** rögzíti minden envelope bájtjait és azok helyét a láncon, de shielded állapotátmenetet nem validál. Az **indexerek** figyelik a Bitcoin láncot a Shielded Bitcoin átutalásokért, Bitcoin-blokksorrendben újrajátsszák az elfogadott envelope-okat, és fenntartják a note-fát, a nullifier-halmazt és a blokk-szintű gyökér-történetet. A **tárcák** ezt az újrajátszott állapotot fogyasztják: felismerik a bejövő note-okat, Merkle-tanúkat szereznek, és költéseket építenek. Az indexerek nem letétkezelők, és nem rendelkeznek költési jogosultsággal. Az állapotot rekonstruálják és kiszolgálják, de a tárca az állapotot a Bitcoinon publikált adatokból függetlenül is ellenőrizheti. Egy tisztességtelen indexer cenzúrázhat envelope-okat vagy tetszőleges gyökeret jelenthet, de nem tudja azt a gyökeret konzisztenssé tenni ugyanazon Bitcoin-történelem független újrajátszásával. A shielded állapot formális definíciója az **1. definíció**: bármely replay-határon a metaprotokoll-állapot az `S := (T, N, R, H)` négyes, ahol `T` az csak-hozzáfűző note-leaf Merkle-fa, `N` az elfogadott nullifier-ök halmaza, `R` a megtartott blokk-magasság térkép `R[h]`, `H` pedig az elfogadott átutalás-történet replay-sorrendben. A replay viselkedése pontosan rögzített. Minden elfogadott átutalásnál származtatja az `ℓ` értékeket a nyilvános kimeneti adatokból, hozzáfűzi a leveleket a `T`-hez, és beilleszti a publikált nullifier-öket az `N`-be. Egy átutalás érvénytelen, ha ugyanazt a nullifier-t kétszer tartalmazza, vagy ha bármelyik nullifier-e már szerepel az `N`-ben. Az érvénytelen envelope-ok nem módosítják az újrajátszott állapotot. A gyökereket nem minden elfogadott átutalás után rögzítik: minden `H` blokkra az indexer a `H-1` utáni gyökérből indul, kanonikus sorrendben feldolgozza a tranzakciókat, és a keletkező gyökeret csak a teljes blokk újrajátszása után tárolja `R[H]` néven. Ha a blokk nem tartalmaz elfogadott átutalást, `R[H] = R[H-1]`, tehát minden megtartott magasságnak van jól definiált gyökere. Az envelope nem publikálja a teljes anchor-gyökeret, hanem csak a `h_anchor` blokkmagasságot. Az indexer a replay során lokálisan rekonstruálja a megfelelő gyökeret `r_anchor := R[h_anchor]` formában. Ez a `h_anchor` tehát egy tömör hivatkozás egy blokk-szintű replay-ellenőrzőpontra, nem shielded-átutalás sorszám és nem az elfogadott protokoll-események számlálója. **Az anchor-ablak.** A protokoll-szintű érvényes anchor-ablakot egy maximum és egy minimum mélység definiálja: `H - W ≤ h_anchor ≤ H - K_min`, ahol `H` az éppen újrajátszott Bitcoin-blokk, `W` a maximális anchor-életkor, `K_min` pedig a protokoll által megkövetelt minimális anchor-mélység. Mindkettő Bitcoin-blokkban mért érték. Itt a szerzők egy fontos figyelmeztetést tesznek: `W` értéke **replay-szabály, nem telepítési konfiguráció**. `W` különböző elfogadott értékei különböző érvényességi predikátumot adnak az indexereknek, és minden olyan láncra, amely tartalmaz egy predikátum által elfogadott, a másik által elutasított átutalást, a replay eltérő shielded állapotot származtat. A `K_min` a legkisebb mélység, amellyel az anchor-gyökér már definiált az aktuális blokk feldolgozása előtt; a legkisebb természetes választás `K_min = 1`, ami megengedi `R[H-1]`-et, de tiltja `R[H]`-t, és ezzel azt is megakadályozza, hogy egy `H` blokkban létrehozott note-ot ugyanabban a blokkban elköltsenek. A tárca ezen felül szigorúbb helyi politikát alkalmazhat: `K_wallet ≥ K_min`. Ez a határ nem protokoll-szabály, hanem annak kifejezése, mennyi bizonyosságot akar a tárca arról, hogy a bizonyításhoz használt gyökér az aktív láncon marad. Az átszervezési biztonság külön tárca-politikai kérdés, mert ha a tárca `R[H-1]` ellen építi a bizonyítást, egy egyblokkos átszervezés kicserélheti a `H-1` magasságú blokkot, megváltoztathatja az ottani gyökeret, és a bizonyítás érvénytelenné válik az új aktív láncon. A bizonyítás ilyenkor nem hibás: olyan állapotra készült, amely már nem az aktív lánc újrajátszásából adódó állapot. A maximális életkor más célt szolgál: megadja, meddig marad elfogadható egy kiválasztott anchor a bizonyítás elkészítése után. Ha `W` túl kicsi, a tárcának kevés ideje marad a publikálásra, ami érzékennyé teszi a díjkésésekre, az offline aláírásra, a lassú koordinációra és a relayer-munkafolyamatokra. A `W` növelése közvetlen kockázatot nem hoz, mert a replay az aktuális `N` ellen ellenőrzi az összes publikált nullifier-t az anchor korától függetlenül. A költségek operatívak: hosszabb gyökér-történetet kell megtartani, és a szokatlan anchor-életkorok ujjalenyomatként működhetnek. Ha a legtöbb tárca 6 és 20 blokk közötti mélységű anchor-t használ, és egy átutalás 700 blokkosat, az offline aláírást, relayer-késést vagy nem szabványos tárca-politikát sugallhat. ## Note-modell, kulcshierarchia és címek A shielded tulajdon alapegysége a **note**, amely szerepében a Bitcoin UTXO-hoz hasonlít: diszkrét értékdarab, amelyet a tulajdonosa később elkölthet. A különbség az, hogy a note a nyilvános láncon titkosítással és kapcsolódó nyilvános protokoll-adattal jelenik meg, nem a plaintext tartalmával. A note plaintext meglepően kicsi, és a szerzők ezt tudatos tervezési döntésként mutatják be: ``` pt_note := (v, d, r_seed) ``` Itt `v` a kanonikus előjel nélküli satoshi összeg, `d` a diverzifikált fogadási útvonalat azonosítja, `r_seed` pedig friss, note-specifikus randomitás. A többi note-szintű értéket nem tárolják plaintext mezőként, hanem determinisztikusan származtatják a seedből: ``` ρ := H_ρ(r_seed) sk_eph := ScalarFromBytes(H_eph(r_seed)) pk_eph := [sk_eph] G_d ``` A `ρ` a nullifier-származtatás note-specifikus bemenete, a `sk_eph` a note efemer titkos kulcsa a kimeneti titkosításhoz, a `pk_eph` pedig a hozzá tartozó publikált efemer kulcs. A fogadónak csak a `(v, d, r_seed)` hármast kell visszafejtenie a fogadói ciphertextből. Utána a tárca újraszármaztatja `ρ`-t, `sk_eph`-et és `pk_eph`-et, ellenőrzi, hogy a származtatott `pk_eph` megegyezik az elfogadott envelope-ban publikálttal, majd ellenőrzi, hogy a hozzá tartozó `ℓ` az, amit a replay kiosztott. Mivel a note a Bitcoinra titkosított ciphertextként kerül, a kisebb plaintext közvetlenül csökkenti a kimenetenkénti láncköltséget. A note-levél egy `h_aux` mezőt is hordoz, amely **nem** része a titkosított note-plaintextnek, és nem kerül bele a `ct_note`-ba. A küldő adja meg a note létrehozásakor, és a nyilvános levél-származtatásba kerül be. A `h_aux` jelenleg a `aux_null` kanonikus konstansra van rögzítve és nem szerializálódik, de fenntartott bővítési hely: a tervezett felhasználás egy atomi swap hash-lockjának elkötelezése a note létrehozásakor, anélkül hogy a kiegészítő adat a note-plaintextbe kerülne. Egy note három állapot egyikében van: **létrehozott**, ha a levele bekerült a fátba a replay által; **elkötött**, ha a nullifier-e publikálva és elfogadva lett; vagy **megerősítetlen**, ha csak egy el nem fogadott vagy még újra nem játszott envelope-ban szerepel. Egy note addig nem költhető, amíg nincs megerősített pozíciója a note-fában. **Kulcshierarchia.** A kulcsmodell a költési jogosultságot, a bejövő megtekintést és a kimenő helyreállítást külön tárca-képességekre bontja, egyetlen seedből, rögzített, domain-szeparált HKDF-SHA256 címkékkel. A táblázat szerinti származtatási lánc: - `sk_master = HKDF_master(seed_wallet)` - `sk_spend = ScalarFromBytes(HKDF_spend(sk_master))` - `sk_nf = HKDF_nf(ser(sk_spend))` - `vk_in = HKDF_in(ser(sk_spend))` - `vk_out = HKDF_out(sk_master)` A szerkezeti lényeg a szülőviszonyokban van. A `sk_nf` a `ser(sk_spend)` gyermeke, ezért a nullifier-származtatás a költési jogosultsághoz kötve marad. A `vk_in` szintén a `ser(sk_spend)` gyermeke, de **csak olvasható**: a `vk_in` felfedése a bejövő note-okat mutathatja meg, költést nem engedélyez. A `vk_out` a `sk_master`-nél válik szét, és a kimenő történetet tárhatja fel, de nem ad `sk_spend`-et vagy `sk_nf`-et. Egy fogadási útvonalhoz a tárca egy `d` diverzifikálót választ: ``` sk_view := ScalarFromBytes(HKDF_view(vk_in)) G_d := DiversifyHash(d) pk_d := [sk_view] G_d addr_d := (d, pk_d) ``` A fizetési cím nyilvános, és kizárólag az egyenlet objektumaiból áll. A küldő a `pk_d`-t használja a fogadói Diffie-Hellman számításban, és a `d`-t helyezi a titkosított note-plaintextbe. A visszafejtés után a fogadó a `d` alapján azonosítja a helyi fogadási útvonalat, és újraszármaztatja a `pk_d`-t a `vk_in`-ből. A diverzifikáló tehát az cím-névtér része, nem önálló költési jogosultság-forrás. **Felfedési és auditmodell.** A felfedés tárca-vezérelt, csak olvasható művelet. Sem konszenzusszabály, sem protokoll-hátsóajtó, sem alternatív költési útvonal. Nincs globális felfedési kulcs, és a felfedési képességek nem ruháznak át letétkezelést vagy költési jogosultságot az auditornak vagy bármely protokoll-szolgáltatónak. A szerzők négy felfedési módot definiálnak: - **IncomingView:** a `vk_in` megosztása, ha az auditornak önállóan meg kell találnia a tárca által fogadott kimeneteket az elfogadott történelemben. Hasznos bevétel-ellenőrzéshez és a fogadott note-plaintextek helyreállításához. Csak olvasható, nem ad hozzáférést a kimenő helyreállítási rekordokhoz, nem azonosítja, mely note-okat választották bemenetként, és nem ad költési jogosultságot. - **OutgoingView:** a `vk_out` megosztása a küldő oldali rekordok vizsgálatához. Költség-átvizsgáláshoz, partneri egyeztetéshez és a `ct_out`-ból származó küldési előzmények bizonyításához hasznos. Nem azonosítja azokat a bemeneti note-okat, amelyeket ezek az átutalások felemésztettek. - **NoteOpening:** egy konkrét note, kimenet, átutalás vagy riportbejegyzés megnyitása, ha az audit helyi. Az auditor a megnyitott plaintextet az elfogadott envelope-hoz, az újrajátszott note-levélhez, a Merkle-úthoz és az igényelt pozícióhoz ellenőrzi. - **DerivedReport:** riport exportja, ha az auditornak csak egy korlátos állítás kell, például időszaki beáramlás, kiáramlás, partneri összesítés, note-tulajdon vagy egyenleg egy `H` magasságon. A szerzők figyelmeztetnek, hogy a nyers `vk_in` és `vk_out` széles olvasási képesség. A `Q` hatókör korlátozza az audit-állítást, de kriptográfiailag nem korlátozza a nyers viewing kulcsot: aki `vk_in`-t vagy `vk_out`-ot kap, bármely elérhető replay-történelemre alkalmazhatja. Ha az auditornak nem szabad megismernie a nem kapcsolódó egyező történelmet, a tárcának note-megnyitást vagy származtatott riportot kell használnia. És ami a legfontosabb: **egyetlen felfedési anyag sem tartalmaz `seed_wallet`-et, `sk_spend`-et vagy `sk_nf`-et**, mert a `sk_nf` kizárása azt is megakadályozza, hogy a felfedés általános nullifier-összekapcsoló eszközzé váljon. ## A protokoll: levél, nullifier, envelope és kötés **Note-levél és nullifier.** A replay minden létrehozott kimenethez egy kanonikus note-fa levelet származtat a nyilvános envelope-adatokból: ``` ℓ_j := H_leaf(const_salt, h_body, j, pk_eph,j, ct_note,j, h_aux,j) ``` A `j` a zéró-alapú kimeneti index az aktuális envelope-on belül, nem a globális Merkle-pozíció. A globális `pos`-t a replay osztja ki később, amikor az elfogadott note-leveleket Bitcoin-sorrendben hozzáfűzi a fához. Későbbi költéshez a tárca mindkét azonosítót tárolja: a létrehozási kimeneti indexet, ami újraszármaztatja a note-levelet, és a kiosztott fa-pozíciót, amit a Merkle-út és a nullifier-reláció használ. A költött note-okra a nyilvános spend-marker reláció: ``` nf := H_nf(BytesToField(sk_nf), BytesToField(ρ), pos) ``` Itt `sk_nf` a nullifier-származtatást a költő által ellenőrzött titkos anyaghoz köti, `ρ` a nullifier-t note-specifikussá teszi, a `pos` pedig a költést a note-levél globális fában elfoglalt kiosztott pozíciójához. Újrajátszott metaprotokollban ez a pozíció a költési identitás része. A szerzők itt egy kulcsfontosságú megkötést tesznek: a `sk_nf` **nem** önálló witness-titok. Az áramkör determinisztikusan származtatja a `sk_spend`-ből, és elutasítja azt a konstrukciót, amely lehetővé tenné a bizonyítónak, hogy a `sk_nf`-et külön válassza. Erre a kötésre azért van szükség, hogy egy költési jogosultság egy nullifier-származtatási utat implikáljon egy adott note-hoz és pozícióhoz. Enélkül ugyanazt a note-ot többször lehetne elkölteni különböző nullifier-ökkel. Az áramkör-szintű tulajdonosi szabály megköveteli, hogy minden költött bemeneti note-ra a `sk_spend`-ből származtatott diverzifikált fogadási kulcs egyezzen a note ciphertext-relációjában használt `pk_d`-vel. Ez a szabály **csak a bemenetekre** vonatkozik: a létrehozott kimenetek a cél fizetési címéről választott fogadói oldali `pk_d`-re titkosítanak, és nem származtatják azt a küldő `sk_spend`-jéből. **Az envelope.** A logikai envelope szerkezete hét mezőből áll a bizonyítás előtt: `header` (mágikus bájtok, verzió, átutalás-típus), `h_anchor`, `input_count`, `output_count`, a nullifier-ök vektora, a kimenetenkénti `pk_eph` vektor, a fogadói ciphertext-ek vektora, a `ct_out` küldő-helyreállítási ciphertext, végül a `π` bizonyítás. A bináris sorrend rögzített, és a `π` a test bájtjai **után** szerializálódik. **Testkötés.** A bizonyítás csak azokat a mezőket korlátozza, amelyek publikus bemenetként az áramkörbe kerülnek. A többi publikált mező nincs egyenként kitéve az ellenőrzőnek: a szerializált header, a `h_anchor`, az explicit bemeneti és kimeneti darabszám, és a `ct_out`. Explicit elköteleződés nélkül ezek bármelyike újraírható lenne a bizonyítás után anélkül, hogy a bizonyítás-ellenőrzést befolyásolná. A `h_body` zárja be ezt a rést, egyetlen objektumként kötelezve el a teljes nyilvános testet: ``` h_body := H_body(const_salt || canonical_transfer_body) ``` A `π` mező kimarad a hashelt bájtokból, mert a `h_body`-ból keletkezik és csak a bizonyítás befejezése után fűződik hozzá; a hashelése körkörös lenne. Mivel a hash az egész testet lefedi, a publikált envelope egységként nem malleálható. A kötés a note-fába is elér: minden kimenet `ℓ_j`-je a `h_body`, a kimeneti index, a `pk_eph,j` és a `ct_note,j` együtteséből keletkezik, ezért ugyanaz a ciphertext egy másik átutalásban vagy más kimeneti pozícióban különböző levelet ad. A replay a kötést **minden állapotváltozás előtt** ellenőrzi. **Az átutalási állítás.** A publikus állítás a bizonyítás és a replay közötti interfész: a származtatott `r_anchor`, a bemeneti és kimeneti darabszámok, a nullifier-ök, a kimenetenkénti `pk_eph` és `ct_note` értékek, valamint a `h_body`. A `h_anchor` önmagában nem külön bizonyítási bemenet, hanem a `h_body`-on keresztül kötődik. A nullifier-egyediséget a replay kényszeríti ki, nem az áramkör. Az áramkör kilenc feltételt igazol egy átutalásra: minden bemeneti note létezik a kiválasztott `r_anchor` alatt; a bizonyító ismeri a kanonikus pozíciót és a Merkle-utat; ismeri a költéshez szükséges titkokat; a publikált nullifier-ök pontosan a költött bemeneti note-okból származtatott értékek; a nyilvános `pk_eph` és `ct_note` értékek ugyanazokat a kimeneti note-okat titkosítják, amelyeket az áramkör használ; a kimeneti levél-származtatásba kerülő publikus mezők azok, amelyeket a `h_body` köt és a bizonyítás ellenőriz; minden érték kanonikus satoshi összeg a megengedett tartományban; a bemeneti értékek összege egyenlő a kimenetiek összegével moduláris túlcsordulás nélkül; és a Bitcoinra publikált envelope ugyanaz, amelyre a bizonyítás kötődik. A **witness** a privát adatot tartalmazza. Bemenetenként: érték, diverzifikáló, seed, a létrehozási `h_body`, a létrehozási kimeneti index, a `pk_eph`, a `ct_note`, a pozíció és a Merkle-út. Kimenetenként: érték, `d`, `pk_d`, seed. Emellett egyetlen `sk_spend`, ami az összes bemeneti költést engedélyezi. A szerzők kifejezetten kizárják a witnessből az előre kiszámított note-leveleket, nullifier-öket, `ρ`-t és `sk_eph`-et: ezeket az áramkörön **belül** kell származtatni, hogy az áramkörön kívüli segédlogika ne tudjon csendben eltérni az áramkör szemantikájától. A `sk_nf` szintén nem szabad witness-érték. **Replay és elfogadás.** Minden envelope-nak először egy közös validációs rétegen kell átmennie: a bináris payload parse-olható, a mágikus bájtok és a verzió egyeznek, a vektorhosszak megegyeznek a deklarált darabszámokkal, a görbepontok dekódolhatók, és a bizonyítás által kötött `h_body` egyenlő a kanonikus testből újraszámított értékkel. Utána az indexer ellenőrzi, hogy `h_anchor` az érvényes ablaksávban van, származtatja `r_anchor`-t az aktív lánc gyökértérképéből, elutasítja az ismétlődő vagy már jelen lévő nullifier-öket, és ellenőrzi a bizonyítást a származtatott gyökér ellen. A replay **csak azután** módosítja a kanonikus állapotot, hogy minden érvényességi feltétel teljesült. Egy elutasított envelope az `S`-t változatlanul hagyja, soha nem alkalmazódik részlegesen. A 2. definíció ezt formalizálja: az `Accept(S, B, e)` predikátum hamis értéke esetén az állapotátmenet identitás, igaz értéke esetén a fa, a nullifier-halmaz és a történet a megadott módon frissül. **Átszervezés.** A replay az aktív láncon van definiálva, ezért egy Bitcoin-átszervezés megváltoztatja a bemenetét. `R[h]` megváltozhat az első kicserélt magasságra és minden utána következőre. Egy envelope, amelynek `h_anchor`-ja a kicserélt láncon lévő gyökérre hivatkozott, csak akkor fogadható el az új aktív láncon, ha a bizonyítása még mindig ellenőrződik az adott magasságra most származtatott gyökér ellen. A mempool soha nem replay-állapot: a tárcák kizárólag az elfogadott blokkok determinisztikus újrajátszásából nyert gyökerek ellen építenek költési bizonyítást. ## Biztonsági elemzés Az elemző rész nyolc célt rögzít (G1-G8): replay-egyezés, kétszeres költés elleni ellenállás, egyensúly, test-állítás kötés, költési jogosultság, tárca-helyreállítás, átutalás tömörsége és tranzkriptum-adatvédelem. Az első hét célt az 1. tétel összegzi egyetlen korlátban: ``` ε_btc(k) + c_H · Adv_cr_H(λ) + q · c_K · Adv_ks_Rtr(λ) + Adv_aead(λ) + Adv_auth(λ) ``` ahol `ε_btc(k)` a Bitcoin közös-előtag feltevésének bukási valószínűsége `k` mélységen, `Adv_cr_H` a hash-ütközés előnye, `Adv_ks_Rtr` a bizonyítási rendszer tudás-tömörségi előnye, `q` az elfogadott envelope-ok száma, `c_H = c_K = 3` a közreműködő lemmákat gyűjti össze, `Adv_aead` a titkosítás integritás-előnye, `Adv_auth` pedig a becsületes note ellopásának előnye. A szerzők megjegyzik, hogy a **per-envelope extrakciós faktor `q` csak a tudás-tömörségi tagot szorozza**: az ütközési és AEAD-redukciók feszesek, mert a publikált objektumok közül bármelyik ütköző vagy hamisító példány közvetlenül töri meg az egy-példányos játékot. **Kétszeres költés.** Az 1. lemma a `Adv_cr_H + q · Adv_ks_Rtr` korlátot adja. Az indoklás szerkezeti: minden elfogadott bemenet olyan nullifier-t publikál, amely a note-specifikus `ρ`-ból, a `sk_nf` kulcsanyagból és a replay által kiosztott `pos`-ból származik. A replay elutasítja az ismétlődő nullifier-t egy envelope-on belül és az `N_C` ellen. A költő **nem választja meg** a `pos`-t: azt akkor osztja ki a rendszer, amikor a kimeneti levél bekerül a note-fába, ezért ugyanazon költés újbóli publikálása egy másik `h_anchor` ellen megőrzi a nullifier-t. Itt jön a Zerocash-sel való összehasonlítás, ami a tanulmány egyik legérdekesebb megjegyzése. Mivel a nullifier a replay által kiosztott `pos`-hoz kötődik, a különböző elfogadott note-oknak akkor is különbözik a származtatási bemenetük, ha a küldő újrahasználja az `r_seed`-et. Ez elkerüli az eredeti Zerocash konstrukcióban azonosított sorozatszám-újrahasználati hibát, ahol a serial number a fogadó kulcsát kombinálta a küldő által választott randomitással, ezért randomitás-újrahasználatnál ütközött. **Tömörség, egyensúly, jogosultság.** A 2. lemma `q · Adv_ks_Rtr` korlátot ad az átutalás tömörségére, az 1. következmény pedig ebből vezeti le az egyensúlyt és a költési jogosultságot. Az érvelés: a replay nem vizsgál titkosított értékeket, csak akkor fogad el egy átutalást, ha a bizonyítás ellenőrződik egy olyan publikus állításra, amelynek witnesse kielégíti az `R_tr` relációt, ami ellenőrzi a note-tagságot, a Merkle-út konzisztenciáját, a bemeneti tulajdont, a nullifier-származtatást, az értéktartományt és az egészértékű értékmegmaradást. A `vk_in` és a `vk_out` csak megtekintési képességek, és az `R_tr` nem fogadja el őket költési jogosultságként. A 2. következmény a főkönyv-egyensúlyt és a lopás-ellenállást köti össze, hozzáadva az `Adv_auth` tagot. A bizonyítás vázlata szerint az egyensúlyi invariáns indukcióval következik az elfogadott belső átutalásokon: minden elfogadott belső lépés eltávolítja a bemeneti értékeket és egyenlő kimeneti értékeket ad hozzá, ezért `V_active` változatlan marad. A belépés és a kilépés konstrukció szerint kimarad, és saját elszámolást hordoz. **Malleabilitás és a bizonyítás újrandomizálása.** A 4. lemma a `Adv_cr_H + q · Adv_ks_Rtr` korlátot adja az állítás-malleabilitásra. A szerzők külön bekezdést szentelnek annak, amit a lemma **nem** tilt: a bizonyítás újrandomizálását. Az implementációs profilban rögzített Groth16 megengedi, hogy egy érvényes bizonyításból egy másik, szintén érvényes bizonyítást származzunk ugyanarra a publikus állításra. Mivel a `h_body` a bizonyítás bájtjai nélkül számítódik, az újrandomizált másolat ugyanazt a testet, ugyanazt a `h_body`-t és ugyanazokat a nullifier-öket adja. Mivel minden belső átutalás legalább egy nullifier-t publikál, az újrandomizált másolat újrapublikálja azt a nem üres nullifier-vektort, és a replay ismétlődő nullifier-ként elutasítja. Az újrandomizálás tehát nem eredményez kétszeres költést, lopást vagy állapot-divergenciát, de megváltoztatja a hordozó tranzakció azonosítóját, ami a publikációs réteg kérdése. **Helyreállítás.** A 3. lemma az `Adv_aead + Adv_cr_H` korlátot adja. A bejövő helyreállítás az átutalásokat szkenneli és a bejövő viewing képességgel próbál visszafejteni, a kimenő helyreállítás a `vk_out`-ot, a `ct_out`-ot és a sorrendezett nyilvános kimeneti adatot használja. Egy jelölt note csak akkor kerül be a tárca-nézetbe, ha a plaintext konzisztens a ciphertexttel, a publikus `pk_eph` egyenlő `[sk_eph]G_d`-vel, és a származtatott `ℓ` a replay által kiosztott levél. A hibás ciphertext-ek, hibás pontkódolások és véletlen visszafejtések ezért csak AEAD-hibán, hash-hibán vagy elérhetetlen történelmen keresztül juthatnak be. ## Adatvédelmi modell és a szivárgási határ A tanulmány adatvédelmi része módszertanilag a legerősebb. A szerzők először tisztázzák, mit **nem** állítanak: nem állítják, hogy a Shielded Bitcoin minden Bitcoin-szintű metaadatot eltüntet, és nem adnak végpontok közötti adatvédelmi áttekintést a peg-inről, peg-outról, díjfinanszírozásról, tárca-hálózatról vagy relayer-működésről. A cél a **bizalmasság** és az átutalási relációk **adatvédelme**, de nem a **megfigyelhetetlenség**: minden átutalás publikál egy envelope-ot a Bitcoinra, ezért az a tény, hogy egy átutalás megtörtént, az időzítése és az aritása konstrukció szerint megfigyelhető. A formális definíció szerint a nyilvános tranzkriptum egy explicit szivárgási függvényen túl nem árul el semmit a privát történetről. A `Leak(X)` szivárgási függvény négy csoportot gyűjt össze: - **Bitcoin publikációs metaadat:** blokkmagasság, tranzakciósorrend, hordozó tranzakció szerkezete, díjak, díjráta-viselkedés, finanszírozó bemenetek, visszajáró kimenetek és bármely Bitcoin-szinten látható tárca-klaszterezési információ. - **Envelope-alak:** protokollverzió, átutalás-típus, `h_anchor` és ezáltal a gyökér kora `H - h_anchor`, bemeneti és kimeneti darabszám, envelope-méret. - **Replay-ütemterv:** elfogadás vagy elutasítás a kanonikus újrajátszás szerint, a note-leaf beszúrási sorrendje és a kiosztott fa-pozíciók ordinális indexként, valamint az érvényes ablaksáv magasságai. - **Határmetaadat:** a metaprotokollba belépő vagy onnan kilépő érték által felfedett nyilvános információ. A jelenlegi verzióban ez tartalmazza a belépéskor látható nyilvános Bitcoin-tranzakciót és összeget, mert a peg-in és a peg-out kimarad az átutalási specifikációból. - **Felfedett képességek:** bármely `vk_in`, `vk_out`, note-plaintext, riport vagy partneri információ, amelyet a felhasználó átad a támadónak. A 2. tétel a tranzkriptum-adatvédelmet mondja ki: ``` Adv_priv(λ) ≤ q · Adv_zk(λ) + (n_o + q) · Adv_enc(λ) + n_i · Adv_prf(λ) + (q_nf · 2^-ℓ_nf) / 2 ``` ahol `q` az elfogadott envelope-ok, `n_o` a kimeneti note-ok, `n_i` a bemeneti note-ok, `q_nf` a publikált nullifier-ök száma, `ℓ_nf` pedig a nullifier kimeneti hossza, és az utolsó tag a `G_3` játékban végzett egyenletes nullifier-helyettesítés születésnapi korlátja. A bizonyítás három játékból áll, és érdemes megérteni, mi történik bennük: - **G1 (bizonyítások):** minden átutalási bizonyítást a nulla-tudású szimulátor által gyártott bizonyításra cserélnek a saját publikus állítására. A `q · Adv_zk` hibát adja. Utána a bizonyítás bájtjai csak a publikus állítás függvényei, witness-információt nem hordoznak. - **G2 (ciphertext-ek):** minden kimenet `pk_eph`-jét friss efemer kulcsként újramintavételezik, és minden fogadói ciphertextet és a küldő-helyreállítási köteget egy rögzített, egyenlő hosszúságú nulla-plaintext titkosítására cserélik, a mögöttes kulcstól függetlenül. A fogadói és küldői identitás adatvédelme a kulcs-privátságból, a plaintext bizalmassága a szemantikai biztonságból következik. - **G3 (nullifier-ök):** minden publikált nullifier-t megfelelő hosszúságú egyenletes sztringre cserélnek. A `sk_nf`-en kulcsolt nullifier-származtatás pszeudorandomitása miatt a hibát `n_i · Adv_prf` adja. A helyettesített sztringek ütközhetnek egymással vagy más publikált nullifier-rel, de csak a születésnapi valószínűséggel, amit a szerzők explicit additív tagként visznek tovább. A `G_3` után minden titokból származtatott publikált objektum olyan értékre cserélődött, amely csak a `Leak`-en keresztül függ a privát történettől. A szerzők itt egy figyelemre méltó megjegyzést tesznek: a származtatott note-leaf értékek, a blokk-szintű gyökerek és a `h_body` ezeknek a most világfüggetlen objektumoknak a determinisztikus függvényei a kanonikus újrajátszás mellett, ezért **nem fogyasztanak ütközés-ellenállási tagot**, mert az érv csak azt igényli, hogy ezek a származtatások determinisztikusak. **Amit egy elfogadott átutalás nem tesz ki.** A publikus állítás felfedi a kiválasztott `r_anchor`-t, a bemeneti és kimeneti darabszámokat, a nullifier-öket, a kimeneti ciphertext-mezőket és a `h_body`-t. Nem teszi ki a bemeneti note-plaintexteket, a kimeneti note-plaintexteket, a bemeneti Merkle-utakat, a `sk_spend`-et, a `sk_nf`-et, a `vk_in`-t, a `vk_out`-ot, a fogadói `pk_d` értékeket, azt, hogy mely nyilvános note-levelek szolgáltak bemenetként, és a felemésztett note-ok és a létrehozott note-ok közötti megfeleltetést. **A megmaradó szivárgási felületek.** A szerzők négy elsődleges felületet neveznek meg. - **Átutalás-aritás.** Egy 1-ről 2-re és egy 2-ről 1-re menő átutalás megkülönböztethető, még akkor is, ha mindkettő titkosítja a küldőt, a fogadót és az összeget. Az envelope-alak és a hordozó tranzakció szerkezete ezt nyilvánvalóvá teszi. - **Anchor-kor.** A nullifier felfedi, hogy valamilyen note-költést elfogadtak egy adott Bitcoin-blokkban, de nem azt, hogy melyik korábbi levél lett elkötve. Az anchor-gyökér viszont korlátozást szivárogtat meg: minden bemenetnek már léteznie kellett `R[h_anchor]` alatt. A `H - h_anchor` értéke nyilvános, ezért a szokatlan anchor-életkorok ujjlenyomatot adhatnak a tárcákról vagy az aláírási munkafolyamatokról. - **Envelope-csoportosítás.** Mivel minden kimenet egy átutalás `h_body`-jához kapcsolódik, az egy átutalás minden kimenete ugyanazt a `h_body`-t hordozza. Két fogadó, aki összehasonlítja a megfigyelt `h_body`-t, megállapíthatja, hogy együtt fizették ki őket, és ezáltal hogy közös küldőjük van. Azoknak a tárcáknak, amelyeknek ezt el kell kerülniük, a nem összetartozó fizetéseket külön átutalásokra kell bontaniuk. - **Díjtárca-kapcsoltság.** A hordozó tranzakciónak bányászdíjat kell fizetnie. Ha ezeket a hordozó tranzakciókat ismételten ugyanabból az átlátszó Bitcoin tárca-klaszterből finanszírozzák, a Bitcoin szintjén össze lehet kapcsolni őket, még akkor is, ha a shielded átutalás tartalma titkos marad. A szerzők ezt élesen megkülönböztetik: az átutalás adatvédelme és a publikálás adatvédelme két külön dolog. A szerzők a díj-finanszírozás lehetséges irányaként egy **PIPE-alapú díj-tárat** vázolnak fel: a felhasználó bizonyítja a jogosultságát egy PIPE-vezérelt díj-tárhoz, amelynek Bitcoin-likviditása az adott felhasználó publikációs költségeire van fenntartva. Amikor a társzabály ellenőrződik, a tár kiadja a hordozó tranzakció finanszírozásához szükséges Bitcoint. A közzétevőnek nem kell megismernie a privát átutalás tartalmát: a felhasználó helyben építi az envelope-ot és a bizonyítást, a közzétevő csak a nyilvános envelope-ot és a díjfeloldási szabályhoz szükséges adatot látja. A szerzők hozzáteszik, hogy a tár-hozzáférési minták, a visszatérítési szerkezet, a publikációs időzítés és a közzétevővel való interakció továbbra is megfigyelhető metaadattá válhat, ezért a díjfeloldási mechanizmusnak saját szivárgási elemzésre van szüksége. **A privacy-halmaz és a tényleges adatvédelem.** A szerzők itt a tanulmány legerősebb önkorlátozó szakaszát adják. A privacy-halmaz mindig egy támadóhoz, egy megfigyelési modellhez és egy érdekes titokhoz képest definiált. A Shielded Bitcoinnál a releváns titok nem egy felhasználói identitás elszigetelten: a költési oldalon az a note-levél, amelyet egy nyilvános nullifier felemészt, a kimeneti oldalon pedig a fogadó által ellenőrzött note-plaintext és az azt létrehozó privát történet. A szerzők figyelmeztetnek, hogy egy nagy globális note-fa **csak szintaktikai felső korlátot** ad a költési privacy-halmaz méretére. Ez lényegesen túlbecsülheti a felhasználói szintű adatvédelmet, ha kevés szereplő hozta létre a note-ok többségét, ha a támadó sok note-ot ellenőriz vagy ismert meg, vagy ha egy tárca ismételten megkülönböztethető publikációs mintákat használ. A költési oldalon a protokoll-szintű jelölthalmazt az `R[a]` alatt már elkötelezett note-levelek korlátozzák, de a jelölthalmazt csökkenti minden kiegészítő tudás: a támadó által ellenőrzött levelek, a felfedett plaintexttel vagy viewing adattal rendelkező levelek, a láncon kívüli partneri rekordokból ismert levelek, és a határeseményekkel, időzítéssel, díjviselkedéssel vagy tárca-politikával össze nem egyeztethető levelek. A kardinalitás önmagában gyenge mérték, ha a jelöltek nem egyformán valószínűek. Az entrópia-alapú privacy-halmaz metrika szerint `|A_eff| := 2^H(P)`, ahol `P` a támadó posterior eloszlása a jelöltek fölött. Az effektív méret csak egyenletes posterior esetén egyezik a nyers jelöltszámmal. A szerzők maguk idézik a Zcash empirikus elemzését, ahol ez a gyakorlati tanulság már megjelent: a nagy nominális pool önmagában nem implikál nagy effektív privacy-halmazt. A végső állítás ezért feltételes: a Shielded Bitcoin a szivárgási függvénnyel kompatibilis történetek halmazán belül titkosítja az elkötött note-ot és a kimeneti plaintextet, és ennek a halmaznak a mérete és eloszlása **telepítési tulajdonság**. ## Implementációs profil és költségek Az A függelék egy konkrét implementációs profilt rögzít, hogy a független implementációk interoperáljanak. A szerzők világossá teszik, hogy az átutalási reláció maga nem függ ezektől a választásoktól, viszont az interoperabilitás megköveteli, hogy egy adott hálózaton minden újrajátszó implementáció ugyanazt a csomagot ossza, mert a replay elfogadási predikátuma tartalmazza a kanonikus szerializációt, a test- és aritás-elrendezést, a hordozó-meghatározási szabályt, a bizonyítás-ellenőrzést egy rögzített ellenőrző kulccsal, a `W` anchor-szabályt a hálózat-szintű `K_min` minimummal, és a determinisztikus elfogadási sorrendet. Csak néhány választás valóban helyi, és azok soha nem befolyásolják az interoperabilitást: a belső tárolási elrendezés, a tárca seed-entrópiája és a tárca-oldali anchor-mélység `K_wallet`. **Bizonyítási rendszer.** A profil Groth16-ot használ, ami áramkör-specifikus setupot igényel: az áramkör befagyasztása, egy trusted setup ceremónia, a bizonyító kulcs és az ellenőrző kulcs publikálása, és a kulcsanyag hozzárendelése a megfelelő ellenőrző azonosítóhoz. Bármely áramkör-módosítás megváltoztatja a setupot és ezzel mindkét kulcsot. A szerzők összehasonlítják a jelölteket: a Groth16 körülbelül 192 bájtos bizonyítást ad, a Polymath körülbelül 176-ot, a Pari körülbelül 160-at. Mivel minden envelope publikál egy bizonyítást, ezek a különbségek közvetlenül a lábnyom számokba folynak be. **Hordozó és méret.** A profil pontosan egy OP_RETURN kimenetet használ a teljes bináris envelope hordozására. A darabolás több kimenetre, a witness-hordozás és az alternatív hordozó-helyek nem részei a profilnak. Az indexerek figyelmen kívül hagyják a witness bájtokat, amikor shielded envelope-okat nyernek ki. A 2 bemenetes, 2 kimenetes konfiguráció mérete: - 6 bájtos header, 4 bájtos anchor, két egybájtos darabszám - 2 × 32 bájt nullifier, 2 × 32 bájt tömörített efemer kulcs - 2 × 67 bájt fogadói ciphertext - 144 bájt küldő-helyreállítási köteg (két 64 bájtos bejegyzés és egy 16 bájtos tag) - 192 bájt bizonyítás - Összesen **610 bájt** szerializált protokoll-envelope A minimálisan push-olt OP_RETURN script 614 bájt, a teljes szerializált Bitcoin kimenet 625 nem-witness bájt. Minden envelope-bájt négy súlyegységbe, azaz egy virtuális bájtba kerül ebben a hordozóban. Összehasonlításként a szerzők egy konkrét witness-hordozó sablont számolnak ki: egy prepay/commit tranzakció, amely egy P2TR key-path bemenetet költ el és két P2TR kimenetet hoz létre (a script-path elköteleződést és a visszajárót), majd egy reveal tranzakció, amely az elköteleződést egy egy-leveles P2TR script pathon keresztül költi el. A két tranzakció együtt **438 vB**, szemben az OP_RETURN 625 vB-jával. A witness-hordozás tehát nagyjából negyedére viszi a súlyköltséget, de egy két-tranzakciós prepay-reveal folyamat és saját standardness-feltevések árán. **Standardness-feltevés.** A szerzők itt őszinték: az egy-kimenetes OP_RETURN publikáció relay- és bányászati politikai feltevés, nem konszenzusgarancia. A feltételezett környezet a Bitcoin Core v30.0-ban bevezetett enyhített `-datacarriersize` defaultot támogatja, amely 83-ról 100 000 bájtosra emelte a korlátot, és megengedi több OP_RETURN kimenetet tranzakciónként. Ez a default node-konfigurálható és nem univerzálisan elfogadott: az operátorok visszaállíthatják a történelmi 83 bájtos korlátot, ezért a legacy cap fölötti envelope-ok relay-je attól függ, hogy elég relay- és bányászcsomópont futtatja-e az enyhített politikát. Ez egy figyelendő telepítési tulajdonság. **Anchor-ablak.** A profil ajánlott konstansai `W := 100` és `K_min := 1`. Ezekkel a replay akkor fogad el egy `H` blokkban lévő jelölt átutalást, ha `H - 100 ≤ a ≤ H - 1`. A `W = 100` a cél blokkintervallum mellett körülbelül tizenhat óra publikációs ablakot ad a bizonyítás elkészítése és a bekerülés között, ami lefedi a szokásos díjbecslést, újrasugárzást, késleltetett bekerülést és egyszerű relayer-munkafolyamatokat, miközben a megtartott gyökér-történet kicsi marad. A szerzők azt is javasolják, hogy a tárca-szoftver szigorúbb helyi anchor-politikát alkalmazzon `K_wallet > K_min` értékkel, és hogy a tárcák **közös anchor-választási politikát** használjanak, mert a szokatlan anchor-életkorok elkerülhető metaadat-különbségeket hoznak létre. **Tárca seed és diverzifikáló.** A tárca gyökérbemenete egy egyenletesen véletlen 32 bájtos `seed_wallet`. A szerzők kifejezetten megjegyzik, hogy **alacsony entrópiájú jelszavak nem alkalmasak tárca seedként**. A fizetési címek 11 bájtos `d` diverzifikálót használnak, ami cím-névtér és kódolási választás: elég változatosságot ad ahhoz, hogy egy viewing kulcs alatt sok fogadási útvonalat osszanak ki, miközben a fizetési címek és a note-plaintextek tömörek maradnak. Ez nem önálló biztonsági paraméter a note-felismeréshez vagy a költéshez. **AEAD-követelmények.** A szerzők figyelmeztetnek, hogy egy egyszerű AEAD nem elegendő. A fogadói csatornának **elköteleződő AEAD**-nak kell lennie (kulcs-elköteleződő és note-megnyitás-robusztus, azaz egy ciphertext nem nyílhat meg két kulcs alatt vagy két plaintextre) és kulcs-privátnak (a fogadó identitását a ciphertext nem fedi fel). A küldő-helyreállítási csatornának kulcs-privátnak kell lennie (a küldő identitását a ciphertext nem fedi fel), valamint bizalmasnak és ciphertext-integritást megőrzőnek. ## Nyitott kérdések és a jövőbeli munka A tanulmány záró része felsorolja, mi marad nyitva, és ez a lista önmagában informatív a rendszer érettségéről. **Telepítési paraméterek.** A bizonyítási rendszer, a publikációs hordozó, az átutalás-aritás és a nyilvános állítás tartalma nem független egymástól. Együtt kereskednek az envelope lábnyomával, a bizonyítási költséggel és a privacy-halmaz méretével, és egy telepítési profil ezeket együtt rögzíti, nem egyenként. A szerzők egy 2-ről 2-re formátumot tartanak valószínű defaultnak, mert támogatja a visszajáróval járó fizetést, de nem választanak szabványos aritást, mert ahhoz a várható átutalás-minták és a padding konkrét költségének mérése kell. Itt érdemes megjegyezni, hogy a szabványos aritás hiánya közvetlen adatvédelmi következménnyel jár: ha nincs egy szabványos aritás, a megfigyelő az átutalásokat a darabszámok alapján osztályozhatja. **Light client és ellenőrzött szinkron.** A tárcának note-pozíciókra, Merkle-utakra és helyes blokk-szintű gyökérre van szüksége a költési bizonyítás építéséhez, és jelenleg három módon juthat megbízható nézethez: teljes helyi újrajátszással, egy indexer válaszának a Bitcoin-adatok elleni ellenőrzésével, vagy egy kiválasztott indexerre tett explicit bizalmi feltevéssel. A teljes újrajátszás drága, a bizalmi feltevés pedig gyengíti a garanciát azoknak a tárcáknak, amelyek nem tudnak újrajátszani. A nyitott kérdés az, hogy egy light client tud-e szoros bizonyítást adni arról, hogy `R[h]` az elfogadott envelope-ok helyes determinisztikus újrajátszása `h` magasságig, újrajátszás nélkül ellenőrizhetően. A szerzők szerint egy ilyen rekurzív vagy proof-carrying konstrukció lehetővé tenné egy view-only tárcának a gyökér helyességének ellenőrzését anélkül, hogy az indexert megbízható komponenssé emelné. Ez a szinkron- és bizalmi költséget csökkentené, de a láncköltséget nem, mert a költés továbbra is publikál egy hordozó tranzakciót és fizeti a Bitcoin díját. **A peg, mint külön tanulmány.** A peg-in és a peg-out nincs specifikálva. A szerzők szándékolt iránya a PIPE-alapú határmenet: a közönséges Bitcoin-likviditás az L1-en köteleződik el, a belépési, kilépési és feloldási szabályok pedig Bitcoinhoz horgonyzott metaprotokoll-átmenetként jelennek meg, nem konszenzusváltoztatásként. A föderált vagy multisig letétkezelés, a BitVM-stílusú hidak és a jövőbeli covenant- vagy vault-alapú konstrukciók hasznos összehasonlítási pontok maradnak, de a belépés és kilépés bizalmi, élősségi, cenzúra-ellenállási és adatvédelmi tulajdonságai a határprotokollhoz tartoznak, nem az átutalási bizonyításhoz. A szerzők itt egy gyakorlati szivárgási mintát is leírnak: egy megkülönböztető peg-in összeg, amelyet rövidesen shielded aktivitás követ, vagy egy későbbi peg-out korreláló összeggel és időzítéssel, összekapcsolást támogathat a note-titkosítás megtörése nélkül. Ugyanez a hatás érhető el ugyanazon híd-operátor, feloldási minta, díjforrás vagy kilépési szolgáltatás ismételt használatával. **Hálózati megfigyelés és mempool.** Az elfogadott láncra vonatkozó adatvédelmi modell nem fedi le azt az erősebb támadót, amely a tranzakció eredetét, a mempool-terjedést, a sikertelen sugárzásokat, a helyettesítési kísérleteket vagy a csak árva blokkokban megjelenő envelope-okat figyeli. Ezek az észlelések időzítést, anchor-kort, aritást, díjstratégiát és újrapróbálkozási mintákat tárhatnak fel akkor is, ha a megfelelő átutalás soha nem fogadódik el a replay-ban. A mempool soha nem replay-állapot, de megfigyelési felület. A szerzők a hálózati réteg lehetséges eszközeiként említik a Dandelion és Dandelion++ sugárzási sémákat, valamint az onion-routing és mixnet rendszereket (Tor, Loopix), de hangsúlyozzák, hogy ezek külön hálózati támadómodellt igényelnek, és nem következnek a nulla-tudású átutalási bizonyításból. **Tárca-politika.** A tárca viselkedése érdemben befolyásolhatja az adatvédelmet akkor is, ha a kriptográfiai protokoll helyes. A bemenetválasztás, a kimeneti aritás, a visszajáró elhelyezése, az anchor-választás, a publikációs időzítés, a relayer-választás, a kötegelt publikálás és az újraépítési konstrukció mind formálja a támadó posterior eloszlását a jelölt történetek fölött. Egy tárca, amely megkülönböztethető aritást, elavult anchort, determinisztikus visszajáró-pozíciót, ismétlődő díjforrást vagy determinisztikusan újraépített tranzakciókat használ, az effektív privacy-halmazt csökkentheti anélkül, hogy bármely átutalás-érvényességi szabályt megsértene. A szerzők szerint az aritás ezek közül a legerősebb kar, mert hatása túlnyúlik a tárca-politikán, egészen az áramkörig és a trusted setupig. **A fenntartott levél-hely bővítései.** A note-levél fenntart egy használaton kívüli elköteleződési helyet, a `h_aux`-ot, amely a `aux_null` értékre van rögzítve és nem szerializálódik. Ez a kijelölt kötési pont azoknak a bővítéseknek, amelyeknek a note létrehozásakor kiegészítő adatot kell elkötelezniük anélkül, hogy az adat a note-plaintextbe kerülne. Az átutalási réteg nem értelmezi a helyet: egy bővítés definiálja a saját megnyitási relációját, egy kiterjesztett áramkörben bizonyítja, és a kiegészítő nyilvános adatot a saját envelope-formátumában hordozza, nem az alap `e`-ben. A motiváló példa egy atomi swap egy shielded note és átlátszó Bitcoin között, amely `h_aux`-ba köti a hash-lockot. **Opcionális KYC-evidencia.** A D függelék egy meglepő és figyelemreméltó irányt vázol fel: egy opcionális nulla-tudású lineage réteget, amellyel egy intézmény helyben ellenőrizheti, hogy egy bejövő note jóváhagyott Bitcoin-bemenetekből származik-e, és hogy a későbbi privát átutalások hitelesített fogadókon belül maradtak-e. A konstrukció lényege: egy Trust Authority igazolja a jóváhagyott Bitcoin-bemeneteket és hitelesít konkrét shielded PaymentAddress értékeket. Egy certified-lineage kimenet rekurzív bizonyítást hordoz arról, hogy a gyökerei hitelesített peg-inek, hogy minden megőrző átutalás csak érvényes lineage-szal rendelkező bemenetet használt, és hogy a kimenet a hitelesített fogadói címre készült. A Bitcoin konszenzus és az alap replay nem értelmezi; a lineage-evidencia nélküli note-ok érvényes Shielded Bitcoin note-ok maradnak. A szerzők három részletet emelnek ki, amelyek módszertanilag fontosak. Az első: a lineage-package a fogadó-titkosított note-adatban utazik, és a **valódi lineage-evidencia és a dummy payload ugyanazt a kódolást és hosszúságot használja**, ezért a fogadó viewing kulcsa nélküli megfigyelő a ciphertextből nem tudja megkülönböztetni őket. A második: a certified-lineage tulajdonság csak akkor őrződik meg, ha az átutalás **minden** felemésztett bemenete érvényes package-dzsel rendelkezik. Egy olyan átutalás, amely egyszerre fogyaszt certified-lineage note-ot és közönséges note-ot, érvényes marad az alapprotokoll szerint, de egyetlen kimenete sem tarthatja meg a certified-lineage állítást. A harmadik: az authority-tanúsítvány egy adott **szabályzati korszakban** hozott döntést rögzít, nem a jelenlegi ellenőrt vagy haszonélvező tulajdonost; a jelenlegi állapotra vonatkozó állításhoz authority-hitelesített állapot-pillanatkép és szabályzati korszak kell a rekurzív állításban, enélkül az evidencia csak a kiadáskori jóváhagyást igazolja. ## Forrás - **Tanulmány:** (Clara Shikhelman, Mikhail Komarov, Aleksei Moskvin, [[alloc] init], 2026-09-24, 55 oldal) - **Kutatócég oldala:** - **Kulcsszavak:** Shielded Bitcoin, shielded note, nullifier, nulla-tudású bizonyítás, determinisztikus replay, metaprotokoll, PIPEs v2, witness encryption, Groth16, OP_RETURN hordozó, anchor-ablak, note tree, szivárgási függvény, privacy-halmaz, tárca-kulcshierarchia, viewing key, certified-recipient lineage - **Alkalmazhatóság:** KÖZEPES. A tanulmány Bitcoin-protokolltervezési dokumentum, nem rendszerterv a mi infrastruktúránkhoz. A közvetlenül átvihető elemek a szerkezetiek: az olvasási és írási képességek szétválasztása, a determinisztikus újrajátszás mint állapotforrás, az explicit szivárgási függvény mint az adatvédelmi állítások kerete, és a fenntartott bővítési hely mint visszafelé kompatibilis kiterjesztési pont. - **Megjegyzés a mérési adatokról:** a tanulmány specifikáció és elemzés, **nincs telepített hálózat**, és a szerzők nem közölnek működési méréseket. A biztonsági és adatvédelmi állítások a megadott feltevések mellett érvényesek (bitcoin ledger feltevés, őszinte setup, kanonikus implementáció, őszinte tárca-viselkedés), és nem független verifikáción alapulnak. A peg-mechanizmusról szóló sajtóbeszámolókban szereplő számok (körülbelül 700 vB shielded tranzakciónként, nagyjából 8 TB-ra csökkentett titkosított fájlok a witness encryptionhöz) **nem** a tanulmányból származnak, hanem Misha Komarov 2026. szeptember 10-i interjújából, ezért másodlagos forrásként kezelendők. ## Kapcsolódó külső források - [[alloc] init]: (a kutatócég, amely a Shielded Bitcoint és a PIPEs primitívet fejleszti) - Bitcoin PIPEs v2: (Abdalla, Carmer, El Gebali, Kilinc-Alper, Komarov, Rebenko, Soukhanov, Tairi, Tatuzova, Towa, Cryptology ePrint Archive 2026/186) - Bitcoin Magazine, Shinobi: (2026-09-24-i híradás a javaslatról) - Unchained, Misha Komarov interjú: (2026-09-10-i felvétel, a díj- és méretbecslések forrása) - Crypto Times: (2026-09-24-i összefoglaló) - Zcash protokollspecifikáció: Hopwood, Bowe, Hornby, Wilcox (Electric Coin Company, 2025), a shielded-note architektúra közvetlen előzménye - Zerocash: Ben-Sasson, Chiesa, Garman, Green, Miers, Tromer, Virza, Cryptology ePrint Archive 2014/349 - Zerocoin: Miers, Garman, Green, Rubin, IEEE Symposium on Security and Privacy 2013 - Shielded CSV: Nick, Eagen, Linus, Cryptology ePrint Archive 2025/068 (a legközelebbi Bitcoin-specifikus rokon munka, kliensoldali adatelérhetőségi modellel) - Zcash anonymity empirikus elemzése: Kappos, Yousaf, Maller, Meiklejohn, USENIX Security 2018 (a nominális és effektív privacy-halmaz szétválásának mért eredménye) - RGB: és Taproot Assets (Lightning Labs), kliensoldali validációs előzmények - BitVM: Linus, 2023; BitVM2: Linus, Aumayr, Avarikioti és mtsai, 2025/1158; BitVM3: Woll, Alexopoulos, Aumayr és mtsai, 2026/933 - Groth16: Groth, Cryptology ePrint Archive 2016/260 - Dandelion és Dandelion++: Venkatakrishnan, Fanti, Viswanath (2017), illetve Fanti és mtsai (2018), a hálózati szivárgás lehetséges ellenszerei ## Kapcsolódó belső források - [2026-09-22_bitcoin_optech_newsletter_423_recap.md](../bitcoin_optech/2026-09-22_bitcoin_optech_newsletter_423_recap.md), a Bitcoin Optech legutóbbi feldolgozott epizódja: az unspendable internal keys draft BIP (NUMS-pont), a Covenants.diy covenant-szerkesztő és a BitBoxApp Spark-integráció közvetlenül ugyanabban a tervezési térben mozog, mint ez a tanulmány. Az epizód Murch-féle megkülönböztetése a "nem-kasztodiális" elnevezés félrevezető voltáról pontosan az a kérdés, amit ez a tanulmány a metaprotokoll-szintű nem-kasztodiális állításánál óvatosan kezel. - [2026-05-13_bitcoin-privacy-panel.md](../tanulmanyok/2026-05-13_bitcoin-privacy-panel.md), a Bitcoin adatvédelmi eszközeinek panelje: a CoinJoin, PayJoin és Silent Payments korlátai, amelyeket ez a tanulmány a related work szekcióban rendszerez - [2023-03-14_lightning_network_privacy_explainer_voltage.md](../tanulmanyok/2023-03-14_lightning_network_privacy_explainer_voltage.md), a Lightning adatvédelmi modellje, mint a nem-láncon-validált réteg korábbi tárgyalása - [2026-09-21_polylane_prevent_slop_hitting_prod.md](../tanulmanyok/2026-09-21_polylane_prevent_slop_hitting_prod.md), módszertani párhuzam: a Polylane cikk háromállapotú ítélete (confirmed/plausible/refuted) és ennek a tanulmánynak a szivárgási függvénye ugyanazt a fegyelmet képviseli: előbb definiáld, mit tud a megfigyelő, aztán fogalmazz állítást - [2025-12 Recursive Language Models](2025-12_recursive-language-models.md), a rekurzív bizonyítási konstrukció elvi háttere, ami a light client verified sync nyitott kérdéséhez kapcsolódik ## Hogyan kapcsolódik a saját rendszerünkhöz? Három szerkezeti párhuzam van, és egy, ami közvetlenül érinti a saját adatvédelmi álláspontunkat. **Az olvasási és írási képességek szétválasztása.** A tanulmány kulcshierarchiája a költési jogosultságot, a bejövő megtekintést és a kimenő helyreállítást külön ágakra bontja, és a felfedési modell kizárólag olvasási képességeket ad ki. A szerzők ezt a hierarchia szülőviszonyaival érik el, nem ígéretekkel: a `sk_nf` a `ser(sk_spend)` gyermeke, a `vk_in` szintén az, de csak olvasható, a `vk_out` pedig a `sk_master`-nél válik szét, és soha nem ad `sk_spend`-et vagy `sk_nf`-et. Ez a minta közvetlenül ismerős: a saját skill- és eszközrendszerünkben is az a helyes elv, hogy a hozzáférési szint a struktúrából következzen, ne a használat szándékából. A tanulmány ezt formálisan is megfogalmazza: "egyetlen felfedési anyag sem tartalmaz seedet, költési kulcsot vagy nullifier-kulcsot", és a `sk_nf` kizárásának az a célja, hogy a felfedés ne váljon általános összekapcsoló eszközzé. Ez ugyanaz a logika, mint a saját napló- és bizonyíték-kezelésünkben: a bizonyíték megadása ne adjon egyben cselekvési jogosultságot. **A determinisztikus újrajátszás mint állapotforrás.** A tanulmány központi állítása, hogy két helyes implementáció, ugyanazon a bemeneten futva, koordináció nélkül ugyanahhoz az állapothoz jut, és ezért nincs szükség vitarendezésre. Ez pontosan az a tulajdonság, amire a saját tudásbázis-építésünk is törekszik: a a kanonikus forrás, és a wiki raw, az indexek és a topic-bejegyzések ebből determinisztikusan származnak. A tanulmány ehhez ad egy hasznos fegyelmezési szabályt: **ami nem determinisztikus, az nem lehet az elfogadási predikátum része**. Nálunk ugyanez a kérdés merül fel a szerkesztési döntéseknél: ha két futtatás eltérő eredményt ad ugyanarra a bemenetre, akkor az a lépés nem tartozhat a "kanonikus" részbe. **A fenntartott bővítési hely.** A note-levél `h_aux` mezője jelenleg a `aux_null` konstansra van rögzítve és nem szerializálódik, de a szerzők már most kijelölik a jövőbeli bővítések kötési pontjaként, és a kódolást úgy rögzítik, hogy a bővítés ne törje meg a kanonikus szerializációt. Ez a visszafelé kompatibilis kiterjesztés minta, amit a saját skill-frontmatterünkben és a canonical FOOTER struktúrában is alkalmazunk. A tanulmány ehhez hozzátesz egy éles megszorítást: a bővítés a saját megnyitási relációját definiálja, és a saját envelope-formátumában hordozza az adatot, nem az alapban. Vagyis a fenntartott hely csak **elköteleződési pont**, nem tároló. **A KYC-lineage függelék és a saját álláspontunk.** Ez az a rész, ahol a legélesebb a különbség a technikai érdekesség és a saját elveink között. A D függelék egy olyan konstrukciót vázol fel, amely nulla-tudású bizonyítással igazolja, hogy egy note jóváhagyott Bitcoin-bemenetből származik, és hogy a későbbi átutalások hitelesített fogadókon belül maradtak. Technikailag elegáns: a bizonyítás nem fedi fel a korábbi címeket, a tartókat és az átutalási gráfot, és a dummy payloadok azonos hosszúságúak, ezért a láncon nem megkülönböztethetők. A szerzők maguk is pontosan megjelölik a határt: az állítás az **issuer**, a **szabályzati korszak** és az **ellenőrzött követelés** szintjén továbbra is felfedi a döntést, és nem mond semmit a Bitcoin-történelemről a jóváhagyott bemenetek előtt, sem a tanúsítványban szereplő cím jelenlegi tulajdonosáról. A saját álláspontunk szerint ez a rész az, amit a legszorosabban kell figyelni: egy opcionális, de protokoll-szinten támogatott lineage-réteg könnyen válik a következő években de facto elvárássá, és akkor a "nem mainnetre" jellegű önkéntesség eltűnik. A tanulmány legalább őszintén jelzi, hogy opcionális és hogy a base protocol szerint a lineage nélküli note is érvényes.