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

[ZmnSCPxj]

Good morning James,

It is helpful to also remember that the only requirement be that the sequence number be monotonically increasing.
There is no requirement that the step size be *the same* at every update.

Note however that the step size being anything other than 1 is not very useful as long as the blinding initial number `m` is truly selected at random.
That should be sufficient to blind the actual number of updates.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, February 1, 2019 6:18 PM, James Chiang <james.chiangwu at gmail.com> wrote:

> 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 <ZmnSCPxj at protonmail.com> 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