Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-04 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, First: > Like mentioned above the entire job of trampolines is to provide base > routing capability, and we should not make special provisions for myopic > trampoline nodes, since routing is their entire reason for existence :-) The point of providing this special

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-04 Thread Christian Decker
Hi ZmnSCPzj, I think we should not try to recover from a node not finding the next hop in the trampoline, and rather expect trampolines to have reasonable uptime (required anyway) and have an up to date routing table (that's what we're paying them for after all). So I'd rather propose reusing

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-03 Thread Christian Decker
On Wed, 3 Apr 2019, 05:42 ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Pierre and list, > > > There is another unrelated issue: because trampoline nodes don't know > > anything about what happened before they received the onion, they may > >

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-01 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-01 Thread Christian Decker
Thanks Pierre for this awesome proposal, I think we're onto something here. I'll add a bit more color to the proposal, since I've been thinking about it all weekend :-) There are two ways we can use this: - A simple variant in which we just tell a single trampoline what the intended

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-01 Thread Pierre
Hello ZmnSCPxj, > Unless we propose to massively change the onion packet construction...? I'm afraid we would have to make some changes. I imagine we would have two onions: - one for the adjacent hops (this is the onion we are currently using) - one for the trampoline hops The 'trampoline

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-01 Thread ZmnSCPxj via Lightning-dev
Good morning Pierre, Rene, and list, I would also like to point out that even if the trampoline point does not know the next trampoline point, then it need not fail the routing. (this may occur if we start pruning the routemap as the LN size grows) As long as we can fix the issues regarding

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-03-31 Thread ZmnSCPxj via Lightning-dev
Good morning Rene and Pierre, An issue here (which I think also affects Rendezvous Routing) is with compatibility of the HMAC. HMAC covers the entire 1300-byte `hops_data` field. If, in order to reach the next trampoline, more than one intermediate node is inserted, would the packet that

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-03-28 Thread René Pickhardt via Lightning-dev
Dear Pierre-Marie and fellow lightning developers, I really like that suggestion. In the context of JIT routing I was tinkering about the same idea (is it possible for sending nodes to only know a small part of the network - for example the friend of a friend network - to save Hardware / gossip

[Lightning-dev] Outsourcing route computation with trampoline payments

2019-03-28 Thread Pierre
Hello List, I think we can use the upcoming "Multi-frame sphinx onion format" [1] to trustlessly outsource the computation of payment routes. A sends a payment to an intermediate node N, and in the onion payload, A provides the actual destination D of the payment and the amount. N then has to