[c-lightning] Policy signer PoC

[ZmnSCPxj]

Good morning devrandom,

> Agreed on all points.  Would you agree that there is no risk that composable musig (or musig composed with threshold sig) is impossible for some reason?  i.e. we are just searching for the most convenient protocol and we have some candidates?

In http://www.erisian.com.au/taproot-bip-review/log-2019-11-22.html nickler offhandedly mentions "definitely something we want to support in libsecp-zkp" with regards to my proposed multi-`R` proposal for composable MuSig, so it seems this is likely to at least be supported in base libraries.
The multi-`R` proposal simply has the drawback that you are leaking how many signers you actually have for your node, when in principle the other side of the channel should not have to know this information.
Closing that privacy leak is theoretically possible if we have some commitment scheme on points that is homomorphic to addition of points but *not* homomorphic to negation of points.

It is not clear if the attack on ElGamal (which allows negation of points) is something that can actually be promoted into a "real" attack, but the existence of that negation does seem to complicate proving that using ElGamal commitments is secure, at least as I understand from private communications with at least one MuSig paper author.

So there is a reasonable chance that multi-`R` gets into Lightning, as it is a trivial extension of the MuSig protocol, but it is not clear if "better" commitment schemes for the first phase of MuSig is possible.

> - The backup should be per-channel, so that an update of the backup on a channel state change is O(1)

This is not quite what C-lightning supports currently; we have a single `db_write` hook that includes all database updates for all channels, with no easy way (other than writing an SQL parser yourself) to determine which channel is being updated.

> - The signer should have its own signed backup in case the node is compromised.  There will probably be a need to reconcile the state of the node and the signer - i.e. the last state change should be replayed if necessary.

It seems to me that the signer could be stateless?
Or at least persistent-stateless.

The funding transaction takes some money, which the signer could validate in order to learn the initial state of the channel.
It validates which inputs it controlled (it can see which signatures it released to authorize the funding transaction in the past; assuming that it only releases a signature for the funding transaction if it was presented proof at that time that the funding transaction spent actual transaction outputs it controls).
Then from there it can determine how much was put into the channel for its node, minus any change outputs that it still controls.
That is then the starting value it has in the channel.

Every state change of the channel is strictly ordered.
In particular, every state change of the channel involves a revocation secret being sent to the other side.
If the revocation secret is created and kept by the signer, as a hardened derivation from its secret, then presentation of the revocation secret should convince the signer that yes, it has already issued particular state changes before.

Then the node software can simply "replay" the entire history of the channel, showing the signed commitment transaction that was signed off by the signer, plus the revocation of the previous commitment transaction.
The signer can then validate that each step along the way to the latest state was valid.

That way, the signer can be amnesiac and unable to form long-term memories, while still being able to ensure some measure of safety.

It is entirely possible that I am now thinking of completely blue-sky research that is impractical, because this implies that the node software has to log every change in every channel, which is undesirable.

> - It seems that the communication channel between the node and the signer should already be encrypted and authenticated for privacy.  Therefore the only encryption needed is for the backup at rest.  In that case, I would have the hsmd process encrypt internally - the node doesn't have to worry about it.

Assuming the signing hardware is not too far from the node physically, it seems to me that it is the hardware on which the node software is running that is easiest to exploit (in which case the node software credentials may already be compromised), but in any case an additional encryption and authentication seems fine to me.

>- hsmd could use ECIES for encryption instead of rolling our own scheme, and the key can be derived from the seed as you say

Indeed.

Regards,
ZmnSCPxj