Merge pull request #983 from kallewoof/202008-signet-empty-commitment

bip-0325: clarify the OP_TRUE challenge special case

1 files changed, 3 insertions, 1 deletions

diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki
index ff1a145..752570d 100644
--- a/bip-0325.mediawiki
+++ b/bip-0325.mediawiki
@@ -65,10 +65,12 @@ The "to_sign" transaction is:
 
 The scriptSig and/or scriptWitness for <code>vin[0]</code> are filled in from the Signet header push above.
 
-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.
+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.
 
 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.
 
+There is one other acceptable special case: if a block's challenge is e.g. `OP_TRUE` (`0x51`), where an empty solution would result in success, the block is also considered valid if the signet commitment is absent.
+
 == Genesis Block and Message Start ==
 
 The genesis block is the same for all signet networks, whereas the message start is defined as the first four bytes of the sha256d of the challenge script as a single data push (see below).