64 | @@ -65,10 +65,12 @@ The "to_sign" transaction is:
65 |
66 | The scriptSig and/or scriptWitness for <code>vin[0]</code> are filled in from the Signet header push above.
67 |
68 | -To simplify block generation (mining), the signature also does not commit to the the block nonce value, so that rolling the nonce to generate proof-of-work does not also require regenerating signatures. When grinding proof of work, the extended nonce cannot be used as it would invalidate the signature. Instead, simply resigning the same (or an updated) block will give a new search space.
69 | +To simplify block generation (mining), the signature also does not commit to the block nonce value, so that rolling the nonce to generate proof-of-work does not also require regenerating signatures. When grinding proof of work, the extended nonce cannot be used as it would invalidate the signature. Instead, simply resigning the same (or an updated) block will give a new search space.
70 |
71 | A block is considered fully validated only if the to_sign transaction is a valid spend of the to_spend transaction. It is recommended that this verification is done directly before or after the witness commitment verification, as the data required to do both is approximately the same.
72 |
73 | +There is one other acceptable special case: if a block's challenge is equal to `OP_TRUE` (`0x51`), the block is considered valid iff the signet commitment is absent. (It is invalid if present, even if both scriptSig and scriptWitness are empty.)
Reading the code, I don't think this is true. Additional bytes can be put in the commitment even with an OP_TRUE challenge.
Also, it seems overly specific to mention OP_TRUE, as the only special case (There should be more than that)
I wanted to say "Wouldn't that violate the segwit clean stack rule?" but I realize that rule is probably not enforced in signet validation.
I modified to be less specific. Edit: Removed the part about empty present commitment being invalid.
