Good morning James,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, January 31, 2019 6:31 AM, James Chiang <james.chian...@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 <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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to