bip-noreplay: Redo leading zero logic and allow truncated block hashes

1 files changed, 15 insertions, 4 deletions

diff --git a/bip-noreplay.mediawiki b/bip-noreplay.mediawiki
index 5fac80c..947c611 100644
--- a/bip-noreplay.mediawiki
+++ b/bip-noreplay.mediawiki
@@ -31,13 +31,11 @@ When this opcode is executed:
 * If the blockchain (in the context of the execution) does not have ParamHeight blocks, the script fails (this failure must not be cached across blocks; it is equivalent to non-final status).
 * If ParamHeight specifies a block deeper than 52596 blocks in the chain (including negative values), the opcode completes successfully and script continues as normal.
 * The second-to-top item on the stack is interpreted as a block hash (ParamBlockHash).
-* If ParamBlockHash is longer than 28 bytes or has leading zeros, the script fails.
-* If ParamBlockHash does not match the block hash of the block specified by ParamHeight, the script fails.
+* If ParamBlockHash is longer than 28 bytes, the script fails.
+* If ParamBlockHash does not match the equivalent ending bytes of the block hash specified by ParamHeight, the script fails.
 
 Otherwise, script execution will continue as if a NOP had been executed.
 
-FIXME: some way to mask out parts of the block hash for gambling/deterministic-random applications?
-
 ===Deployment===
 
 This BIP will be deployed by "version bits" [[bip-0009.mediawiki|BIP9]] with the '''name''' "cbah" and using '''bit''' TBD.
@@ -77,6 +75,19 @@ Why are blocks older than 52596 deep in the chain not verified?
 * It is assumed that 1 year is sufficient time to double-spend any common UTXOs on all blockchains of interest.
 * If a deeper check is needed, it can be softforked in. Making the check more shallow, on the other hand, is a hardfork.
 
+Why is ParamBlockHash allowed to match less than the full block hash?
+
+* In a chain split, it is sufficient to check only a few bytes to avoid replay.
+* In all scenarios, it is likely sufficient to check only a minority of the full hash to avoid any realistic chance of replay.
+* Allowing less than the full hash to be specified saves space in transaction data.
+* Using a single byte can be combined with other opcodes (such as <code>OP_LESSTHAN</code>) to enable on-chain gambling logic.
+
+What if ParamBlockHash has leading zeros? Should this be prevented?
+
+* If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.)
+* It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern.
+* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes.
+
 TODO
 
 ==Backwards Compatibility==