From matsjj at gmail.com Sun Oct 18 11:21:13 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Sun, 18 Oct 2015 13:21:13 +0200 Subject: [Lightning-dev] Preventing MITM - Providing new nodes with real pubkeys In-Reply-To: <871tcuzgfd.fsf@rustcorp.com.au> References: <871tcuzgfd.fsf@rustcorp.com.au> Message-ID: > 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. ;) >> 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.. > Also, once a node is live, I'm not sure how much of the map it will need > to keep. It might be able to prune distant parts of the map randomly, > and get it back from the rest of the network if needed? Requires more > thought, though. > >> As I'm implementing broadcast messages anyways for other purposes (see >> other ML post), I tent to like (2) the most, it is the most expensive >> to attack as well I think. > > I agree. Least on-chain spam. Well, all nodes can always refuse to participate in the gossip network anyway by just never requesting data and never relaying anything either. For a lot of things, it is very similar to the whole blockchain. Important to keep at some points, most of it is throw-away for individual nodes already participating in the network though.. But I don't see this a problem anywhere soon.. Cheers, Mats