Rusty Russell 795601dfcf daemon: reconnect with timeout, try from both sides.
This is dumb, since one side will never succeed.  But in future when
there is a method for nodes to broadcast their public address (or send
their address inline to connected nodes), either side should try to
connect.

Importantly though, there are places which will queue packets at
various times (eg. HTLC timeout), so we need to clear the queue just
before re-transmitting, not when disconnecting.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 14:25:13 +09:30
2016-07-01 12:00:17 +09:30
2016-01-22 09:09:33 +10:30
2016-07-01 12:00:17 +09:30
2016-08-18 14:23:45 +09:30
2016-01-22 06:41:46 +10:30
2016-08-18 14:25:08 +09:30
2016-05-26 15:25:25 +09:30
2016-05-26 15:25:25 +09:30
2016-07-01 12:00:17 +09:30
2016-07-07 16:49:05 -05:00
2016-08-18 14:23:46 +09:30
2016-08-18 14:25:08 +09:30
2016-08-18 14:23:46 +09:30
2016-05-06 14:07:44 +09:30
2016-05-03 11:28:49 +09:30
2016-05-03 11:28:49 +09:30

Lightning Protocol Reference Implementation

In this repository we're developing a reference implementation of bitcoin lightning (see: http://lightning.network which proposed the original "lightning network").

This implementation is being developed in parallel with the protocol definition, which you can find on my fork of the protocol description repository.

So far, we are working on the inter-node encryption and transaction negotiation phases.

Later steps will enhance the protocol to network individual daemons, advertise their IP addresses, publish routes and fees, and use that information to pay specific nodes. These details are currently being hashed out on the mailing list and the IRC channel #lightning-dev on Freenode.

Final note: This is very much a testbed and work in progress; expect All The Things to change, all the time.

Welcome aboard!

Rusty.

Description
No description provided
Readme MIT 55 MiB
Languages
C 74.9%
Python 20.7%
Rust 1.5%
Makefile 1.1%
Assembly 0.9%
Other 0.8%