EDS calculation

EDS calculation is based on the same principles as in EON 1 ([TestNet3 - EON Peer API / Transaction signature], but the Bencode string is not converted to uppercase):
1.Forming a dictionary with the data to be signed.
2.Forming a Bencode string from the dictionary.
3.Bytes are taken in UTF-8 coding.
4.Signing received bytes with the private key.
5.The obtained signature is inserted into the appropriate field.
For transaction
The following fields are used to form the dictionary (similar to the transaction structure):
version : long
timestamp : long
deadline : long
publisher : String
fee : long
tags : map<string> (optional field)
commands : list<map> (commands are formed as for signature)
Example (JSON):
{
    "commands": [
        {
            "data": {
                "alg": "ed25519",
                "id": "EON-27Z6X-N77SJ-B8GEM",
                "key": "9zUema0KRJFkx2mC4HjEZZ0xCH0MMAdGH34rXfz2p4o="
            },
            "deadline": 300,
            "network": "core.dev.Ti2YGY",
            "publisher": "EON-HRAEQ-8NZL7-C9LHJ",
            "timestamp": 1592296782,
            "type": "core.auth.pk.new",
            "version": 1
        }
    ],
    "deadline": 300,
    "fee": 1000,
    "publisher": "EON-HRAEQ-8NZL7-C9LHJ",
    "timestamp": 1592296782,
    "version": 1
}
For command
The following fields are used to form the dictionary (similar to the command structure):
version : long
network : String
timestamp : long
deadline : long
publisher : String
type : String
data : map
reference : string (optional field)
note : string (optional field)
Example (JSON):
{
    "data": {
        "alg": "ed25519",
        "id": "EON-27Z6X-N77SJ-B8GEM",
        "key": "9zUema0KRJFkx2mC4HjEZZ0xCH0MMAdGH34rXfz2p4o="
    },
    "deadline": 300,
    "network": "core.dev.Ti2YGY",
    "publisher": "EON-HRAEQ-8NZL7-C9LHJ",
    "timestamp": 1592296782,
    "type": "core.auth.pk.new",
    "version": 1
}
Signing transactions and commands
The transaction is signed by the account specified in the publisher field. Each type of command has its own rules for determining who should sign it (if the command requires a signature at all).
Commands and transactions are signed according to the multisignature settings. I.e., if multisignature is enabled, then it should be signed by the accounts specified in the multisignature. The accounts sign the commands and transactions according to their multisignature settings if they are enabled (except when an account includes itself in the multisignature setting, in which case the account's EDS is required).
For example:
The `A' account issues the transaction. It must be signed.
If account A has set the accounts B and C in the multisignature, then the signatures of accounts B and C are expected in the transaction (taking into account their multisignature settings).
If account B has set multisignature to account C, then only account C is expected to sign in the transaction (taking into account its multisignature settings).
If account C has set multisignature to accounts C and D, then the signatures of accounts C and D are expected in the transaction (EDS  forC and for D, taking into account the multisignature settings).
If account D has not set multisignature, then the transaction must have two EDS: one from account C and one from accountD.
Last modified 2yr ago