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