From joseph at lightning.network Sat Jul 25 00:38:25 2015 From: joseph at lightning.network (Joseph Poon) Date: Fri, 24 Jul 2015 17:38:25 -0700 Subject: [Lightning-dev] commitment update steps In-Reply-To: <20150724232449.GB18345@lightning.network> References: <87egjyqt02.fsf@rustcorp.com.au> <20150724223828.GA18345@lightning.network> <20150724232449.GB18345@lightning.network> Message-ID: <20150725003825.GA29178@lightning.network> 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. Thinking through further, using OP_RETURN metadata is objectively better than just having the nonstandard non-P2SH output when considering transaction size. So for OP_RETURN, you could have a blob up to 80 bytes (or 40 if you want to maximize relay), which results in ~3 transactions if you assume 26-bytes per transaction. If you have a lot, you should probably just fill it all up and compact it, I guess. 16-bits is fine for timeouts since that's 65535 block heights, which is a little over a year's worth. Nothing's stopping you from supporting more than a year's worth if you can find the route, but that's a fine upper-bound for now. 32-bits is used for the Commitment Transaction. For even the most high-volume node, 10 commitments per second results in 300 million Commitment Transactions. This identifies in which Commitment Transaction the HTLC was created. By knowing the Commitment Transaction, you'll know the revocation preimage, so after the revocation information has been exchanged, you only need to know which Commitment Transaction the HTLC was originally formed, since the revocation information was originally *generated* using a merkle tree derived from the Commitment Transaction as an index. In total that's 48-bits (6bytes) per HTLC output per Commitment. Plus 20-bytes for the hash(R), 26bytes. If someone broadcasts an old Commitment and you don't have the HTLC data because it's expired and too old, check the OP_RETURN data for the 6-bytes, then compute the revocation data and compute a couple hundred revocations and see which one fits. I think the tradeoff might be worth it. If you stored this data locally, the cost shouldn't be too high for end-users. However, for those that wish to do a lot of routing, this can add up. A node that does 10 commits/s with 100 HTLCs on average that results in a little over 800GB of local storage per channel if OP_RETURN wasn't used, which may very well be feasible for large hubs. Of course, whether OP_RETURN or local storage were used, it's better than having the entire script as part of the output. -- Joseph Poon