[Lightning-dev] [BOLT Draft] Onion Routing Spec

[Olaoluwa Osuntokun]

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

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

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.

> 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. A
node could still forward multiple HTLC's with identical r-hashes (perhaps
due
to having to fragment a payment due to insufficient link-capacity), these
HTLC's would have distinct (indistinguishable) onion packets.

(as a side note: I think we should establish some better terminology than
r-hash, or H)

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

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160804/34ecad88/attachment-0001.html>