1245ffaae3
We need to enforce this onchain as we do in the protocol off-chain, otherwise we can have an onchain redemption we can't redeem upstream via the protocol. While Laolu points out there's a 520 byte limit on witness stack element, that can still make for a larger tx and make problems for the steal tx case. The downside is that even the timeout transaction, which used to spend the HTLC with an empty 'secret', now needs a 32-byte secret, making it a little larger. We create a 'bitcoin_witness_htlc' helper for this case. See: http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-May/000529.html 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.