cityofzion / neo-mamba Goto Github PK

Additional contextual information
Go reference:
NewWalletFromFile (location: string) : Wallet)

This issue covers the creation of the marketing banner for v0.4.

@ixje could you please provide a few bullets of key features?

FYI @J-G-W

Currently all classes that extend ISerializable need to have their init() callable without arguments to support

• deserialize_from_bytes()
• read_serializable()
• read_serializable_list()

These are nice functions to have and we should keep them as the old neo-python way (class path lookup) was horribly slow.

The current approach makes it look as if all parameters to ISerializable subclass initializers are optional, which they certainly are not. Example

This makes for a poor coding experience because now you can't rely on your IDE telling you what is mandatory and what not, and you have to look into the implementation to see what is and isn't actually optional. It also results in poor documentation as we now need to make some explicit remark about it and then hope people actually read it.

Solution:
Add an abstract class method to ISerializable e.g. serializable_init() that will create a new instance supplying whatever mandatory arguments are needed to the default init(). Remove all fake optional values from current ISerializable subclasses.

neo-project/neo#1549

On NEO2 the VM used to be the major performance bottleneck. Now that this is resolved for NEO3 through a C-extension a place with room for performance is in signature verification.

The current pure Python ECC implementation comes from neo-python and works fine but is slow. An issue about replacing that implementation existed for neo-python but was dropped to focus on more important issues. At the time also most considered ECC packages did not seem suitable. This was 2+ years ago and available libraries have evolved.

The requirements have not changed much

• support custom curves (as we never know what NEO will change to)
• support point on curve validation
• support ECPoint loading from binary data (not PEM/DER format)
• support compressed points

The options

1. python-ecdsa

• is a pure Python implementation, but if it detects gmpy2 it will use that for arithmetic speeding it up massively. With gmpy2 it is supposedly 3 x faster than fast-ecdsa. gmpy2 is supported on all platforms and has wheels for Windows. The downside is that you'll need to have build tools for OSX/Linux
• signing key can be made deterministic which is nice for unittests
• need to try creating a custom curve to see how/if that works
• sacrifices side-channel resistance for speed. This is good for our purpose
• note that we already use this package for signature verification, but ideally we also use it in signing and all other parts. Meaning among others we wrap Point into ECPoint and inherit from ISerializable.

2. Do our own in C++ (or port the NEO version to C++) and wrap it with pybind11.

• the pro is that we can create wheels for all platforms thus not needing any compilers.
• the downside is that it takes significantly more time to create and adds maintenance

fast-ecdsa is not considered because that has side channel resistance which results in being slower than python-ecdsa. Speed for us is more important.

Validate the feature-parity branch against the preview3 network once available.

We should be able to send a transaction that will invoke a smart contract, with parameters, from the account API.
Example:
account.invoke(GAS.script_hash, "transfer", from, to, amount, user_data)
There should be a way to run the transaction on 'read mode' only (test invoke), before sending it to the network.

@ixje we need to talk to you about this. Should this be on the Account class or in another place? We need to be able to 'test-invoke' the invocation first and we don't know where this logic should go.

neo-project/neo#1752

Release Discussion

This release will incorporate wallet support including signing which will enable invocation transactions.

neo-project/neo#1768

Original issue description (ref)

Need to define a place to house the documentation as well as the build and push strategy. I'd like to propose that this be handled in circleci as part of our CI/CD workflow.

Need to re-submit CityOfZion/neo3-python#13 in this repo (and adjusted as discussed).

Summary or problem description
We need to be able to import private keys that are not originally encrypted. That way, it can also be part of a collection of accounts (wallet)

Do you have any solution you want to propose?

This requirement is similar to "Account creation using NEP-2" (#60), however, instead of generating a new private key, we should grab the private key to be imported and encrypt it using NEP-2 standard format.

Additional contextual information

We should take into consideration that all the NEP-2 accounts in a NEP-6 wallet will have the same decryption password. This is not mandatory in NEP-6, but our implementation will adopt it. So, whenever users import a NEP-2 account that is not using the same passphrase as the NEP-6 Wallet, they have to change the passphrase to be the same as the one in the wallet.

Depends on #59

NewAccountFromWif(wif: string)

neo-project/neo#1751

neo-project/neo#1736

• neo-project/neo#1729
• neo-project/neo#1400
• neo-project/neo#1199

Summary or problem description
There's not support for multi account signing, where the funds are associate with a smart contract and not a single user. That way, the transactions of the funds in this type of multi account can only be executed if N of X people provides signatures for it. For example, 2 out of 3 of the account owners must sign in order for the funds to be withdrawn.

Do you have any solution you want to propose?

We should follow implement multi accounts signing as is described [here]

Additional contextual information
Add support to multisign

ConvertMultisig(m int, publicKeys : publicKey[])

Depends on #1

• neo-project/neo#1481
• neo-project/neo#1736
• shargon/neo@50ffaac#diff-1cca3de737c6b2869e7606ef6401486b
• shargon/neo@76775ce#diff-1cca3de737c6b2869e7606ef6401486b
• shargon/neo@bbed8cf#diff-1cca3de737c6b2869e7606ef6401486b
• shargon/neo@1abdbdf#diff-1cca3de737c6b2869e7606ef6401486b
• neo-project/neo#1419

Summary or problem description
Wallets can have multiple accounts. This issue is for including new accounts to existing wallets and creating new wallets with multiple accounts

Additional contextual information

• A NEP-6 wallet is a collection of accounts, meaning that it can contain one or multiple NEP-2 accounts.
  • The wallet should be already implemented in #59. This issue is to include accounts to the wallet

AddAccount(acc: Account)
RemoveAccount(address: str)

Subject of the issue

Niah has created this Issue to report Sphinx vulnerable packages in the pip dependencies of this project.

https://pypi.org/project/neo-mamba/

**Vulnerability Scanning Report : **
Niah Report

Vulnerable for following couple of CVEs

CVE-2020-11022,CVE-2020-11023

Severity
Couple of High, Medium Severity Vulnerabilities open in Sphinx dependencies.

Solution
Use latest version of Sphinx "3.0.4 " in requirements.txt file

Release Discussion

neo-project/neo#1729

neo-project/neo#1673

Determine if this has an impact on our implementation

Summary or problem description
On issue #59, we're covering a way for creating a wallet using NEP-6. On this issue, we need a way to export it.
Do you have any solution you want to propose?

• We should support wallet export, where the account information (including private key, password, address, etc.), should be stored in a specified wallet NEP-6 JSON file.
• Users should choose the path they want the file to be exported to.
• Users should be able to change the password when exporting a wallet, if they want to.

Additional contextual information

• Depends on issue #59

Save()
JSON()

Release Discussion

neo-project/neo#1629

Summary or problem description
Currently we are not adhering to any wallet standard. This becomes troublesome when trying to migrate between different client programs as they might not be in the same format. In the Neo Enhancement Proposal 6 (NEP-6), a standard JSON format for wallets has been established.

Do you have any solution you want to propose?
We should adhere to NEP-6 and implement the wallet file JSON format detailed in the proposal. That way, it will be easier for our user base to migrate between different NEO platforms, for example: moving your wallet from a NEO client program on C# to a NEO implementation on Python.

Additional contextual information

• Here a wallet can be defined as data structure, that should follow the JSON standard file format.
• A NEP-6 wallet is a collection of accounts, meaning that it can contain one or multiple NEP-2 accounts.
  • In this issue, implement the wallet creation with one account only. Multiple accounts on #63

NewWallet (location: string) : Wallet

neo-project/neo#1397

• renamed GetBlockData to GetBlockByIndex
• Changes to GetBlockDataPayload
  • renamed
  • change of count type
  • change of deserialization logic

The user must input the current password to decrypt the key and will be asked to add the wallet password. The key will be saved on the NEP-6 wallet using the wallet password (same password for all accounts)

CreateAccount(name: str, passphrase : str)
NewAccountFromEncryptedKey(nep2: string, password: string)

Create a single account using NEP-2 (password is needed)

NewAccount()
NewAccountFromEncryptedKey(nep2: string, password: string)
NewAccountFromPrivateKey()

It will use the wallet password to encrypt the wif and generate its NEP-2 equivalent

Summary or problem description
In a wallet there's no way to describe content in a JSON file. An alternative to that is to use the Extra field, where users could add any contextual data to the wallet.

Do you have any solution you want to propose?
The field Extra in a NEP-6 wallet should enable other users to store arbitrary contextual data. i.e.: add a property called password_hint with a value "hint".

Additional contextual information

AddToken(scriptHash: UInt160)
RemoveToken(scriptHash: UInt160)

neo-project/neo#1689

Summary or problem description
There's currently no support to single account signing in Neo Mamba (?)

Do you have any solution you want to propose?

https://docs.neo.org/v3/docs/en-us/basic/concept/transaction.html
https://docs.neo.org/v3/docs/en-us/basic/concept/cryptography/encryption_algorithm.html (?)

Additional contextual information
Sign a transaction using a single account

SignTx(magic: Magic, tx: Transaction)
GetVerificationScript()

Hey Guys, Recently I am importing neo-mamba as SDK in a python script. However, I can not find toScripthash as in C# helper. How can I use it?

neo-project/neo#1397
seems to have also changed some protocol handlers besides OnGetBlockByIndexMessageReceived

Audit of Preview3 testnet block 127240 showed that the C# reference code did not take the manifest size into account when calculating the GAS price in the Contract.Update syscall, whereas we did. We ran out of GAS causing the engine to FAULT, whereas C# incorrectly said it was all good. We've temporarily patched to code such that the preview 3 release produces identical results to C#.

This is a reminder to restore the code (currently commented out)