From rusty at rustcorp.com.au Fri Aug 5 00:52:07 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 05 Aug 2016 10:22:07 +0930 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: References: <87oa5byeyf.fsf@rustcorp.com.au> Message-ID: <87oa58ox54.fsf@rustcorp.com.au> Olaoluwa Osuntokun writes: >> Hmm, I think we should combine the "header" and "per-hop payload" into a >> single 40 byte field. They're not meaningfully distinct for lightning, >> AFAICT. > > It's not clear to me what we gain by squashing the header (hop's ephemeral > key, > MAC, next hop) and the per-hop payload (amount to forward, possibly an > allowed > CLTV range, etc) into a single blob. I think the extensibility features are > the > same regardless. Ephemeral key and mac make sense as a header, but it's fairly easy to image a different next hop address format for different networks. See also "realm byte" below. Thus I'm suggesting a format like: [ephemeral key] [mac] [realm] [per-realm-information] Per-realm-information is next-hop, amount, etc. >> And I think we should add/steal at least one byte for "realm". 0 = >> terminal. 1 = bitcoin lightning. 2 = TBA. etc. > > What does "terminal" represent in this context? You're right; "Terminus" aka "you're the final hop", rather than using magic HMAC value. > I don't think we need an equivalent of Bitcoin's "net magic" bytes within > the > onion blob itself, as I'd imagine that the onion blob would be encapsulated > within a fixed-length field within the "htlcAdd" message. The "htlcAdd" > message > would then have a header similar to Bitcoin's, in which the "net magic" > bytes > would be placed. An explicit network byte makes sense since we could eventually have multiple networks (atomic cross-chain exchange). While node keys are network globally unique (thus the exchange is *implied* by the next hop), it's nice to be explicit. We need some flag for the terminal node anyway, so it makes sense IMHO to expand it. >> We can't simply deny multiple HTLCs with the same r hash, since that > allows an >> attacker to probe the network to see where an HTLC went (note that in the >> longer run, it's in a node's short-term economic interest to allow this, > which >> is why rhash is troubling). > > We wouldn't deny multiple HTLC's with the same r hash. We'd deny a packet > with > a shared secret we've already seen, meaning one that we've processed > before. Sorry, I was unclear: We're agreeing. I was clarifying why an alternative approach to replay avoidance (using r hash uniqueness) doesn't work. > (as a side note: I think we should establish some better terminology than > r-hash, or H) Ergh, yes! Strawman proposal: 1) HTLC-hash and HTLC-preimage? (aha H-hash & H-preimage). 2) committx-hash and committx-preimage (C-hash / C-preimage) for the commitment transaction revocation? That avoids R altogether, which is overloaded... >> If we switch from hash/preimage to the privkeys with point addition scheme >> (which has other benefits) this is no longer an issue and we can simply > refuse >> to accept two HTLCs with the same pubkey. > > The point addition derivation (P2CH style) scheme only applies to > revocations. > > It's not clear to me how one can switch to priv/pub key based HTLC's without > modifying Bitcoin Script. At the moment, we're unable to guarantee/force key > disclosure with Script's current capabilities. Yeah, it was easy to miss; it's buried deep in a thread (see the "alternative approach"): https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html Basically, you force r-value reuse in signatures to reveal the private key. The script to do this would be pretty big though, involving two other keys, three signatures and three OP_CHECKMULTISIG. And AFAIK nobody has actually written such a script... Cheers, Rusty.