While some suggest that softforks may be sufficient for achieving the desired changes, others argue that hardforks should not be completely avoided.One proposal discussed in the thread was to change the block header format to include both SHA-256 and SHA-3 hashes in the same place. This would allow new nodes to see the correct SHA-3 hashes if SHA-256 were to be fully broken in the future. It was suggested that the Merkle Tree could also be changed to use SHA3 instead, by requiring miners to embed a commitment to the SHA3-Merkle-Tree on the coinbase of the "original" block format.However, it was noted that this definition of "softfork" requires "> 50% of miners to pull everyone to the fork". Additionally, the block header format and how proof-of-work is computed from the block header may not be easily changed through a softfork. Despite these limitations, the flexibility of the coinbase allows for new commitments to be added to new Merkle Trees, which can annotate transactions with additional information that is invisible to unupgraded nodes. This is similar to the witness field of SegWit transactions.It was emphasized that any hardforks would have to go through the hurdles that Taproot and SegWit had to go through but will also have to pass through the much higher hurdle of being a hardfork. Therefore, anyone contemplating a hardfork must be prepared to work on it for several years before anyone even considers it.The email thread provides valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. The link to the mailing list's signup page has also been shared for interested individuals to join the conversation.