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
As I've been implementing KIP 15 I have noticed the following potential issues.
It is 100% possible that the sigs become "detached" or not match the actual signers list in the Pact Command.
If a wallet holds multiple keys that a CommandSigData specifies in its sigs list, it should sign multiple times, but there isn't an QuicksignOutcome specified for this, nor it there an QuicksignOutcome if one signature succeeds but another fails.
For problem number 2, it should be easy enough to specify how the wallet should respond if multiple signatures are attached to the same CommandSigData.
I am not sure how it should respond if one sig fails and another succeeds however.
Changing it to have a list of QuicksignOutcomes associated with the CommandSigData would resolve this issue entirely.
And this issue might be something we don't care about: What's the likelihood of a wallet having two private keys required by Quicksign? Likely pretty low... But I would personally take it into account nonetheless.
For problem number 2, each library has to implement a sanity check to make sure the signers list of the Pact Command Payload actually matches the sigs list of the CommandSigData.
Floppie brought this up to me, and I agree:
It would be simpler, in the long term, to just send Pact Commands and use those to determine if more signatures are required by comparing the signers in the Pact Command Payload with the sigs in the Pact Command.
All I have to do is send this to a wallet, they can deserialize the json, and check the signers list to see if they have a matching public key.
If they do, they sign, and add their sig to the sigs list.
Then return the Pact Command with the hash and new sigs attached:
Granted, this doesn't allow for what QuicksignOutcome allows for, but I feel like you can likely create some kind of structure that works in exactly the same way to give errors/feedback to the user.
Building things in this manner would:
Remove the potential of the sigs to get desynced from the signers
Make it possible for dApps to immediately use the result with the Pact API.
Both of the above are current hurdles with Quicksign as it stands.
Perhaps I should make a new KIP for the above...
The text was updated successfully, but these errors were encountered:
alber70g
changed the title
KIP15 Problems
Potential Issues and Proposed Solution for Implementing KIP 15: Ensuring Synchronization Between sigs and signers in Pact Commands
Jun 8, 2023
As I've been implementing KIP 15 I have noticed the following potential issues.
sigs
become "detached" or not match the actualsigners
list in the Pact Command.CommandSigData
specifies in itssigs
list, it should sign multiple times, but there isn't anQuicksignOutcome
specified for this, nor it there anQuicksignOutcome
if one signature succeeds but another fails.For problem number 2, it should be easy enough to specify how the wallet should respond if multiple signatures are attached to the same CommandSigData.
I am not sure how it should respond if one sig fails and another succeeds however.
Changing it to have a list of
QuicksignOutcome
s associated with the CommandSigData would resolve this issue entirely.And this issue might be something we don't care about: What's the likelihood of a wallet having two private keys required by Quicksign? Likely pretty low... But I would personally take it into account nonetheless.
For problem number 2, each library has to implement a sanity check to make sure the
signers
list of the Pact Command Payload actually matches thesigs
list of theCommandSigData
.Floppie brought this up to me, and I agree:
It would be simpler, in the long term, to just send Pact Commands and use those to determine if more signatures are required by comparing the
signers
in the Pact Command Payload with thesigs
in the Pact Command.An example of a Pact Command:
All I have to do is send this to a wallet, they can deserialize the json, and check the signers list to see if they have a matching public key.
If they do, they sign, and add their sig to the sigs list.
Then return the Pact Command with the hash and new sigs attached:
Granted, this doesn't allow for what
QuicksignOutcome
allows for, but I feel like you can likely create some kind of structure that works in exactly the same way to give errors/feedback to the user.Building things in this manner would:
sigs
to get desynced from thesigners
Both of the above are current hurdles with Quicksign as it stands.
Perhaps I should make a new KIP for the above...
The text was updated successfully, but these errors were encountered: