From aj at erisian.com.au Fri Jul 24 03:30:05 2015 From: aj at erisian.com.au (Anthony Towns) Date: Fri, 24 Jul 2015 13:30:05 +1000 Subject: [Lightning-dev] commitment update steps In-Reply-To: <87egjyqt02.fsf@rustcorp.com.au> References: <87egjyqt02.fsf@rustcorp.com.au> Message-ID: On 24 July 2015 at 10:49, Rusty Russell wrote: > Anthony Towns writes: > > 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. > It might be millions. If a channel is updated ~100 of times a second, and lasts for a month, that would be 259M updates?, which on your laptop would be 22 minutes of search time. If we're talking 3 days worth of OP_CSV delay, even that would be pretty fine. So yeah, okay, seems plausible. > 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"? > > Good point! With p2sh you need to know the R hash values and timeouts > to spend the output (40 bytes). Since OP_RETURN is length-limited to 80 > bytes, you can't fit more than 2. > ?You could have multiple OP_RETURN outputs though? Your txn would look like: version n inputs: 2 input 1: [txn] [idx] [len] [SIGA SIGB] [seq] input 2: [txn] [idx] [len] [SIGB SIGA] [seq] n outputs: 2 + x ? output 1: [value] [len] [p2sh] # Alice output 2: [value] [len] [p2sh] # Bob output 3: [value] [len] [p2sh] # R1 output 4: [value] [len] [p2sh] # R2 output 5: [value] [len] [OP_RETURN R1R2] ... p2sh outputs are 32 bytes total I think; OP_RETURN is 51 bytes, so you're increasing the txn size by about 80%. Otherwise I think you have to remember all the R's you see. But if that's okay -- 100/second for a month is just 5GB if you just store them in the order you see them; you can probably do something like: - at the time of this transaction, I've seen 0 < N < 2^32 R's on this channel - here's a 288 bit bloom filter telling you which of the first N R's that I've seen are worth checking - add a single 0btc "OP_RETURN [N | bloomfilter]" output - (or if there are 10 or less R outputs, just concatenate their indexes as the OP_RETURN data) Actually, I forgot about the TIMEOUT values which you'd presumably also need; so I guess that's an extra 4 bytes to include in the database of every R (+25%), and if you're not storing, I guess an extra OP_RETURN output that covers 10 R's for an additional overhead of 16%, so ~96% overhead all up. If you consider your counterparty very reliable, then having 100% overhead in the commitment txns might not be a big deal -- you'll almost always close the channel cooperatively anyway, so the commitments don't get used and the fees for the overhead won't get paid; OTOH, if your counterparty isn't known to you, and you think it's likely they might randomly disappear off the net and you'll have to use the commitment, then trading off disk for fees might be sensible. You could change the choice while the channel's operating -- if a new R value is verbatim in the output, no need to store it locally, whether or not you've stored previous R values locally. Cheers, aj -- Anthony Towns -------------- next part -------------- An HTML attachment was scrubbed... URL: