Published on: 2017-07-14T21:11:07+00:00
A discussion on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation in Bitcoin Core releases prior to 0.13.1. The conversation began with a user named Dan Libby expressing his desire to avoid segwit activation until he felt comfortable with it. However, Gregory Maxwell pointed out that disabling segwit activation is not a simple task and is also an unsupported configuration. Another respondent criticized Maxwell's attitude, warning that it could lead to Bitcoin Core being dropped and multiple competing implementations emerging.One of the concerns raised by Libby was the difficulty in maintaining and reading the consensus-critical code with segwit, as less than one third of it is visible on-screen. He suggested that users should have the ability to firewall off the code to ensure they are not running segwit. Another issue discussed was the risk for those using legacy clients, as segwit transactions can appear as "anyone-can-spend" outputs from their perspective. This vulnerability creates a risk for "zero confirm" transactions. One proposed solution was to avoid any transaction chain that contains a segwit transaction, but this would require everyone they transact with to follow the same rule.The conversation then shifted to the topic of achieving full security in bitcoin transactions. The recipient expressed uncertainty about how to achieve this, given that anyone they have transacted with can send them coins at any time. One option suggested was to run a node that has never published an address to a third party. Another option was to modify their own node to reject segwit transactions, but this would hardfork the network. It was also mentioned that it may be possible to construct a "certain balance" and an "uncertain balance" without modifying any rules.Hampus Sjöberg provided further clarification, explaining that there are two ways to be fully secure regarding chain transactions. The first option is to validate using the new rules of the network by running a segwit node. The second option is to avoid any transaction chain that contains a segwit transaction. He explained that the witness program in segwit transactions is encoded in a new format that old nodes do not understand, so for old nodes, a number greater than zero will be counted as a valid spend.The implications of not upgrading to a segwit compliant node were discussed. It was noted that if the majority of the network adopts segwit, non-segwit nodes would be downgraded to near-SPV node validation and may not be able to fully verify the ownership of bitcoins. It was also mentioned that even if one does not upgrade to segwit, they cannot avoid receiving UTXOs that were previously encumbered by a segwit output. However, it was suggested that continuing with a lower bandwidth cap and keeping coins "untainted" could be an experiment worth considering.Another point raised in the discussion was the desire to disable enforcement of segwit rules. It was explained that individuals cannot control the collective action of the bitcoin ecosystem to start enforcing the rules after a sufficient number of miners signal support. Disabling segwit enforcement could result in accepting blocks that nobody else in the network would accept, leading to a higher risk of double spends.The reasons for not wanting to run a segwit compliant node were also discussed. One reason mentioned was the potential increase in bandwidth requirements for segwit transactions. It was suggested that those not interested in segwit transactions may prefer to keep their node lower-cost by running a non-segwit node. However, it was noted that if the majority of the network adopts segwit, it would be in their best interest to validate those transactions.In summary, the conversation on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation and the implications of not upgrading to a segwit compliant node. Various concerns and suggestions were raised regarding security, validation, bandwidth requirements, and maintaining backward compatibility. The discussion provided different perspectives and considerations for users who may be interested in or hesitant about adopting segwit.
Updated on: 2023-08-01T21:21:38.347917+00:00