Right now a bizarre error message can occur if an address flag was not
set: `wallet contains no account for 'AFmseVrdL9f9oyCzZefL9tG6UbvhPbdYzM'`.
This bug is 10x worse if it occures in `transfer` --from flag.
Implement ability to sign transactions with multisig address.
This should be done in several steps:
1. Create TX with `wallet transfer --out <file>`
2. Sign TX with `wallet multisign sign --in <file> --out <file2>`.
3. Repeat 2 for every party.
Input file contains transaction with possibly incomplete
set of the signatures. Output file will contain the same tx
with updated signature set.
When --rpc flag is provided, result transaction is sent
via `sendrawtransaction`.
GAS can be claimed via `wallet claim` command.
This will claim first get all claimable outputs via
`getclaimable` RPC and then form a transaction signed
byte the private key from the wallet.
Merged two types:
- smartcontract.ParamType
- rpc.StackParamType
into single one:
- smartcontract.ParamType
as they duplicated the functionality.
NOTE: type smartcontract.MapType was added (as in C# implementation).
From now, list of supported smartcontract parameter types:
UnknownType
SignatureType
BoolType
IntegerType
Hash160Type
Hash256Type
ByteArrayType
PublicKeyType
StringType
ArrayType
MapType
InteropInterfaceType
VoidType
Mostly as is, no real effort done yet to optimize them, so there are still a
lot of duplicates there, but at least we sort them out into different smaller
packages.
One positional argument can be provided. If so, it is
interpreted as address and only WIFs corresponding to it
are exported. If address is provided '--decrypt' flag can be
specified to export unencrypted WIFs.
Given `-s 1` with a dump of 6001 blocks it skipped the first one and then
tried to import the next 6001 which failed with EOF because there are only
6000 blocks left.
NGD dumps are all zero-based and even though I don't like it (genesys block
should not be imported, it's the root of chain trust), we have to conform to
this convention for interoperability with C# nodes (otherwise they're not able
to import our dumps).
This also renames `skip` dumper parameter to `start` which is more logical
now, the default is to start the dump from block number zero.
This seriously improves the serialization/deserialization performance for
several reasons:
* no time spent in `binary` reflection
* no memory allocations being made on every read/write
* uses fast ReadBytes everywhere it's appropriate
It also makes Fixed8 Serializable just for convenience.