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 <zmnsc...@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.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?
> >
> > 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
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to