[Lightning-dev] Speculations on hardware wallet support for Lightning

[ZmnSCPxj]

Good morning ZmnSCPxj,

>
> > 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.

Right, that does seem correct.

>
> > [...]
> > 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.

I had not thought of having the watchtower(s) sign a receipt of the channel state being backed up there, thank you.

>
> > 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.

Well, if the hardware itself has only a tiny secure storage (e.g. the example of only being able to store a commitment to the entire state) there would be no space to put those in as well, even with shachains.
Further, all previous HTLC hashes and timelocks need to be stored as well, since old commitment transactions will only have P2WSH output to represent those HTLC hashes and timelocks, and the actual HTLC hashes and timelocks need to be shown as well in order to revoke the old HTLCs.
It seems to me that, since the amount of storage needed would be linear on the number of HTLCs that ever appeared on the channel, a hardware with storage limits would not be appropriate to store this state and your append-only log machine might do better for that purpose.

>
> > 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.

It would have to be a sophisticated threshold: a corrupted software would split up the node funds into tiny 546-satoshi channels, paying a funding tx fee each time.
I suppose when considering autopilot it would have to be auto-approved though.

>
> > 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.

I believe not.
Consider this sequence of events:

* The hardware approves an outgoing HTLC on one channel based on the existence of an incoming HTLC on another channel.
* Both channels are dropped unilaterally onchain, with their respective latest states, before the outgoing HTLC can be claimed offchain.
* The software lets the outgoing HTLC to be claimed by the other node using the hashlock branch.
* The software lets time pass and lets the incoming HTLC be claimed by the other node using the timelock branch.

As the hardware is incapable of actually pushing transactions onchain, it cannot do anything about the incoming HTLC getting lapsed (though since it has its own UI, if it had read access to the UTXO set somehow, it could give a warning to the user using its UI and maybe hope the user notices?).
Indeed it is hard to give the hardware even read access to the blockchain in order to even *know* about the outgoing HTLC getting claimed by hashlock, without serious increases in hackability, storage, and sophistication of the hardware.
Once you start having a hardware *that* sophisticated, it becomes more and more like a complete Lightning node, and if you could implement that in a *secure* unit, you would not need a separate software to drive it, the software would effectively *be* inside the trusted hardware unit (when the entire point of this exercise is to have a separate software we have reduced trust in).

>
> > 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).

Well, the incoming HTLC would have to be deleted as well before the payer re-attempts (otherwise the payer could give out multiple HTLCs that are simultaneously claimable).
The "flag" we associate with each incoming HTLC would be deleted when the incoming HTLC is deleted as well, and separate incoming HTLCs would have to be used to authorize separate outgoing HTLCs.

In any case the point of this digression above was that we cannot key on the *hash* of the HTLC, we have to have some identifier of HTLC (shared between software and hardware) that is *not* the *hash*, but some other identifier.

>
> > [...]
> > 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.

Watchtowers, at least as currently designed, treat each channel in isolation.
Forwarding is about events on two channels.
So you would need a more sophisticated watchtower design as well.

>
> > 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.


I imagine that secure of a memory would be expensive to implement and thus limited, thus if you implement it all in the hardware, you would impose limits on the number of channels and updates and so on.

The idea of having a secure append-only log could also be used for the off-hardware state storage as well anyway, if you are trusting it enough to be able to recover the node state.
The append-only log machine can even just accept new hardware states when it sees the signature from the hardware attesting the change in root as well, so that it forms a secure channel between the hardware and the append-only log machine.

Regards,
ZmnSCPxj