#2, pt 1/6. Taproot introduces new “common signature function” for signing tx with BIP-340 Schnorr signature. This function may be re-used in a future soft-forks (simplifying implementation/code review). It provides two ways of changing signing algo:
#2, pt 2/6. First, for incremental updates, where we do not change the order of data signed, but append new data to the end, we can use so-called *ext flag* - a value in range 0-127 passed as a parameter to the common signing function.
#2, pt 3/6. Tapscript (BIP-342) already uses this mechanism to add to the signed data commitment to a specific key serialization algo (which may change with future updates), script branch version & code (via tapleaf_hash) and code separator.
#2, pt 4/6. By default, if no script is used, taproot requires signatures to be created with ext_flag=0. If script is present, than the flag must be set to 1.
#2, pt 5/6. The second mechanism is so-called *sighash epoch*, used for introducing breaking changes in the signing function. It is defined as byte prefix provided to tagged hash function which produces out of tx data the actual message to sign.
#2, pt 6/6. Changes to signature procedure will always require soft fork, but with #taproot it may happen without an upgrade of witness version: by either using different length of v1 witness program – or via new leaf version value (introduction of new scripting)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
#Taproot is coming. Each day before taproot activation I will publish mostly unknown tech insights into what taproot brings.
#1, pt 1/5. Taproot introduces new versioning for bitcoin script (as many know). But do you know that each taproot branch may have a different script?
#1, pt 2/5. Moreover, taproot separates script versioning from witness versioning. I.e. in witness v5 we may have something like three script versions - or today v1 P2TR output may have a script condition for future versions of script
#1, pt 3/5. The new script versioning system is named *leaf version*. Current leaf version is 0xC0, meaning BIP-341, aka “Tapscript”. Yes, taproot can work not only with tapscript/BIP-341, but other future standards!
1/ With #RGB one needs to change a mindset from “ethereum smart contracts” to normal understanding of what smart contract is. And first, this is a _contract_ between parties. Well-defined parties. Not some record in a global registry, like this concept was distorted in ethereum.
2/ RGB is _bearer rights_ smart contracts, returning the world what was lost of the true free market because of regulations and requirements for centralized censorhip with global registries (even when they are on blockchain, decentralization does not make them less global).
3/ Next, after shifting the point of view, you understand that as an owner of something you are responsible for your own self to keep the data required for securing and ensuring your actual ownership