4110376e87
There's no real reason to avoid commands for the next commit; this has the benefit that we can remove the infrastructure to queue commands. The only exceptions are the commit command and the opening phase. We still only allow one commit at a time, but that's mainly run off a timer which can try again later. For the JSONRPC API used for testing, we can simply fail the commit if one is in progress. For opening we add an explicit peer_open_complete() call in place of using the command infrastructure. Commands are now outside the state machine altogether: we simply have it return the new state instead of the command status. The JSONRPC functions can also now run commands directly. This removes the idea of "peercond" as well: you can simply examine the states to determine whether an input is valid. There are fine-grained helpers for this now, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
The protocol requires features not currently in bitcoin, so you will need Pieter Wuille's Segregated Witness bitcoind: https://github.com/sipa/bitcoin/tree/segwit4
Final note: This is very much a testbed and work in progress; expect All The Things to change, all the time.
Welcome aboard!
Rusty.