Author: Jameson Lopp 2015-12-16 21:51:47
Published on: 2015-12-16T21:51:47+00:00
The email thread from the bitcoin-dev mailing list discusses the deployment of Segregated Witness (SegWitness, SW) in the context of scaling Bitcoin. While it has useful attributes such as addressing a major malleability vector, it is not considered a short-term scaling solution. One proposal presents SW instead of a hard fork block size increase. It creates two views of each transaction and block, with newer clients seeing extended blocks and transactions while older clients see standard 1M blocks. The rollout pace for SW is expected to be slow, with wallet software and programmer libraries needing upgrades that will take 12+ months in some stacks. On the other hand, a simple hard fork such as BIP 102 is automatically compatible with most of today's ecosystem software, unlike SW which requires merchants to upgrade almost immediately, requiring wallet and other peripheral software upgrades to make use of. The number of lines of code that must change for BIP 102 is very small, and the problem domain is well known, compared to SW. Furthermore, SW creates more complex bidding structures by creating a second economic resource and splitting blocks into two pieces, each with separate behaviors and resource values, thus creating two fee markets. It is unlikely that SW provides scaling in the short term, and it introduces new economic complexities. A "short term bump" hard fork block size increase addresses the economic and ecosystem risks that SW does not. Bump + SW should proceed in parallel, independent tracks, as orthogonal issues.
Updated on: 2023-06-11T02:15:56.300479+00:00