-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Is the conversion of transaction signer to stackitem implemented as intended? #2705
Comments
Agree, the first version only wanted the binary, now it's not required |
I think we can keep the binary data for convenience. |
To me it's just duplicating for no good reason, interpreting these bytes is time-consuming and error-prone activity that is easily avoided by using proper stack item representation (which we already have anyway). |
In some cases, we can use a single |
What do you think? We need to decide before 3.3.0 is released. |
Problem description
#2685 introduces new
GetTransactionSigners
method to native Ledger. Take a look at the way how each signer is converted to stackitem: the first array item is the serialized binary representation of the Signer itself:neo/src/neo/Network/P2P/Payloads/Signer.cs
Lines 187 to 191 in ed68274
The binary representation is followed by a set of Signer's fields serialized to stackitem separately:
neo/src/neo/Network/P2P/Payloads/Signer.cs
Lines 192 to 197 in ed68274
So the first stackitem (binary Signer's representation) looks weird and redundant a bit. We have all other Signer's data available at the same stackitem, so why do we need its serialized binary representation?
The question
Do we need the Signer's binary representation to be included in its stackitem representation? If so, could you, please, explain, why?
The text was updated successfully, but these errors were encountered: