From b582f4e9a9f4e8580a934e60898ad1c7630c9fd1 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Thu, 11 May 2017 22:12:49 +0000 Subject: bip-noreplay: Redo leading zero logic and allow truncated block hashes --- bip-noreplay.mediawiki | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) (limited to 'bip-noreplay.mediawiki') 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 OP_LESSTHAN) 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== -- cgit v1.2.3