Published on: 2020-01-16T22:30:01+00:00
The Lightning Network (LN) presents unique challenges for hardware wallets due to its different security model. LN requires on-chain monitoring and reaction to ensure the safety of funds. To address this, a master-slave scheme could be implemented, where an external signer coupled with watchtowers serves as UTXO oracles, mitigating node compromise.In this scheme, the external signer would store commitment numbers and balances for each channel and perform key derivation locally. The watchtower would handle justice delegation, timeout HTLCs, and outgoing-to-incoming preimage passing in case of regular node failure. By running their own full-nodes, watchtowers provide security against p2p sybil attacks, but issues like spurious broadcast of revoked commitments and trusted external signers need to be resolved.Implementing this kind of deployment initially benefits important processing LN nodes, but it also has long-term advantages for more thrifty node operators through commoditization. The Lightning-dev mailing list discusses ways to reduce trust in node software and the required hardware. One suggestion is delegating publishing penalty transactions to a quorum of watchtowers, with the software providing receipts signed by the watchtowers to prove that they have been informed of new state. However, revocation secrets for remote commitment transactions should be stored by the software, while secure storage attached to the hardware store is recommended for the hardware to store these secrets.When opening a channel, the hardware should confirm with the user using its UI if there is a difference in fees paid. For trusted forwarding, the hardware has to trust the software to perform it correctly, although there may be methods to prove correctness to the hardware. Storage size can be reduced by storing a single commitment to the current valid state, but reliable backup options are necessary in case of catastrophic failure. A secure append-only log could be used for off-hardware state storage, creating a secure channel between the hardware and the append-only log machine.The email exchange discusses the limitations of external hardware wallets in terms of Lightning Network. The goal is to have a hardware unit act as a signer for Lightning-related transactions, but it cannot fully replicate the capabilities of an on-chain Bitcoin hardware wallet. While some features can be stored on the hardware, others require software storage. Delegating publishing of penalty transactions to watchtowers reduces trust in node software. However, certain aspects like revocation of old remote state and forwarding still require trust. The hardware provides APIs for channel close operations. Trust in the software can be reduced by requiring confirmation from the user for fee differences during channel opening. Storage size can be reduced by storing only essential data and utilizing secure off-hardware storage options.The author explores the creation of a hardware unit that can act as a signer for Lightning-related transactions. The design aims to minimize trust in software and reduce storage requirements for the hardware signer. However, it acknowledges that complete trustlessness like an on-chain Bitcoin hardware wallet cannot be achieved. The hardware needs to store current states securely and verify the integrity of funds owned by this node on the channel. Commitment transactions and closing channels are also discussed, with the hardware providing various APIs for these operations. Revocation of old remote state requires trust in the software. The author proposes methods for reducing storage size, ensuring consistency between hardware and software states, and recovering the system after power loss.
Updated on: 2023-07-31T22:31:13.849863+00:00