L2-multisig-meeting-03-21-23.md

L2 MultiSig Meeting Agenda - 03-21-23

Nonces

Verifiable Encryption Schemes

• Cut-and-Choose
• Juggling

Revocation Secrets

• Deviating from BOLT specification based on "Rusty' trick" (compatability issues?)
• Applicability of DKG + VE to revocation secret
• Storage requirements

BFT

• Consensus required for state transitions?
• 2-of-3?

I made this gist recently: https://gist.github.com/LLFourn/1287d6c58df8e7cfda64a409d41d17e3

It would need a lot of work including publishing a paper on it before using it but it might be an interesting research direction. Would be keen to at least make people aware of the very rough idea.

The Jonas gist: https://gist.github.com/jonasnick/6a56ae6bdc7c3a444d01817a897fbcf6

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