[Lightning-dev] An Alternative Onion-Routing Proposal

[Olaoluwa Osuntokun]

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

So we don't have any docs out (yet). But the general ideas arises from
considering the following scenario: an edge wallet wishes to send funds
over lightning to 49hwYWYV26Qgym2n1GnpgxBffhKf at roasbeef.computer. Assuming
we're not use HORNET for payment related messages, the wallet attempts to
connect directly to roasbeef.computer but is unable to. As a fallback, the
wallet simply decodes the ID from base58, appends the checksum, adds a
version byte, and then sends the coins to the resulting address.

Essentially, the idea is to have an easy mechanism for a graceful fallback
to regular on-chain Bitcoin transactions. But, it's really just a
half-baked idea at this point.


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

Sure. Also, I'm referring to colliding public-key hashes. So for a moment
let's view the network as essentially having two namespaces: global vs
local. It's not a requirement that the local namespace be of lower
cardinality than the global namespace. However, in the case of 16-byte
local (mix-net) ID, and 32-byte global ID (LN) it is, therefore collisions
are more frequent. In practice, I think this is safe because in the case a
global node ID conflicts with the local mix-net ID, it doesn't undermine
the propagation of an HTLC, since only one node will be able to
successfully check the MAC, and unwrap the mix-header for the next hop.

Here's an illustration:

Say Alice wishes to send funds to Dave, and her channel sub-graph looks
like this:
                 Estelle
               /
Alice -- Bob
                \
                Carol  - Dave

Alice collects the necessary public keys for the route: Bob -> Carol ->
Dave. She then generates the Sphinx mix-header for the route. As a step in
the process she generates 16-byte local node ID's for the "next-hop" part
of each node's mix-header. She then sends the mix-header to Bob, the first
hop. However, unbeknownst to Alice, the 16-byte ID of Estelle's public-key
collides with Carol's ID. Bob get's the mix-header, and processes it as
normal: checks the MAC, re-blinds group element, and finally peels off
layer from nested mix-header. Bob then realizes there's a collision in the
local namespace. So he first tries to send the mix-header to Estelle first.
Estelle rejects the mix-header because she's unable to check the MAC since
her derived shared secret isn't the one Alice computed for this hop. Bob
gets this error message, so he instead forwards it to Carol, who accepts,
resulting in everything continuing as normal.

To Estelle it just looks like Bob computed the mix-header incorrectly, or
simply forwarded to the wrong node.

I think that's okay (there may be something I'm overlooking)?


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

Sphinx requires that the mix-net node ID's be the same size as the MAC
within the mix-header. So if node ID's in the mix-net were 32-bytes, then
we couldn't use poly3015 to generate tags since its tag size is 16-bytes.

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151218/1fcd7977/attachment.html>