Published on: 2016-10-17T13:31:07+00:00
In a recent discussion on the Bitcoin-dev mailing list, concerns were raised about the safety and implementation of the SegWit upgrade. Tom Zander pointed out that if any issues occurred after deployment, all transactions made during that time would become everyone-can-spent transactions, resulting in real people losing real money. He emphasized the importance of ensuring proper miner support before activation to avoid this risk.However, there was debate over whether a longer grace period would actually make the network safer. Some members argued that companies would not roll out their updates until lock-in is confirmed, while others believed that many wallets already had code ready and tested but had not yet released it. The discussion also touched upon the amount of code and changes in SegWit, with Zander expressing concern that it was a dangerous change in Bitcoin. However, another member pointed out that SegWit had undergone extensive testing and review on various testnets.There were also discussions about the status of wallet developer updates for SegWit support. Some developers had already worked on SegWit support, but concerns were raised about inadequate testing and vetting. In addition, there were concerns about potential network splits and the need for an extended "fallow period" to ensure safety. However, some members dismissed these concerns and insisted that the safety period should not be extended.The discussion also mentioned the controversy surrounding the implementation of SegWit and the objections raised by some members. Despite this, most underlying libraries have already been adapted or are being adapted for SegWit. However, since SegWit is not yet live on mainnet, most libraries cannot release their SegWit supported versions until it is released as final. Companies are already planning to update their services for SegWit, but the actual state of wallet readiness may not be accurately reflected.Overall, the discussion on the Bitcoin-dev mailing list revolved around the safety measures for deploying SegWit, concerns about potential issues, and the readiness of wallet developers to support SegWit. There were differing opinions on the need for a longer grace period and the risks associated with the changes in SegWit. The debate highlighted the complexity and controversy surrounding the implementation of this upgrade.Tom Zander, a developer, has raised concerns about the deployment of SegWit, stating that using BIP9 to shorten the grace period is risky. He argues that once deployed, the feature cannot be rolled back, potentially turning all transactions into everyone-can-spend transactions. Zander believes that there is no need to use BIP9 and that stalling the process for two months does not improve security.In response, developer Jorge Timón argues that changing BIP9's initial date would not benefit those who have not yet started working on supporting SegWit. Zander suggests that if the reason for the short activation timespan is the use of BIP9, then it should not be used at all.There are objections to the implementation of SegWit due to its long wait time and the fact that some wallets are taking a "wait and see" approach. The majority of wallets are not ready for SegWit, leading to reservations about investing resources in adding support for a feature that may not be activated. Flexible Transactions has been proposed as a safer alternative, but its activation is dependent on whether it is locked in.The deployment of Segregated Witness (SegWit) has faced objections, with some wallets adopting a cautious approach. This is because most wallets are not prepared for SegWit activation, and they may not want to allocate resources to a feature that may never be activated. Flexible Transactions has been suggested as an alternative, but it remains uncertain which option will ultimately be activated.Bitcoin Core's 0.13.1 release includes segregated witness for Bitcoin mainnet after extensive testing. Setting BIP 141's start time to November 15, 2016, was proposed, following the recommendation to set the versionbits start time a month in the future. Activation on the network requires passing this date, a full retarget window of 2016 blocks with 95% signaling the version bit (bit 1 for BIP141), and a fallow period of another 2016 blocks.SPV wallets will continue to function normally without upgrading, as full nodes will provide transactions in a format they understand. However, end users may want to upgrade to benefit from lower transaction fees. Tom Zander suggests a minimum of two months for the fallow period, as this upgrade affects both businesses and end users.Gavin Andresen conducted a survey on how long it would take businesses and individuals to upgrade to a new release, with no one responding that it would take more than two weeks. He believes that those running their own validation code should be able to mitigate any risks associated with SegWit activation.
Updated on: 2023-08-01T19:11:28.846432+00:00