Author: Rusty Russell 2017-04-12 20:03:14
Published on: 2017-04-12T20:03:14+00:00
The issue of hotwallet security is a real one. The ideal case is that all keys are offline, but funding secret key and payment basepoint secret for channel updates are required. Security is fairly easy before and after the channel. Mutual close can pay straight to a cold wallet address and open waits for several blocks anyway. Once open, two avenues are open to a malicious party who has key access. With cooperation of the peer, simply create a transaction which spends the funding tx. If anyone can control the compromised node, they do not need the cooperation of the peer: create an HTLC sending maximum amount out to some other place. We can mildly increase security with additional requirements where we tell the other node "don't allow me to spend more than X without a signed message from this other key”. In addition, a future Trezor firmware could also hold the channel secrets and various enforce rules too. They nominally got an HSM daemon for this in their new implementation, but they don't use it for this so far. More research needed! Jonathan Underwood wrote a very primitive BOLT for consideration. In his mail, he asked for feedback and ways to possibly mitigate, or at least give the channel owners a fighting chance, the scenario where a single attacker compromises both sides of the channel.
Updated on: 2023-05-24T01:03:22.688814+00:00