#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, pt 4/5. This means one can get taproot-based covenants like OP_TAPLEAF_UPDATE_VERIFY with another softfork but with no new witness version introduced – and it will work well with future witness softforks.
#1, pt 5/5. The strange version values, like 0xC0, are due to the fact that we need to distinguish witness elements in transaction inputs without knowing which version of witness it is - this we need not to use existing OP_CODE bytes. More to follow…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Dr Maxim Orlovsky [LNP/BP]

Dr Maxim Orlovsky [LNP/BP] Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @dr_orlovsky

7 Nov
Continuing #Taproot series.

#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.
Read 6 tweets
9 Mar
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
Read 13 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(