Author: Gregory Maxwell 2015-12-08 23:59:33
Published on: 2015-12-08T23:59:33+00:00
In an email from Gavin Andresen to bitcoin-dev on December 8, 2015, the topic of segwit (segregated witness) was discussed. Andresen questioned why segwit should be implemented as a soft fork, stating that stuffing the segwit merkle tree in the coinbase would complicate consensus-critical code. However, others argued that it was nearly costless to put segwit in the coinbase transaction and that exploring the costs was one reason for implementing it this way. They also mentioned that we already have consensus critical enforcement in the height, which has almost never been problematic. Additionally, they discussed the location of the segwit merkle tree, with most but not all previous proposals suggesting the same or similar locations. The exact location is not critical and there are several soft-fork compatible options. Andresen expressed concern that putting the segwit data in the coinbase transaction would make any segwit fraud proofs significantly larger, but others argued that the overhead would be pretty tiny. Regarding risk reduction, it was suggested that performing the primary change backwards compatibly and picking up the data reorganization in a hardfork later if necessary would be much preferable. They also mentioned that fixing the O(n^2) sighash problem would be necessary for any blocksize increase. Some believed that segwit would make the current bottleneck (block propagation) worse in the short term due to the extra fraud-proof data, but that the benefits outweighed the costs. Finally, Andresen discussed the possibility of a fundamental difference of opinion regarding capacity, with some businesses generating tens of thousands of transactions per day disagreeing with the current state of affairs. However, he laid out a plan for several complementary capacity advances that reflected the emerging consensus in the Bitcoin Core project.
Updated on: 2023-05-19T22:37:33.051461+00:00