From c1.devrandom at niftybox.net Thu Jan 16 00:44:25 2020 From: c1.devrandom at niftybox.net (Devrandom) Date: Wed, 15 Jan 2020 16:44:25 -0800 Subject: [Lightning-dev] Speculations on hardware wallet support for Lightning In-Reply-To: References: Message-ID: Thank you for the detailed evaluation. Please see inline comments. To make reading easier, I've replaced some uncontroversial text with [...]. On Tue, Jan 14, 2020 at 7:15 AM ZmnSCPxj via Lightning-dev wrote: > > [...] > In any case, the goal is to have some hardware unit, using only a simple communications channel with the software, to act as signer for all Lightning-related things (channel funding, channel updates, reclaiming funds after channel close). > As is typical for such Bitcoin-related hardware units, it might possess its own user interface by which it can require confirmation of certain actions. > Also, to reduce risk of hacking, the hardware unit does not have a connection to the netwrok, only a communications channel that is restricted to a local direct connection (such as USB). > > I will now demonstrate that such a design cannot achieve what an onchain Bitcoin hardware wallet does, namely that the hardware need not tr\*st the software and need not keep any state beyond the private key (which remains constant). > For Lightning, it seems any hardware would require tr\*st in the software *and* some state. Agreed, any external signer must maintain state because it must not sign revoked transactions, etc. . > > Channel Updates > =============== > > [...] > Thus, the hardware has to remember at least what the current state is, and store this knowledge in persistent, secure, modifiable memory that the software cannot touch. Agreed. > It need not store the *whole* state: for example, it could store just a commitment to the current state (and have the software store the entire state). > In fact, it is best for the hardware to store the *signature* for the commitment transaction: I would say that's not enough, if we assume that the attacker can destroy the underlying data, and destroy all backups. If the attacker can do that, the node is at the mercy of channel partners, since they will be able to publish old state without the possibility of retaliation. Thus there needs to be a secure form of storage where at least one backup must be recoverable at all times within the penalty time window. I do agree that a low-resource hardware wallet may just store the signature, or other commitment to the state. In that case, we could store the full data using an append-only log to a hardened machine that specializes in preventing destruction of data by an attacker. > > [...] > > Tr\*sted Eventual Synchrony of Two Commitments > ============================================== > [...] > This may prevent some HTLCs from being safely forwardable, but that only means stalls in payment forwarding. This is a good point we haven't considered in our original writeup. Intuitively, you are right that this can only result in stalls. > > > > Non-publication of Revoked Transactions > ======================================= > > [...] > To prevent publication of our *own* commitment transaction at least, the hardware can simply not sign *own* commitment transactions as they are created. Agreed. > > [...] > Thus, the hardware has to have a concept of a "closed" channel, where it marks that the current txid for the *own* commitment transaction is the last one, and it Agreed. > > [...] > Thus the hardware provides three APIs: > > * Mark-as-close. > * Get-final-signature (unilateral or mutual close option). > * Delete-closed. It seems that the first API call can be folded into the second. Also, delete must be only performed once enough time has passed so that the closing tx is unlikely to be reorged out of existence. This requires the hardware wallet to have a trusted source of knowledge about the state of the blockchain or current time. We wrote about UTXO set oracle and the use of roughtime oracles in our original writeup. > > [...] > Tr\*sted Revocation of Old Remote State > ======================================= > > Unfortunately, the hardware has to tr\*st the software to check that the other node is not cheating. > As the hardware itself is not capable of accessing the blockchain or mempool, it cannot do this checking directly. > Thus, revocation of old remote state is not ensurable by the hardware. I am more optimistic about this. Publishing of penalty transactions can be delegated to a quorum of watchtowers, some possibly run by other entities. The node software can prove to the hardware that the watchtowers have been informed of new state by providing a receipt signed by the watchtowers. Thus it's possible to reduce trust in the node software. > > > As revocation can only be done by the software anyway, the revocation secrets for the *remote* commitment transactions can be stored by the software only. > The hardware need never learn the revocation secrets as it can do nothing with them anyway. I would at least back up the secrets in the secure storage attached to the hardware store, so that the node can be recreated if the node software has been catastrophically compromised. > > Opening a Channel > ================= > > [...] > If there is a difference, that implies that this node is what pays the fee, and the hardware should probably double-confirm with the user using its UI whether the paid fees are acceptab;e. If the fee is under a preset threshold, it can be auto-approved. > > > Tr\*sted Forwarding > =================== > > Forwarding should be automated and not require a confirmation from the user on the hardware unit UI. > Unfortunately, the hardware has to trust the software to actually perform forwarding correctly. Let's look at this carefully, I feel it should be possible to prove correctness of forwarding to the hardware. > > However, the hardware has to keep track that an incoming HTLC only has at most one outgoing HTLC,. > It cannot identify using the hash, incidentally: it is theoretically possible for a route to loop through a node twice, e.g. A -> B -> C -> D -> E -> C -> F, where C appears twice. I think it's enough to require that each incoming HTLC can be associated with a single outgoing HTLC. The hardware would have to maintain state about which HTLCs have been "used up" in this way. > > Further, if a payment attempt fails, then the ultimate payer might still try to route through this node, giving a different postfix past this node, so this node may forward the same hash twice on two or more different payment attempts. hmm... that doesn't sound safe, because then two different nodes would be able to claim the funds from us, and we can only propagate back to a single input, so we lose funds. If the Lightning protocol allows this, then it sounds like a design issue. Seems like the failed HTLC should be invalidated first. The invalidation can be proven to the hardware (a new commitment tx is signed, removing the HTLC, or the outgoing channel is closed). > > [...] > Regardless, even if we somehow, the *enforcement* of HTLCs is still controlled by the software: > > * The hardware has no access to the blockchain, thus it cannot know if the incoming HTLC is in fact something in the deep past already. > A corrupted software can induce the hardware to create an outgoing HTLC whose timelock is deeply in the past, then refuse to take the timelock branch of the outgoing HTLC while letting the timelock branch of the incoming HTLC be claimed by the other nodes. See above about watchtowers, and trusted sources of time/blockchain state. > > > Thus, forwarding is still trusted. > > [...] > Reducing Storage Size > ===================== > > The hardware can, instead of storing multiple channel slots and payment slots in its own persistent memory, can instead just store a single *commitment* to the current state it knows to be valid. Agreed, but see the need to have a reliable backup above. > > > > Regards, > ZmnSCPxj