From aj at erisian.com.au Fri Oct 16 23:47:47 2015 From: aj at erisian.com.au (Anthony Towns) Date: Sat, 17 Oct 2015 09:47:47 +1000 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: <20151016234747.GB22262@navy> On Sat, Oct 17, 2015 at 07:20:30AM +1030, Rusty Russell wrote: > KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE AFAICS, to have a lightning channel between NODE-A and NODE-B, you just have to have a way for those two people to be comfortable writing IOUs to each other. HTLCs and commitments spending anchor transactions on the blockchain is one way to do this, but you could also do it on a pegged sidechain, or, if the two parties trusted each other, you could do it with literal IOUs written on bits of paper. I'm not sure we want to block people from doing those things? Also, if you're only doing dual-signature, not quad-signature, I think it's open to creating fake edges in the routing graph: ie, I make up to keys AJ1 and AJ2, and publish a multisig transaction in the blockchain, then claim there's a route between RUSTY and MATS by publishing AJ1 AJ2 RUSTY MATS TX Then when Alice wants to route to Bob, she decides to use that edge, and her transaction fails because it doesn't exist. (If you just sign with RUSTY and MATS, obviously you can claim to have a route just by referencing any multisig transaction that you know the pubkeys of) > > For 100k nodes and 10 open channels per node, > > this adds up to 220MB. [...] > 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. Well, we could not worry about it until there are >10k nodes; and then we'd have actual data as well? Cheers, aj