From rusty at rustcorp.com.au  Fri Oct 16 20:50:30 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sat, 17 Oct 2015 07:20:30 +1030
Subject: [Lightning-dev] Preventing MITM - Providing new nodes with real
	pubkeys
In-Reply-To: <CAE8CtV=uH9PG1Tb3e9Kh2CmnNXGVBBaEokocZuv0bjiD-TQm1w@mail.gmail.com>
References: <CAE8CtV=uH9PG1Tb3e9Kh2CmnNXGVBBaEokocZuv0bjiD-TQm1w@mail.gmail.com>
Message-ID: <871tcuzgfd.fsf@rustcorp.com.au>

Mats Jerratsch <matsjj at gmail.com> writes:
> So being done with encryption and authentication, the next layer for
> me now is to figure out how exactly nodes will broadcast their
> existence and open channels and everything.

Hi Mats,

        Thanks for bringing this on-list!

> (2)
> As long as the malleability issue has not been fixed, the blockchain
> can only used with additional techniques to obtain a map of the
> channels from it. As the anchor transactions are P2SH, we need to
> expose the script, such that others are able to verify we at least
> have an anchor tx on the blockchain (associated with costs after all).

This makes some sense (though the anchor transactions don't need to be
P2SH, it's nicer for bitcoin's UTXO if they are).

> 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)

To prove we control KEYA, we simply need to sign something with it (our
nodePubKey):

        KEYA NODE-PUBKEY TXID SIGNATURE

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.

Later on, we can send SPV proofs for TXID.

> This is information everyone should store in case a new node joins a
> network, similar to the blockchain. New nodes can then check against
> the blockchain, whether this data is actually present there. An
> attacker can fake a complete network together with lots of
> transactions on the blockchain, but the incentive is low (vandalism)
> and the costs are high. For 100k nodes and 10 open channels per node,
> this adds up to 220MB. Not too bad, considering full nodes are highly
> incentivised to run full bitcoin nodes as well, it is actually rather
> negligible. This information is pretty static, however we want
> everyone to have a decently consistent view of the network, so we
> would probably do some rebroadcast of that every few days, just to
> ensure everyone knows about it.

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.

Thanks!
Rusty.