Simple browser extension for managing Polkadot and Substrate network accounts in a browser. Allows the signing of extrinsics using these accounts. Also provides a simple interface for compliant extensions for dapps.
Apache License 2.0
965
stars
403
forks
source link
Sign arbitrary data using a specified signature algorithm #1292
What is the current behavior and expected behavior?
When calling signRaw or signPayload on a Signer using the extension, the keyring pair type seems to be selected by the extension(what the user has configured or substrate default) and in cases where you want to use the users private-key/seed to generate a deterministic signature, accounts using the sr25519 type isn't a viable approach.
What is the motivation for changing the behavior?
We need to generate a deterministic signature using the users private key stored in the extension to generate a salt that is used to authenticate the users submission in a two step extrinsic submission process.
This is related to the new court implementation on zeitgeist where the user votes in secret and later reveals their vote.
For reference here is the kleros implementation outlined:
As currently implemented in the existing Kleros interface, the salt is generated by having the user use their Ethereum private key to sign a block of text that includes an identifier for the specific dispute. Then this salt is always recoverable from the main key by resigning the same text. Nonetheless, the signatures on this text with different keys will be different and are computationally infeasible to obtain without the user’s private key under the assumption of the security of the signature algorithm. Thus, a juror is prevented from copying the commitment of others. Nevertheless, if a user deletes her salt from her local memory, she can regenerate it as long as she retains access to her private key.
Wanted feature:
To be able to specify the type ethereum or other deterministic algorithm when signing arbitrary pieces of data using the wallet extension. In the assumption that the extension can use the same seed to generate the needed KeyringPair to sign the data.
I'm submitting a ...
What is the current behavior and expected behavior?
When calling
signRaworsignPayloadon aSignerusing the extension, the keyring pair type seems to be selected by the extension(what the user has configured or substrate default) and in cases where you want to use the users private-key/seed to generate a deterministic signature, accounts using thesr25519type isn't a viable approach.We need to generate a deterministic signature using the users private key stored in the extension to generate a salt that is used to authenticate the users submission in a two step extrinsic submission process.
This is related to the new court implementation on zeitgeist where the user votes in secret and later reveals their vote. For reference here is the kleros implementation outlined:
To be able to specify the type
ethereumor other deterministic algorithm when signing arbitrary pieces of data using the wallet extension. In the assumption that the extension can use the same seed to generate the neededKeyringPairto sign the data.