current witness reserved value
witness reserved value #646
pull 4tochka wants to merge 1 commits into bitcoin:master from 4tochka:patch-1 changing 1 files +1 −0-
4tochka commented at 1:34 PM on February 9, 2018: none
-
witness reserved value a0319d6b6a
-
jl2012 commented at 2:14 PM on February 9, 2018: contributor
NACK. It has no special but no assumption could be made.
-
4tochka commented at 9:12 PM on February 9, 2018: none
So at this moment to calculate correct commitment to verify block, What witness reserved value we should use? Experimentally I got correct value on existing testnet blocks using b"\x00" * 32 double_sha256(merkleroot(wtxid_list[::-1]) + b"\x00" * 32)
-
sipa commented at 11:24 PM on February 9, 2018: member
There is no restriction. Those 32 bytes can literally be anything, and the block will be valid.
It's there for future extensibility which may give a meaning to those 32 bytes.
-
4tochka commented at 5:07 AM on February 10, 2018: none
Ok I understand, but still not clear about recent value. I have read BIP and got definition that Commitment hash: Double-SHA256(witness root hash|witness reserved value). Where is defined recently used witness reserved value? At example I take block from testnet and try to recalculate commitment hash. How do I know which value used by block creator concatenated with witness root hash? The result is Double-SHA256 and can't be reversed. Is any other document have definition about what value we should use today?
-
sipa commented at 5:17 AM on February 10, 2018: member
The value is in the coinbase transaction's witness. No need to guess it. It's chosen by the miner and included in the block.
-
4tochka commented at 5:21 AM on February 10, 2018: none
Thank you!
-
MarcoFalke commented at 3:13 PM on February 10, 2018: member
Close?
-
4tochka commented at 3:14 PM on February 10, 2018: none
Yes please close
- luke-jr closed this on Feb 10, 2018
- luke-jr added the label Proposed BIP modification on Feb 10, 2018
-
luke-jr commented at 10:18 PM on February 10, 2018: member
I think it'd be reasonable to suggest some "default" value that can be used if a miner doesn't want to give it a special meaning. Otherwise, someone implementing could be left wondering...