-
Notifications
You must be signed in to change notification settings - Fork 4
feat: Add Move Authenticator support #442
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
base: develop
Are you sure you want to change the base?
Conversation
| /// and optionally wait for finalization. | ||
| pub async fn execute_with_move_authenticator<I: PTBArgumentList>( | ||
| mut self, | ||
| fn_call: MoveAuthenticatorFnCall<I>, |
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.
Do you think this can be a Signer from #445?
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.
I did think about that. The problem is that the inputs need to be resolved from the transaction but we can only do that before the transaction is finished since we need information from the builder.
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.
the inputs need to be resolved from the transaction
Can you elaborate on that? What data is only available from the builder but not from the built tx?
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.
Basically the inputs to the auth fn must end up being inputs in the transaction, and we can't do that if we build the transaction first. Or at least it would not be as simple. We would have to have a whole separate process to amend the transaction with these inputs and again ensure that everythin is valid. So, probably possible but also probably quite complex. Still, I can give it a try later if you want.
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.
inputs to the auth fn must end up being inputs in the transaction
This is not the case, so we can simplify
b9e9baa to
48cab0d
Compare
7d758a3 to
e9b223d
Compare
| } | ||
| } | ||
|
|
||
| impl PartialEq<&IdentifierRef> for Identifier { |
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.
I'm actually not sure why this is needed, to investigate
Description
Adds support for authenticating using an Abstract Account via a move authorization function. This PR adds basic support for constructing a Move Authenticator variant of the
UserSignatureand also convenience function to execute a transaction builder with the appropriate data.Closes iotaledger/iota#9407