Hi ZmnSCPxj & René.
One way you could have both determinism and encourage a diverse distribution of
network maps is to treat it as a spatial indexing problem, where the space we
use is the lexicographical space of the node ids (or hashes of), borrowing some
similarities from DHTs.
If for
Good morning Hossein,
This is already known.
Indeed, this is the basis of Burchert-Decker-Wattenhofer "Channel Factories".
https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
See also discussion regarding Fulgurite.
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
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
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
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
