[Lightning-dev] Revocations with OP_CSFS & signed sequence commitments

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Feb 1 09:33:53 UTC 2019

Good morning,

The Stamford presentation points to BOLT #3, but this obfuscates the sequence number by XOR.
Unfortunately this cannot result in an obfuscated number where `<` operation is sensible.

An idea would be to *add* an obfuscating number.
For instance, suppose the `n` field is 64-bit and we decide that 2^63 updates should be enough for anyone.
Then at channel setup time, both sides would select a 2^63 number as base for update `n = 0`.
So for example, suppose we select the random number `m` at the start of the channel setup.
What we publish in-script is `m + n`.
The next number would be `m + n + 1`, and so on.
This allows comparison of sequence numbers, while obscuring the number of updates.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ 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?
> I learned about this concept from Johnson Lao's and Roasbeef's Talk from Scaling Bitcoin at Stanford:
> https://scalingbitcoin.org/stanford2017/Day1/SB2017_script_2_0.pdf 
> Any pointers would be very much appreciated.
> Kind regards,
> James

More information about the Lightning-dev mailing list