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

Christian Decker decker.christian at gmail.com
Tue Aug 16 08:10:57 UTC 2016


On Tue, Aug 16, 2016 at 04:54:32AM +0000, Olaoluwa Osuntokun wrote:
> > 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

Good catch! We need to make sure that the integrity of the per-hop
payload is protected at all costs. The per-hop payloads were
introduced to provide intermediate hops with instructions on what to
do, i.e., how many coins to forward, so if we can't guarantee their
integrity it could result in exploits. An attacker could for example
instruct an intermediate hop to forward more, in the hopes of
collecting it further down the line.

A mitigating fact may be that a node will forward at most the amount
it received, minus its fee, limiting this to a fee-shaving attack. But
if we can find a way to fix it, that would be great.

So it would appear we cannot drop the payloads from the MAC after all,
which makes stitching routes difficult in the case of rendezvous. The
interactive protocol I outlined before may still works, but it is
rather ugly as it deviates from the invoice pattern, i.e., the final
recipient gives the necessary information for the transfer in a single
bundle.

Cheers,
Christian


More information about the Lightning-dev mailing list