[Lightningdev] Revocations with OP_CSFS & signed sequence commitments
James Chiang
james.chiangwu at gmail.com
Fri Feb 1 09:01:20 UTC 2019
Good morning ZmnSCPxj,
Many thanks for your answers, those are greatly appreciated!
May I followup with the following questions related to <n> 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 preimage revealed,
thereby revealing n ... what am I missing?
Kind regards,
James
On Fri, Feb 1, 2019 at 6:15 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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
> onstack 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 <n> 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: <http://lists.linuxfoundation.org/pipermail/lightningdev/attachments/20190201/6d3b26fe/attachment.html>
More information about the Lightningdev
mailing list