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
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.
>
> >
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
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
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 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
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
> 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
> 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
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
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
Good morning Ariel,
I am forking this thread as my reply is not at all related to the JIT-Routing.
Sent with ProtonMail Secure Email.
> Public nodes could advertise channels which don't actually exist directly but
> are instead hidden paths that the source node doesn't need to know or care
>
12 matches
Mail list logo
