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

[Olaoluwa Osuntokun]

Christian Decker <decker.christian at gmail.com> wrote:

> > Now, we'd hope nobody would screw this up, but I think it's worth
> > flagging since the sender really should know it's changing chains.
>
> I agree that the realm byte is a sensible addition. To trigger this we
> would need to have multiple channels, on different chains, using the
> same identifiers between two nodes. Only in this case we'd have an
> ambiguity where to transfer the funds. Assuming we have the route A ->
> B => C, where => indicates two channels, one in litecoin and one in
> bitcoin, and both channels use the same identity for C. Then the
> instruction to forward 0.01 units to C is ambiguous, as it could be
> denominated in either litecoin or bitcoin.
>
> While not dangerous it is rather unfortunate as it results in
> guesswork. It is not dangerous because if A transferred litecoin to B
> then B will (hopefully) never forward a higher value to C using
> bitcoin, and if it were bitcoin then the final recipient would not
> sign off an inferior amount than what he expected.
>
> To prevent this we could make it a policy to never re-use identities
> for multiple channels, but someone will surely get it wrong at some
> point :-)
>

Great example; I hadn't considered this particular case before. It's clear
to me now that we should eliminate this potential ambiguity by making the
chain of the target link for each hop along the route explicit.


I was thinking that it'd be stored in the per-hop payload, along with
> the instructions for the hop, which is why I did not specify it, but
> I'm happy to add it, should it make things clearer.
>
>
I think the byte specifying the target realm should be protected under a
MAC, as forwarding to the correct realm may be critical in order for the
payment to succeed. Therefore, if we retain the MAC for the per-hop payload
then it can be placed there, otherwise they header may need to extended by
a byte in order to place the realm information there.

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