Published on: 2021-04-08T11:11:06+00:00
In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks.
Updated on: 2023-08-02T03:29:44.650329+00:00