Currently all channel creation is a manual process that must be executed by users either on the command line or directly through a native program which drives the RPC interface. An alternative op-tin mode would be created wherein lnd examines the known channel graph from it's PoV, and using a set of heuristics opens up a series of channels that are deemed to be locally advantageous for the driving node and also possibly channels that tend the global channel graph to a more optimal state.
This mode should be added as new command line parameter, and governed by a set of policies set by the user. At a glance, two such possible policies come to mind:
The user states that N% of their available funds should be allocated towards channels at all times.
The users states that K channels funded with at-least P satoshis should remain funded at all times.
In order to complete this issue a new sub-system should be added to the daemon which automatically establishes channels in accordance with the policies defined above using heuristics guided by preferential attachment.
Steps To Completion
[x] Add new configuration parameters which allow users to toggle auto channel creation governed by one of the policies described above, or one that is entirely new.
The ChannelGraph will be used to traverse the known graph from the PoV of the driving lnd node to determine which channels to whom should be opened. A set of heuristics which take into account a variant of preferential attachment should be implemented.
The ChainNotififer will be used to be notified upon the attachment of a new block to the end of the main chain. Each time a new block is attached, the wallet's balance may have increased, which may trigger the necessary conditions to open another channel.
Finally, the WalletController will be used to obtain a TransactionSubcription which will allow it to receive notifications each time the wallet's balance changes.
[x] The LightningNode struct contains the information necessary to employ the proposed set of heusrtics to figure out if a channel should be opened to a particular node or not. If a node has the Addresses struct populated, then this indicates that they've signalled that they wish to accept inbound connection, and therefore channels.
The ForEachChannel iterator on the node struct can be used to traverse the outbound edges of the node to figure out things like it's degree and total channel capitalization
[x] The daemon should also dynamically maintain the set of channels according to the governing policy and set of heuristics. Meaning if a channel is closed, then it's possible that the sub-system attempts to re-open a new set of channels. The sub-system can use the TopologyClient can be used to receive such notifications.
Roasbeef
commented
7 years ago
Currently all channel creation is a manual process that must be executed by users either on the command line or directly through a native program which drives the RPC interface. An alternative op-tin mode would be created wherein
lndexamines the known channel graph from it's PoV, and using a set of heuristics opens up a series of channels that are deemed to be locally advantageous for the driving node and also possibly channels that tend the global channel graph to a more optimal state.This mode should be added as new command line parameter, and governed by a set of policies set by the user. At a glance, two such possible policies come to mind:
N%of their available funds should be allocated towards channels at all times.Kchannels funded with at-leastPsatoshis should remain funded at all times.In order to complete this issue a new sub-system should be added to the daemon which automatically establishes channels in accordance with the policies defined above using heuristics guided by preferential attachment.
Steps To Completion
ChannelGraphtheWalletController, and is able to receiveBlockEpochnotifications.ChannelGraphwill be used to traverse the known graph from the PoV of the drivinglndnode to determine which channels to whom should be opened. A set of heuristics which take into account a variant of preferential attachment should be implemented.ChainNotififerwill be used to be notified upon the attachment of a new block to the end of the main chain. Each time a new block is attached, the wallet's balance may have increased, which may trigger the necessary conditions to open another channel.WalletControllerwill be used to obtain aTransactionSubcriptionwhich will allow it to receive notifications each time the wallet's balance changes.LightningNodestruct contains the information necessary to employ the proposed set of heusrtics to figure out if a channel should be opened to a particular node or not. If a node has theAddressesstruct populated, then this indicates that they've signalled that they wish to accept inbound connection, and therefore channels.ForEachChanneliterator on the node struct can be used to traverse the outbound edges of the node to figure out things like it's degree and total channel capitalizationTopologyClientcan be used to receive such notifications.