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
Currently we hard code Marlowe hash into the script which tightly couples the script to the main validator version. This approach has significant downsides:
The script cannot be reused between different versions of Marlowe validator.
We cannot use the hash of Open Role validator in an internal double spending white list of the Marlowe validator.
I propose:
Change to the logic of the script so it authorizes release of the locked role token solely based on the presence of the thread token in some of the tx inputs.
We can add slight optimization to the script. Let's accept optional redeemer which provides an index of the Marlowe input to speed up the check.
The text was updated successfully, but these errors were encountered:
It doesn't seem to influence the security. Thread token should guard uniqueness of the Marlowe itself. Maybe we can observe as slight decrease in the script performance.
@bwbush, could you please tell me what is your opinion on that?
Currently we hard code Marlowe hash into the script which tightly couples the script to the main validator version. This approach has significant downsides:
The script cannot be reused between different versions of Marlowe validator.
We cannot use the hash of Open Role validator in an internal double spending white list of the Marlowe validator.
I propose:
Change to the logic of the script so it authorizes release of the locked role token solely based on the presence of the thread token in some of the tx inputs.
We can add slight optimization to the script. Let's accept optional redeemer which provides an index of the Marlowe input to speed up the check.
The text was updated successfully, but these errors were encountered: