ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-01 📝 Original message: Good morning Christian, > ...
📅 Original date posted:2019-04-01
📝 Original message:
Good morning Christian,
>
> There are two ways we can use this:
>
> - A simple variant in which we just tell a single trampoline what the
> intended recipient is (just a pubkey, and an amount) and it'll find a
> route.
>
> - A complex variant in which a trampoline is given a next hop, and a
> smaller onion to pass along to the next hop. The trampoline doesn't
> learn the intended recipient, but can still route it.
The simple variant definitely tells the trampoline who the payee is, so I would reject it.
> Multi-trampoline routing
> =========================
>
> The more complex proposal involves nesting a smaller onion into the
> outer routing onion. For this the sender generates a small onion of, for
> example, 10 hops whose length is only 650 bytes instead of the 20 hops
> for the outer routing onion. The hops in the inner/smaller onion do not
> have to be adjacent to each other, i.e., they can be picked randomly
> from the set of known nodes and there doesn't need to be a channel
> between two consecutive hops, unlike in the outer/routing onion. The
> hops in the smaller onion are called trampolines `t_1` to `t_10`.
>
> The construction of the smaller onion can be identical to the
> construction of the routing onion, just needs its size adjusted. The
> sender then picks a random trampoline node `t_0` in its known
> neighborhood and generates a routing onion containing the smaller onion
> as payload to `t_0` and signaling data (final recipient, amount, inner
> onion). Upon receiving an incoming payment with trampoline instructions
> a trampoline `t_i` unwraps the inner onion, which yields the next
> trampoline `t_{i+1}` node_id. The trampoline then finds a route to
> `t_{i+1}`, serializing the inner onion (which was unwrapped and is now
> destined for `t_{i+1}`) and creating the outer routing onion with that
> as the payload. Notice that, like in the simple variant, `t_i` generates
> a new outer onion, which means we don't have any issues with shared
> secrets and HMACs like in rendezvous routing. Resolution is also
> identical to above.
>
> This construction reuses all the onion primitives we already have, and
> it allows us to bounce a payment through multiple trampolines without
> them learning their position in this nested path. The sender does
> not have to have a total view of the network topology, just have a
> reasonable chance that two consecutive trampolines can find a route to
> each other, i.e., don't use mobile phone as trampolines :-)
Naively, would it not be possible?
Suppose a mobile phone keeps only a small subset of the routemap due to memory constraints, but has high uptime because it is the precious mobile device of somebody who uses the mobile phone at all hours.
When the mobile phone trampoline is unable to route to the next trampoline, could it not "delegate" this by looking for some node in its smaller routemap that it believes (by some other mechanism) to be more likely to route to the next trampoline?
Could this be implemented by replacing only the front of the trampoline-level onion?
(presumably with some adjustment of how the HMAC is computed for the new trampoline layer)
If we will change to use trampoline-level onions then maybe we can change things somewhat to support this usage better.
Otherwise it would seem that possible trampolines would have to advertise themselves as such.
It would be better if a trampoline could be just "taken out of a hat" and selected randomly.
And as long as the trampoline is able to *delegate* the routing to some other trampoline, and there is sufficient fee, payment can succeed.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Christian,
>
> There are two ways we can use this:
>
> - A simple variant in which we just tell a single trampoline what the
> intended recipient is (just a pubkey, and an amount) and it'll find a
> route.
>
> - A complex variant in which a trampoline is given a next hop, and a
> smaller onion to pass along to the next hop. The trampoline doesn't
> learn the intended recipient, but can still route it.
The simple variant definitely tells the trampoline who the payee is, so I would reject it.
> Multi-trampoline routing
> =========================
>
> The more complex proposal involves nesting a smaller onion into the
> outer routing onion. For this the sender generates a small onion of, for
> example, 10 hops whose length is only 650 bytes instead of the 20 hops
> for the outer routing onion. The hops in the inner/smaller onion do not
> have to be adjacent to each other, i.e., they can be picked randomly
> from the set of known nodes and there doesn't need to be a channel
> between two consecutive hops, unlike in the outer/routing onion. The
> hops in the smaller onion are called trampolines `t_1` to `t_10`.
>
> The construction of the smaller onion can be identical to the
> construction of the routing onion, just needs its size adjusted. The
> sender then picks a random trampoline node `t_0` in its known
> neighborhood and generates a routing onion containing the smaller onion
> as payload to `t_0` and signaling data (final recipient, amount, inner
> onion). Upon receiving an incoming payment with trampoline instructions
> a trampoline `t_i` unwraps the inner onion, which yields the next
> trampoline `t_{i+1}` node_id. The trampoline then finds a route to
> `t_{i+1}`, serializing the inner onion (which was unwrapped and is now
> destined for `t_{i+1}`) and creating the outer routing onion with that
> as the payload. Notice that, like in the simple variant, `t_i` generates
> a new outer onion, which means we don't have any issues with shared
> secrets and HMACs like in rendezvous routing. Resolution is also
> identical to above.
>
> This construction reuses all the onion primitives we already have, and
> it allows us to bounce a payment through multiple trampolines without
> them learning their position in this nested path. The sender does
> not have to have a total view of the network topology, just have a
> reasonable chance that two consecutive trampolines can find a route to
> each other, i.e., don't use mobile phone as trampolines :-)
Naively, would it not be possible?
Suppose a mobile phone keeps only a small subset of the routemap due to memory constraints, but has high uptime because it is the precious mobile device of somebody who uses the mobile phone at all hours.
When the mobile phone trampoline is unable to route to the next trampoline, could it not "delegate" this by looking for some node in its smaller routemap that it believes (by some other mechanism) to be more likely to route to the next trampoline?
Could this be implemented by replacing only the front of the trampoline-level onion?
(presumably with some adjustment of how the HMAC is computed for the new trampoline layer)
If we will change to use trampoline-level onions then maybe we can change things somewhat to support this usage better.
Otherwise it would seem that possible trampolines would have to advertise themselves as such.
It would be better if a trampoline could be just "taken out of a hat" and selected randomly.
And as long as the trampoline is able to *delegate* the routing to some other trampoline, and there is sufficient fee, payment can succeed.
Regards,
ZmnSCPxj