Topic: List of past soft forks and OP codes? (Read 1104 times)
Thank you both for the extremely helpful and informative replies.
Apart from the P2SH, there was:
* BIP34 (v2 blocks) - activated at block #227931. This change was about the block number value to be included in the coinbase.
* BIP66 (v3 blocks) - from block #363725. Disallowed some encoding of the signatures.
* BIP65 (v4 blocks) - block #388381. Support for OP_CHECKLOCKTIMEVERIFY.
* CSV (through BIP9) - active from block #419328. Support for OP_CHECKSEQUENCEVERIFY.
I think that's all. Plus the ongoing segwit.
Redeem script is pushed onto the stack as one binary blob (as the last element, after public keys and signatures).
"OP_HASH160 OP_EQUAL" hashes that binary blob and compares against the required value.
Then (what BIP16 activation changed) is that the last binary blob is ten taken from the stack and executed as a regular script.
So basically it executes two different scripts, one after another: first the "OP_HASH160 OP_EQUAL" one, then the spending one.
* BIP34 (v2 blocks) - activated at block #227931. This change was about the block number value to be included in the coinbase.
* BIP66 (v3 blocks) - from block #363725. Disallowed some encoding of the signatures.
* BIP65 (v4 blocks) - block #388381. Support for OP_CHECKLOCKTIMEVERIFY.
* CSV (through BIP9) - active from block #419328. Support for OP_CHECKSEQUENCEVERIFY.
I think that's all. Plus the ongoing segwit.
Code:
Did the "OP_HASH160 OP_EQUAL" output just automatically require checking redeem scripts when it was implemented?
Redeem script is pushed onto the stack as one binary blob (as the last element, after public keys and signatures).
"OP_HASH160
Then (what BIP16 activation changed) is that the last binary blob is ten taken from the stack and executed as a regular script.
So basically it executes two different scripts, one after another: first the "OP_HASH160
As a learning exercise, I am writing a full node from scratch. I am currently writing the transaction validation logic, and I know that there have been numerous soft forks and changes/updates to assign NOP's to something useful, but I want to make sure that I don't use the current OP code definition for a time period when the definition was still a NOP. Is there a list of soft forks and OP code changes I can reference, or do I just have to research that myself and estimate based on the blockchain history and whatever other info I can find..?
All soft forks were done through the BIP process. Take a look through the BIP list: https://github.com/bitcoin/bips/blob/master/README.mediawiki. Anything that has "Consensus (soft fork)" for Layer and "Final" for status is a soft fork which has already activated.I am also wondering how P2SH was originally implemented. Obviously OP_HASH160 doesn't include the code for "oh and check if the stack object is a script, and if it is, verify it". Did the "OP_HASH160 OP_EQUAL" output just automatically require checking redeem scripts when it was implemented?
When BIP 16 activated, it created a new standard output type of the form OP_HASH160 [20-byte-hash-value] OP_EQUAL. Any output of that form is considered a P2SH output. Any P2SH output will always have the last item in the stack after the scriptsig eval (i.e. after the redeemscript was pushed to the stack) evaluated as a script even if it is not a script.
As a learning exercise, I am writing a full node from scratch. I am currently writing the transaction validation logic, and I know that there have been numerous soft forks and changes/updates to assign NOP's to something useful, but I want to make sure that I don't use the current OP code definition for a time period when the definition was still a NOP. Is there a list of soft forks and OP code changes I can reference, or do I just have to research that myself and estimate based on the blockchain history and whatever other info I can find..?
I am also wondering how P2SH was originally implemented. Obviously OP_HASH160 doesn't include the code for "oh and check if the stack object is a script, and if it is, verify it". Did the "OP_HASH160 OP_EQUAL" output just automatically require checking redeem scripts when it was implemented?
Thanks for the help everybody.
I am also wondering how P2SH was originally implemented. Obviously OP_HASH160 doesn't include the code for "oh and check if the stack object is a script, and if it is, verify it". Did the "OP_HASH160
Thanks for the help everybody.
Jump to: