René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-28 📝 Original message: Sorry I sent this mail by ...
đź“… Original date posted:2018-03-28
đź“ť Original message:
Sorry I sent this mail by accident only to Karan.
---------- Forwarded message ---------
From: René Pickhardt <r.pickhardt at googlemail.com>
Date: Di., 27. März 2018 11:10
Subject: Re: [Lightning-dev] Opening channels with neighbors for
cost/connectivity benefit
To: Karan Verma <karanverma at alumni.stanford.edu>
Dear karan,
There is a feature called autopilot in the lnd implementation that tries to
achieve something similar to what you describe.
However the problem is much harder than just using some plausible
heuristic. I have an open issue on github discussing these problems:
https://github.com/lightningnetwork/lnd/issues/677
>From there I also linked a draft of a whitepaper that I am working on in
which I plan to discuss ways of automatically create a well connected
network topology fitting the specific needs of the peers in the lightning
network.
Your help and ideas would be appreciated. Also you could just implement
your idea in the lnd autopilot interface
Best regards Rene Pickhardt
Karan Verma <karanverma at alumni.stanford.edu> schrieb am Di., 27. März 2018
05:58:
> Hello,
>
> The sender node doesn’t always have a route to the receiving node
> accepting lightning payments and since opening new channels is costly - I
> was wondering if there was a smarter way to open channels such that it
> increases the connectedness of the sender node with other nodes in the
> network and also possibly save money in the intended transaction.
>
> To clarify, if Bob wants to send money to Alice but doesn’t have a route
> to her. He would need to open a new channel with Alice and send the money.
> This is costly for Bob if that was the only transaction he ever wanted to
> do with Alice. However, if Alice was connected to Charlie and Dave
> (Unidirectional: Charlie -> Alice & Dave -> Alice due to the amount being
> sent). He could instead connect with Charlie/Dave or nodes connected with
> them which have a route to Alice through Charlie/Dave such that it
> minimizes the transaction cost to reaching Alice (some routes might have
> negative fee) and maximizes the number of nodes Bob can now reach through
> this channel. Lets say if Bob chose Charlie's neighbor, then he can now
> reach at-least three nodes - Charlie's neighbor, Charlie and Alice and end
> up paying less.
>
> Essentially we're sorting choice of the nodes to open a channel with by
> transaction fee and connectedness it brings to the origin node. This would
> benefit Bob in the long term and also maybe lightning network as a whole.
> I'm new to lightning and would appreciate feedback on this idea. Thanks.
>
> -Karan
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180328/9e7ab97e/attachment-0001.html>;
đź“ť Original message:
Sorry I sent this mail by accident only to Karan.
---------- Forwarded message ---------
From: René Pickhardt <r.pickhardt at googlemail.com>
Date: Di., 27. März 2018 11:10
Subject: Re: [Lightning-dev] Opening channels with neighbors for
cost/connectivity benefit
To: Karan Verma <karanverma at alumni.stanford.edu>
Dear karan,
There is a feature called autopilot in the lnd implementation that tries to
achieve something similar to what you describe.
However the problem is much harder than just using some plausible
heuristic. I have an open issue on github discussing these problems:
https://github.com/lightningnetwork/lnd/issues/677
>From there I also linked a draft of a whitepaper that I am working on in
which I plan to discuss ways of automatically create a well connected
network topology fitting the specific needs of the peers in the lightning
network.
Your help and ideas would be appreciated. Also you could just implement
your idea in the lnd autopilot interface
Best regards Rene Pickhardt
Karan Verma <karanverma at alumni.stanford.edu> schrieb am Di., 27. März 2018
05:58:
> Hello,
>
> The sender node doesn’t always have a route to the receiving node
> accepting lightning payments and since opening new channels is costly - I
> was wondering if there was a smarter way to open channels such that it
> increases the connectedness of the sender node with other nodes in the
> network and also possibly save money in the intended transaction.
>
> To clarify, if Bob wants to send money to Alice but doesn’t have a route
> to her. He would need to open a new channel with Alice and send the money.
> This is costly for Bob if that was the only transaction he ever wanted to
> do with Alice. However, if Alice was connected to Charlie and Dave
> (Unidirectional: Charlie -> Alice & Dave -> Alice due to the amount being
> sent). He could instead connect with Charlie/Dave or nodes connected with
> them which have a route to Alice through Charlie/Dave such that it
> minimizes the transaction cost to reaching Alice (some routes might have
> negative fee) and maximizes the number of nodes Bob can now reach through
> this channel. Lets say if Bob chose Charlie's neighbor, then he can now
> reach at-least three nodes - Charlie's neighbor, Charlie and Alice and end
> up paying less.
>
> Essentially we're sorting choice of the nodes to open a channel with by
> transaction fee and connectedness it brings to the origin node. This would
> benefit Bob in the long term and also maybe lightning network as a whole.
> I'm new to lightning and would appreciate feedback on this idea. Thanks.
>
> -Karan
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180328/9e7ab97e/attachment-0001.html>;