Deeply understand Bitcoin's "SegWit" technology and its three version upgrades.

From SegWit to Taproot and then to the TaprootAssets protocol, a comprehensive analysis of the three major upgrades of Bitcoin's Segregated Witness technology, deeply understanding the history of Bitcoin's scalability and capacity development. This article is based on a piece written by Fu Shaoqing, SatoshiLab, and the BTC studio of Wànwù Dǎo, organized, compiled, and authored by PAews. (Background summary: Adam Back on quantum computer “cracking Bitcoin”: suggests using SLH-DSA to integrate Taproot) (Background supplement: The biggest controversy after Bitcoin Taproot, how will removing OP_Return affect the BTC ecosystem?) 1. Introduction When the author was studying Bitcoin technology, he found that understanding the three knowledge points of SegWit, Taproot, and TaprootAssets from the perspective of the development history of Segregated Witness makes it easier to learn and grasp their development patterns. It also allows for a better understanding of the Taproot Assets protocol of the Lightning Network Laboratory, grasping the role of the Universe, and understanding the functions that the TaprootAssets protocol can achieve and its potential future development. With these understandings, better products can be designed for users. Reading this article also requires two important perspectives: the scalability of Bitcoin and the capacity of Bitcoin. Scalability refers to expanding the data capacity that Bitcoin can use and manage, initially limited to the block size, and later to the total data capacity that can be managed by Bitcoin. The limit of scalability is managing infinite data space; capacity refers to expanding the ability of Bitcoin's script instructions to achieve functions, with the limit of capacity being the realization of Turing Complete programming capability. The entire development history of Bitcoin is a history of scalability and capacity development, including various Bitcoin fork chains, as well as the exploration of Bitcoin on OP_RETURN and the three version changes of Segregated Witness. Most readers can ignore the detailed principle diagrams in the three versions, as they are included by the author for a deeper understanding of the relevant technology, and ignoring them does not affect the reading experience. The author has marked the time of the BIP protocols involved in the article, allowing readers to feel the time cycle from the generation of an idea to the production environment going live, thereby experiencing the difficulty level of realizing this technology to some extent. More importantly, the time of the emergence of the three Segregated Witness version protocols to their go-live time can also reflect the larger development patterns of this matter, making it easier to predict future developments. This serves as a good reference for teams developing products based on these technologies and protocols, facilitating the selection of participation timing. Early participation in a new thing often becomes a “pioneer” due to immature supporting technologies; late participation can result in missing opportunities and becoming a “spectator”; the author believes that entering just before it becomes usable is a better timing. The judgment of this “imminent usability” is often based on temporal judgments and technical detail assessments. 1.1. Early Transactions (Without Segregated Witness) Transactions defined in the White Paper (the simplest transaction model) Early basic Bitcoin transactions allowed multiple inputs and two outputs. One output is the change back to oneself, and the other output is a transfer to an external entity. (Note: The difference between total input and total output is the transaction fee) Most transactions have 2 outputs, but there are indeed scenarios with only one output, summarized as follows: To better illustrate the differences, we use a diagram of 2 inputs and 2 outputs. (Another main reason is that the reference material I consulted provided such a 2 input and 2 output picture, so no need to redraw it. Just being lazy ^_^) Is it easier to understand with such a comparison diagram? Comparison of traditional transaction example diagram and Segregated Witness transaction schematic diagram 1.2. Exploration on OP_RETURN Why mention OP_RETURN when discussing Segregated Witness? Because this was an earlier exploration than Segregated Witness, allowing for a better understanding of the reasons for the emergence of Segregated Witness. OP_RETURN is an operation code used to terminate the script and return the value at the top of the stack. This operation code is similar to the return function in programming languages. Throughout Bitcoin's history, the function of the OP_RETURN operation code has been modified multiple times, and it is now mainly used as a method to store data on the ledger. The function of OP_RETURN has undergone significant changes in the past, and it is now an important mechanism that allows us to store arbitrary data on-chain. OP_RETURN was initially used for early termination of script execution, with the execution result presented as the top item of the stack. This operation code initially had a vulnerability that could be exploited, but Satoshi Nakamoto quickly patched it. Further changes to OP_RETURN functionality In the Bitcoin Core v0.9.0 upgrade, the “OP_RETURN output” script was established as a standard output type, allowing users to attach data to “unspendable transaction outputs.” The initial limit on the amount of data that could be used in such scripts was restricted to 40 bytes, later raised to 80 bytes. Storing data on the blockchain Changing OP_RETURN to always return false resulted in interesting outcomes. Since no operation codes or data are evaluated after OP_RETURN, network users began to use this operation code to store data of any format. During the period of Bitcoin Cash (BCH), from August 1, 2017, to November 15, 2018, the length of data that could be attached to OP_RETURN outputs was extended to 220 bytes, enabling innovative applications on the blockchain, such as publishing content on blockchain social media. In BSV, the 220-byte limit was retained for a short time. Subsequently, in January 2019, because the OP_RETURN operation code terminates the script without nodes validating any subsequent operation codes, nodes also did not check whether the script was within the maximum script size limit of 520 bytes. As a result, network node operators decided to increase the maximum transaction size to 100KB, giving developers more freedom for application innovation, allowing new applications to place larger, more complex data into the Bitcoin ledger. At that time, there was an application example where someone stored an entire website in the BSV ledger. Although OP_RETURN has certain functional expansions, its overall capability remains limited. Moreover, the improvements on OP_RETURN do not lead to more technical evolution architecturally (still limited to 1M blocks), which led to the emergence of Segregated Witness technology. Its three version upgrades better illustrate the correctness of Segregated Witness in terms of scalability and capacity, as well as the powerful effects generated. 1.3. Comparison schematic diagram of early transactions and three versions of Segregated Witness changes To help everyone better understand the entire history of Bitcoin with Segregated Witness, we first present comparison schematic diagrams of the four stages at the beginning of the article. 2. The First Version of Segregated Witness Segwit 2.1. Introduction and Related Protocols Segregated Witness, or SegreGated Witness (abbreviated as S…