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-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-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] Decoy node_ids and short_channel_ids

2020-02-02 Thread m.a.holden via Lightning-dev
> (I'm seeking a clever way that Bob can assign them and trivially tell > which ID is assigned to which peer, but I can't figure it out, so I > guess Bob keeps a mapping and restricts each peer to 256 live scids?). Hi Rusty. Here's a potential way for Alice and Bob to agree a set of 256 scids