Segregated Witness in the context of Scaling Bitcoin



Summary:

The email thread discusses the deployment timeline of a hard fork versus the Segregated Witness (SegWit) solution as a scaling solution for Bitcoin. It is suggested that economically important nodes need to be upgraded before the fork kicks in and that a year is considered an aggressive timeline for implementation. Jameson Lopp notes that over a year seems like an extraordinarily long time frame for deploying a hard fork and adds that 75% of reachable nodes have upgraded in the past six months, while up to 25% may not have been upgraded in over a year. However, there is no way of knowing what percentage of nodes are economically important.The discussion also mentions observations on data structure formats and views with respect to SW, which creates two views of each transaction and block. Newer clients see extended blocks and transactions, whereas older clients do not see extended blocks and upgraded transactions appear as unsigned anyone-can-pay transactions. Each extended transaction exists in two states - unsigned and signed - both of which pass validation as valid Bitcoin transactions. The email thread also covers definitions of terms such as Import Fee Event, ECE, TFM, and FFM from previous emails.It is noted that transactions created by older clients will not use the extended transaction format, meaning all data is stored in the standard 1M block. The core block economic resource is heavily contended, and older clients will pay a higher fee than newer clients. The roll-out pace for SW will be slow due to the need for wallet software and programmer libraries to be upgraded. There are also concerns about the more complex economic policy, new game theory, and new bidding structure risks associated with SW.A hard fork to a bigger block size such as BIP 102 is automatically compatible with most software, unlike SW which requires merchants to upgrade almost immediately and other updates that occur more slowly. Even if SW is merged into Bitcoin Core tomorrow, it does not address the risk of a Fee Event and associated Economic Change in the coming months. Splitting blocks into two pieces creates two fee markets, which could create a more-complex bidding structure by creating a second economic resource.The email thread also notes that SW introduces new economics complexities and is unlikely to provide scaling in the short term. A "short term bump" hard fork block size increase addresses economic and ecosystem risks that SW does not. Bump + SW should proceed in parallel, independent tracks, as orthogonal issues. Hard forks provide much stronger validation and ensure the network operates at a fully trustless level. An SW hard fork could also add several zero-filled placeholders in a merkle tree for future use.


Updated on: 2023-05-19T22:52:34.772155+00:00