<div dir="ltr"><div>Thank you for the responses!  See inline:</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 15, 2019 at 11:14 PM ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com" target="_blank">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning devrandom,<br>
<br>
> 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?<br>
<br>
In <a href="http://www.erisian.com.au/taproot-bip-review/log-2019-11-22.html" rel="noreferrer" target="_blank">http://www.erisian.com.au/taproot-bip-review/log-2019-11-22.html</a> 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.<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>Got it, thank you.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> - The backup should be per-channel, so that an update of the backup on a channel state change is O(1)<br>
<br>
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.<br></blockquote><div><br></div><div>Got it, perhaps it can be modified later on.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> - 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.<br>
<br>
It seems to me that the signer could be stateless?<br></blockquote><div><br></div><div>Unfortunately, not having a tamper proof persistent store for the signer opens up some attacks.  For example, if you can make the signer believe that the last transaction didn't happen, you can have it counter-sign a revoked transaction, losing all funds in the channel.  So the signer's store must be persistent and resistant to rollback.</div><div> </div><div>[trimmed...]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> - 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.<br>
<br>
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.<br></blockquote><div><br></div><div>Let's consider the node backup and the signer backup separately.</div><div><br></div><div>Node backup:</div><div><br></div><div>Once the secrets are externalized to a separate signer, the node backup needs encryption only for privacy.  An attacker can't steal funds just by accessing that backup.</div><div><br></div><div>In any case, the integrity of the backup should also be ensured, otherwise the node may not function correctly (a DoS vector).  That can be done via a separate mechanism, e.g. a signature or a MAC.</div><div><br></div><div>Signer backup:</div><div><br></div><div>Separately, there will be a backup of the signer, which needs both confidentiality *and* a high level of integrity (no rollback).</div><div><br></div><div>Once we have Eltoo, broadcasting an old state is not catastrophic anymore, since we can further spend that with a later state stored elsewhere.  So the integrity requirements will be somewhat reduced.  For example, if you have multiple backups, only one of them needs to be current and it's safe for all of them to try to broadcast.<br></div><div><br></div><div>[trimmed...]</div><div><br></div></div></div>