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
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
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
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
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 .
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
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