[Lightning-dev] An Alternative Onion-Routing Proposal

[Zooko Wilcox-OHearn]

On Thu, Dec 17, 2015 at 6:08 PM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Currently, in our code, node ID's take two forms: either the hash160
> (Bitcoin style) of a node's current pub-key or the raw serialized pub-key
> itself. This is done such that "nodeID at host" locators explicitly provide a
> level of backwards (p2pkh) compatibility for end wallets that are unable to
> establish a connection in a timely manner.

I'm afraid I don't understand how this backwards-compatibility works,
so if it is important that I understand it please point me to docs or
explain it more.

> Within the Sphinx mix-header, I think we should be safely able to truncate
> this (the hash160) to 16-bytes. In the case of a collision, the onion-route
> propagation across the incorrect node will simply fail, as it won't be able
> to properly derive the shared secret.

Do you mind explaining why you think this is safe? I don't understand
how it could be safe, in the case that the attacker knows a private
key that maps to the same 128-bit nodeid as a user's private key does.

> Otherwise, we'd be forced to ditch chacha20+poly3015 for
> AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node
> ID's in the routing info.

I don't understand why the use of entire public keys instead of
possibly-truncated hashes of public keys would force a decision about
which cipher and MAC to use.

Sincerely,

Zooko