Once #33 merges we will have the ability to attach state commitments to Simplicity programs. However, there are some ergonomic issues here because adding a state commitment (and changing the state) will change the generated address, and the user must invoke everything with a consistent state commitment to avoid bad things happening.
First,
- The output of
hal-simplicity info should clearly indicate whether there is a state commitment alongside the CMR.
Then update-input has several ways it can be improved.
- The output of
hal-simplicity update-input should warn if you provide an input UTXO but no CMR. (This is actually unrelated to state.)
- The output of
hal-simplicity update-input should error if you provide state but no CMR (in this case currently it just silently ignores the state which is nasty)
- The output of
hal-simplicity update-input should warn better if you provide the wrong/missing state. (The existing message is not bad, but it doesn't output the state.)
Once #33 merges we will have the ability to attach state commitments to Simplicity programs. However, there are some ergonomic issues here because adding a state commitment (and changing the state) will change the generated address, and the user must invoke everything with a consistent state commitment to avoid bad things happening.
First,
hal-simplicity infoshould clearly indicate whether there is a state commitment alongside the CMR.Then
update-inputhas several ways it can be improved.hal-simplicity update-inputshould warn if you provide an input UTXO but no CMR. (This is actually unrelated to state.)hal-simplicity update-inputshould error if you provide state but no CMR (in this case currently it just silently ignores the state which is nasty)hal-simplicity update-inputshould warn better if you provide the wrong/missing state. (The existing message is not bad, but it doesn't output the state.)