Recently a big criticism has been made about it changes in the BIP 85 repository. For those unfamiliar with the BIP, it is a very simple scheme to generate new word seeds based on an inference path in a pre-existing word seed you have. The logic of the BIP is to allow people who use multiple wallets to manage the chaos of maintaining individual isolated backups for numerous wallets.
By generating new seeds based on the entropy of an inference path, users can simply create a single backup of one ‘master’ word seed, and from there regenerate any child seed from that master word. One backup and you can have as many independent word seeds as you need. They are even safe to carry around, import into different devices or wallets, and there is no risk of compromising the master seed or the coins stored on it.
There is cryptographically no way to go back from a child seed to the master seed, even if it were compromised. This design makes it very safe to use multiple independent seeds/wallets, while streamlining the process of backups to prevent loss.
The BIP has been updated to follow a pull request suggestion which clarifies numerous things, but the most significant change was a change in the way the actual underlying keys were generated, ostensibly to follow the specification in BIP 32 ( which describes how to generate keys using derivation paths in HD wallets) which BIP 85 strictly speaking did not do. This would have resulted in the same BIP 85 paths generating different keys than under the current specification. This is a groundbreaking change.
If it was implemented in the new specification by any project, it would not properly generate old BIP 85 seeds that users had already generated and sent money to. This would mean that this money would be “lost” in the sense that the update wallets would no longer properly generate keys to get people’s money if they lost a copy of the previously generated seed.
However, the reality is that no wallet would have implemented this feature, or if they had, they would have done it in a way to support both methods, because they already have users in the world who have generated seeds using of the old specification. Wallet and device manufacturers would not make a change that would only hinder users’ ability to get existing funds back; that’s just not in their best interest.
The only thing this incident has shown is a lack of communication, nothing more. There was no real risk of anything breaking out that would impact users. Projects that implemented BIP 85 made no changes; nothing happened except a technical document was changed. It was even rolled back to remove the change immediately following public opposition to the nature of the change and the lack of communication between developers and projects actually implementing the BIP.
People need to stop blaming these types of communication errors, which have no real consequences, as examples of nefarious intentions or a profound lack of competence. It was simply a mistake, which can be learned from by improving communication between developers and project managers in the future, and which caused no real harm to anyone.
Blowing up molehills in mountains like these serves no one in this space, and does nothing to improve real problems with communication and coordination in space. Contextualizing it correctly in a productive, civil way so that people can learn how to deal with these things.