Nostr Silent Payments (NSP) — Kritikai Elemzés (Contra)
Miről van szó?¶
A Nostr Silent Payments (NSP) — korábban Nostr Silent Wallet (NSW) — Tim Bouma javaslata, amely minden Nostr npub-hoz determinisztikusan hozzárendel egy BIP-352 Silent Payment fogadó címet (sp1...). A 2026-05-25-i frissítésben a név NSW-ről NSP-re változott, és a szerző több korábban implicit biztonsági aggályt explicit módon dokumentált.
A core ötlet továbbra is elegáns: nostr identitás = bitcoin fizetési cím, külső infrastruktúra nélkül. De a frissítés után is maradnak problémák.
1. Privacy Paradox: A Követőid Tudják a Címedet¶
Ez a legsúlyosabb probléma. Az NSW lényege, hogy mindenki, aki ismeri az npub-odat, determinisztikusan le tudja származtatni a Silent Payment címedet. Ez azt jelenti:
- Minden Nostr követőd — köztük spam botok, chain analysis cégek, állami szereplők — pontosan tudja, melyik
sp1...cím tartozik hozzád - Ez fordítottja annak, amit a BIP-352 eredetileg el akart érni: a Silent Payments pont azért lett tervezve, hogy a cím ne legyen publikus
- Az NSW-ben a cím szükségszerűen publikus, hiszen a küldőnek ismernie kell a származtatáshoz
Következmény: Bár az on-chain tranzakciók maguk privátak maradnak (csak a scan kulcs birtokosa detektálja őket), a metaadat — hogy kihez tartozik a cím — nyilvános. Ez egy chain analysis cégnek elég ahhoz, hogy az összes NSW tranzakciót egy identitáshoz kösse, még ha a konkrét összegeket nem is látja egyből.
Összehasonlításképp: egy normál BIP-352 Silent Payment címnél a küldő egy publikusan nem ismert scan pubkey-ből származtat. Az NSW-ben a scan pubkey maga az npub tweak-elt változata — tehát a kapcsolat triviális.
2. Dust és DoS Támadási Vektor¶
Mivel bárki származtathatja a címedet és bárki küldhet rá:
- Dust támadás: Bárki eláraszthatja az NSW címedet apró, értéktelen UTXO-kkal, amelyeket neked kell sweep-elni (vagy ignorálni, de attól még ott vannak)
- Nyomkövetési szennyezés: Egy rosszhiszemű szereplő "megjelölheti" a címedet azzal, hogy küld rá egy ismert forrásból származó dust-ot, majd ezt a kapcsolatot felhasználhatja későbbi elemzéshez
- Privacy degradation: Minél több dust UTXO van a címeden, annál nehezebb normál tranzakciókat privátan sweep-elni
A klasszikus Silent Payments-nél ez kisebb probléma, mert a címet nem ismeri meg előre bárki — meg kell osztanod. Az NSW-ben a cím automatikusan nyilvános.
3. BIP-352-től Való Eltérés — Inkompatibilitás¶
Az NSP nem szabványos BIP-352 implementáció:
| BIP-352 | NSP | |
|---|---|---|
| Kulcs forrása | Wallet seed | Nostr nsec |
| Származtatás | scan_key = spend_key + H(...) |
Additív tweak npub-ból |
| Cím formátum | Standard sp1... |
Saját sp1... (más paraméterekkel) |
| Wallet támogatás | Cake, BlueWallet, Sparrow | Csak Cake/BlueWallet (küldő oldal) |
Probléma: Az NSP által generált sp1... címeket a meglévő BIP-352 wallet-ek nem feltétlenül tudják feldolgozni fogadó oldalon. A seed-alapú származtatás helyett az nsec-ből indul — ez azt jelenti, hogy a Nostr privát kulcs kompromittálódása esetén a Bitcoin kulcsok is kompromittálódnak. A frissített gist ezt most már explicit módon dokumentálja ("Important Security Caveats" szekció).
3b. Scan Key Root-Equivalens — A Szerző Által Megerősítve ✅¶
A 2026-05-25-i frissítés legfontosabb változása: a szerző explicit módon dokumentálja, hogy:
Mivel t_scan nyilvánosan számolható az npub-ból, aki ismeri scan_priv-et, az visszaszámolja az nsec-et. A szerző szavai: "NSP is not a safe untrusted remote-scanning model."
Ez validálja a korábbi kritika "single point of failure" pontját. A következmény: - NSP scanning csak lokális vagy fully trusted scanner infrastruktúrával biztonságos - Untrusted third-party remote scanner HASZNÁLHATATLAN NSP-hez - Ez jelentős gyakorlati korlátozás, különösen mobile wallet use-case-eknél
4. OpSec Bonyodalmak¶
Az NSW dokumentációja explicit módon figyelmeztet:
Soha ne költs közvetlenül az NSW walletből külső címre. Mindig sweep-elj saját kontroll alatt álló, unrelated címre.
Ez a gyakorlatban azt jelenti, hogy az NSW nem wallet — hanem egy fogadó-csatorna, amit rendszeresen üríteni kell. Ez:
- Extra tranzakciós költséget jelent (minden sweep = on-chain fee)
- UX szempontból nehézkes (nem "set and forget")
- A sweep tranzakció maga potenciálisan nyomon követhető, ha nem vagy elég óvatos
5. Korai Specifikáció, Nincs Audit¶
- A Gist egy egyéni szerző munkája (Tim Bouma), nem BIP és nem közösségi konszenzus
- Nincs formális biztonsági audit
- Nincs implementációs referencia (reference implementation)
- Csak két wallet támogatja, és csak küldő oldalon
- A
H_tag("nostr-sp/scan", P)hash konstrukció nincs független kriptográfiai elemzésnek alávetve - Pozitívum: a szerző aktívan frissíti és dokumentálja a biztonsági caveat-eket
6. Alternatívák¶
| Megoldás | Privacy | Komplexitás | Működik most? |
|---|---|---|---|
| NSW | Közepes (cím publikus, tranzakciók privátak) | Alacsony | Csak küldő oldal |
| BIP-352 normál | Magas (cím is privát) | Közepes | Igen (több wallet) |
| LNURL/Lightning Address | Alacsony (custodial) | Alacsony | Igen |
| Cashu token | Magas (chaumian e-cash) | Alacsony | Igen, de federált trust |
| NIP-57 (zap) | Alacsony (LN invoice publikus) | Alacsony | Igen, széles körben |
Összegzés¶
Az NSP egy elegáns kísérlet két protokoll (Nostr + BIP-352) összeházasítására. A 2026-05-25-i frissítés jelentős előrelépés: a szerző explicit módon dokumentálja a scan_priv root-equivalens természetét és a remote-scanning veszélyeit — ami validálja a korábbi kritikákat és növeli a specifikáció őszinteségét.
A fennmaradó problémák: - A determinisztikus npub→cím leképezés továbbra is alapvető privacy paradox - A dust/DoS vektor továbbra is fennáll - A single point of failure (nsec = bitcoin kulcsok) továbbra is strukturális probléma - A korai specifikáció státusza változatlan
Érdemes figyelemmel követni a fejlesztését — a core ötlet (Nostr identitásból származtatott fizetési cím) értékes —, de a jelenlegi privacy és biztonsági trade-off-ok miatt csak nagyon specifikus use-case-ekben ajánlható, ahol a sender-side verifikáció előnye felülmúlja a receiver-side kockázatokat.
Lásd még: Nostr Silent Wallet (Pro) | BIP-352 Silent Payments | Silent Payments