From rusty at rustcorp.com.au Mon Jul 27 01:43:19 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 27 Jul 2015 11:13:19 +0930 Subject: [Lightning-dev] commitment update steps In-Reply-To: <20150725003825.GA29178@lightning.network> References: <87egjyqt02.fsf@rustcorp.com.au> <20150724223828.GA18345@lightning.network> <20150724232449.GB18345@lightning.network> <20150725003825.GA29178@lightning.network> Message-ID: <87si8ape88.fsf@rustcorp.com.au> Joseph Poon writes: > Oh, I forgot it's necessary to store the hash of the R value. That'll > make it much bigger. 26-bytes or so. > > Also, if OP_RETURN is viewed as acceptable, then you should be able to > fit 3 outputs per OP_RETURN metadata output. So that's the summary of where we stand. Beyond 3 HTLCs, you need to remember HTLC values forever. I think this has an effect on how we do anchor upgrades (to increase or decrease channel capitalization). Naively, we just open another channel. Alternately, we create a new anchor which spends the existing anchor(s). While we're waiting for it to be sufficiently buried we create commitment txs (and HTLCs) against both the new and old anchor. Once the new anchor is buried enough, we drop the old one. At that point, those ancient HTLCs all become unspendable, so we can forget those old values. I think that's a win... (I've ignored issues with how we avoid mutation etc. with the new anchor, since I'm about to re-open that can in another thread). Cheers, Rusty.