-
Notifications
You must be signed in to change notification settings - Fork 23
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
Extra HashableScriptData
in TxBody
for PK inputs and reference inputs with hashed datums.
#637
Conversation
data PrivateKeyWitness witctx era where | ||
PrivateKeyWitness | ||
:: KeyDatum witctx | ||
-> PrivateKeyWitness witctx era |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make this not a GADT? I know there are lots of them floating around but we are actually moving away from using GADTs when not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes i can. I basically just mimicked how other types around were defined. But indeed GADTs are not necessary there.
data KeyDatum witctx where | ||
KeyDatumForTxIn :: Maybe HashableScriptData -> KeyDatum WitCtxTxIn | ||
NoKeyDatumForStake :: KeyDatum WitCtxStake |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make this not a GADT? I know there are lots of them floating around but we are actually moving away from using GADTs when not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this is not the cleanest approach to add this functionality. Myself and my team will handle this. Thank you for the attempt!
@Jimbo4350 I barely started and I was in need for feedback in case there was a better way to approach this, but that's fine by me if you handle it. |
This PR aims to solve issue #600 by allowing users to provide instances of
HashableScriptData
for hashed datums located:For now, these data can only be provided:
This contribution intends to be as little invasive as possible, and to respect the current way of handling the creation of the data map provided in the script context. The map is currently built by browsing through the relevant parts of the body content and retrieving the relevant data there. Thus, the idea here is not to create a new field in the body content, but instead to allow user to add additional
HashableScriptData
at two addition locations in the body content.