Breaking change in calculation of hash_serialized_2

The email discusses the possibility of considering an option that was not previously considered in a proposal. The sender mentions that they could not find any reference to this option in the original proposal and cannot recall it being discussed since they started following the project closely in 2020. The reasons for this could be as follows:1. If the serialization and hashing of the UTXO (Unspent Transaction Output) set works as intended, the existing hash should be sufficient. The sender mentions that the hash_serialized_2 has been assumed to be robust and has been around for a long time, so it may have been seen as additional overhead to introduce a new hash.2. There might be a need to optimize the serialization of data to files further, by adding compression or other techniques, in order to have smaller files that represent the same UTXO set. This would avoid the need to change the chainparams that commit to the UTXO set or potentially have multiple file hashes for the same block.3. Another possibility is to explore other file hashing strategies that are more optimized for peer-to-peer sharing of the UTXO snapshots. The idea of peer-to-peer sharing of the UTXO set has always been part of the assumption, but it hasn't been extensively explored yet.To delve deeper into this topic, the sender suggests referring to a conversation on IRC (Internet Relay Chat) that took place during a meeting between sipa, aj, and others. The links [2] and [3] provided in the email can be followed to access this conversation.In conclusion, the email brings up the possibility of considering an option that was not previously discussed in a proposal. The reasons for not considering this option could be related to the effectiveness of the existing hash, the need for further optimization of data serialization, and potential exploration of alternative file hashing strategies for peer-to-peer sharing.