How stable is the miniscript implementation in terms of the generated script?

[thomaseizinger]

While playing around with the policy compiler, I noticed that the generated script has some cool optimizations! At the same time, I was quite surprised in the way it was structured.

For our trustless atomic swap usecase, we need to infer, what the HTLC address will be that the other party will lock the funds on. For this, we currently rely on a static HTLC script which allows us to deterministically compute the HTLC address given the parameter (identities, secret-hash and expiry).

My question is, how stable is miniscript in terms of the generated script? If we were to define our Bitcoin-HTLCs through miniscript, we somehow have to ensure that two versions of the software generate the same underlying script (resulting in the same address).

What is the versioning policy of miniscript in regards to that? Are changes to the generated script considered breaking changes? Can we rely on the generated script being the same across future versions?

[thomaseizinger]

Something just crossed my mind. There is actually two different parts in play here: policies and the miniscript.

Am I correct in assuming that a conversion from miniscript to actual Bitcoin script is (fairly) stable? On the contrary, newer versions of (rust)-miniscript could ship an improved policy compiler that generates a more efficient miniscript?

Hence, one could rely on the generated miniscript but not on the policy?

[sanket1729]

Hi @thomaseizinger,

how stable is miniscript in terms of the generated script? There is one to one mapping between Miniscript and the generated bitcoin script, so it is 100% guaranteed to have minisicript = miniscript.encode().decode(). The encode and decode functions are deterministic and will not change. (unless we change miniscript language entirely)

Currently, the Miniscript compiler produces the most optimal compilation in terms of average satisfaction costs, but the compiler internal uses non-deterministic HashMap traversal, it might produce two different compilations of the same average satisfaction cost. So, it is not advised to rely on policy compiler producing the same results.

I don't foresee any changes to the script-encoding and hence encoding/decoding is deterministic and stable. However, I will leave @apoelstra to comment on the exact mechanism for versioning policy.

Hence, one could rely on the generated miniscript but not on the policy? You should only use the compiler once to create the corresponding Miniscript, and rely on that Miniscript to for your use-cases.

[thomaseizinger]

You should only use the compiler once to create the corresponding Miniscript, and rely on that Miniscript to for your use-cases.

Thanks! Will do that :)

[apoelstra]

The mapping between Miniscript and Script will never change. (At least, not without a major version bump of this library and at this point, probably a "Miniscript 2" which is billed as a different language.)

As Sanket says, the mapping from policy to miniscript may change even between successive runs of the compiler :)