# The Lightning Security Spectrum — Jack Ronaldi (VLS.tech)

**Típus:** Cikk / Technikai útmutató
**Szerző:** Jack Ronaldi
**Dátum:** 2026-07-08
**Forrás:** https://vls.tech/posts/lightning-security-spectrum/

---

## Alapgondolat

> *"Non-custodial" is not a security model on Lightning.*

A Bitcoin L1-en a non-custodial tiszta: a privát kulcsok cold storage-ban vannak, csak akkor írnak alá, amikor te akarod. A Lightningen ez nem működik — a HTLC-k, channel frissítések és fizetések időszenzitívek, az aláíró kulcsoknak **online** kell lenniük. A "nem a te kulcsaid, nem a te coinjaid" elv a Lightningen nem automatikusan biztonságot jelent.

A valódi kérdés: **ha a node-ot kompromittálják, mit tud tenni a támadó?**

---

## A Lightning Biztonsági Spektrum

| Szint | Név | Mit jelent | Kompromittáláskor |
|-------|-----|-----------|-------------------|
| **-1** | Blind signing | Aláíró különválik a node-tól, de validálás nélkül jóváhagy | Két támadási felület, rosszabb mint hot wallet. **NE ÉPÍTSD EZT** |
| **1** | Custodial hot wallet | Szolgáltató tartja a kulcsokat, futtatja a node-ot | Szolgáltatói adatszivárgás vagy belső támadó mozgathatja a pénzt |
| **2** | Non-custodial hot wallet | Te tartod a kulcsokat, de online a node-dal | Node kompromittálás → pénz lopható |
| **3** | Hardened node | Secure enclave, HSM, attestation | Kevesebb esély a kompromittálásra, de ha megtörténik, a node továbbra is aláírhat lopást |
| **4** | VLS (Validating Lightning Signer) | Különálló aláíró, policy-t enforceol | **Node kompromittálás túlélhető** — az aláíró blokkolja a policy-n kívüli műveleteket |
| **5** | VLS + threshold multisig (jövő) | M-of-N jóváhagyás Lightning aláíráshoz | Legmagasabb biztonság, legnagyobb komplexitás |

### Két beállító gomb

1. **Komromittálás valószínűsége** (mennyire valószínű, hogy valaki bejut)
2. **Robbanás sugara** (mennyit veszíthetsz)

> *"Keep smaller balances in simpler models. As balances become serious or business-critical, invest in designs that reduce worst-case loss, not just the chance of an incident."*

---

## Szintek részletesen

### Level -1: Blind signing (anti-pattern)
Különálló aláíró, de biztonsági ellenőrzés nélkül jóváhagy mindent. Rosszabb mint egy sima hot wallet, mert két támadási felület van (node + aláíró). **Senki se építse ezt.**

### Level 1: Custodial hot wallet
A szolgáltató kontrolálja a kulcsokat és a node-ot. Legjobb UX, legkevesebb felhasználói felelősség, legmagasabb bizalmi kockázat. Kisebb egyenlegekre és onboarding-ra.

### Level 2: Non-custodial hot wallet
Te tartod a kulcsokat, de online a node környezetében. Szuverén, de a biztonság erősen függ a node környezetétől. Költési egyenlegekre.
- **Példa:** Phoenix (ACINQ), Bitkit, Blixt Wallet
- **Lokális vs hosted:** A non-custodial hot wallet lehet a felhasználó eszközén (lokális) vagy szerveren (hosted). A hosted nem automatikusan biztonságosabb vagy kockázatosabb.

### Level 3: Hardened node (secure enclave / HSM)
A node hardened környezetben fut (SGX, Nitro Enclaves, HSM). Kevesebb esély a kulcskinyerésre, de a **blast radius nem csökken** — ha valaki rosszindulatú logikát futtat a node-on, az továbbra is lophat.

- **Példa:** ACINQ ($100M Lightning node AWS Nitro Enclaves-ben, Ledger-alapú emberi jóváhagyás szenzitív műveleteknél), LEXE (Intel SGX)
- **Költség:** drága, specializált infrastruktúra, többéves erőfeszítés

### Level 4: VLS (Validating Lightning Signer)
A kulcsok és aláírási döntések különálló aláíróban vannak. Az aláíró **policy-t enforceol** aláírás előtt. A kompromittált node nem tud lopni a policy-n kívül.

**Policy példák:**
- Close destinációk korlátozása engedélyezett címekre
- Fee határok és rate limit-ek
- Fizetési összeg limit-ek és velocity limit-ek
- "Panic button" — aláírás leállítása ha gyanús tevékenység van

**Ígéret:** *"Even if the node is compromised, the attacker cannot get signatures for actions that violate policy."*

- **Példa:** Blockstream Greenlight, Blockstream App

### Level 5: VLS + threshold multisig (jövő)
M-of-N jóváhagyás Lightning aláíráshoz (pl. 3-of-5). Még nincs standard production implementáció, de érdeklődés van (Flowrate kereste meg a VLS projektet).

---

## Valós incidensek

| Incident | Mi történt | Szint | Ok |
|----------|-----------|-------|-----|
| **LNBank** (BTCPay plugin) | Race condition: párhuzamos visszavonások ~4.07 BTC lecsapolása | Level 2 (operator) / Level 1 (users) | Stale state balance check párhuzamosság alatt |
| **LNbits** | Támadó extrém routing fee-kkel csapolta le a wallet-et (>0.1 BTC) | Level 1-2 | Hiányzó per-payment fee limit és "amount + fee" guardrail-ek |
| **LND "Replacement Stalling"** | Theft-capable vulnerability: force-close sweeping és replacement viselkedés | Level 2-3 | Implementációs hiba az on-chain sweeping edge-nél |

> *"These aren't exotic attacks. They are common software and operational failures that become drains because the compromised node is a hot wallet that has full authority to approve the theft."*

---

## VLS: Hogyan működik?

A VLS az architektúrát változtatja meg, nem csak hardened-í ugyanazt:

1. **Separation:** Kulcsok és aláírási döntések a node-on kívül, dedikált aláíróban. Az aláíró kevesebbet csinál mint a node → kevesebb dependency, kisebb támadási felület
2. **Enforcement:** Az aláíró policy ellen validálja a kéréseket aláírás előtt
3. **Containment:** Node kompromittálás nem vezet lopáshoz (a policy-n kívül)

**Greenlight mint működő példa:** Hosted node kényelem + VLS-alapú validating signer. Bizonyítja, hogy a separation nemDestroyálja a UX-t.

---

## Ellenőrző lista: Mennyire biztonságos a wallet-od?

1. **Ha a node kompromittálódik, tud-e a támadó lopni?** — Erős válasz: "Node kompromittálás túlélhető, az aláíró policy-t enforceol"
2. **Hol van az aláírási jog?** — "Az app/node processzében" = gyenge; "Külön aláíróban" = másik biztonsági határ
3. **Milyen konkrét limit-ek vannak?** — Close destináció korlátozás, payment limit, fee ceiling, panic mode
4. **Mi a worst-case loss?** — Ha nem tudják egy bekezdésben leírni, assume "total loss"
5. **Mit látnál a log-okban támadáskor?** — Clear audit trail, rejected attempts, alertek
6. **Mi véd insider risk ellen?** — Separation of duties, controlled deployments, human approvals
7. **Mi a recovery plan?** — Dokumentált incident response, lock-down lépések, key rotáció

> *Ha az egyetlen válasz "non-custodial", akkor nincs válaszod a kompromittálási kérdésre.*

---

## Wallet besorolás (2026-02-11)

| Wallet | Szint | Kulcs/Node helye |
|--------|-------|-----------------|
| Blockstream Greenlight | **4: VLS** | Kulcs: User Device (VLS), Node: Provider |
| Blockstream App | **4: VLS** | Kulcs: User Device (VLS), Node: Provider |
| Phoenix (ACINQ) | 2: Non-custodial (hot) | User Device |
| Bitkit (Synonym) | 2: Non-custodial (hot) | User Device |
| Blixt Wallet | 2: Non-custodial (hot) | User Device |
| Blocktank (Synonym) | 2: Non-custodial (hot) | User Device |
| Blink (Galoy) | 1: Custodial (hot) | — |
| Wallet of Satoshi | 1: Custodial (hot) | — |
| IBEX Mercado | 1: Custodial (hot) | — |
| Machankura (8333.mobi) | 1: Custodial (hot) | — |
| ACINQ (node infra) | 3: Hardened node | AWS Nitro Enclaves |
| LEXE | 3: Hardened node | Intel SGX |

---

## Call to Action (fejlesztőknek)

- Ne add el a "non-custodial"-t úgy, mintha megválaszolná a nehéz kérdéseket
- Definiáld a worst-case kompromittálási modelled (és írd le)
- Publikáld, milyen kontrol-ok akadályozzák meg az unauthorized close-okat és policy violation-öket
- Dokumentáld a recovery, auditability és operational safeguard-okat
- Ha hosted UX-t akarsz, céloz validating-signer modellt

> *"Security is an architecture choice, not a checkbox."*