Segregated Witness in the context of Scaling Bitcoin

Summary:

The email from Jeff Garzik via bitcoin-dev discusses Segregated Witness (SegWitness, SW) in the context of Scaling Bitcoin. It notes that while SW has useful attributes, such as addressing a major malleability vector, it is not a short term scaling solution. The email provides definitions for Import Fee Event, ECE, TFM, FFM, older clients, newer clients, block size, core block, extended transaction, extended block, and EBS. SW creates two views of each transaction and block, with blocks and extended blocks, and transactions and extended transactions. Newer clients see extended blocks and extended transactions, while older clients see blocks (limit 1M) and do not see extended blocks. Each extended transaction exists in two states, one unsigned and one signed, each of which passes validation as a valid bitcoin transaction. Transactions created by older clients will not use the extended transaction format. All data is stored in the standard 1M block as today.SW complicates block economics by creating two separate, supply-limited resources. The core block economic resource is heavily contended, while the extended block economic resource is less heavily contended. Because core blocks are more heavily contended, it is presumed that older clients will pay a higher fee than newer clients. The email identifies several problems with SW, including the pace of rollout being slow due to the whole ecosystem needing to be considered, the hard fork to bigger block size just working with most software unlike SW, the risk of a Fee Event and associated Economic Change in the coming months even if SW is merged into Bitcoin Core tomorrow, the more complex economic policy, new game theory, and new bidding structure risks created by SW, the need for improvement in the current SW mining algorithm, and new, under-analyzed attack surfaces. The email concludes that a "short term bump" hard fork block size increase addresses economic and ecosystem risks that SW does not. It recommends that bump + SW should proceed in parallel, independent tracks, as orthogonal issues. The email also notes that hard forks provide much stronger validation and ensure the network operates at a fully trustless level, and that an SW hard fork could add several zero-filled placeholders in a merkle tree for future use.

Updated on: 2023-05-19T22:53:56.336154+00:00