Validating Lightning Signer

@VLSProject

Non-custodial Lightning security for serious balances. Off-node keys + full validation = a compromised node can’t steal funds Open source Rust SDK. http://vls.tech

gitlab.com/lightning-sign…

Joined September 2020

480Posts 1KFollowers 51Following

You might like

@Core_LN

@ElleMouton

@bitcoindevkit

@bitcoin_design

@roy_breez

@realtbast

@voltage_cloud

@ambosstech

@mycitadel_io

@boltfun_btc

@EricSirion

@gkrizek

@OpenSecretCloud

@darosior

@danielabrozzoni

Validating Lightning Signer

@VLSProject

7 h

When something goes wrong, you want logs that tell a clear story. VLS gives you a trail of what was asked, what was checked, and why a signature was allowed or refused.

Inside VLS, every request gets interrogated: Are we signing a revoked commitment? A re the outputs and amounts what we expect? Are HTLCs being added or settled in a way that can leak value? If the answers are not right, no signature. Not in our house.

Validating Lightning Signer

@VLSProject

Nov 28

Think about attack surface. Monolithic node: everything that runs on that box is in scope for “all funds lost." VLS: the signer is a small Rust codebase, narrow API, no gossip, no plugins, no user traffic. You harden a tiny component, and treat the node as untrusted.

Validating Lightning Signer

@VLSProject

Nov 28

VLS in practice: • Keeps keys on a dedicated signer, not on the Lightning node • Replays the relevant Lightning state for each request • Refuses to sign revoked states, bad closes, or sketchy HTLC flows So compromising the node alone is not sufficient to move funds.

Validating Lightning Signer

@VLSProject

Nov 27

A Lightning node is basically a hot wallet with a lot of network surface area. Keys, channel state, plugins, RPC, OS, all on one box. If that box is owned, so are your channels. VLS moves keys and Lightning validation to a separate signer so a hacked node is not the end of…

Validating Lightning Signer

@VLSProject

Nov 27

Lightning setups: one node that routes, talks to Bitcoin, and holds all the keys. Fine for small balances. Once the amounts are real, the only question that matters is: “What happens if this node is compromised?” VLS exists so the answer is not “we lose everything.”

Validating Lightning Signer

@VLSProject

Nov 26

“Only the user can spend” is a benefit customers understand in one read. You do not need to explain the entire protocol to make the value land.

Validating Lightning Signer

@VLSProject

Nov 26

Blind signing trusts the node. Validating signing checks the request. Same UX, very different outcomes.

Validating Lightning Signer

@VLSProject

Nov 25

If your answer to “Could your servers drain me” is anything but “No,” you do not have self-custody.

Validating Lightning Signer

@VLSProject

Nov 25

Hosted node without custody risk is not a dream. It is a pattern that exists today.

Validating Lightning Signer

@VLSProject

Nov 24

Users expect Bitcoin-level control on Lightning. Keep keys off the node and verify every request.

Validating Lightning Signer

@VLSProject

Nov 24

LSPs grow balances when users believe they alone control spending. A validating signer makes that belief true.

Validating Lightning Signer

@VLSProject

Nov 23

Two simple questions for any wallet or LSP: 1. If your node is compromised, can funds move? 2. What exactly does the signer check?

Validating Lightning Signer

@VLSProject

Nov 23

Keys without validation are not control. They are permission slips.

Validating Lightning Signer

@VLSProject

Nov 22

Bottom line: Lightning does not require choosing between usability and control. Keep the fast UX. Add validation. Make “only the user can spend” true in the real world, not just in a tagline.