Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-09 Thread ZmnSCPxj via Lightning-dev
Good morning m.a.holden, > > Let me clarify: When you say "node" here, do you mean Lightning Network > > node? > > Or do you mean instead an in-memory node? > > Neither. I meant a node in a tree. I tried to use the term bucket to make the > distinction between this and Lightning node. > The

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-08 Thread m.a.holden via Lightning-dev
Hi ZmnSCPxj, > Let me clarify: When you say "node" here, do you mean Lightning Network node? > Or do you mean instead an in-memory node? Neither. I meant a node in a tree. I tried to use the term bucket to make the distinction between this and Lightning node. The tree is not strictly in-memory.

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-07 Thread ZmnSCPxj via Lightning-dev
Good morning m.a.holden, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, April 6, 2019 10:39 AM, m.a.holden m.a.hol...@protonmail.com wrote: > Good morning ZmnSCPxj, > I'll try to clarify my proposal further, but also have a few questions about > yours. > > >

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-05 Thread m.a.holden via Lightning-dev
Good morning ZmnSCPxj, I'll try to clarify my proposal further, but also have some questions about yours. --- > Now, it seems to me what you propose, is to have octrees contain octrees, and > so on. There's one global tree, which is the same for all users. Every node in the tree has a

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-04 Thread ZmnSCPxj via Lightning-dev
Good morning m.a.holden, > > I think you might have misunderstood what I was proposing, but it's probably > my fault for not expressing it well. With my suggestion, all nodes continue > to be equal participants and there are no special nodes. I used the term > "endpoint" previously to mean one

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-04 Thread m.a.holden via Lightning-dev
Good morning ZmnSCPxj, thanks for the response. > I would be hesitant to divide the world in such manner. > I understand that in typical computer science, splitting your objects up into > smaller parts is a long-accepted method of doing things. > However, when it comes to finances and

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-02 Thread ZmnSCPxj via Lightning-dev
Good morning list, > 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. > >

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-01 Thread m.a.holden via Lightning-dev
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

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, > > Maybe I oversee something - in that case sorry for spamming the list - but I > don't understand how you could know the distance from yourself if you don't > know the entire topology? (unless u use it on the pruned view as you > suggested)  That is correct, and the

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread ZmnSCPxj via Lightning-dev
Good morning Ariel, > > A good pruning heuristic is "channel capacity", which can be checked > > onchain (the value of the UTXO backing the channel is the channel capacity). > > It is good to keep channels with large capacity in the routemap, because > > such large channels are more likely to

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread Ariel Luaces
> I am forking this thread as my reply is not at all related to the JIT-Routing. Sorry I think my last reply was also getting off subject as well. Thank you for forking the thread > Nonexistent channels (i.e. channels that do not have some backing UTXO in the > Bitcoin blockchain) are not safe

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread Ariel Luaces
> I am forking this thread as my reply is not at all related to the JIT-Routing. Sorry I think my last reply was also getting off subject as well. Thank you for forking the thread > Nonexistent channels (i.e. channels that do not have some backing UTXO in the > Bitcoin blockchain) are not safe

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread Ariel Lorenzo-Luaces
> I am forking this thread as my reply is not at all related to the JIT-Routing. Sorry I think my last reply was also getting off subject as well. Thank you for forking the thread > Nonexistent channels (i.e. channels that do not have some backing UTXO in the > Bitcoin blockchain) are not safe

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-29 Thread René Pickhardt via Lightning-dev
Good morning ZmnSCPxj, Maybe I oversee something - in that case sorry for spamming the list - but I don't understand how you could know the distance from yourself if you don't know the entire topology? (unless u use it on the pruned view as you suggested) On the other hand querying for a certain

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-29 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, March 29, 2019 1:54 PM, René Pickhardt wrote: > Dear ZmnSCPxj and fellow lightning developers, > > I want to point out two things and make a suggestion for a new gossip > message.  > > > A good

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-28 Thread René Pickhardt via Lightning-dev
Dear ZmnSCPxj and fellow lightning developers, I want to point out two things and make a suggestion for a new gossip message. A good pruning heuristic is "channel capacity", which can be checked > onchain (the value of the UTXO backing the channel is the channel capacity). > It is good to keep