search

renepickhardt / Automatically-Generating-a-Robust-Topology-for-the-Lightning-Network-on-top-of-Bitcoin

trying to fix https://github.com/lightningnetwork/lnd/issues/677 and contribute my 2 cents to the lightning network
MIT License
6 stars 0 forks source link

Project goals and work organisation #2

Open dmytropiatkivskyi opened 6 years ago

dmytropiatkivskyi commented 6 years ago

Hi Rene,

I was thinking to discuss with you the intentions of the project. First of all, what context you're considering the autopilot in? My guess is that you're set to study what is the best for the current state of the network, a practical approach. From the research perspective I intend to consider different topologies in fictitious scenarios -- hub-and-spoke and organic to begin with. Different topologies entail different assumptions. For example, in the hub-and-spoke topology hubs are expected to provide the service of payment routing. Hence, they are to be assessed based on some service metrics. A user should not care about low level characteristics such as how much funds a hub have invested, it just expects the hub to manage the requested volume. The responsibility of the efficient management lies on the hub then. Moreover, the autopilot should differentiate channel opening requests the wallet nodes send from those sent by routing nodes. Another difference is that a wallet node by connecting to a hub does not change the network throughput and might expect the hub to invest, if incoming payments are expected.

In the organic topology there is no one to expect service from. Each node is expected to efficiently manage its own channels. Every channel in the organic topology should be considered from the perspective of the whole network throughput increase. What is more important, nodes' balances are to be closely monitored as balances eventually determine routing capacity together with the number of opened channels. If a node's balance goes to zero, it can't route and becomes a broken link in the chain. In the hub-and-spoke topology we never expect hubs to have zero balance as they generate their revenue from those investments.

Anyway, the question is how do we organise the work. I suggest we have different domains with well defined assumptions. We could leave your github project real-world applicable, while I could create another project for theoretical considerations only. What do you think?

renepickhardt commented 6 years ago

Hey Dimi,

thanks for your message and thoughts! I agree that there are two different approaches. One is more real world related with the sense of faster implementation within lightning and the other one would be more research oriented. However I think both should be going closely together. For example I can quickly implement some heuristics for an autopilot but those will probably include some poor choices which could be improved after researching.

I don't think there is a problem having two seperate projects. For me it is more important to have several people working on the autopilot because I think it will become a crucial part of the technology and yes I will always stick close to the current state of the lightning network. e.g. assume there are 10k nodes and we realize a different topology would be great but people have build up channels, then I can't force them to change or adapt to a better topology.