From james.chiangwu at gmail.com Fri Feb 1 10:18:44 2019 From: james.chiangwu at gmail.com (James Chiang) Date: Fri, 1 Feb 2019 11:18:44 +0100 Subject: [Lightning-dev] Revocations with OP_CSFS & signed sequence commitments In-Reply-To: References: Message-ID: Hello ZmnSCPxj, So you suggest obfuscating the initial `n=0` with an initial pre-negotiated m, and applying some kind of deterministic step to this obscured initial state number. Potentially the deterministic sequence step sizes could be determined via pre-negotiated parameters which also obscure the number of states between most current and broadcast... - m + a*n - (m, a pre-negotiated) - (Though this would affect # of possible updates.) Very cool, thanks so much for your answer(s)! Kind regards, James On Fri, Feb 1, 2019 at 10:34 AM ZmnSCPxj wrote: > 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 < > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: