[Lightning-dev] Preventing MITM - Providing new nodes with real pubkeys

Anthony Towns aj at erisian.com.au
Fri Oct 16 23:47:47 UTC 2015


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 <SIG:AJ1 AJ2>

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



More information about the Lightning-dev mailing list