017d199305
BOLT#2 says we MUST NOT send out commit messages with no changes (and we drop the connection if the peer does). But that's harder than it sounds: we can have changes in theory which cancel out (eg. fee adjustments, not yet implemented) or others which don't change the commit tx (eg. dust outputs). Simplest is to have a generation count, which also allows us to simply show number of pending changes in RPC. It's 32 bit, but you can only use it to screw yourself really (each side can only add 1500 htlcs, so the rest would have to be fee changes; wrapping will only make us hang up on you). 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 [https://github.com/rustyrussell/lightning](on my fork of the protocol description repository).
So far, we are working on the [https://github.com/rustyrussell/lightning/blob/master/communications/low/01-encryption.md](inter-node encryption) and [https://github.com/rustyrussell/lightning/blob/master/communications/low/02-wire-protocol.md](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, but can be tested with bitcoin (on testnet) with OP_NOP substitution.
Final note: This is very much a testbed and work in progress; expect All The Things to change, all the time.
Welcome aboard!
Rusty.