From aj at erisian.com.au Thu Jul 23 04:40:45 2015 From: aj at erisian.com.au (Anthony Towns) Date: Thu, 23 Jul 2015 14:40:45 +1000 Subject: [Lightning-dev] commitment update steps Message-ID: Hi *, For my own understanding I've been trying to work out what the lightning protocol looks like at a network-protocol level. I think the following works, maybe it's interesting for others: For notational convenience I'm going to just list the secrets that need to be known to use to spend an output. "Alice" and "Bob" are Alice and Bob's respective keys, Alice_N and Bob_N are the Nth numbers in shachain sequences [0]. I'm using TIMEOUT for the checktimelockverify construction; DELAY for the checksequenceverify construction. ?Assume Alice and Bob already have a channel setup. Then their current commitments might be: Alice's commitment txn: (fully signed) 500 Alice + DELAY | #Alice_101 + Bob 500 Bob Bob's commitment txn: (fully signed) 500 Alice 500 Bob + DELAY | #Bob_101 + Alice Alice knows the hash of #Bob_101 and Bob knows the hash of #Alice_101 (because they've respectively seen the full txns to sign them). If Alice wants to update the channel to reflect a conditional payment from Bob once R is revealed, they can follow the following steps: 1) Alice proposes: (unsigned) 500 Alice + DELAY | #Alice_102 + Bob 400 Bob 100 R + Alice + DELAY | Bob + TIMEOUT | #Alice_102 + Bob [1] Bob checks: txn structure, amounts, R, Bob key is correct Bob stores the hash of #Alice_102 2a) Bob declines; proposal never happened 2b) Bob approves, replies: signing Alice's proposal requesting sig of: 500 Alice 400 Bob + DELAY | #Bob_102 + Alice 100 R + Alice | Bob + TIMEOUT + DELAY | #Bob_102 + Alice Alice checks: signature, txn structure, amounts, R, Alice key is correct Alice signs and stores new txn. Alice stores the hash of #Bob_102 3) Alice discards old commitment txn. Alice replies: signing Bob's transaction revealing Alice_101 Bob checks: signature, Alice_101 hashes correctly (ie matches the hash of #Alice_101, stored previously), Alice_101 forms hash chain with prior secrets (Alice_100, Alice_99..) as expected Bob signs and stores his new commitment txn Bob discards the hash of #Alice_101. 4) Bob discards old commitment txn Bob replies: revealing Bob_101 Alice checks: Bob_101 hashes correctly (ie #Bob_101 does clear the old txn), Bob_101 forms hash chain with prior secrets (Bob_100, Alice_99..) as expected Alice discards the hash of #Bob_101 If the protocol follows through to completion, then they each have matching, updated, signed commitment transactions; along with the secrets necessary to void attempts to use older commitments. If the protocol goes off track (checks fail, or no response from partner within a protocol timeout), then either party can safely close the channel after any step: Alice can close at (500/500) up until step (3) Alice can close at (500/400/100) after step (2b) Bob can close at (500/500) up until step (4) Bob can close at (500/400/100) after step (3) If Alice ever tries cheating, and publishes and old commitment: 800 Alice + DELAY | #Alice_42 + Bob 200 Bob Then Bob needs to work out which of the 100 Alice_N hashes he knows or can work out is being abused; prior to the DELAY expiring. With millions of transactions that could be a bunch of hash calculations or a 100MB lookup table. Might make more sense to have a dummy output of "0: OP_RETURN 42" to make that calculation trivial though? That could trivially be verified as part of the "forms hash chain as expect" and "txn structure" checks. HTLCs are harder if you assume pay2scripthash is used though. If Alice published: 100 Alice + Delay | #Alice_55 + Bob 100 Bob 200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob 200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob 200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob 200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob well after R1..R4 were known and Alice_55 was revealed in order to try stealing most of the channel's funds, I think Bob could only claim the final outputs if he could unhash the scripts, which would require having remembered R1..R4 even after those contracts had long been resolved. I guess it could be feasible in that case to have the extra output be "0: OP_RETURN 42 #R1 #R2 #R3 #R4"? Cheers, aj ?[0] It's easy to calculate Alice_N given Alice_M for some M > N, but unfeasible for any M < N. ?[1] I don't understand the construction for HTLCs in 0.5.9 of the lightning paper; what I'm doing instead is taking an underlying output of "Alice + R | Bob + TIMEOUT" and mapping it through "my key becomes my key + DELAY" + "they get everything with my secret sequence and their key". I'll post about that separately so it can get shot down :) [2] (Unattached footnote) This project's motto is "The lightning network: it's off the chain!" right? http://www.urbandictionary.com/define.php?term=off+the+chain -- Anthony Towns -------------- next part -------------- An HTML attachment was scrubbed... URL: