caf50c9ae4
We now need to use bitcoin_witness_htlc with the r value, so that API is updated to take 'struct rval' or 'struct sha256'. We use the nc->delay amount (ie. dstate->config.min_htlc_expiry) to wait for a timeout refund to be buried before "failing" upstream. This should probably be made into a clearer parameter rather than overloading this one. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Header from folded patch 'dont-use-peer-nc-in-onchain-code.patch': peer: Don't use peer->nc->delay for onchain case. Use the config var directly. We should be freeing peer->nc when the connection dies anyway. 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.
Final note: This is very much a testbed and work in progress; expect All The Things to change, all the time.
Welcome aboard!
Rusty.