2bf43f1ebd
From BOLT#2 (rev 8ee09e749990a11fa53bea03d5961cfde4be4616): Thus each node (conceptually) tracks: ... 3. Two *unacked changesets*: one for the local commitment (their proposals) and one for the remote (our proposals) 4. Two *acked changesets*: one for the local commitment (our proposals, acknowledged) and one for the remote (their proposals, acknowledged). (Note that an implementation MAY optimize this internally, for example, pre-applying the changesets in some cases). In our case, we apply the unacked changes immediately into staging_cstate, and save them in an unacked_changes array. That array gets applied to staging_cstate as soon as it's acked (we only allow one outstanding update_commit, so we only need one array). 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.