highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 21:32:50 +01:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Luke Dashjr 2017-05-11 22:12:49 +00:00
parent d7abc41bb6
commit b582f4e9a9
1 changed files with 15 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
bip-noreplay.mediawiki
View File

@ -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==