From zooko at leastauthority.com Thu Dec 17 19:33:45 2015 From: zooko at leastauthority.com (Zooko Wilcox-OHearn) Date: Thu, 17 Dec 2015 19:33:45 +0000 Subject: [Lightning-dev] An Alternative Onion-Routing Proposal In-Reply-To: References: <87wpsgh28z.fsf@rustcorp.com.au> <87d1u7xoxl.fsf@rustcorp.com.au> Message-ID: On Thu, Dec 17, 2015 at 6:08 PM, Olaoluwa Osuntokun 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