While there were differing opinions on whether hardforks should be completely avoided, one proposal suggested changing the block header format to include both SHA-256 and SHA-3 hashes. This would allow new nodes to see the correct SHA-3 hashes if SHA-256 were to be broken in the future. It was also mentioned that the Merkle Tree could be changed to use SHA3 instead. However, it was noted that making changes to the block header format and proof-of-work computation may require a hardfork. Despite this, the coinbase allows for new commitments to be added, similar to SegWit's witness field.The discussion emphasized the challenges and hurdles that any hardfork would have to go through, similar to what Taproot and SegWit experienced. Any hardfork would require more engineering manpower and several years of work before being considered. The conversation provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. Interested individuals were also invited to join the conversation by signing up for the mailing list. Another discussion on the bitcoin-dev mailing list explored the limitations and possibilities of implementing softforks. It was noted that while significant changes can be made to transaction and block formats with softforks, there are limitations to what can be changed. The block header format and how proof-of-work is computed from it cannot be changed without a hardfork. The discussion highlighted the hurdles that any hardfork would have to overcome, as seen with SegWit and Taproot. Hardforks would require more engineering manpower and several years of work. The conclusion was that it is important to work with the existing system or start working on future solutions today.A user on the mailing list pointed out that the space of possible softforks is wider than expected. They discussed the potential for changes to block discovery rates and cited SegWit as an example of massive changes that can be made with softforks. However, they noted that the block header format and proof-of-work computation cannot be usefully changed with softforks. The discussion also highlighted the importance of Taproot's implementation and deployment, which took time due to controversy surrounding the activation code. It was emphasized that any hardfork would have to go through similar hurdles and must be prepared to work on it for several years. The discussion concluded by emphasizing the need to find solutions for future problems and mentioned the existence of an "emergency" branch for adding post-quantum signature schemes in case of a quantum break.In another email exchange, the topic of consensus protocol changes in Bitcoin was discussed. One participant argued that hard forks are required for hard consensus changes, while soft forks can be useful. Another participant disagreed and highlighted the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. They mentioned examples like relative lock time verify and SegWit, which have made lightning transactions easier and more efficient. The discussion touched upon the role of hard forks and soft forks in implementing these changes, as well as the ongoing debate within the Bitcoin community about the balance between stability and adapting to changing user needs.Overall, the email exchanges provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. They highlighted the challenges and limitations of implementing changes through softforks, the hurdles that any hardfork would have to overcome, and the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs.