Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-04-20 Thread Benjamin Mord
Good afternoon ZmnSCPxj, "I do not see a bloom filter?" Well, if you look at it kinda sideways, you are using a bloom filter in your March 23rd proposal. As originally defined, I think the "false positives" in bloom filtering were the unfortunate cost of performance. In BIP 37, the false positive

Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-04-19 Thread ZmnSCPxj via Lightning-dev
Good morning Benjamin, > I think there are two distinct concepts here. The first is the identification > of a 'neighborhood', and the second is the establishment of an order within > that neighborhood for purpose of cycle formation. > > Your use of bloom filters to define a neighborhood, is I th

Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-04-19 Thread Benjamin Mord
Hello ZmnSCPxj, I think there are two distinct concepts here. The first is the identification of a 'neighborhood', and the second is the establishment of an order within that neighborhood for purpose of cycle formation. Your use of bloom filters to define a neighborhood, is I think the most valua

Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-04-18 Thread ZmnSCPxj via Lightning-dev
Good morning Benjamin, Rusty simulated an older version of my idea here; C code near the end of the message: https://lists.ozlabs.org/pipermail/c-lightning/2018-April/29.html However this has a bug: I specify that: >If the candidate already has a channel with us, or has no address info and

Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-04-18 Thread Benjamin Mord
Elegant idea. Is there a simulation platform yet for experimenting with ideas such as this? I imagine it may sometimes be useful to empirically test aggregate effects of different routing heuristics, however naive or artificial the underlying assumptions may need to be. Is there an API, perhaps i

Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-03-24 Thread ZmnSCPxj via Lightning-dev
Good morning list, I have decided on a better termination condition for searching for a cyclic superhub. I re-describe below the algorithm: Start with `i` = 0 and a set of known nodes, including our own node. Iterate over `i`: - Compute hash = H(i || pubkey) for each node. H = RIPEMD160 . SHA

Re: [Lightning-dev] Towards a gridlike Lightning Network

2018-03-23 Thread ZmnSCPxj via Lightning-dev
Good morning list, Igor Cota has started implementing my idea: https://github.com/icota/presto/commit/3311785e660d840f0ac8f2e333d0f0097aec980e This forced me to actually start thinking more deeply about the algorithm I gave. 1. We should use a well-used hash algorithm, such as RIPEMD160(SHA25

[Lightning-dev] Towards a gridlike Lightning Network

2018-03-19 Thread ZmnSCPxj via Lightning-dev
Good morning list, As my award-winning and supremely notable and talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution Towards Reasonable Lightning Network Topography" points out, cycles are a good way to organize the LN in order to allow easier accessibility to the networ