From james.chiangwu at gmail.com Fri Feb 1 09:01:20 2019 From: james.chiangwu at gmail.com (James Chiang) Date: Fri, 1 Feb 2019 10:01:20 +0100 Subject: [Lightning-dev] Revocations with OP_CSFS & signed sequence commitments In-Reply-To: References: Message-ID: Good morning ZmnSCPxj, Many thanks for your answers, those are greatly appreciated! May I follow-up with the following questions related to being in the output script of the nth commitment transaction as you described, which is required so the inequality n++ ?> n can be evaluated during the sweep of the revoked nth state. - Does this not imply that n & n++ will necessarily be revealed during a unilateral close? - The Stanford presentation: "The # of updates is hidden in case of a unilateral broadcast." The following slide from Olaoluwa describes a prior sequence number commitment being embedded in the commitment output: - https://docs.google.com/presentation/d/14NuX5LTDSmmfYbAn0NupuXnXpfoZE0nXsG7CjzPXdlA/edit#slide=id.g2f288a09cf_0_2 How can the arguments for the evaluation of n++ ?>n be supplied without revealing either commitment sequence numbers? Regarding Olaoluwa's proposal (slide linked above), I don't follow how the prior commitment opening and embedding of the commitment in the output script contributes to this, any commitment needs its pre-image revealed, thereby revealing n ... what am I missing? Kind regards, James On Fri, Feb 1, 2019 at 6:15 AM ZmnSCPxj wrote: > Good morning James, > ??????? Original Message ??????? > On Thursday, January 31, 2019 6:31 AM, James Chiang < > james.chiangwu at gmail.com> wrote: > > > Dear all, > > I am trying to understand how channel commitment transactions can be > revoked with op_checksigfromstack(msg, sig, key) and signed sequence > commitments. > > > > I understand that a commitment c(n, randomness) is signed by both > parties for each state, and that this signature can be verified with > op_csfs(c, sig(A+B), key(A+B)). The sequence n is incremented for each new > state. > > > > Given the most recent commitment sequence signature (from both parties) > and the sequence commitment opening (n++, r), an output script of an older, > revoked commitment transaction can verify that a newer signed commitment > sequence exists by examining: > > > > - op_checksigfromstack(c++, sig(A+B), key(A+B)) > > - c++ == commitment(n++, r) > > > > However, it must also have information about its own sequence number n, > so it can verify that this is indeed lower than n++ (current). How is > sequence number n committed to the nth commitment tx and accessible > on-stack during script evaluation? > > From what little I understand, I imagine that "n++" here is a SCRIPT input > (such that any "n < n++" must be given). > Then the SCRIPT itself contains the "n" it has. > > So the SCRIPT above is lacking the check: > > n < n++ > > which I suppose can be done via > > OP_DUP OP_GERATERTHAN OP_VERIFY > > > Thus `n` is embedded in the SCRIPT directly as a constant. > Now the script itself is committed via P2WSH, and the output SCRIPT is > committed to in the SIGHASH algorithm used. > > Regards, > ZmnSCPxj > -------------- next part -------------- An HTML attachment was scrubbed... URL: