Author: VLS
summary
- The current state of Lightning Network wallets and Lightning Network Service Providers (LSPs), and what exactly constitutes "non-custodial" services.
- On Bitcoin Layer 1, holding the key means self-custody. However, in Lightning Channels, even if you hold the key, your funds can be lost if your signer blindly authorizes payment requests without verification, or if your node is compromised—this is the shared custody model.
- Blind signing is neither non-custodial nor secure. It creates two points of failure (the node and the signer). If either one is compromised, the funds will be lost.
- "VLS (Lightning Channel Signer with Validation)" provides a truly non-custodial solution for separating private keys and nodes. Even if a node is compromised, funds will not be lost.
Lightning Wallet's Promises and Issues
You carefully research and select "non-custodial" Lightning wallets because you believe in "no private key, no coin." You meticulously protect your seed word.
One day, you wake up to find your channel closed, and the Bitcoin that should have been yours sent to an address you don't know. The program's logs show that your signer authorized everything. Your Bitcoin has simply vanished. Your "self-custodial" wallet has deceived you.
Lightning Wallet promised to uphold Bitcoin's autonomy in instant payments. However, problems arose in some areas.
Your wallet software may claim to be "non-custodial" because "you hold the private key yourself," but if your signer blindly grants permissions to requests without verification, then who is actually controlling your money?
This is the truth behind blind signatures, the dirty secret of Lightning Wallet.
What is "blind signature" in Lightning Wallet?
Lightning Wallet has two modules:
- The node is responsible for proposing state changes (increasing or decreasing the balance);
- The signer determines whether these updates can be securely signed (licensed).
In a proper unmanaged setup, the signer verifies each request before signing, according to the rules of the protocol and the user's terms.
In "blind signature" mode, the Lightning wallet's private key is isolated from the node; however, the signer blindly authorizes the node's requests, meaning it doesn't verify the content of the requests at all. This is because a blind signer can sign correctly formatted transactions but doesn't have enough information to distinguish between secure and insecure requests.
Labeling a blind signature generator as "uncustodial" is like a bank claiming to be uncustodial because it doesn't know your bank card password. An unverified signature generator is not a controller, but a threat.
Users have the right to know the truth: blind signature mode is shared escrow, and it is actually more dangerous than some escrow solutions . For years, Lightning Wallet Technology has been disguising its blind signature solution as "non-custodial" or "self-custodial."
Hardware wallet test
Imagine a Bitcoin hardware wallet that signs any transaction without checking the change address, fees, or payment destination. Would you call such a wallet a "non-custodial" wallet? Would you trust it?
This is the blind signature mode of Lightning Wallet.
Why is blindly signing in worse than using a hot wallet?
纯托管：1 个攻击点（托管商）盲目签名：2 个攻击点（节点+ 盲目签名器）热钱包：1 个攻击点（设备）VLS：1 个加强后的攻击点（带有验证程序的签名器）Blindly signing signatures multiplies the number of interfaces you might be vulnerable to attack (literally multiplies), and this is still done through a managed service . If either the node or the signing generator is compromised, you could lose your funds. We specifically point this out because users have the right to know the truth.
Users of hot wallets are at least aware of the risks they are taking. Users who blindly sign, however, mistakenly believe they are safe because they "control the private key."
Possible attack forms
Every breach begins at a certain point. Here's how vulnerabilities can be converted into theft:
Scenario 1: Supply Chain -> Node Compromise -> Maliciously Shutting Down Channels
An attacker modifies a node's dependencies to gain control of the node.
Node request: "Close the channel and send funds to the attacker's address" ->
Blind Signer: Unable to verify address -> License ->
Funds stolen
Scenario 2: Social Engineering Attack -> LSP Access Rights -> Stale State
The attacker posed as a user and told the support team that they needed an "urgent fix".
Gain access to the node and broadcast the old channel status ->
Blind signer: Unable to recognize this as obsolete -> License ->
Punishment transaction takes away all funds
Scenario 3: Insider Threat -> Fee Manipulation
Malicious employees or compromised infrastructure ->
The node sets an excessive fee for each transaction.
Blind Signer: Unable to verify amount -> Permission ->
The funds were slowly drained.
A signer with a verification mechanism will reject all of these requests, while a blind signer will approve all of them .
Why is the custody model of Lightning Wallet different from that of Bitcoin Wallet?
On Bitcoin Layer 1, self-custody is very straightforward. Your hardware wallet (cold wallet) checks every transaction by verifying the address, transaction fees, and change address before signing it. This verification process, combined with control over your private key, makes it self-custody. Your private key is essentially your currency.
Bitcoin's cold wallet model cannot be directly ported to Lightning wallets because:
- The channel status is constantly updated : unlike addresses in a Bitcoin wallet which remain static.
- HTLCs have a deadline : missing the deadline means losing funds.
- Penalties require a rapid response : if the opponent broadcasts outdated channel status, your side must respond immediately.
- Routed payments need to complete the signature within sub-second time : cold wallets are too slow.
These requirements meant that early implementations of Lightning wallets required you to run your own node and use hot private keys (i.e., the two were combined), which was too complicated and risky for users.
LSP: Creating solutions to new problems
Lightning Network Service Providers (LSPs) emerged to address the usability crisis of Lightning wallets. Running a Lightning node requires specialized technical knowledge, continuous monitoring, coordination with Gates, and liquidity provision. LSPs handle all these complexities for users and truly deserve credit. This represents a significant upgrade in user experience.
However, in order to use LSP while remaining "non-custodial," the entire industry adopted a blind signature model. The patch is simple: the LSP runs your node, and you keep your private key. With the private key, you have the coins, right?
Absolutely not. When your private key blindly signs LSP node requests without verification, you're essentially trusting the LSP not to steal your money. This isn't self-custody; it's shared custody at best.
The irony is this: LSP makes Lightning wallets usable, but blind signatures make them insecure, less secure than hot wallets and custodial services. What you get is complexity without a lever.
The good news is that the convenience of LSPs doesn't necessarily come at this cost. Verified signatures can solve this problem.
Translator's note: The usage of LSP described in the text is likely just one example, and may not even be the primary one.
How can VLS fix this problem?
“VLS (Lightning Wallet Signer with Verification)” does what every Lightning Wallet Signer should do: verify before signing.
Before signing anything, VLS checks:
Protocol compatibility
- Is this an outdated situation? Yes -> Reject
- Does the HTLC balance match? Yes -> By
- Is the transaction fee reasonable? -> Check restrictions
- Is the payment destination authorized? Yes -> Approved
User Terms and Conditions
- The payment amount is within the limit.
- The payment address for closing the channel is on the licensed list.
- Blocking uncommon usage patterns
- Large transactions require additional permissions
Independent verification
- Specifically for verifying blockchain status
- Independent tracking channel status
- Monitoring time lock expired
- Cross-check node declaration
VLS in Action
| Blind Signature | VLS | |
|---|---|---|
| node | "Close the channel and send funds to address X" | "Close the channel and send funds to address X" |
| Signature generator actions | "Received! Signature!" | Is address X on the whitelist? Does the transaction status show the latest activity? Does the amount match? |
| result | Funds may have been stolen | Malicious requests are blocked, funds are safe. |
Proof that this really works: Blockstream Greenlight Wallet
Greenlight has demonstrated that VLS can be deployed at scale:
- Architecture : Blocsteam runs the nodes, and users control authentication via VLS.
- Tracking records : No funds were lost due to node compromise.
- Security : Funds cannot be stolen even if the node is compromised.
- Performance : Sub-second verification, without affecting user experience.
- Users : Thousands of users have gained true self-management capabilities.
This model demonstrates that you can obtain the convenience of LSPs without sacrificing hosting. This section explains in more detail why Greenlight chose VLS and their integration experience.
Lightning Wallet's Four Custody Modes
Understanding where your Lightning wallet falls on the spectrum is extremely important:
1. Fully Managed
You possess : Air
They hold : private key + node
Storage level : 0% (They control everything)
Attack interface : 1 point (hosting provider)
Case Study : Most Exchange Wallets
Suitable for : Users who are trying to buy a cup of coffee using the Lightning Network for the first time.
2. Shared Hosting: Blindly Signing In
You possess the private key, but it's blindly signing.
They hold : the node requesting the signature.
Storage level : Approximately 50%; Shared hosting: Both parties need each other, but nodes can cheat the signer.
Attack interface : 2 points (node or signature generator compromised = fund loss)
Case Study : Many "Non-Custodial" LSP Wallets
Fact check : Worse than fully managed – More complex, more attack interfaces, and still requires trust.
3. Self-managed hot wallet
You possess : a private key and a node, both located on the same device.
They hold : None
Security level : 100% (You have complete control over everything)
Attack interface : 1 point (your device)
Case studies : Zeus (using local node mode), Phoenix (self-managed)
Suitable for : Professional users who are accustomed to the risks of hot wallets
4. Use a self-custody wallet with a Verified Signature Unit (VLS).
You possess : Private key + Verification logic
They hold : nodes (but cannot steal them).
Security level : 100% (Nodes can propose security measures, but only you can grant them)
Attack interface : 1 reinforcement point (signature generator with verification logic)
Case Study : Blockstream's Greenlight, using VLS
Suitable for : Users who invest a significant amount of money.
Current situation: Who is truly unmanaged?
Below is a table showing where Lightning Wallet and LSP fit specifically on the custodial mode spectrum. You can see how many "non-custodial" services actually use blind signature mode. Marketing slogans don't necessarily match technical facts!
(Please refer to the original text for the table; it is not attached here.)
How can I check what mode my current wallet is using?
Ask your Lightning Wallet provider the following questions:
Question 1: "If your server/node is hijacked today, can the attacker steal my money?"
"No, because the verification process protects it" -> Self-managed wallet with a verified signer
"No, because the private key is in your possession" -> Warning about blind signing wallets
"Yes, you will lose money" -> At least they are honest.
Question 2: "What specific checks does the signer perform before signing?"
Detailed verification checklist -> True self-custody
"It will sign anything you authorize" -> Blind signing
Vague safety slogans -> Blindly signing off
Question 3: "When my channel is closed, can the remaining balance be sent to any address?"
"Can only be sent to the address you specified" -> With verification
"Will be sent to any address you have signed" -> Blind Signature
Choose the right custody model for your funds
The price of a cup of coffee
- Fully managed wallets are fine too—simple, and honest in their trust model.
- Avoid blind signature patterns – this is unnecessary complexity.
" Daily Expenses "
- Hot wallets, if you're tech-savvy
- If you lack technical expertise, choose a high-quality managed LSP.
- Clearly avoid the risks of blindly signing.
" A considerable sum of money "
- Use only self-custodial wallets with a verified signature generator (such as VLS).
- Hot wallets are also acceptable, as long as you are sure you understand the associated risks.
- Never use a blind signature wallet.
Corporate users/exchange margin :
- VLS is the only responsible choice.
Unless the amount of money is so small that you don't care if you lose it, don't use blind signature mode. It multiplies the attack surface and is more dangerous than other options.
A call to action from developers: Do not release blind signers.
Which device should be used?
I'm a developer for a business or app, and I just want a secure, fast wallet device; I don't want to build heavy infrastructure.
-> Use a VLS-enabled, facility-unmanaged provider : Blockstream's Greenlight or Breez SDK .
I want to control my own Lightning node, but I don't want to develop everything from scratch.
-> Use CLN + VLS ; secure and flexible, requiring no fully customized plugins.
I desire complete control and deep integration flexibility.
-> Use LDK + VLS ; suitable for customized deployments.
- - -
Which Lightning wallet technology stack should be used?
Choose your starting point:
Use our
vls-hsmdplugin to forward signature requests from Core Lightning nodes.Integrate it into your LDK-based nodes using
vls-proxylibrary.Running CLN + VLS + Bitcoind using Docker is ideal for testing.
LND or Eclair
VLS is not yet supported. Please request VLS support from LND and Eclair.
There are no longer any technical excuses to use blind signers. VLS is open-source software under the Apache License and is ready for production.
Your actions: Demanding true self-custody
The Lightning Wallet ecosystem has confused holding private keys with controlling funds for far too long. Blind signing is shared escrow with extra steps, not self-custody.
VLS has proven that true self-custody lightning wallets are possible. Stop making excuses, stop using blind signature mode.
The Road Ahead
The future of the Lightning Network depends on our honesty with the managed model. We request:
user :
- Understand what you truly trust
- Choose a custody model that matches your risk appetite.
- Demanding transparency from wallet providers
- Vote with your intelligence: Support true self-custody.
Developer :
- Stop calling blind signatures "non-escrow".
- Implement validation logic, or be honest in a managed model.
- Compete on real security, not marketing wars.
- Distinguishing genuine unmanaged products
Lightning Network Ecosystem :
- Establishing verified signatures as the industry minimum standard.
- Pointing out the essence of blind signatures: Shared hosting
- Projects where users prioritize true self-custody.
- Completely eliminate blind signatures
Now that you know the truth, what will you do?
- Today : Use our questions to check your current wallet.
- This week : If needed, move funds to a verified, non-custodial wallet.
- The future : requires transparency and supports genuine solutions.
Without verification, your private key has no control over your funds. Please make an informed choice.
(over)
