C-Lightning Prototype With Segregated Witness Anchor

That took longer than I’d hoped, but it was only about 4 days (the rest was random cleanups that inevitably occur along the way).

The downside of having one’s own code to do all the bitcoin stuff is that changes are painful. In this case, it means reimplementing most of BIP144 and BIP141. The upside is that it requires a significant level of understanding.

The two main roadblocks to getting it to work: I had to ask on #segwit-dev to discover that even with Pieter’s branch it takes 432 blocks to activate segregated witness. Then bitcoind still failed to accept my transaction and I debugged it down to OP_CHECKSIG failing, I discovered BIP143 which redefines how signatures sign transactions!

There’s nothing worse than thinking you’re finished and realizing you’re very, very not! But I’m recovered now, and the improved signature scheme adds another incremental reason why all Bitcoin transactions in the (distant) future will be witness transactions.

Segregated witness’s elimination of malleability (unless all parties agree, of course) is the key to making channel establishment secure without hacks: I co-sign a transaction which gives the funds back to me, then you release the anchor transaction to open the channel. If someone malleates your anchor, that return transaction is now useless.

The current code I just pushed to github insists that the anchor transaction (if we create it!) uses segregated witness on all its inputs, preventing this problem. (Next will be to use it for the commitment and close transactions, as well, but that’s more about efficiency than necessity).

Unfortunately, even Pieter’s bitcoind doesn’t create witness transactions by default, and we need the inputs to the anchor to be witness transactions. To work around this, the daemon hands out funding P2SH addresses (which wrap P2WPKH) you send funds to, and it uses those to create the anchor transaction. It’s a little awkward, but it works for the prototype.

Using P2SH is backwards compatible, but it wastes space: using witness directly (P2WPKH and P2WSH) is preferable. Unfortunately, there’s no address format specified for these (BIP142 is deferred), which lead me to take an aside into what I’d like it to look like where Luke-Jr pointed out that what people really need is an address specifier which can be reused without causing address reuse. There’s no good way of doing that (you probably need an OP_RETURN to tell the recipient what the key is), and I backed off, fast. Greater minds will intervene, I’m sure!