Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] - Script context validity interval inequality failure #4172

Open
CarlosLopezDeLara opened this issue Jul 12, 2022 · 2 comments
Open

[BUG] - Script context validity interval inequality failure #4172

CarlosLopezDeLara opened this issue Jul 12, 2022 · 2 comments
Assignees
Labels
bug Something isn't working era: babbage priority: critical Requires immediate attention. Critical issue that needs to be fixed ASAP and released as hotfix. priority highest issues to be worked on immediately tag: 1.35.1 type: blocker Major issue, the tagged version cannot be released user type: internal Created by an IOG employee

Comments

@CarlosLopezDeLara
Copy link
Contributor

Unable to test for inequality between validity intervals

@CarlosLopezDeLara CarlosLopezDeLara added bug Something isn't working priority highest issues to be worked on immediately Vasil_blocker labels Jul 12, 2022
@Jimbo4350
Copy link
Contributor

Jimbo4350 commented Jul 12, 2022

Checking for inequality between a POSIXTimeRange in my custom redeemer and the txInfoValidRange fails unexpectedly. We know that the POSIXTimeRange created in my redeemer is a little behind the txInfoValidRange in the ScriptContext so we expect these two values are not equivalent. We further provide evidence for this because asserting their equality causes script execution to fail. Therefore asserting inequality (/=) should result in the plutus script successfully executing however this is not the case, it also fails.

To narrow down where the problem is coming from, I asked @james-iohk to create plutus scripts that check the following conditions (separately): txInfoValidRange txInfo == txInfoValidRange txInfo, txInfoValidRange txInfo /= txInfoValidRange txInfo, txInfoValidRange txInfo /= (txInfoValidRange txInfo + moreTime)

They appear to all work as expected

It appears to be working as I expect. I've tried these txInfoValidRange txInfo == txInfoValidRange txInfo,
V1 ✅
V2 ✅
txInfoValidRange txInfo /= txInfoValidRange txInfo
V1 ✅ correctly fails validation
V2 ✅ correctly fails validation
txInfoValidRange txInfo /= always
V1 ✅
V2 ✅

And for the case of txInfoValidRange txInfo /= (txInfoValidRange txInfo + moreTime)

this validator can be used to prove inequivalence is working by extending the timerange by whatever integer is passed as redeemer. It correctly fails validation when redeemer is 0 and passes when redeemer is greater or less than 0.

Therefore this points to the conversion of POSIXTimeRange to/from Data
via my functions:

customRedeemerToScriptData :: AnyCustomRedeemer -> ScriptData
customRedeemerToScriptData (AnyPV1CustomRedeemer cRedeem) =
  fromPlutusData $ V1.toData cRedeem
customRedeemerToScriptData (AnyPV2CustomRedeemer cRedeem) =
  fromPlutusData $ V2.toData cRedeem

and in transaction construction:

toAlonzoData :: ScriptData -> Alonzo.Data ledgerera
toAlonzoData = Alonzo.Data . toPlutusData

It is strange that all of the other fields in my redeemer behave normally with the exception of POSIXTimeRange. I am unable to diagnose this problem any further without involving ledger and/or plutus

@Jimbo4350
Copy link
Contributor

Jimbo4350 commented Jul 15, 2022

I'm good to close this because I've asked @james-iohk to try out some more scenarios and we can't reproduce it. My main concern was not being able to pass POSIXTimeRanges via a redeemer but this has been shown to be possible.

@Jimbo4350 Jimbo4350 reopened this Sep 15, 2022
@dorin100 dorin100 added type: blocker Major issue, the tagged version cannot be released priority: critical Requires immediate attention. Critical issue that needs to be fixed ASAP and released as hotfix. user type: internal Created by an IOG employee era: babbage tag: 1.35.1 labels Oct 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working era: babbage priority: critical Requires immediate attention. Critical issue that needs to be fixed ASAP and released as hotfix. priority highest issues to be worked on immediately tag: 1.35.1 type: blocker Major issue, the tagged version cannot be released user type: internal Created by an IOG employee
Projects
None yet
Development

No branches or pull requests

3 participants