From rusty at rustcorp.com.au Tue Oct 20 01:42:26 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 20 Oct 2015 12:12:26 +1030 Subject: [Lightning-dev] Preventing MITM - Providing new nodes with real pubkeys In-Reply-To: References: <871tcuzgfd.fsf@rustcorp.com.au> Message-ID: <87eggqgvst.fsf@rustcorp.com.au> Mats Jerratsch writes: >> This makes some sense (though the anchor transactions don't need to be >> P2SH, it's nicer for bitcoin's UTXO if they are). > > Well, currently there is no one working on a malleability fix, so we > should probably work forwards the next available goal. ;) Oh, I'm pushing BIP 62, as well, in parallel with everything else :) >>> For the current form it would be enough to have >>> SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B) >>> with KeyB being the node pubkey (lots of key reusage...) >>> or >>> SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey || >>> SignatureB (L=264B) with KeyB as a channel key that does not need to >>> be equal with the nodePubKey. >> >> Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX >> output looks like: >> >> P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG) > > Having to deal with malleability, the only viable solution for anchor > transactions are with escape and fast-escape? > >> I think we can do slightly better with Schnorr signatures (which you can >> simply do multisig by addition, if I understand correctly) where both >> parties cooperate to form: >> >> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE >> >> That's 33+33+33+33+32+64 = 228 bytes per channel. > > Interesting, I kinda feel uncomfortable with Schnorr though. It feels > like some experimental method, and at least for Java, there are very > few implementations around (and I don't feel comfortable implementing > it on my own either..) > > I like the idea of adding together one object for the channel to be > sent by both nodes. Even without Schnorr it saves some bytes and the > overhead of gossipping.. We can always switch the signature to Schnorr > too.. Yes, we've not as bound to consensus, which is nice. Schnorr is something we can decide on later, for sure. Cheers, Rusty.