A simpler but slightly inefficient solution might be to retraverse the tree again. I am not against doing this because we are already traversing the tree once when translating.

@sanket1729 I advise caching because the function could have interior mutable state and lie to you...

@JeremyRubin, We can call the translate function only once and save the output policy/miniscript which possibly contains duplicate keys. Do the checks again on the translated miniscript/policy.

Am I missing something or are you looking for an efficient way to it while creating(one traversal) while aborting at the first duplicate?

Ah, certainly doing full checks after translating is the safest choice, but I think given that most functions are probably just getters around a map might make sense to do something just passing a map in. I'm for whatever works and closes the safety hole.

When you said 'retraverse' I thought you meant while translating in a manner that calls the function more than once per key. (Interestingly this sort of trick could be used to translate a duplicated-key script to non duplicated if it uses e.g. sequential HD derivation per call per key)

Planning to cleanly address this after #493.

@sanket1729 reminder now that #493 is merged. I just experimented with this library and was quite confused why there was no error with duplicate keys present.

@benma. Are you facing the no error when translating keys using TranslatePk? This is fixed in #556. All regular methods from_str, parse, compile etc should currently be fail on duplicated keys.

@benma. Are you facing the no error when translating keys using TranslatePk?

Yes exactly. Thanks for the fix.