Published on: 2019-02-04T04:07:01+00:00
In a conversation between James Chiang and ZmnSCPxj, they discuss the implementation of obfuscating the sequence number by XOR in BOLT #3. However, this method does not meet the requirement of having a monotonically increasing sequence number. ZmnSCPxj suggests adding an obfuscating number to the sequence number instead, which allows for comparison of sequence numbers while obscuring the number of updates. 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. At channel setup time, both sides can select a 2^63 number as base for update 'n = 0', and publish it as 'm + n'. The next number would be 'm + n + 1', and so on.James also seeks clarification on how sequence numbers are committed to the nth commitment tx and accessible on-stack during script evaluation. He refers to Johnson Lao's and Roasbeef's Talk from Scaling Bitcoin at Stanford for more information on this concept.In an email conversation about the revocation of channel commitment transactions with op_checksigfromstack(msg, sig, key) and signed sequence commitments, ZmnSCPxj proposes obfuscating the initial 'n=0' with a pre-negotiated m and applying a deterministic step to this obscured initial state number. This ensures that sequence numbers can be compared while obscuring the number of updates. In response to James Chiang's inquiry about how sequence number n is committed to the nth commitment tx and accessible on-stack during script evaluation, Johnson Lao's and Roasbeef's Talk from Scaling Bitcoin at Stanford is suggested as a reference.The writer of the message is seeking information on how channel commitment transactions can be revoked using op_checksigfromstack(msg, sig, key) and signed sequence commitments. Each state has a commitment c(n, randomness) that is signed by both parties, and this signature can be verified with op_csfs(c, sig(A+B), key(A+B)). The sequence number n is incremented for each new state. 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)) and c++ == commitment(n++, r). However, the script must also have information about its own sequence number n to ensure it is lower than n++. The writer learned about this concept from a presentation at Scaling Bitcoin at Stanford by Johnson Lao and Roasbeef.In this conversation, James seeks clarification on how channel commitment transactions can be revoked with op_checksigfromstack(msg, sig, key) and signed sequence commitments. He asks ZmnSCPxj about the n++ ?> n inequality evaluation during the sweep of the revoked nth state. James wonders if n and n++ will necessarily be revealed during a unilateral close. ZmnSCPxj provides a link to a slide from Olaoluwa that describes a prior sequence number commitment being embedded in the commitment output. James asks about the arguments for the evaluation of n++ ?>n being supplied without revealing either commitment sequence numbers. Regarding Olaoluwa's proposal (slide linked above), James doesn't understand how the prior commitment opening and embedding of the commitment in the output script contributes to this. ZmnSCPxj explains that "n++" here is a SCRIPT input such that any "n" Then the SCRIPT itself contains the "n" it has. Thus `n` is embedded in the SCRIPT directly as a constant. Now the script itself is committed via P2WSH, and the output SCRIPT is committed to in the SIGHASH algorithm used.In this email exchange, James Chiang is seeking to understand how channel commitment transactions can be revoked using op_checksigfromstack(msg, sig, key) and signed sequence commitments. The commitment is signed by both parties for each state and the signature can be verified with op_csfs(c, sig(A+B), key(A+B)). The sequence number is incremented for each new state. 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)) and 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). `n` is embedded in the SCRIPT directly as a constant and the script itself is committed via P2WSH, and the output SCRIPT is committed to in the SIGHASH algorithm used.The author of the message is trying to understand how channel commitment transactions can be revoked using op_checksigfromstack(msg, sig, key) and signed sequence commitments.
Updated on: 2023-07-31T21:25:37.713502+00:00