From joseph at lightning.network Mon Jul 13 22:26:59 2015 From: joseph at lightning.network (Joseph Poon) Date: Mon, 13 Jul 2015 15:26:59 -0700 Subject: [Lightning-dev] [RFC] Anchor (funding) transactions without segregated witness In-Reply-To: <874mlgebx8.fsf@rustcorp.com.au> References: <874mlgebx8.fsf@rustcorp.com.au> Message-ID: <20150713222659.GA4548@lightning.network> On Tue, Jul 07, 2015 at 03:39:39PM +0930, Rusty Russell wrote: > Feedback, optimizations, horrible holes? I think this model works! As soon as OP_CHECKLOCKTIMEVERIFY soft-forks into bitcoin, a basic lightning implementation may be theoretically possible in real bitcoin (with some significant caveats)! I think Thaddeus Dryja came up with a similar implementation to resolve malleability in multisig (involving a clock and 2-input/2-output). However, I think a true malleability fix is still ideal. To complete the thought, I think it's possible to make the Commitment Transactions malleability-safe under this construction. > 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. To create the Commitment Transaction (in step 6 and all future Commitment Transactions), it requires spending from the two inputs separately and the output would require having OP_CLTV or OP_CSV in the script output to determine whether a Commitment has been revoked. This is necessary since one cannot be fully confident about the Transaction ID beforehand. If the inputs are 0.5 Alice and 0.5 Bob, the first Commitment Transaction would refund 0.5 to Alice and 0.5 to Bob. As always, there are a pair of Commitment Transactions per commitment state. Presume the current block height is 350,000 and the channel closes at 355,760. The Commitment Transaction which only Alice can broadcast, Commitment 1a, would have the following outputs: 0. 0.5 BTC BobKey 1. 0.5 BTC OP_IF OP_CHECKSIGVERIFY <355,760> OP_CLTV OP_DROP OP_ELSE OP_HASH160 OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_END This is the general idea at least (haven't checked the script). Bob gets all his money if Alice broadcasts it immediately because Alice is attesting Bob should get *at least* 0.5 BTC. For the second output (output 1), the first path gives Alice the funds at channel expiration. The second path is so if the current Commitment transaction is not Commitment 1 and Alice should lose all her money for incorrectly broadcasting Commitment 1. Alice does this by attesting to Bob she wouldn't broadcast Commitment 1 by giving the RevocationPreimage which is hashed into RevocationHash. Bob also has a Commitment Transaction which is the opposite (Alice's funds get paid immediately, Bob's funds is encumbered by time). The purpose of doing this type of construction instead of using nLockTime on the transactions spending from the Commitment Transaction is so that each output only requires one signature. By having only one signature, malleability concerns can be mitigated, since that single party can simply resign and is not dependent upon the cooperation of the counterparty if the Commitment Transaction itself gets mutated. Since the Commitment Transaction is only build after the Anchor and Escape transactions exist, then this construction will allow for Lightning Network channels to exist with OP_CLTV, with the caveat that with uncooperative counterparties, you will have to wait until channel expiration to get your money back. However, it does mean that playing with LN is a possibility on the real bitcoin chain in the near future. Very cool, Rusty! -- Joseph Poon