From rusty at rustcorp.com.au  Tue Jul  7 06:09:39 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 07 Jul 2015 15:39:39 +0930
Subject: [Lightning-dev] [RFC] Anchor (funding) transactions without
	segregated witness
Message-ID: <874mlgebx8.fsf@rustcorp.com.au>

Hi all,

        http://ozlabs.org/~rusty/diagrams/dual-anchor.svg

        Since I posted my first design of HTLC yesterday, and noted that
it doesn't seem to require new sighash modes, I went back and revisited
my discarded ideas for establishing an anchor without new sighash modes.
If we can do that (and my HTLC design stands up), then lightning network
only needs OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY, which are
fairly low-albedo soft forks.

        To recap: the draft paper and current code trade signatures on
the first commitment transaction before signing the anchor transaction.
That way you are sure to have a way to get your funds back before you
put them into the anchor.  (The paper uses the term funding transaction;
I prefer anchor).

        This can't be done in normal bitcoin, as you don't know the TXID
of the anchor until after its inputs are signed, so you can't sign the
commitment transaction without knowing the txid of the anchor.  It works
in Elements Alpha because they have segregated witness; the txid of the
anchor doesn't hash the input scripts.  It could work in bitcoin with a
softfork of a new CHECKSIG2 which has new signature modes, but there's
not even a BIP for that, and there are so many things that could be done
there that it's likely to be long delayed.

        So, how can we solve this?  Well, we can have two anchors
instead of one.  I put my inputs into my anchor, you put your inputs
into yours: each one requires both our signatures to spend.  The
commitment tx has two inputs, one for each.

        We can trade anchor txids, so we can both sign the commitment
tx.  But now one of could withhold our anchor, leaving us with an
unusable commitment tx and stuck output from an anchor.  We need a way
to get the funds back in that "abort" case.

        Thus we add an intermediary transaction (called "Escape"
transactions) which spends the 2 of 2 anchor output, but can be spent
either by 2 of 2 (ie. the commitment tx), OR back to the anchor owner
after a delay (using OP_CHECKSEQUENCEVERIFY).

        The order is as follows:

1) We both trade anchor txids and amounts.
2) We both trade signatures for the escape transactions, so either one
   can broadcast them.
3) Now we are sure to be able to recover our funds, we each broadcast
   our anchor txs.
4) If the other side broadcasts their escape transaction, abort and
   broadcast our escape transaction.  After the timeout, we can spend
   it.
5) If the other side doesn't broadcast their anchor tx, abort and
   broadcast our escape transaction.
6) Otherwise, when the anchor txs reach the required depth, we exchange
   signatures for the commitment transaction.
7) If the other side broadcasts either escape transaction, broadcast
   the other escape transaction and the commitment tx as normal (this is
   a unilateral close) before they can reclaim their anchor funds.

I think this works, and doesn't add any new requirements; you now need
to watch out for escape txs being broadcast instead of commitment txs.

The downside is that there are 3 extra transactions involved; 1 extra
for the channel open, and 2 for the channel close.

Feedback, optimizations, horrible holes?
Rusty.