You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mintscript module is currently only used internally for verifying transactions. It is, however, designed with the possibility of putting it on chain in mind. This allows users of the blockchain to place custom spending conditions on UTXOs.
Here is a rough and probably incomplete outline of steps needed to achieve it.
Make script encodable
Encoding has to be picked. Putting Encode and Decode derive traits on script types should work fine as a starting point. Since script is a recursive data structure, a maximum depth limit should be probably imposed. There seems to be some support for this in SCALE.
Script commitment
It is most likely not a good idea to place script spending conditions directly into outputs. Rather, only a hash-commitment for spending conditions should be in the output. The full script is revealed when spent by placing it into the witness part of the transaction.
The commitment hash contains parts of the script that specify spending conditions:
For signatures, it's pubkey/destination. Signature is omitted.
For hashlocks, it's the hash challenge, not preimage
Timelocks are committed completely.
For thresholds, the number of required conditions, the total number conditions (may need some extra thought) and the merkle root of the conditions is comitted.
When spending, the commitment calculated from revealed script must be checked against the one specified in the output.
Threshold
It makes sense to only reveal the threshold conditions the spender wishes to satisfy for threshold conditions. This could be done by reusing the merkle multiproofs currently being used for multisig.
The DissatisfiedScript type is currently a placeholder for conditions the spender does not wish to (or can't) satisfy. With the merkle construction, the dissatisfied conditions are represented simply by the pruned out branches of the merkle tree.
Achieving a degree of compatibility with Bitcoin
The constructs available in mintscript closely follow the ones included in Bitcoin miniscript. It should be possible, with some effort put into the appropriate tooling, to translate miniscript into mintscript which provides a pipeline for translating a well-behaved subset of bitcoin scripts to equivalent spending conditions on Mintlayer.
Remarks
These are just ideas / suggestions, this will sure be a subject of intense subsequent discussion. Just sketching out the initial proposal.
The text was updated successfully, but these errors were encountered:
The
mintscript
module is currently only used internally for verifying transactions. It is, however, designed with the possibility of putting it on chain in mind. This allows users of the blockchain to place custom spending conditions on UTXOs.Here is a rough and probably incomplete outline of steps needed to achieve it.
Make script encodable
Encoding has to be picked. Putting
Encode
andDecode
derive traits on script types should work fine as a starting point. Since script is a recursive data structure, a maximum depth limit should be probably imposed. There seems to be some support for this in SCALE.Script commitment
It is most likely not a good idea to place script spending conditions directly into outputs. Rather, only a hash-commitment for spending conditions should be in the output. The full script is revealed when spent by placing it into the witness part of the transaction.
The commitment hash contains parts of the script that specify spending conditions:
When spending, the commitment calculated from revealed script must be checked against the one specified in the output.
Threshold
It makes sense to only reveal the threshold conditions the spender wishes to satisfy for threshold conditions. This could be done by reusing the merkle multiproofs currently being used for multisig.
The
DissatisfiedScript
type is currently a placeholder for conditions the spender does not wish to (or can't) satisfy. With the merkle construction, the dissatisfied conditions are represented simply by the pruned out branches of the merkle tree.Achieving a degree of compatibility with Bitcoin
The constructs available in
mintscript
closely follow the ones included in Bitcoin miniscript. It should be possible, with some effort put into the appropriate tooling, to translate miniscript into mintscript which provides a pipeline for translating a well-behaved subset of bitcoin scripts to equivalent spending conditions on Mintlayer.Remarks
These are just ideas / suggestions, this will sure be a subject of intense subsequent discussion. Just sketching out the initial proposal.
The text was updated successfully, but these errors were encountered: