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
Start from this disscusion, I dive into gnokey command and find out somethings that weird with Sign() and Verify()
cc: @zivkovicmilos@leohhhn
Definition: Verify: To verify a transaction signature is correct Sign: To Sign the document.
Then adds some informations of tx: tx.Fee, tx.Msgs, tx.Memo (from the file.tx) to contruct a SignDoc data.
This SignDoc data will be sorted and marshaled to a []byte signBytes message.
The sign() function will take this final message as a message to sign.
Then the sign() signs this msg, with the corresponse keys, and then writes it (append) into the originial file.tx.
Problems:
The problem is here. The Verify() now take the whole file.tx after signed as input to verify. So, there are things that we should make it clearer: (which I think currently not work)
This Verify() will not works as if its input is the whole file after signed because file.tx is already changed and different from the signBytes. AFAIK we should have same message hash for sign and verify (?)
Since it is an oneway function, and the additional information which is added into the tx.GetSignBytes() comes from command, how to reconstruct the original signBytes to verify?
If we not need to / can not recontruct the orignal signBytes, then should we expose the signedMessage ?
Where can user take the hex format to feed the Verify command. And since the Sign() writes with signature (JSON encoded) into the file.tx, can we remove this argument?
WIP:
I am currently working around this and something relates. I am really looking to hearing from all of you.
The text was updated successfully, but these errors were encountered:
I can reconstruct the messageHash with chainID, account-number and account-sequence.
Should I query for it or just take it as arguments of Verify command? @zivkovicmilos.
Description
Start from this disscusion, I dive into gnokey command and find out somethings that weird with
Sign()
andVerify()
cc: @zivkovicmilos @leohhhn
Definition:
Verify
: To verify a transaction signature is correctSign
: To Sign the document.Lets say we save our transaction into
file.tx
.Then sign it with:
There is a
tx.GetSignBytes()
that is used insideSign()
gathers arguments from command, in thesignOptions
:Then adds some informations of tx:
tx.Fee
,tx.Msgs
,tx.Memo
(from thefile.tx
) to contruct aSignDoc
data.This
SignDoc
data will be sorted and marshaled to a []bytesignBytes
message.The
sign()
function will take this final message as a message to sign.Then the
sign()
signs this msg, with the corresponse keys, and then writes it (append) into the originialfile.tx
.Problems:
The problem is here. The
Verify()
now take the wholefile.tx
after signed as input to verify. So, there are things that we should make it clearer: (which I think currently not work)This
Verify()
will not works as if its input is the whole file after signed becausefile.tx
is already changed and different from thesignBytes
. AFAIK we should have samemessage hash
for sign and verify (?)Since it is an oneway function, and the additional information which is added into the
tx.GetSignBytes()
comes from command, how to reconstruct the originalsignBytes
to verify?If we not need to / can not recontruct the orignal
signBytes
, then should we expose thesignedMessage
?Where can user take the hex format to feed the
Verify
command. And since theSign()
writes with signature (JSON encoded) into thefile.tx
, can we remove this argument?WIP:
I am currently working around this and something relates. I am really looking to hearing from all of you.
The text was updated successfully, but these errors were encountered: