From laolu32 at gmail.com  Thu Aug  4 18:47:34 2016
From: laolu32 at gmail.com (Olaoluwa Osuntokun)
Date: Thu, 04 Aug 2016 18:47:34 +0000
Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec
In-Reply-To: <87oa5byeyf.fsf@rustcorp.com.au>
References: <CALxbBHWSnf_0FAdzoFvYhHUxVqyvT+4+n1f=r=XuHktMxC9dvg@mail.gmail.com>
	<CAO3Pvs-VnEGnY9QvWywpv3_mo6LKzwE_aMWvK=xTV86Ax-Tp6Q@mail.gmail.com>
	<87oa5byeyf.fsf@rustcorp.com.au>
Message-ID: <CAO3Pvs-3AHpT6o6VoVPYUtAc52=Utvkr8_RjMqcSZT3CoZGu3w@mail.gmail.com>

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