- Cut-and-Choose
- Juggling
- Deviating from BOLT specification based on "Rusty' trick" (compatability issues?)
- Applicability of DKG + VE to revocation secret
- Storage requirements
- Consensus required for state transitions?
- 2-of-3?
rough notes from meeting:
Lightning protocol requires nonce to be committed to in advance
When you receive a MuSig partial signature, commits to a nonce, need a partial sign for the pre-agreed nonce so that the latest channel state can be broadcast even if the other channel party goes online
Security violation for the multisig for the latest state is that the partial signature should not be completed until the state is ready to be broadcast (delayed signing), in-flight HTLCs, otherwise a stale state would be ready to be broadcast
LLoyd idea: Counterparty encrypts the signature, but that's not the right adversarial model (because the counterparty can collude with a malicious signer)
Jonas idea: Online signers create an adaptor signature, which is verifiable
Cut-and-choose: simplest VE, but they are all complicated, secp256k1 with no additional dependencies, relatively simple to implement, recent implementations have batch optimizations for encryption, DLEQ, El Gamal encryption; could create a bunch up-front and verify in them in batch; 100 reasonable for a batch, on Ristretto: 10 ms/encryption (~5x faster than non-batch)
Juggling: secp256k1 with no additional dependencies, El Gamal with bulletproof rangeproof; 138 ms/encryption
Jonas: concerns about nonce reuse
Matt: nonce protocol should incorporate the Lightning counter to prevent against nonce reuse
Lloyd: maybe there is a way to pick the right nonce from the data of the transaction itself
Wilmer: the commitment number has an issue for the nonce because re-transmission, malicious could not resend or send more HTLCs on re-connect and syncing state with counterparty
Jonas: Tim's idea for sharing nonces with MuSig; in 2-of-3, malicious signer could withhold nonces
Devrandom: security model is that there is a quorum of non-malicious signers online within a period of time;
Matt: blockchain is source of truth about whether the channel has been closed; of 5 signers, 4 are honest, only 1 is malicious; we start with 3 online, with 1 malicious; then the offline signers come online and can only get latest state from the 1 malicious
Lloyd: only protects against offline signers, but not malicious
Jonas: this underscores that BFT consensus is likely needed, so would this be a problem for 3-of-4? doesn't seem like it, but then we can't do 2-of-3
Matt: if we drop Rusty's trick, we'll need to create a bolt variant, good chance any solution for nonce works for revocation secret; a simple sighash mode and do real signatures here; could be okay to have a less efficient scheme with more storage
Lloyd: it's very desirable to have constant storage by using adaptor signatures; revocation point doesn't need to be represented in the transaction; we can't do this without Rusty's trick
Arik: Eltoo has less risk of broadcasting old state, threat model changes, we might able to weaken security requirements
The Jonas gist: https://gist.github.com/jonasnick/6a56ae6bdc7c3a444d01817a897fbcf6