Kihagyás

Cashu / Math Academy — Bitcoin ecash protokoll (teljes kurzus)

Műsor: Cashu / Math Academy (interaktív kurzus) • Cím: Cashu: Bitcoin's Ecash Protocol • Dátum: 2026-07-19 • Szerző/készítő: Math Academy, Calle (a Cashu protokoll alkotója) közreműködésével Forrás: Cashu: Bitcoin's Ecash Protocol | Math Academy • Terjedelem: 23 lecke (Section00–Section22) + 7 külső forrás Transcript: interaktív kurzus JS-bundle-jából kinyert plain text (~15 651 szó)

Bevezetés és a lényeg

A Math Academy Cashu kurzusa egy 23 leckéből álló interaktív tananyag, amely a Cashu Chaumian ecash protokollt a matematikai alapoktól a wallet-implementációig vezeti végig. A kurzus a Bitcoin ökoszisztémán belüli privacy-re fókuszál, és a szerzők között ott van Calle, a Cashu protokoll alkotója.

A Cashu David Chaum 1982-es blind signature (vak aláírás) koncepciójának modern újraértelmezése. A DigiCash-csal szemben, amely hagyományos bankokra és fiat pénzre épült, a Cashu a Bitcoint használja settlement rétegként, és ezzel a digitális készpénz privacy-jellegét hozza vissza úgy, hogy közben megőrzi a Lightning sebességét és alacsony díjait.

A kurzus legfontosabb tanulságai:

  • A blind signature lényege, hogy az aláíró (a mint) nem ismeri az aláírt tartalmat, de az aláírás érvényes rá. A carbon-envelope analógia ezt vizuálisan mutatja be.
  • A bináris token-dekompozíció (2-hatvány címletek) determinisztikus felépítést és hatékony aggregációt ad a swap műveletekhez.
  • A secp256k1 elliptikus görbe és a hash_to_curve függvény adja a teljes rendszer kriptográfiai alapját: ha valaki hatékonyan számolná a diszkrét logaritmust, az egész rendszer összeomlana.
  • A protokoll négy alapművelete a deposit, a mint, a swap és a melt. A deposit Bitcoinból ecash-ba visz, a melt ecash-ból Lightning-tranzakcióba.
  • A BDHKE (Blind Diffie-Hellman Key Exchange) biztosítja, hogy a mint ne láthassa, milyen Y értékeket ír alá.
  • A NUT specifikációs rendszer (NUT-00 … NUT-12) tagolja a protokollt az alapoktól a spending conditions-ig.
  • A DLEQ proof zero-knowledge bizonyíték arra, hogy a mint ugyanazt a privát kulcsot használta a blinding során, tehát nem hazudik a keyset-ekről.
  • A Cashu nem újabb coin mixer, hanem új privacy-primitív a Bitcoin mellett, amely kiegészíti a CoinJoint, a PayJoint és a Lightning onion routingot.

Összegzés

A kurzus egyetlen íve a Chaum-féle vak aláírástól a működő wallet-implementációig tart. A tanuló a kurzus végére nem csak használni tudja a Cashut, hanem a saját wallet-ét is meg tudja építeni, és a protokoll aktív közreműködőjévé válhat. A kurzus külön értéke, hogy a hét külső forrás (Calle interjúk, Bitcoin Magazine cikkek, konferencia-előadások) nem mellékletként, hanem a leckék szerves részeként jelenik meg, így a protokoll mögötti motivációk és a hosszú távú ökoszisztéma-vízió is átjön.

1. rész: Bevezető és a Chaumian ecash alapjai (Section00–Section05)

A szerző központi tézise

A Cashu egy modern újraértelmezése David Chaum 1982-es blind signature (vak aláírás) koncepciójának, amelyet a Bitcoin és a Lightning Network felett valósítanak meg. A DigiCash-cal ellentétben, amely hagyományos bankokra és fiat pénzre épült, a Cashu a Bitcoint használja settlement rétegként, és a Chaumian ecash privacy-tulajdonságait hozza vissza a digitális korban. A kurzus célja, hogy a tanuló ne csak a protokoll felszínét ismerje meg, hanem a kriptográfiai alapokat, a gyakorlati implementációt, és a hosszú távú ökoszisztéma-víziót is.

A kurzus különlegessége, hogy a Chaumian ecash-t nem elszigetelt technológiaként mutatja be, hanem a Bitcoin és Lightning Network természetes kiterjesztéseként. A tananyag 23 leckéből áll, és hét, gondosan válogatott külső forrást is feldolgoz (köztük Calle saját BTC++ konferencia-előadásait, Bitcoin Magazine interjúkat, és a What Bitcoin Did podcast epizódjait).

A kurzusról és a szerző(k)ről

A kurzust a Math Academy készítette, amely 2024-2025-ben indította el a Bitcoin-specifikus kurzus-sorozatát. A Cashu kurzus a második a sorban (az első egy általános Bitcoin-kurzus volt), és célzottan a Bitcoin ökoszisztémán belüli privacy-re fókuszál. A kurzus interaktív: KaTeX-szel renderelt matematikai képletek, élő kód-szerkesztők, vizuális demonstrációk (carbon-envelope analógia a blind signature-hez, bináris token-dekompozíció, token-lifecycle flowchart), és egy 384 kérdésből álló kvíz-bank gondoskodik a tanulás megerősítéséről.

Calle, a Cashu protokoll alkotója, többször is megjelenik a kurzusban: vendégként a What Bitcoin Did és az Investor's Podcast epizódokban, előadóként a BTC++ Berlin 2024 konferencián, és a Bitcoin Magazine interjúkban. A kurzus "long-term vision" szekciója nagyrészt Calle saját ökoszisztéma-vízióját dolgozza fel, amely a Cashu-minták (ecash kibocsátó szerverek) hálózatát írja le.

A hét külső forrás áttekintése

A kurzus hét külső forrást integrál, amelyeket a hallgató a leckék mellé kap. Ezek együttesen lefedik a Cashu 2023-as indulásától 2025-ig tartó időszakot.

A Bitfinex Blog 2023. márciusi cikke ("Cashu: Chaumian E-Cash & Mints Over Lightning") a protokoll egyik legkorábbi intézményi elemzése. A cikk projekt-áttekintés a Lightning Network-kompatibilis Chaumian ecash-ről, és részletezi, hogy a Cashu hogyan nyújt privacy-előnyöket a hagyományos custodial Lightning tárcákhoz képest. Fontos kontextus: a cikk írásakor a protokoll még korai fejlesztési stádiumban volt.

A Bitcoin Magazine két cikke 2024-ből származik. Az első ("Ecash Makes Bitcoin (And Fiat) Private With Calle's Cashu", Frank Corva tollából, 2024. május) a Cashu-t mint ingyenes és nyílt forráskódú Chaumian ecash protokollt profilozza, amely cash-szerű privacy-védelmet nyújt mind a Bitcoin, mind a fiat tranzakciókhoz. A második ("Cashu: A Vision For A Bitcoin Powered Ecash Ecosystem", Shinobi tollából, 2024. június) technikai elemzés a Cashu-minták hosszú távú ökoszisztémájáról: hogyan fejlődhet a rendszer a biztonság és az operatív fenntarthatóság megőrzése mellett.

A What Bitcoin Did podcast két epizódja Calle-vel készült. A korábbi (2024. január, "Scaling Bitcoin Privacy w/ Calle: Cashu vs. Fedimint") bevezetést nyújt a Cashu és az ecash világába, összehasonlítja a Cashu és a Fedimint architektúrákat, és kitér a Bitcoin privacy aggályokra. Az újabb (2025. augusztus, "The War on Bitcoin Privacy") szélesebb kontextusba helyezi a Cashu-t: a pénzügyi és kommunikációs privacy eszközöket (Cashu, BitChat) tárgyalja, és azt, hogy a privacy miért fontos a demokrácia szempontjából.

A BTC++ Berlin 2024 konferencia ("E-cash Edition") Calle saját előadása a bitcoin++ konferenciasorozat e-cash kiadásán. A konferencia a Bitcoin++ rendezvénysorozat negyedik állomása volt (a korábbiak: Riga, Firenze, Hong Kong), és kifejezetten a Chaumian ecash ökoszisztémára fókuszált.

Végül az Investor's Podcast "eCash on Bitcoin & Nostr w/ Calle from Cashu" epizódja (2024. szeptember) a Cashu protokoll fejlesztésének motivációit tárgyalja, a Bitcoin Lightning Network ökoszisztémában betöltött szerepét, és a Nostr integrációt a privacy-megőrző fizetésekhez.

Section00 – Cashu: rövid áttekintés

Az első lecke ("Experience how blind signatures work using the carbon-envelope metaphor") a Chaumian ecash alapfogalmát vezeti be a carbon-envelope (karbon-papír) analógiával. Az analógia szerint: írj egy titkos üzenetet, zárd egy olyan borítékba, amelynek belsejében karbonpapír van, a bank az aláírásával a boríték külsejét írja alá, és a karbonpapír az aláírást átviszi a belső üzenetre anélkül, hogy a bank látná azt. Amikor kinyitod a borítékot, a hiteles aláírás már a te titkos üzeneteden van. Ez a blind signature (vak aláírás) alapelve: az aláíró nem ismeri az aláírt tartalmat, de az aláírás érvényes rá.

A lecke kiemeli, hogy a Cashu a modern újraértelmezése Chaum 1982-es ötletének: ahol a DigiCash hagyományos bankokra és fiat pénzre épült, ott a Cashu a Bitcoint használja settlement rétegként. A Bitcoin biztosítja azokat a tulajdonságokat, amelyek a Cashu-t értelmezhetővé teszik: a digitális szűkösséget, a globális elszámolhatóságot, és a cenzúra-ellenállást.

A Section01 ("Binary Tokens: Decomposition of Amounts") a Cashu token-rendszerének alapját mutatja be: a bináris dekompozíciót. Minden Cashu token egy power-of-2 (2-hatvány) címletben létezik (1, 2, 4, 8, 16, 32, 64, 128, 256, 512), és minden összeg ezen címletek összegeként áll elő. Az 1023 sat például 512+256+128+64+32+16+8+4+2+1. Ez a kialakítás két fontos tulajdonságot ad: a tokenek determinisztikus felépítését (minden mennyiséghez egyértelmű a felbontás), és a hatékony aggregációt/szétvágást (swap műveletek).

Section02 – Miért Bitcoin és Lightning?

A második lecke a Cashu és a Bitcoin/Lightning kapcsolatát tárgyalja. A Cashu nem légüres térben létezik: a Lightning Network settlement rétegére épül. Amikor Bitcoint depositolsz egy Cashu mintába, ecash tokeneket kapsz cserébe; amikor a tokeneket beváltod, a mint a Bitcoint visszaküldi neked. A Bitcoin biztosítja a tulajdonságokat, amelyek a Cashu-t értelmessé teszik: a digitális szűkösséget (a Bitcoin nem duplikálható), a globális elszámolhatóságot (a Bitcoin hálózat bárki számára elérhető), és a cenzúra-ellenállást (a tranzakciók nem blokkolhatók).

A lecke kitér arra, hogy a Cashu a Lightning Network speed-jét és alacsony díjait örökli, miközben privacy-t ad hozzá. A hagyományos Lightning-csatornákban a tranzakciók nyilvánosak a csatorna-résztvevők számára; a Cashu ezt a privacy-réteget adja hozzá, miközben a Lightning-speed megmarad.

Section03 – A Cashu protokoll magas szintű folyamata

A harmadik lecke a teljes flow-t mutatja be: a felhasználó fizet egy Lightning számlát, amelyet a mint generált (ez depositálja a Bitcoint a mint tartalékába); a tárca kér egy mint quote-ot; a fizetés után a tárca titkokat generál, elvakítja őket (B_ = Y + r·G), és elküldi a BlindedMessage-eket a mintnak; a mint aláírja a vak üzeneteket, visszaküldi a BlindSignature-öket; a felhasználó "unblindolja" az aláírásokat, és megkapja a végső Proof-okat (Y pont + C_ aláírás). Ezzel a proof tulajdonosa igazolhatja, hogy a mint aláírta az adott Y értéket anélkül, hogy a mint tudná, melyik Y-t adta.

A deposit, mint, swap, és melt négy alapműveletet definiálja a protokoll. A deposit a Bitcoin-ból ecash-ba való átmenet, a mint az ecash kibocsátás, a swap a tokenek egyesítése/szétválasztása, a melt pedig az ecash-ból Lightning tranzakcióba való átmenet (amely során a tartozék Bitcoin kifizetődik a címzett Lightning-csomópontján keresztül).

Section04 – Elliptikus görbe kriptográfia: secp256k1

A negyedik lecke a Cashu kriptográfiai alapját tárgyalja: az elliptikus görbe kriptográfiát, pontosabban a secp256k1 görbét, amelyet a Bitcoin is használ. Az elliptikus görbe az y² = x³ + ax + b egyenlet által leírt pontok halmaza, és a Cashu minden kriptográfiai művelete erre a görbére épül.

A pont-addíció és a skalár-szorzás a két alapművelet. Két pont összeadásával egy új pontot kapunk a görbén, és ha egy P pontot k-szer összeadunk önmagával (k·P), akkor egy másik Q pontot kapunk – de a Q-ból a k-t kiszámítani (diszkrét logaritmus probléma) nehéz, és ez adja a kriptográfiai biztonságot. A lecke hangsúlyozza, hogy a Cashu teljes biztonsága erre a nehézségre épül: ha valaki hatékonyan tudná kiszámítani a diszkrét logaritmust, az egész rendszer összeomolna.

A hash-to_curve függvény (hash_to_curve) tetszőleges szöveget (titkos üzenetet) alakít át a secp256k1 görbe egy pontjává. Ez az alapja annak, hogy a Cashu tokenek "rejtett" üzeneteket tartalmazhatnak, amelyeket a felhasználó szabadon választhat, de a matematikai struktúra biztosítja, hogy a rendszer kezelni tudja őket.

Section05 – Hash-to-Curve Challenge

Az ötödik lecke a hash_to_curve gyakorlati implementációját mutatja be interaktív kód-szerkesztőn keresztül. A tanuló feladata, hogy implementálja a függvényt: a hash-t x-koordinátaként használva, a 0x02 prefixxel, és ha az adott x-hez nincs érvényes y, akkor növelni és újrapróbálkozni. A lecke kiemeli, hogy nem minden x-koordinátának van érvényes y párja a secp256k1 görbén, ezért a hash_to_curve implementációjának kezelnie kell ezt az esetet.

A cél a gyakorlati tapasztalat: a tanuló a saját kódját futtatva érti meg, hogy a blind signature mögötti matematika nem elvont elmélet, hanem néhány sor konkrét kód, amelyet bárki futtathat és tesztelhet.

A kurzus építészeti sajátosságai

A kurzus az interaktív tanulásra épít, nem csupán az elméleti anyag átadására. Minden leckéhez tartozik egy vagy több interaktív demonstráció: a Section00 carbon-envelope analógiája vizuálisan mutatja be a vak aláírást, a Section01 bináris dekompozíciója szám-szemléltető, a Section04 elliptikus görbe vizualizációja a matematikai struktúrát mutatja. A kvíz-bank 384 kérdéssel gondoskodik arról, hogy a tanuló a tananyag minden aspektusát ellenőrizhesse.

A kurzus külön értéke, hogy a külső források (Calle interjúk, Bitcoin Magazine cikkek) nem mellékletként, hanem a leckék szerves részeként jelennek meg. A tanuló nem csak a protokollt tanulja meg, hanem a protokoll mögött álló személyes motivációkat, a közösség visszajelzéseit, és a hosszú távú víziót is.

2. rész: Blinding, signing és a NUT-00 alapjai (Section06–Section10)

A szerző központi tézise

A Cashu protokoll középső harmada (Section06–Section10) a rendszer kriptográfiai magját tárgyalja: a blinding és signing műveleteket, a NUT-00 terminológiát, a BlindedMessage struktúrát, a mint keysets kezelését, és a kriptográfiai hashing implementációt. Ez a szakasz az, ahol a tanuló a felszíni protokoll-magyarázatoktól eljut a tényleges matematikai és strukturális részletekig, és megérti, hogy a Cashu hogyan építkezik a Chaum-féle blind signature sémára a gyakorlatban.

A kurzus itt két fontos építőkockát mutat be: a BDHKE (Blind Diffie-Hellman Key Exchange) protokollt, amely a blinding és signing alapja, és a BlindedMessage/Proof adatstruktúrát, amely az ecash tokenek tényleges formátuma. Ezek együttesen biztosítják, hogy a mint ne lássa, milyen Y értékeket ír alá (privacy), miközben a felhasználó érvényes Proof-okhoz jut, amelyeket később be tud váltani (integritás).

Section06 – Blinding és signing műveletek

A hatodik lecke a Cashu protokoll kriptográfiai magját, a BDHKE-t (Blind Diffie-Hellman Key Exchange) mutatja be lépésről lépésre. A tanuló megismeri, hogyan generál random blinding faktort (r), hogyan számítja ki a blinded message-t (B_ = Y + r·G), és hogyan küldi el a mintnak. A mint a B_ pontot írja alá a privát kulcsával (k), és visszaküldi a C_ = k·B_ vak aláírást. A felhasználó az unblindolás (C = C_ - r·K, ahol K = k·G a mint publikus kulcsa) után megkapja a C aláírást, amelyet a Y titkos értékhez társíthat.

A BDHKE biztonsága a decisional Diffie-Hellman problémára (DDH) és a discrete logarithm problémára (DLP) épül: ha valaki hatékonyan tudná kiszámítani a diszkrét logaritmust, vagy el tudná dönteni, hogy két pont-pár azonos diszkrét logaritmussal rendelkezik-e, akkor a rendszer feltörhető lenne. A secp256k1 görbe ezen problémák nehézségét a gyakorlatban biztosítja.

A lecke kitér a kulcsfontosságú matematikai összefüggésre: C = k·(Y + r·G) - r·(k·G) = k·Y + k·r·G - r·k·G = k·Y. Ez az egyenlet mutatja, hogy az unblindolás után a felhasználó valóban a Y értékhez tartozó, a mint által aláírt C értéket kapja, miközben a mint soha nem tudta meg, hogy melyik Y-t írta alá (mert a B_-ból a Y-t a r véletlen ismerete nélkül nem lehet kiszámolni).

A lecke hangsúlyozza, hogy a blinding nem "titkosítás" a hagyományos értelemben, hanem egy matematikai konstrukció, amelyben az aláíró egy transzformált értéket ír alá, és az aláírt értéket a felhasználó vissza tudja alakítani az eredetire anélkül, hogy az aláíró látná azt.

Section07 – NUT-00: Protokoll terminológia

A hetedik lecke a NUT-00 specifikációt tárgyalja, amely a Cashu protokoll alap-terminológiáját definiálja. A NUT a "Notation, Usage, and Terminology" rövidítése, és a NUT-00 az összes többi NUT (NUT-01, NUT-02, ..., NUT-12) alapja. Ahogy egy jogi dokumentumban a definíciók szakasza, úgy a NUT-00 definiálja a szereplőket, az adatstruktúrákat, és a műveleteket, amelyekre az összes többi NUT épít.

A szereplők a következők: a User (aki a tárcát működteti), a Mint (amely az ecash-t kibocsátja és beváltja), a Wallet (a felhasználó szoftvere), és a Lightning Network (amely a settlement réteget adja). A NUT-00 ezeket a szereplőket és a közöttük lévő interakciókat írja le magas szinten.

A lecke kiemeli, hogy a NUT-00 a protokoll alapnyelve: minden más NUT erre a közös terminológiára épít, és a tanuló számára ez a lecke adja meg a "szótárt", amellyel a többi NUT-ot érteni tudja. A terminológia konzisztens használata kritikus, mert a NUT-ok egymásra épülnek, és a fogalom-eltolódás félreértésekhez vezethet.

A NUT-00 emellett definiálja az adat-típusokat is: a Proof (C aláírás + Y titok + denomination + keyset ID), a BlindedMessage (B_ vak pont + amount + keyset ID), a BlindSignature (C_ vak aláírás + amount + keyset ID), és a Quote (Lightning invoice + quote ID + amount + state). Ezek az adat-típusok a teljes protokoll gerincét alkotják.

Section08 – BlindedMessage konstrukció

A nyolcadik lecke a BlindedMessage adatstruktúrát mutatja be részletesen. A BlindedMessage a felhasználó által a mintnak küldött üzenet, amely a Y titkos érték vakított verzióját tartalmazza. Három mezőből áll: amount (a token címletének értéke), id (a keyset azonosító, amely megmondja, hogy a mint melyik kulcspárját kell használni), és B_ (a vakított Y pont, B_ = Y + r·G).

A lecke kitér arra, hogy az amount mezőnek illeszkednie kell a keyset által támogatott címletek egyikéhez. A keyset-ek (amelyeket a NUT-02 definiál) határozzák meg, hogy a milyen címletekben (1, 2, 4, ..., 2^n) bocsát ki a mint tokeneket. Ha a felhasználó 32 sat értékű tokent kér, de a keyset csak 1, 2, 4, 8, 16, 64, 128 sat-os címleteket támogatja, akkor a tranzakció elutasításra kerül, vagy a felhasználónak több kisebb címletre kell bontania a kérését.

A B_ mező a vakítás matematikai magja. A B_ kiszámítása előtt a felhasználónak generálnia kell egy Y titkos értéket (amely a secp256k1 görbe egy pontja), és egy r véletlen blinding faktort (amely egy 256 bites véletlen szám). A B_ az Y és r·G összege. A B_-ból a Y-t a r ismerete nélkül nem lehet kiszámolni, és a B_-ból a Y-t a r-rel egyszerűen vissza lehet állítani (Y = B_ - r·G).

A lecke gyakorlati szempontból is tárgyalja a BlindedMessage-ek kezelését: a felhasználó gyakran egyszerre több BlindedMessage-et küld (pl. ha 64 sat értékű tokent kér, akkor 32+16+8+4+2+1+1 címletben), és ezeket a tárca-kezelő szoftvernek kell nyilvántartania, optimalizálnia, és a megfelelő kulcspárral aláíratnia a minttal.

Section09 – Mint keysets és címletek

A kilencedik lecke a mint keysets kezelését mutatja be. A keyset a mint egy adott időszakban használt kulcspárjainak összessége: minden támogatott címlethez (1, 2, 4, ..., 2^n) tartozik egy privát kulcs (k) és egy publikus kulcs (K = k·G). A mint rendszeresen új keysetet generál (a kulcsok rotációja biztonsági okokból), és a régi keyseteket inaktívvá teszi, de a már kibocsátott tokeneket továbbra is elfogadja.

A lecke kitér a keyset ID-ra, amely egy egyedi azonosító (a kulcsok hash-e), és a walletek ezen ID alapján azonosítják, hogy melyik kulcspárral kell ellenőrizniük egy adott tokent. A keyset rotáció kritikus a forward security szempontjából: ha egy privát kulcs kompromittálódik, akkor csak az adott keyset-hez tartozó tokenek érintettek, és a korábbi/későbbi keysets-hez tartozó tokenek biztonságban maradnak.

A gyakorlati implementáció szempontjából a keyset kezelés az egyik legbonyolultabb része a wallet-fejlesztésnek. A walletnek nyilván kell tartania az összes ismert keysetet, a hozzájuk tartozó publikus kulcsokat, és a kulcsok lejárati idejét. A keyset rotáció kezelése (mikor kell új keysetet használni, hogyan kell kezelni a régi tokens-t) komplex állapotgép.

A lecke említi az input fee-t is, amelyet a swap műveleteknél a mint számít fel: a walletnek az input proof-ok mellé egy kis díjat (általában 0-1 sat proof-onként) kell fizetnie, hogy a mint fedezze a swap művelet swap-out tranzakciós költségeit. Ez az input fee ösztönzi a walletet a tokenek aggregálására (kevesebb, nagyobb címletű token használatára), ami a hálózat hatékonyságát növeli.

Section10 – Kriptográfiai hashing

A tizedik lecke a Cashu által használt kriptográfiai hash-függvényeket tárgyalja, különös tekintettel a noble-hashes könyvtárra, amely a Bitcoin és Cashu implementációk standard library-jává vált. A noble-hashes a Rust nyelvű hashlib nemes parancsából származik, és tiszta TypeScript implementációt nyújt a leggyakoribb hash-függvényekhez (SHA-256, SHA-512, RIPEMD-160, HMAC-SHA256).

A lecke kitér a hash-függvények három kulcs-tulajdonságára: a preimage resistance (egy hash-ből nem lehet az eredeti üzenetet visszafejteni), a second preimage resistance (egy adott üzenethez nem lehet egy másik, azonos hash-ű üzenetet találni), és a collision resistance (nem lehet két különböző üzenetet találni, amelyek azonos hash-sel rendelkeznek). Ezek a tulajdonságok biztosítják a Cashu integritását: a proof-ok Y értéke egy hash-ből származik, és a hash-függvények tulajdonságai garantálják, hogy a proof-ok nem hamisíthatók.

A gyakorlati implementáció szempontjából a noble-hashes használata a Cashu wallet-ekben a következő: a titkos Y érték generálásakor egy véletlen sztringet SHA-256-oznak, majd a hash_to_curve függvénnyel a görbe egy pontjává alakítják. A proof integritás-ellenőrzésénél ugyanez a hash kerül kiszámításra, és a wallet ellenőrzi, hogy a proof-ban tárolt Y megegyezik-e a hash-szel.

A lecke említi a HMAC-SHA256-ot is, amely a kulcs-alapú hash-függvények családjába tartozik, és a Cashu NUT-13 specifikációjában játszik szerepet a tokonok signing-validációjánál. A HMAC (Hash-based Message Authentication Code) biztosítja, hogy egy adott üzenet (a token Y értéke) csak a megfelelő kulcs birtokában generálható, és így a hamis proof-ok készítése a kulcs ismerete nélkül kivitelezhetetlen.

A lecke kitér a CBOR (Concise Binary Object Representation) formátumra is, amelyet a Cashu a proof-ok bináris reprezentációjára használ. A CBOR a JSON-hoz hasonló, de binárisan kódolt, és kisebb helyen elfér. A Cashu proof-ok tipikusan CBOR-ban szerializálódnak, és a nut-02 specifikáció definiálja a pontos struktúrát.

A kurzus építészeti sajátosságai a középső szakaszon

A középső szakasz (Section06-Section10) a kurzus legtechnikaibb része. Itt a tanuló a felszíni magyarázatokról a tényleges implementációs részletekbe merül. A leckék sorrendje logikus: először a kriptográfiai alap (BDHKE, Section06), majd a terminológia (NUT-00, Section07), majd az adatstruktúra (BlindedMessage, Section08), majd a kulcskezelés (keysets, Section09), végül a hash-implementáció (Section10).

A leckék gyakran egymásra épülnek: a Section06-ban bemutatott BDHKE matematikai képletei a Section08 BlindedMessage struktúrájában testesülnek meg, és a Section09 keysets kezelésében a privát kulcs (k) a BDHKE-ben központi szerepet játszik. A Section10 hash-függvényei a Y érték generálásához és a proof integritás-ellenőrzéséhez kellenek.

A középső szakasz külön értéke, hogy a tanuló a kurzus elvégzése után nem csak a Cashu-t tudja használni, hanem a saját wallet-ét is képes lesz implementálni, mert minden építőkockát ismer: a kriptográfiai primitíveket (BDHKE, secp256k1, hash_to_curve), az adatstruktúrákat (BlindedMessage, Proof, Quote), a terminológiát (NUT-00), és a kulcskezelést (keysets).

3. rész: A Cashu protokoll gyakorlati API-ja (Section11–Section15)

Vezetői összefoglaló

A Cashu protokoll gyakorlati API-ja, a token-swap mechanizmus, a melt (Lightning hálózatra váltás) folyamata és a double-spend detection együttesen alkotják azt a műszaki magot, amely a Chaum-féle vak aláírásokon alapuló ecash rendszert a Lightning Networkkel összeköti. A harmadik negyed anyaga — a Section11 és Section14 között — azt mutatja be, hogyan jut el egy fejlesztő vagy auditáló szereplő az elméleti kriptográfiai ígéretektől a konkrét, végpontok közötti HTTP-kérésekig, idézőkig (quote), tranzakciós állapotgépekig és a dupla költés elleni védelmi mechanizmusokig. Az itt bemutatott négy végpont (POST /v1/swap, POST /v1/mint/quote/bolt11, POST /v1/mint/bolt11, POST /v1/melt/quote/bolt11, POST /v1/melt/bolt11, valamint GET /v1/info és GET /v1/keysets) a teljes NUT-04 és NUT-05 specifikáció gerincét adja.

A public-affairs megközelítés ezt az anyagot úgy értelmezi, mint a digitális pénzügyi infrastruktúra egyik legérzékenyebb határfelületét: ahol a magánélet védelme, a cenzúra-ellenállás, a programozhatóság és a letétkezelői kockázat egyszerre, egyetlen protokollrétegben mérlegelendő. A Swap, a Melt és a Double-Spend Detection együttesen biztosítják, hogy a Cashu tokenjei egyszerre viselkedjenek készpénzként (azonnal, végleg, peer-to-peer) és digitális fizetési eszközként (klienseken kezelhető, programozható, feltételekhez köthető).

A Cashu gyakorlati API-architektúrája

A Cashu protokoll REST-szerű HTTP végpontokra épül, amelyeket a NUT (Notation, Usage, and Terminology) specifikációk definiálnak. A wallet-implementációk (nutshell, cashu-ts, Minibits, eNuts stb.) ezeken a végpontokon keresztül kommunikálnak a Verővel (mint). A 3. negyed tananyaga négy alapvető útvonalat mutat be, amelyek együttesen fedik le a teljes életciklust: a token-cserét (swap), a Bitcoinból ecashbe váltást (mint, NUT-04), az ecashből Bitcoinba váltást (melt, NUT-05), valamint a felfedező és nyilvános metaadat-végpontokat (info, keysets, NUT-06).

A legfontosabb szerkezeti jellemző, hogy a Verő mindig kétlépcsős (quote + végrehajtás) tranzakciós mintát követ, amikor a Lightning hálózattal kommunikál. Először a wallet egy „quote” (árajánlat) végpontot hív, amely egy árat, egy díjtartalékot és egy quote-azonosítót ad vissza; a wallet ezután a tényleges „végrehajtás” végponton nyújtja be az input proofokat. Ez a minta teszi lehetővé, hogy a Verő és a wallet aszinkron módon egyeztessen a díjakról, mielőtt a Lightning-hálózati fizetés megtörténne — csökkentve ezzel a nem kívánt pótdíjak vagy az elavult BOLT11 számlák kockázatát.

A NUT-07 (proof állapotok) és a NUT-10 (spending conditions, well-known secret-ek) együttesen biztosítják, hogy a rendszer ne csak adatvédelem-központú, hanem programozható is legyen. A NUT-11 (P2PK), a NUT-12 (DLEQ proofok) és a NUT-17 (WebSocket-értesítések) a 3. negyed kiegészítő, de a működés megértéséhez elengedhetetlen elemei. A NUT-06 egységesíti a felfedezést: a wallet a /v1/info végpontból tudja meg, hogy a Verő milyen képességeket támogat, mielőtt bármilyen tranzakciót indítana.

A token-swap mechanizmus: Section11

A swap a Cashu protokoll egyik legfontosabb atomi művelete: a wallet leadja a meglévő proofjait (input), és a Verő új vak aláírásokat ad ki számára (output), azonos összértékben, esetleges díjak levonásával. A cél háromrétű: (1) nagy címletek felosztása kisebbekre, (2) sok apró token összevonása kevesebb nagyobb címletbe a tárhely és a tranzakciós költségek csökkentése érdekében, valamint (3) a proofok frissítése a hosszú távú adatvédelem fenntartásához. Még ha az összegek nem is változnak, a swap új vak aláírásokat generál, amelyeket a Verő a BDHKE (Blind Diffie–Hellmann Key Exchange) nem-összekapcsolhatósági tulajdonsága miatt nem tud összekötni a régi proofokkal.

A NUT-03-ban definiált POST /v1/swap végpont JSON-formátumú kérést fogad, amelynek két fő része az inputs (a leadandó proofok listája, titkokkal és signature-ökkel) és az outputs (a vakított BlindedMessage-ök listája, amelyeket a wallet generál). A Verő a kérés feldolgozásakor három ellenőrzést hajt végre: (1) minden input proof aláírása érvényes-e az adott kulcskészlethez (keyset) és címlethez, (2) az input proofok összege megegyezik-e az output proofok összegével (díjak levonásával), valamint (3) egyik input proof sem szerepel-e már a spent proof adatbázisban. A művelet atomi: vagy minden inputot elfogad és minden outputot kiad, vagy egyiket sem — így nincs részleges végrehajtás.

A tananyag egy konkrét példán keresztül mutatja be a swap gyakorlati hasznát. Tegyük fel, hogy Alice-nak van egy 64 satos proofja, de 21 satot akar küldeni Bobnak. Először swappelnie kell: a 64-es proofot hét kisebb (32, 16, 8, 4, 2, 1, 1) proofra bontja. Ezután kiválasztja a 21 satot kitevő kombinációt (16 + 4 + 1), és a többit megtartja magának. Egy másik tipikus forgatókönyv az, amikor a wallet sok apró, egy-két satos proofot halmozott fel (például [1, 1, 2, 4, 4, 4, 8, 8], összesen 32 sat), és a tárigény, valamint a későbbi tranzakciók egyszerűsítése érdekében egyetlen 32 satos proofba vonja össze azokat. Mindkét esetben a művelet díja a Verő kulcskészletének fee-rate mezőjétől függ, és a tananyag hangsúlyozza, hogy a swap az adatvédelem egyik legkritikusabb pontja: ha a wallet mindig ugyanabban a sorrendben adja le az output proofokat, a Verő heurisztikákat alkalmazhat a fizetési összeg kikövetkeztetésére.

A Cashu specifikáció ezért kifejezetten javasolja az output proofok rendezését (tipikusan címlet szerint növekvő vagy csökkenő sorrendbe), hogy a swap-műveletek a lehető legkevesebb információt szivárogtassák ki. A másik kritikus adatvédelmi lépés a fogadás pillanatában történik: amikor Bob megkapja Alice tokeneit, azonnal swappelnie kell azokat, mert a régi proofok még mindig Alice birtokában vannak, és versenyezhetnek a Verőnél a dupla költésért. Ez a „swap immediately on receive” ajánlás a 3. negyed egyik legfontosabb gyakorlati tanácsa, és a Section15-ben (Double-Spend Detection) részletesen kibontjuk, miért kritikus ez a lépés.

A melt folyamat: Section13

A melt a Cashu protokoll ki- és belépő kapuja a Bitcoin ökoszisztémából: a felhasználó ecash tokenjeit valós Lightning fizetésre cseréli. A NUT-05 specifikációban definiált művelet inverze a mintingnek (NUT-04): míg a minting során a felhasználó Lightning számlát fizet, és tokeneket kap cserébe, addig a melt során a felhasználó leadja a tokenjeit, és a Verő fizet egy Lightning számlát a felhasználó nevében. A két művelet együtt alkotja a Cashu on-ramp és off-ramp rendszerét.

A folyamat a POST /v1/melt/quote/bolt11 végponttal kezdődik, ahol a wallet benyújtja a kifizetendő BOLT11 számlát. A Verő válasza egy quote-objektum, amely tartalmazza a számla összegét (például 900 sat), a maximális útvonal-díjat (fee_reserve, tipikusan 10 sat), a quote azonosítót, valamint egy állapotjelzőt. A quote három lehetséges állapotban lehet: UNPAID (a fizetés még nem indult), PENDING (a Lightning fizetés folyamatban van), és PAID (a fizetés sikeresen megtörtént). A wallet ezután a POST /v1/melt/bolt11 végponton nyújtja be a proofjait, amelyek összértékének fedeznie kell a számla összegét és a fee_reserve összegét egyaránt — a fenti példában tehát legalább 910 satnyi proofot kell leadni.

A fee_reserve koncepció a Lightning hálózat sajátosságaiból fakad: a Verő nem ismeri előre a pontos útvonal-díjat, amellyel a BOLT11 számlát ki tudja egyenlíteni, ezért egy felső becslést kér a wallet-től, hogy fedezze az esetlegesen magasabb routing költséget. A tényleges díj a fizetés pillanatában derül ki; ha a tényleges díj alacsonyabb a fee_reserve-nél, a Verő visszaadja a különbözetet change (visszajáró) formájában. A tananyag konkrét példája: 912 satnyi input proof, 900 sat számla, 10 sat fee_reserve, a tényleges routing díj 8 sat → a Verő 2 satnyi vak aláírást ad vissza change-ként. A teljes költség tehát 900 + 8 = 908 sat, nem pedig 910.

A melt sikeres végrehajtását egy kritikus kriptográfiai elem, a preimage (32 bájtos érték) zárja le. A preimage a BOLT11 számlában lévő payment hash megoldása, és a fizetés sikerességének egyetlen igazolása. Amikor a Verő megkapja a preimage-et a Lightning hálózattól, visszaadja azt a walletnek, amely így bizonyítékot nyer a fizetés véglegesítésére. Ez a mechanizmus teremt kapcsolatot a Cashu belső, vak-aláírás-alapú világa és a Lightning külső, hash-időzítéses világa között. Ha a Lightning fizetés valamilyen oknál fogva meghiúsul (lejárt számla, routing hiba, átmeneti csomópont-kimaradás), a Verő a proofokat visszaállítja UNSPENT állapotba, így a wallet újrapróbálkozhat vagy másik számlát használhat — a PENDING állapotú proofok pedig nem használhatók fel párhuzamosan másik tranzakcióban, ami kiküszöböli a dupla költés kockázatát a fizetés ideje alatt.

Hálózati végpontok és felfedezés: Section14

A Section14 a Verővel való kommunikáció technikai oldalát tárgyalja: a CORS (Cross-Origin Resource Sharing) kezelését, a /v1/info végpontot, valamint a felfedezés (mint discovery) különböző mechanizmusait. A CORS-probléma a webes walletek egyik legyakoribb gyakorlati akadálya: ha a Verő szervere nem küld Access-Control-Allow-Origin fejlécet, a böngésző alapértelmezetten blokkolja a cross-origin kéréseket, még akkor is, ha a Verő egyébként működik. Ez nem biztonsági hiba, hanem konfigurációs kérdés: a Verő üzemeltetőjének tudatosan kell beállítania a CORS-szabályokat, ha böngészőből is el akarja érni a wallet.

A /v1/info végpont a Verő öndefiníciós felülete. A wallet az első lépésben mindig ezt a végpontot hívja, hogy megismerje a Verő képességeit: a szoftver nevét és verzióját (pl. „nutshell 0.16.0”), a hosszú távú nyilvános kulcsot (hex formátumban, amely az identitáshoz kell, nem pedig a token-aláíráshoz), a támogatott NUT-ok listáját (beleértve, hogy a NUT-11 P2PK, a NUT-12 DLEQ, a NUT-17 WebSocket támogatott-e), a támogatott fizetési módokat (BOLT11, BOLT12), valamint a Message of the Day (MOTD) szabad szöveges mezőt. A wallet a NUT-ok listájából tudja meg, hogy a Verő támogatja-e a well-known secret-eket (NUT-10), a multisig feltételeket, illetve a maximális és minimális tranzakciós összegeket. A MOTD-t a wallet köteles megjeleníteni a felhasználónak, ha az nem üres — ez az útvonal a tervezett karbantartások, díjmódosítások és migrációs értesítések kommunikálására.

A felfedezés (hogyan találnak egymásra a felhasználók és a Verők) több csatornán zajlik. A legegyszerűbb, amikor a felhasználók egymásnak küldenek Verő-URL-eket üzenetben vagy linken. Emellett közösségi kurátorok által karbantartott nyilvános Verő-könyvtárak is léteznek, és a Cashu tokenek maguk is tartalmazzák a kibocsátó Verő URL-jét, így a fogadó fél automatikusan tudja, hol kell beváltania azokat. Egyes Verők Nostr reléken publikálják az info objektumukat, ami decentralizált felfedezést tesz lehetővé. A tananyag hangsúlyozza: az info végpont által közölt adatok nem bizonyítják a Verő megbízhatóságát — bármely Verő bármilyen nevet és képességet deklarálhat. A wallet és a felhasználó felelőssége, hogy megbízhatósági szempontból mérlegeljen (mióta üzemel az adott Verő, milyen a reputációja, mekkora összeget hajlandó ott tartani). Sok wallet támogatja egyidejűleg több Verőhöz való csatlakozást, és a felhasználók szétszórhatják az ecash egyenlegüket több Verő között, csökkentve ezzel az egypontos meghibásodás kockázatát. Minden Cashu token ahhoz a Verőhöz van kötve, amelyik kiállította: A Verő tokenjeit nem lehet B Verőnél beváltani.

A double-spend detection: Section15

A dupla költés (double-spend) az összes digitális pénzrendszer alapkihívása: a digitális adatok tökéletesen másolhatók, így a küldő a tranzakció után is megtarthatja a token másolatát. A Cashu esetében, amikor Alice elküld egy tokent Bobnak (akár üzenetküldő alkalmazáson, akár e-mailben, akár QR-kódon keresztül), Alice továbbra is birtokolja a token karakterláncát — és megkísérelheti azt a Verőnél elsőként beváltani, megelőzve ezzel Bobot. Ezt a támadást a rendszer csak akkor tudja megakadályozni, ha minden proof felhasználását a Verő nyilvántartja, és bármely ismételt felhasználást visszautasítja. A NUT-07 specifikáció pontosan ezt a mechanizmust definiálja: a Verő minden proofot három állapot egyikében tartja nyilván (UNSPENT, PENDING, SPENT), és a wallet a /v1/checkstate végponton keresztül kérdezheti le egy adott proof aktuális állapotát.

A belső megvalósítás kulcsa, hogy a Verő nem magát a proof secretet tárolja, hanem a secretből származtatott Y = hash_to_curve(secret) görbepontot. Ez lehetővé teszi, hogy a Verő az állapotot a secret felfedése nélkül ellenőrizze (hiszen a hash_to_curve egyirányú függvény, és a görbepont diszkrét logaritmus-problémája miatt a secret visszafejtése kivitelezhetetlen). Minden egyes proof Y-pontját a Verő egy „spent proof” adatbázisban tárolja, és a swap vagy melt tranzakciók során ellenőrzi, hogy az adott Y-pont már szerepel-e a listán. Ha igen, a tranzakciót elutasítja; ha nem, az új Y-pont bekerül az adatbázisba, és a proof SPENT állapotba kerül. Mivel a Y-pont determinisztikusan kötődik a secret-hez, a proof másolatának bármilyen módosítása (más kulcskészlet, más signature, más összeg) esetén is ugyanaz a Y-pont keletkezik, így a dupla költés kísérlete minden esetben kiszűrhető.

A három állapot (UNSPENT, PENDING, SPENT) együttesen kezeli a párhuzamosság és az aszinkronitás problémáit. Az UNSPENT azt jelenti, hogy a proof szabadon felhasználható. A PENDING a melt műveletek közbeni állapot: a Verő a proofot zárolja, amíg a Lightning fizetés függőben van — így a felhasználó nem tudja ugyanazt a proofot párhuzamosan másik tranzakcióban is elkölteni. A SPENT a véglegesen érvénytelenített állapot, ahonnan nincs visszaút. A wallet-oldali gyakorlat szerint fogadás után azonnal swapet kell indítani, mert az UNSPENT proof a másodperc törtrésze alatt is SPENT-be kerülhet, ha a küldő egy másik csatornán gyorsabban cselekszik. A Section15 emellett két további fontos felhasználási esetet emel ki: (1) offline walletek szinkronizálásakor az állapot-ellenőrzéssel a wallet megtudhatja, mely tokenjei maradtak érvényesek egy másik eszközön történt költés után; (2) melt műveletek során a wallet pollingolhatja az állapotot, hogy nyomon kövesse a PENDING → SPENT átmenetet, és a preimage megérkezését.

Biztonsági és adatvédelmi vonatkozások

A 3. negyed tananyaga több biztonsági mechanizmust is részletez, amelyek a fenti négy fő témakört védik. A NUT-10 (Spending Conditions) a well-known secret fogalmát vezeti be: a proof secretje nem feltétlenül egyszerű véletlen bájtsor, hanem egy strukturált JSON-tömb, amely [kind, {nonce, data, tags}] formátumban kódolja a felhasználási feltételeket. A kind mező határozza meg a feltétel típusát (P2PK, HTLC, locktime), a nonce biztosítja, hogy azonos feltétel mellett minden secret egyedi legyen, a data mező a feltétel-specifikus adatokat (például a P2PK címzett nyilvános kulcsát vagy a HTLC hash-ét) tartalmazza, a tags mező pedig kiegészítő paramétereket (signature flagek, multisig küszöb, locktime, refund kulcsok). A NUT-11 (P2PK) a tokeneket egy adott nyilvános kulcshoz köti, így a tokent csak a megfelelő privát kulcs birtokosa költheti el — ehhez a witness mezőben egy Schnorr-aláírást kell csatolni.

A NUT-12 (DLEQ Proofs) a Verő őszinteségét védi: a DLEQ (Discrete Log Equality) zéró-ismeretű bizonyíték garantálja, hogy a vak aláírás ugyanazzal a privát kulccsal készült, mint amit a Verő a /v1/keys végponton közzétett. Ennek hiányában egy rosszhiszemű Verő olyan aláírást adhatna, amelyik látszólag érvényes, de a tényleges kulcskészlethez nem tartozik — a felhasználó csak a beváltáskor szembesülne a hibával. A DLEQ emellett egy inflation attack formát is kiszűri: ha a Verő egy 64 satos proofot 1 satos kulccsal ír alá, a DLEQ ellenőrzés megbukik. A BOLT11 integráció a Lightning Network felé nyit kaput: a NUT-04 és NUT-05 végpontok (mint quote, mint bolt11, melt quote, melt bolt11) a BOLT11 számlákat használják a legelterjedtebb formátumként, de a NUT-05 kiterjesztései a BOLT12 offers szabványt is támogatják, amely újrafelhasználható, a vevő csomópont-identitását elrejtő, és lejárat nélküli fizetési kódokat kínál.

A teljes rendszer adatvédelmi elemzése egy finom egyensúlyt mutat: a BDHKE biztosítja, hogy a Verő ne tudja összekapcsolni a régi és új proofokat swap során; a NUT-10 well-known secret-ek láthatóvá teszik a P2PK/HTLC feltételeket a Verő számára, de a Verő továbbra sem tudja a proofot a kibocsátáshoz kötni a vak aláírások miatt. A dupla költés elleni védelem hatékony, de a Y-pontok adatbázisa a Verő oldalán idővel monoton növekszik, ami a privacy set korlátait jelzi. A NUT-10 strukturált secret-ek a tokeneket programozhatóvá teszik (P2PK a nem-letétkezelő átutaláshoz, HTLC az atomi cross-mint swap-ekhez), egyúttal utat nyitnak a lightning-htlc-kkel kompatibilis, láncon kívüli tranzakciós konstrukciók felé.

Gyakorlati tanulságok és szabályozási vonatkozások

A 3. negyed négy legfontosabb gyakorlati tanulsága közvetlenül alkalmazható a wallet-fejlesztésben, az auditálásban és a szabályozói párbeszédben egyaránt. Először: a swap soha nem szabad automatikus vagy lusta (lazy) lépésként kezelni — fogadás után azonnal kell indítani, mert a Verő a Y-pont alapján nem tud különbséget tenni a jogos és a csalárd újrafelhasználás között. Másodszor: a melt quote-ok fee_reserve értéke egy felső becslés, ezért a wallet mindig adjon change outputokat, hogy a túlfizetett díjrészt visszakapja a felhasználó. Harmadszor: a /v1/info végpont elengedhetetlen a NUT-ok feature-detection-jéhez, és a wallet köteles a MOTD-t megjeleníteni, mert ez a Verő elsődleges kommunikációs csatornája a felhasználók felé. Negyedszer: a P2PK feltételeket használó walleteknek a SIG_ALL signature flaget kell alapértelmezetten használniuk, mert ez véd a kimenet-módosításos támadások ellen.

A szabályozói párbeszéd szempontjából a 3. negyed anyaga egyértelműsíti, hogy a Cashu nem egy új digitális eszköz, hanem egy fizetési réteg, amely a meglévő Bitcoin és Lightning protokollokra épül. A Verő üzemeltetők letétkezelői (custodial) szerepet töltenek be, ami a hagyományos pénzügyi szabályozás (pl. MiCA, CARF) hatálya alá eshet. A tananyag hangsúlyozza, hogy a NUT-10 és NUT-11 által biztosított programozhatóság (P2PK, multisig, locktime) a Cashu-t a magánszemélyek közötti, nem-letétkezelő fizetések platformjává teszi, miközben a Verő központi szerepe a hagyományos letétkezelési kockázatokat (single point of failure, szabályozói nyomás, működési leállás) is bevezeti. A peer-to-peer átutalások (P2PK) és a BOLT12 offer-ek kombinációja hosszú távon a Lightning hálózati identitás nélküli, újrafelhasználható fizetési kódok irányába mutat, ami a jegybanki digitális pénzekkel (CBDC) és a stablecoin-okkal szemben is alternatívát kínál.

Záró gondolatok

A Cashu protokoll gyakorlati API-ja, a token-swap mechanizmus, a melt folyamat és a double-spend detection együtt alkotják a rendszer működési gerincét. A swap atomi, díjkiegyenlítéses és BDHKE-alapú adatvédelmet garantáló művelete, a melt kétlépcsős quote-végrehajtás mintája, a /v1/info végpont feature-detection mechanizmusa, valamint a Y-pont-alapú dupla-költés-védelem együttesen biztosítják, hogy a Cashu egyszerre feleljen meg a digitális készpénz és a modern fizetési protokollok követelményeinek. A 3. negyed leckéi a Section15–Section19 kiegészítésekkel (NUT-10 well-known secret, NUT-11 P2PK, NUT-12 DLEQ, BOLT11 integráció) együtt lefedik a teljes NUT-03, NUT-04, NUT-05, NUT-06, NUT-07, NUT-10, NUT-11, NUT-12 specifikációs halmazt, felkészítve a fejlesztőt, auditort és szabályozót a protokollal való biztonságos és hatékony munkára.

4. rész: Haladó funkciók (Section16–Section19)

4. rész: NUT-10/11/12, P2PK, DLEQ proofs, BOLT11 integráció

A Cashu protokoll a Chaum-féle vak aláírás (blind signature) elvén működő, nyílt forráskódú ecash rendszer, amely a Bitcoin Lightning Networkére épül. A protokoll magját a NUT-00 (Notation, Units, Terminology) és az azt kiegészítő NUT specifikációk (Nuts) definiálják; ezek határozzák meg, hogyan viszonyulnak egymáshoz a felhasználói pénztárcák, a verők (mint) és a Lightning csomópontok. A sorozat negyedik része a Cashu haladó, programozható funkcióit tekinti át: a NUT-10 spending conditions, a NUT-11 P2PK (Pay-to-Public-Key) zárolási mechanizmust, a NUT-12 DLEQ (discrete-log equivalence) honesty proofokat, valamint a BOLT11 alapú Lightning integráció részleteit. Ezek együttesen alakítják át a puszta „elektronikus készpénzt” egy programozható, többeszközös (multi-unit), auditálható fizetési protokollá.

A NUT-10, NUT-11 és NUT-12 szerepe a protokollban

A Cashu nem egyetlen, monolitikus specifikáció: a NUT-00-t követően a NUT-01 (Mint Info), NUT-02 (Keysets and Key Generation), NUT-03 (Swap), NUT-04 (Mint), NUT-05 (Melt), NUT-06 (Mint Info extension) a protokoll gerincét adják, míg a NUT-10, NUT-11 és NUT-12 a haladó, opcionális képességeket írják le. A „NUT” elnevezés a Bitcoin „BIP” (Bitcoin Improvement Proposal) hagyományát követi: rövid, egy-egy jól körülhatárolt funkcióra fókuszáló specifikációk, amelyeket a közösség konszenzussal fogad el. A NUT-10 a spending conditions, vagyis a költési feltételek rendszerét definiálja; a NUT-11 a P2PK zárolási mechanizmust; a NUT-12 pedig a DLEQ proofokat, amelyek a verő (mint) őszinteségét hivatottak bizonyítani. E három NUT együttesen teremti meg a lehetőséget, hogy a Cashu tokenek ne csak egyszerű „bemutatóra szóló” zsetonok legyenek, hanem programozható, feltételhez kötött, auditálható digitális eszközök.

A NUT-10, NUT-11 és NUT-12 a protokoll „felnövéstörténetének” kulcsállomásai. A korábbi NUT-ok kizárólag a vak aláírás és a Lightning deposit/melt ciklusra koncentráltak, és nem nyitottak utat sem a kulcs alapú zárolásnak, sem a verő (mint) visszaélésének kriptográfiai detektálásához. A NUT-10, NUT-11 és NUT-12 bevezetésével a Cashu egy lépéssel közelebb került ahhoz, hogy ne csak technológiai demó, hanem intézményi szinten is használható fizetési infrastruktúra legyen — feltéve, hogy a felhasználók és az üzemeltetők is követik azokat a biztonsági mintákat, amelyeket ezek a NUT-ok megszabnak.

NUT-10: spending conditions, avagy a programozható költési feltételek

A NUT-10 a tokenekhez rendelhető költési feltételeket (spending conditions) definiálja. A legegyszerűbb esetben egy Cashu proof (a token alapegysége) bárki által beváltható, aki birtokolja a proofhoz tartozó secret értéket — a birtoklás (possession) maga a jogosultság. Ez a modell a Chaum-féle ecash alapfilozófiája: a token úgy viselkedik, mint egy fizikai bankjegy, és a verő (mint) semmit nem tud a tulajdonos személyazonosságáról. A NUT-10 ezt a modellt egészíti ki azzal, hogy a proofokhoz opcionálisan spending condition objektumokat lehet csatolni, amelyek a verőt (mint) arra kényszerítik, hogy a beváltás előtt ellenőrizzen bizonyos feltételeket.

A NUT-10 gyakorlati értelme, hogy a felhasználó már a tokenek kibocsátásakor (minting) megadhatja, milyen feltételek mellett lehet azokat elkölteni. A legegyszerűbb feltétel a „bárki elköltheti” (no spending condition), de a NUT-10 bevezeti a P2PK zárolás lehetőségét, amely a NUT-11-ben részletezett módon egy konkrét nyilvános kulcshoz (public key) köti a tokent. A P2PK feltétel teljesül, ha a beváltó a saját titkos kulcsával (private key) alá tudja írni a tranzakciót — ezáltal a tokent csak a kulcs tulajdonosa költheti el. A NUT-10 ezen felül időzár (timelock) és egyéb, jövőben bevezethető feltételek számára is keretet biztosít.

A spending conditions bevezetése átalakítja a Cashu kockázati profilját. Míg a „bárki által beváltható” tokenek elvesztésük vagy ellopásuk esetén azonnal és visszavonhatatlanul elvesznek, a P2PK-zárolt tokeneknél a támadónak a kulcsot is meg kell szereznie. Ugyanakkor a spending conditions növelik a protokollt: a verő (mint) kriptográfiai ellenőrzést végez minden beváltáskor, és a feltételek kiértékelése plusz számítási kapacitást igényel. A kurzus hangsúlyozza, hogy a NUT-10 önmagában nem elég: a gyakorlati biztonság a NUT-11 (a zárolás részletes szintaxisa) és a NUT-12 (a verő (mint) által használt kulcsok hitelessége) együttes alkalmazásától függ.

NUT-11: P2PK — a Pay-to-Public-Key zárolás

A NUT-11 a P2PK (Pay-to-Public-Key) zárolás specifikációja, amelyet a NUT-10 keretében lehet használni. A P2PK lényege, hogy a tokenek egy adott secp256k1 nyilvános kulcshoz kötődnek, és csak a hozzá tartozó titkos kulccsal lehet őket elkölteni. Ez a mechanizmus párhuzamba állítható a Bitcoin P2PK (illetve P2PKH, P2WPKH) címzési modelljével, de a Chaum-féle vak aláírás miatt a verő (mint) nem látja a zárolás tényét, amíg a felhasználó be nem mutatja a proofot. A NUT-11 részletes szintaxist ad a pubkeys, required_signatures (multisig esetén) és egyéb locktime mezőkre, amelyeket a proofokhoz csatolt spending conditions blokk tartalmaz.

A P2PK használati esetei között a kurzus kiemeli a „vidd magaddal a kulcsot” (key-rotation-safe), az intézményi letétkezelés és a multisig wallet-integráció forgatókönyveit. Például egy felhasználó generálhat egy P2PK zárolású tokent a saját hardveres pénztárcájának kulcsával — így ha a tokeneket tartalmazó mobil eszköze elveszik, a támadó nem tudja őket elkölteni a hardveres pénztárca hozzáférése nélkül. Egy másik tipikus eset, amikor egy szolgáltató (pl. egy paywalled tartalom üzemeltetője) zárolja a tokeneket a saját kulcsával, és csak a felhasználó „váltja be” a saját kulcsával aláírt tranzakcióval — ezáltal a verő (mint) és a szolgáltató közötti munkamegosztás tisztán kriptográfiailag definiált.

A NUT-11 egyik legérdekesebb aspektusa a refund (visszatérítés) mechanizmus. Ha egy P2PK-zárolt tokent a címzett nem tud vagy nem akar beváltani, a küldő saját kulcsával aláírhat egy „return_signature” üzenetet, amellyel a zárolás feloldható, és a tokenek visszakerülnek hozzá. Ez a mechanizmus megakadályozza, hogy a tokenek „beragadjanak” a rendszerbe: a küldő mindig rendelkezik egy vészkijárattal. A kurzus rámutat, hogy a refund kulcsot a tokenek létrehozásakor érdemes megadni, mert utólag már nem lehet utólag hozzáadni — a P2PK zárolás a kiadás pillanatában „betonozódik be”.

A NUT-11 másik fontos eleme a multisig (multi-signature) támogatás. A spending conditions blokkban több nyilvános kulcs is megadható, és a required_signatures mező határozza meg, hogy közülük hánynak kell aláírnia a tranzakciót. Ez a mechanizmus lehetővé teszi, hogy a Cashu tokeneket intézményi (pl. 2-of-3 multisig) vagy családi (pl. 1-of-2 spouse-key) tárcák kezeljék. A multisig a Chaum-féle ecash egyik legnagyobb újdonsága: a Bitcoin multisig címekhez hasonlóan itt is „M-of-N” zárolás valósítható meg, de a vak aláírás miatt a verő (mint) továbbra sem tudja, hogy a zárolás multisig-e, amíg a tranzakciót be nem mutatják.

NUT-12: DLEQ proofs — a verő (mint) őszinteségének bizonyítása

A NUT-12 a DLEQ (discrete-log equivalence) proofokat definiálja, amelyek a verő (mint) által használt kulcsok hitelességét hivatottak igazolni. A DLEQ proofok célja, hogy a felhasználó kriptográfiailag bizonyítva láthassa: a verő (mint) a NUT-02-ben bejelentett kulcskészlet (keyset) kulcsait valóban használja-e a vak aláíráshoz, és nem egy „eltérített” kulccsal ír-e alá. A NUT-12 problémája az, hogy a verő (mint) birtokolja a kulcsokat, és a felhasználó nem látja közvetlenül, hogy a kapott blind signature melyik kulccsal készült — csak a későbbi swap vagy melt műveletnél derül ki, hogy a proof konzisztens-e a bejelentett keyset-tel.

A DLEQ proofok ezt a bizonytalanságot szüntetik meg. A DLEQ (discrete logarithm equivalence) egy nulla-ismeretű (zero-knowledge) bizonyítási protokoll, amely két elliptic curve pontpár közötti egyenértékűséget mutatja ki anélkül, hogy felfedné a diszkrét logaritmust. A NUT-12 kontextusában a verő (mint) minden aláíráskor egy DLEQ proofot csatol, amely bizonyítja, hogy a B_ (vak aláírási pont) és a C_ (commitment pont) ugyanazzal a kulccsal lett aláírva, mint amit a keyset ígér. A felhasználó walletje ellenőrzi a DLEQ proofot, és ha az érvénytelen, akkor tudja, hogy a verő (mint) nem a bejelentett kulcsot használta — ezáltal csalás történik.

A DLEQ proofok a kurzus szerint két kritikus fenyegetést kezelnek. Az egyik, hogy a verő (mint) hamis kulcsot használ a vak aláíráshoz, és ezzel később „bevállthatja” a felhasználók tokeneit — ha minden felhasználót ugyanazzal a hamis kulccsal ír alá, a verő (mint) a keyset rotáció után is visszafejtheti a korábbi proofokat. A másik, hogy a verő (mint) az ígértnél kevesebb kulccsal dolgozik, és a valós tartalékai (reserves) nem fedezik az összes kibocsátott tokent — vagy fordítva, a verő (mint) a felhasználók Lightning depositjait eltéríti, és a keyset rotáció során „eltűnik” a fedezettel. A DLEQ proofok nem akadályozzák meg, hogy a verő (mint) extra proofokat gyártson a saját kulcsával (hiszen a kulcsot amúgy is birtokolja), de detektálják, ha a kulcs nem konzisztens a bejelentett keyset-tel. Ezzel a DLEQ a Cashu egyik legfontosabb „honesty proof” mechanizmusa: a felhasználók kriptográfiailag ellenőrizhetik a verő (mint) integritását, anélkül, hogy a verő (mint) elvesztené a vak aláírásból fakadó anonimitást.

A NUT-12 másik aspektusa a keyset rotáció támogatása. A Cashu protokollban a verők (mint) rendszeresen új keysetset vezetnek be (NUT-02), és a régi keyseteket inaktiválják. A DLEQ proofok biztosítják, hogy a kulcsváltás zökkenőmentes legyen: a felhasználó walletje ellenőrizni tudja, hogy a régi és az új kulcsok közötti átmenet konzisztens, és a proofok a rotáció után is érvényesek maradnak. A kurzus rámutat, hogy a DLEQ proofok a NUT-12-nél is fontosabb szerepet játszanak a hosszú távú megbízhatóságban, mint a NUT-11 — mert míg a P2PK zárolás opcionális, a DLEQ proofok a verő (mint) alapvető integritását védik.

BOLT11 integráció: a Lightning, mint deposit és melt csatorna

A Cashu protokoll a BOLT11 (Lightning Network Invoicing) szabványt használja a Bitcoin Lightning hálózattal való interakcióhoz. A BOLT11 a Lightning „fizetési kérelem” (payment request) formátuma, amelyet a verő (mint) generál, amikor a felhasználó ecash-t akar kibocsátani (mint), és amelyet a felhasználó fizet be a Lightning hálózaton keresztül. A fordított irány, a melt (az ecash tokenek Lightning kifizetéssé alakítása) szintén BOLT11 invoice-okon keresztül történik. A BOLT12 (a BOLT11 utódja, amely offer-eket és blind route-okat támogat) opcionális, és csak néhány verő (mint) implementálja; a kurzus a BOLT11-et tekinti a „default” integrációs formátumnak.

A BOLT11 integráció korlátai a kurzus szerint két dimenzióban jelentkeznek. Az egyik a Lightning invoice méretkorlátja: a BOLT11 invoice-ok tipikusan néhány száz bájtméretűek, és a BOLT11 specifikáció nem támogatja a nagyon nagy összegek (1M sat felett) natív kezelését — a Cashu verők (mint) ezért gyakran bevezetnek egy felső limitet (pl. 1M sat BOLT11 esetén, 500K sat BOLT12 esetén). A másik korlát a BOLT11 nem interaktív jellege: a küldő nem kap visszajelzést a fizetés állapotáról, amíg az be nem érkezik — ez a Cashu melt műveletnél azt jelenti, hogy a felhasználónak türelmesen kell várnia a Lightning HTLC (Hash Time-Locked Contract) véglegesítésére.

A BOLT11 integráció a NUT-04 (mint) és NUT-05 (melt) NUT-okban van részletezve. A NUT-04 a deposit flow-t írja le: a felhasználó kéri a verőt (mint), hogy generáljon egy Lightning invoice-t, majd a felhasználó ezt az invoice-t egy Lightning tárcával kifizeti, és a verő (mint) a beérkező fizetés után bocsátja ki az ecash proofokat. A NUT-05 a melt flow-t definiálja: a felhasználó átadja a Lightning invoice-t (amelyet egy másik fél generált) és a megfelelő ecash proofokat a verőnek (mint), amely kifizeti az invoice-t a Lightning hálózaton, és a proofokat érvényteleníti. Mindkét flow a BOLT11 formátumra épül, és a BOLT11 invoice-ok hash-e (a payment_hash mező) szolgál a Cashu oldali egyediség garanciájaként.

A kurzus hangsúlyozza, hogy a Cashu protokoll fizetési-módszer-agnosztikus: a BOLT11 csak egy a lehetséges integrációs formátumok közül. A protokolltervezők szándéka szerint a jövőben új NUT-ok definiálhatnak más fizetési módokat is — on-chain Bitcoin, Liquid network tranzakciók, vagy akár fiat banki átutalások — anélkül, hogy a mag protokoll (a vak aláírás, a keyset, a BDHKE blinding) megváltozna. Ez a modularitás a Cashu egyik legnagyobb erőssége: a verő (mint) üzemeltetők szabadon választhatják meg, milyen fizetési módokat támogatnak, és a felhasználói walletek a NUT-ok által definiált interfészeken keresztül egységesen kezelhetik ezeket.

Multi-unit keysets és a jövőbeli fizetési módok

A kurzus egy másik fontos témája a multi-unit keysetek rendszere. A Cashu alapértelmezetten satoshi alapú (BTC sat), de a NUT-02-ben definiált keysetekhez opcionálisan megadható egy unit mező, amely meghatározza, hogy a keyset milyen pénznemet reprezentál. Egyetlen verő (mint) több unitot is támogathat, különböző keysetssokkal: Bitcoin sat (Lightning hátország), USD cent (stablecoin vagy fiat hátország), és egyéb, jövőben bevezethető unitok. A token unit mezője határozza meg, hogy az amount mező milyen értéket jelent — a 100 amount sat unit mellett 100 satoshit, míg usd unit mellett $1.00-t (100 cent) ér.

Ez a multi-unit képesség teszi a Cashu-t alkalmassá intézményi, fintech szintű használatra. Egy vállalat működtethet olyan verőt (mint), amely egyszerre támogat BTC sat és USD cent unitokat, és a felhasználók szabadon válthatnak a kettő között swap műveletekkel. A kurzus kiemeli, hogy a unitok a keysetshez kötöttek: minden keyset egyetlen unitot támogat, és a verő (mint) a keyset rotáció során dönti el, milyen unitot vezet be. A multi-unit rendszer ugyanakkor új kihívásokat is hoz: a swap műveleteknek figyelembe kell venniük a unit-konverziót, és a felhasználói walleteknek pontosan kell nyilvántartaniuk, hogy melyik proof melyik keysetből származik.

A protokoll payment-method-agnosticitása a NUT-ok jövőbeli bővíthetőségét vetíti előre. A kurzus megemlíti, hogy a jövőben új NUT-ok definiálhatnak on-chain Bitcoin (NUT-??), Liquid network (NUT-??), vagy akár fiat banki átutalás (NUT-??) alapú deposit/melt flow-kat. Ezek a kiterjesztések a mag protokollt nem érintenék: a BDHKE blinding, a keyset struktúra, a vak aláírás és a proofok érvényesítése változatlan maradna, és csak a deposit/melt végpontokon történne a különböző fizetési módokhoz való illesztés. A Cashu ökoszisztémában ez a „payment-method-agnostic” filozófia a fő értékesítési pont: a verő (mint) üzemeltetők szabadon kísérletezhetnek új fizetési módokkal anélkül, hogy a teljes stack-et újra kellene építeniük.

A 4. rész legfontosabb tanulságai

A 4. rész a Cashu protokoll haladó, programozható funkcióit tekintette át. A NUT-10 spending conditions a proofokhoz csatolható opcionális feltételrendszert definiál; a NUT-11 P2PK zárolás egy konkrét nyilvános kulcshoz (vagy multisig konfigurációhoz) köti a tokent; a NUT-12 DLEQ proofok a verő (mint) által használt kulcsok integritását védik; és a BOLT11 integráció biztosítja a Bitcoin Lightning hálózattal való natív interakciót. Ezek együttesen a Cashu-t a puszta „Chaumian ecash”-ból egy programozható, auditálható, többeszközös fizetési protokollá emelik.

A kurzus záró megjegyzése szerint a NUT-10, NUT-11 és NUT-12 együttesen a Cashu „haladó arcát” testesítik meg, és ezeket a funkciókat a walletfejlesztőknek és a verő (mint) üzemeltetőknek egyaránt ismerniük kell. A DLEQ proofok különösen fontosak, mert a verő (mint) integritásának kriptográfiai bizonyítékai — a felhasználók a walletjükben ellenőrizhetik, és ha a verő (mint) nem konzisztens, a wallet azonnal jelzi. A P2PK zárolás a kulcskezelés új szintjét hozza, és a BOLT11 integráció biztosítja, hogy a Cashu tokenek zökkenőmentesen válthatók Lightning kifizetésekre és vissza.

A sorozat következő, 5. része a wallet implementációt, a verő (mint) üzemeltetés gyakorlati kérdéseit és a teljes kurzus-összefoglalót tárgyalja.

5. rész: Wallet implementáció és a teljes kép (Section20–Section22)

5. rész: Wallet implementáció, mint üzemeltetés, teljes kurzus-összefoglaló

A Cashu Chaumian ecash protokoll huszonhárom leckéből álló Math Academy kurzusának záró része a gyakorlati implementációra és a teljes kép összefoglalására fókuszál. Az 5. rész három nagy témát ölel fel: egy referencia ecash wallet felépítését lépésről lépésre (Section20), a verő (mint) üzemeltetésének üzemeltetési és biztonsági aspektusait (Section21), valamint a teljes kurzus tartalmának egybefoglalását a protokoll alapjaitól a haladó funkciókig (Section22). A kurzus a tananyagot kiegészíti egy „laza nap a verőnél” típusú interaktív kvízzel, ahol a felhasználó próbálja rekonstruálni, melyik felhasználó melyik tranzakciót hajtotta végre — ez a tranzakció-gráf (transaction graph) anonimizálási képességét demonstrálja a gyakorlatban.

Section20: Ecash wallet építése — a kliens oldali megvalósítás

A Cashu wallet a felhasználó oldalán futó kliens szoftver, amely az ecash tokeneket kezeli: tárolja a proofokat, kommunikál a verőkkel (mint), és a BDHKE protokollt a felhasználó nevében végrehajtja. A wallet a kurzus szerint négy fő építőelemből áll. Az első a secp256k1 kriptográfiai réteg: kulcsgenerálás, skalár szorzás, pont összeadás, hash-to-curve és a BDHKE blinding/unblinding műveletek. A második a verőkkel (mint) való HTTP kommunikáció: a /v1/keys, /v1/mint, /v1/swap, /v1/melt és /v1/info REST végpontok. A harmadik a lokális proof-adatbázis: az amount, id, secret, C mezők verőnként és keysetenként rendezett tárolása. A negyedik a token formátumok kódolása és dekódolása: a V4 (CBOR) és V3 (JSON) token formátumok, amelyeket a wallet a küldéshez és fogadáshoz használ.

A wallet működésének tipikus folyamata a „minting” (kibocsátás). A felhasználó kéri a verőt (mint), hogy generáljon egy Lightning invoice-t (/v1/mint POST kérés), a wallet visszaadja a Lightning invoice-t, a felhasználó egy Lightning tárcával kifizeti azt, a verő (mint) a beérkező fizetés után bocsátja ki az ecash proofokat, és a wallet a BDHKE protokollal „unblindi” a kapott blind signature-eket, hogy a felhasználó költhető proofokhoz jusson. A kurzus kiemeli, hogy a walletnek a BDHKE blinding során gondoskodnia kell a vak érték (blinding factor) biztonságos generálásáról — ez kriptográfiai biztonsági szempontból kritikus, és a wallet a crypto.getRandomValues() vagy hasonló, kriptográfiailag biztonságos véletlenszám-generátort kell használjon.

A wallet implementáció másik fontos aspektusa a NUT-13 (Deterministic Secrets) szerinti seed-alapú backup. A NUT-13 definiálja, hogyan lehet a tokenek secret értékeit egy BIP-39 seed phrase-ből determinisztikusan származtatni, így a felhasználó egyetlen 12 vagy 24 szavas mondattal helyreállíthatja a teljes proof-tárolóját. A kurzus hangsúlyozza, hogy a backup kritikus: ha a felhasználó elveszíti a proofjait (pl. egy nem mentett mobilalkalmazás adatvesztéssel), az ecash tokenek végérvényesen elvesznek, mert a verő (mint) nem tudja rekonstruálni a felhasználóhoz tartozó proofokat. A NUT-13 ezt a kockázatot csökkenti azzal, hogy a seed phrase-ből a wallet bármikor újraépítheti a proof-listát — feltéve, hogy a verő (mint) megbízható és a proofok még nem jártak le.

A wallet a verő (mint) szerveroldali komponenseivel a NUT-01 (Mint Info) és NUT-02 (Keysets) végpontokon keresztül tartja a kapcsolatot. A /v1/info végpontból a wallet megtudja a verő (mint) nevét, támogatott unitjait, a NUT-ok listáját és egyéb metaadatokat. A /v1/keys végpontból a wallet letölti a verő (mint) aktuális keysetjeit, és ezeket a kulcsokat cache-eli a kriptográfiai ellenőrzésekhez. A wallet minden vak aláírás kérésekor (mint, swap) a megfelelő keyset kulccsal dolgozik, és a DLEQ proofokat (NUT-12) ellenőrzi, hogy a verő (mint) valóban a bejelentett kulcsot használja-e. A kurzus kiemeli, hogy a wallet rendszeresen frissíti a keyset listát, mert a verő (mint) rendszeresen rotálja a kulcsokat (NUT-02).

A wallet UI (felhasználói felület) szintén a kurzus része: a tipikus Cashu walletben a felhasználó látja az egyenlegét, a tranzakció történetét, a verők (mint) listáját és az egyes verőknél (mint) lévő egyenleget. A walletek általában támogatják a „pay-to-Lightning” (az ecash egyenlegből Lightning kifizetés) és a „Lightning-to-ecash” (a Lightning egyenlegből ecash befizetés) flow-kat, valamint a „ecash-to-ecash” (az egyik verőtől (mint) a másikhoz swap) műveletet. A kurzus kiemeli, hogy a modern walletek a NUT-11 (P2PK) zárolást is támogatják, és a felhasználó dönthet úgy, hogy egy adott címzett számára zárolt tokent küld — ez a funkció a Bitcoin multisig címekhez hasonló biztonsági szintet hoz a Chaum-féle ecash ökoszisztémába.

Section21: Verő (mint) üzemeltetés — a szerveroldali megvalósítás

A verő (mint) a Cashu protokoll szerveroldali szereplője: ő kezeli a Lightning csomópontot, tartja a kriptográfiai kulcsokat, fogadja a depositokat, bocsátja ki az ecash proofokat, és hajtja végre a swap és melt műveleteket. A kurzus a verő (mint) üzemeltetést három szempontból vizsgálja: a kulcskezelés, a Lightning integráció és a biztonsági/hitelességi aspektusok. A kulcskezelés a NUT-02 alapján történik: a verő (mint) rendszeresen új keysetset generál, és a régi keysetset inaktiválja. A kulcsokat a verő (mint) biztonságos tárolóban (HSM, encrypted disk, vagy hasonló) tartja, és soha nem teszi közzé a privát kulcsokat.

A Lightning integráció a verő (mint) oldalán a BOLT11 invoice-ok generálását és a bejövő fizetések monitorozását jelenti. A verő (mint) a NUT-04 deposit flow-ban generál egy BOLT11 invoice-t, a felhasználó kifizeti azt, és a verő (mint) a Lightning HTLC (Hash Time-Locked Contract) véglegesítése után bocsátja ki az ecash proofokat. A NUT-05 melt flow-ban a verő (mint) a felhasználó által átadott Lightning invoice-t a saját Lightning csomópontján keresztül fizeti ki, és a beérkező ecash proofokat érvényteleníti. A kurzus kiemeli, hogy a verő (mint) Lightning csomópontjának megbízhatónak és folyamatosan online kell lennie, mert a deposit és melt flow-k valós idejű Lightning tranzakciókhoz kötődnek.

A verő (mint) üzemeltetésének legkritikusabb aspektusa a bizalom. A Cashu protokollban a verő (mint) custodial: a felhasználók rá vannak szorulva, hogy a verő (mint) tisztességesen kezeli a letétbe helyezett Bitcoinokat, és a kért összegnek megfelelő ecash proofokat bocsát ki. A kurzus rámutat, hogy a Cashu tokenek viselik a „bearer token” kockázatot: ha a felhasználó elveszíti a proofjait, vagy a verő (mint) fizetésképtelenné válik, a tokenek elvesznek. A NUT-12 (DLEQ proofs) és a NUT-13 (deterministic seed backup) részben csökkentik ezt a kockázatot, de nem szüntetik meg teljesen — a verő (mint) mindig egy bizalmi pont marad a rendszerben.

A kurzus a verő (mint) üzemeltetés „best practice”-eit is összefoglalja. Ide tartozik a rendszeres keyset rotáció, a DLEQ proofok automatikus kibocsátása minden aláíráskor, a Lightning csomópont monitorozása (channel balance, lánc-konfirmációk), a tranzakció limitek (pl. 1M sat BOLT11 deposit limit), és a Proof of Reserves publikálása (NUT-??, jövőbeni specifikáció). A kurzus hangsúlyozza, hogy a verő (mint) üzemeltetőknek átláthatónak kell lenniük a felhasználók felé: a NUT-01 (Mint Info) végponton közzé kell tenni a verő (mint) metaadatait, és a felhasználóknak joguk van megismerni a verő (mint) által támogatott NUT-ok listáját, a kulcsok nyilvános részét és a tranzakció limiteket.

Section22: Teljes kurzus-összefoglaló — a protokoll egy képen

A kurzus utolsó szakasza egybefoglalja a 23 lecke tananyagát. A Cashu protokoll alapja a Chaum-féle vak aláírás: a felhasználó a verő (mint) tudta nélkül kap egy aláírást egy message-re, és a verő (mint) később nem tudja összekötni az aláírást az eredeti üzenettel. Ez a tulajdonság biztosítja a tranzakció-szintű anonimitást: a verő (mint) nem tudja, hogy a proofokat ki költi el, és a swap műveletekkel a felhasználó a saját proofjait is „átmossa” — ezáltal a tranzakció-gráf (transaction graph) elhomályosul. A kurzus hangsúlyozza, hogy a Cashu nem blockchain-alapú protokoll: a proofok a verő (mint) saját adatbázisában tárolódnak, és a Bitcoin Lightning csak a deposit/melt végpontokon jelenik meg.

A kurzus a protokoll három fő „szereplőjét” különbözteti meg. A felhasználó (user) a proofokkal rendelkezik, és a walletjén keresztül kezeli azokat. A verő (mint) a vak aláírásokat adja, és a Lightning csomópontján keresztül kapcsolódik a Bitcoin hálózathoz. A Lightning Network a deposit és melt tranzakciók lebonyolítója, de a Cashu protokoll szempontjából „fizetési csatornaként” funkcionál. A kurzus kiemeli, hogy a Cashu tervezésénél fontos szempont volt a payment-method-agnosticitás: a jövőben más fizetési módok (on-chain Bitcoin, Liquid, fiat) is beépíthetők a mag protokoll módosítása nélkül.

A teljes kurzus-összefoglaló négy fő tanulságot emel ki. Az első, hogy a Chaum-féle vak aláírás az ecash alapja, és a BDHKE protokoll biztosítja a kriptográfiai biztonságot. A második, hogy a keyset rotáció (NUT-02) és a DLEQ proofok (NUT-12) együttesen biztosítják a verő (mint) hosszú távú integritását. A harmadik, hogy a P2PK zárolás (NUT-11) és a spending conditions (NUT-10) a programozható, kulcs-alapú tokeneket teszik lehetővé. A negyedik, hogy a Cashu protokoll payment-method-agnosticitása a jövőbeli bővíthetőség záloga. A kurzus végén a kvíz-bank magyarázatai ismétlik át a kulcsfogalmakat: a verő (mint) a NUT-00 terminológiában a rendszer központi szereplője, aki a vak aláírásokat bocsátja ki; a verő (mint) a BDHKE protokollon keresztül biztosítja, hogy a kibocsátott proofok később ne legyenek összekapcsolhatók a felhasználóval.

A kurzus záró kvíz-bankja 105 magyarázatot tartalmaz a 19 theorem/definició mellett, és a kulcsfogalmak (BDHKE, blind signature, bearer token, keyset, mint, P2PK, DLEQ, BOLT11) közötti kapcsolatokat világítja meg. A kvíz interaktív formában mutatja be a „laza nap a verőnél” (a quiet day at the mint) forgatókönyvet: 4 felhasználó, különböző összegek, swap nélkül — és a felhasználónak kell rekonstruálnia, ki mit költött. Ez a feladat érzékelteti, hogy a verő (mint) tranzakció-nézete csak az összegeket és az időpontokat mutatja, de a felhasználók kiléte rejtve marad — ez a Cashu egyik legnagyobb adatvédelmi előnye a hagyományos Bitcoin tranzakciókhoz képest.

A Cashu ökoszisztéma a protokoll specifikációból mára egy „vibráns” tájképpé nőtte ki magát: walletek (cashu-ts, cashu-py, Minibits, Nutstash), verők (mint) (Stable.com, Macadamia, Cashu.me), library-k és fejlesztői eszközök sokasága áll rendelkezésre. A kurzus hangsúlyozza, hogy a Cashu nem egyetlen termék, hanem egy protokoll — és a sikerét az ökoszisztéma növekedése, a NUT specifikációk közösségi konszenzusa, valamint a felhasználók adatvédelmi igénye határozza meg.

A sorozat lezárása

Az ötrészes sorozat végigjárta a Cashu Chaumian ecash protokoll teljes spektrumát: az 1. rész a protokoll alapjait és a BDHKE blinding mechanizmust, a 2. rész a NUT-00 terminológiát és a kulcskezelést, a 3. rész a deposit/melt/swap flow-kat és a Lightning integrációt, a 4. rész a NUT-10/11/12 haladó funkciókat és a BOLT11 integrációt, az 5. rész pedig a wallet implementációt, a verő (mint) üzemeltetést és a teljes összefoglalót tárgyalta. A Cashu protokoll 2026-ban a Bitcoin Lightning második rétegének egyik legígéretesebb adatvédelmi technológiája, és a kurzus célja, hogy a fejlesztők, a verő (mint) üzemeltetők és a haladó felhasználók számára egységes, technikai alaposságú képet adjon a protokollról.

Forrás

Vissza a tetejére