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. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, January 31, 2019 6:31 AM, James Chiang <[email protected]> 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 _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
