Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Design to P2P #3

Open
matsjj opened this issue Sep 3, 2015 · 0 comments
Open

Change Design to P2P #3

matsjj opened this issue Sep 3, 2015 · 0 comments

Comments

@matsjj
Copy link
Owner

matsjj commented Sep 3, 2015

With the release of 0.0.2 I will move away from my initial ThunderLightning design. I will implement a channel design similar to the proposal from Rusty. That is, changing revocation method to hashes/preimages instead of pub/priv key and also use of OP_CLTV+OP_CSV.

This will mean we will move away from a solution available today in favor of a full lightning solution. Furthermore, thunder was not able to support P2P, due to the trust-dependency between the parties. If we can help it somehow, we really don't want to end up with central servers, as this will only lead to regulation hell...

Having said that, it will lead to some further changes:

  • Move away from Jetty as the service handler. Currently, making use of NIO for peer-to-peer communication sounds reasonable to me.
  • There will still be some Client/Server-alike behavior. I am thinking about a P2P mesh of lightning nodes (high-uptime and open for incoming connections), free for anyone to run, e.g. on a rPi, and clients connecting to (chosen/random/...) nodes.
  • Some long-needed refactoring. As nodes and clients share pretty much the same functionality, and as the channel design is symmetrical now too, we can put all of the code into a common library.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant