Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-04 📝 Original message: Olaoluwa Osuntokun ...

📅 Original date posted:2016-08-04
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> 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.