Currently, np-utils --scripthash-to-address only converts it as big-endian scripthash, whereas NEO itself often uses little-endian too.

See also https://peterlinx.github.io/DataTransformationTools/

Probably should check if scripthash starts with 0x, and if so do the big endian conversion, else the little-endian one.

Code chain starts here: https://github.com/CityOfZion/neo-python-core/blob/master/neocore/bin/cli.py#L40

Todo: after running the internal tests, Travis-CI should also run the tests from neo-python with the new neocore code, to make sure things are compatible.

• neo-python-core version: v0.3.11-dev
• Python version: 3.x
• Operating System: osx

Description

Test coverage dropped to 98% after the addition of /neocore/bin/cli.py. We should bring it back to 💯

Currently neocore is only compatible with Python 3, because several of the internal modules do some py3 specific byte transformations.

Could be made compatible with Python 2 with some effort, would be great to have I think, but perhaps not a super priority. All the requirements work already with Python 2.

How to hack on this

Remove the line that restricts neocore to Python 3: setup.py#L21

Then create a venv, install the deps and run the tests

virtualenv2 venv-py2
. venv-py2/bin/activate
pip install -e .
pip install -r requirements_dev.txt
python -m unittest discover tests

• neo-python-core version:latest
• Python version:3.7
• Operating System:windows

Description

a = 'AKibPRzkoZpHnPkF6qvuW2Q4hG9gKBwGpR'
b = neoapi.CryptoInstance.Hash160(a)
print (b)

error:E1120:No value for argument 'message' in unbound method call

What I Did

why? how to use this function?

• neo-python: Cryptography
• neo-python: KeyPair

Also migrate the related tests from neo-python, and add new ones where applicable. We aim for >90% test coverage on neocore ;)

Please keep the same namespaces, directory names and filenames for the Cryptography stuff, so we can later just replace neo.Cryptography.* with neocore.Cryptography.* in neo-python. KeyPair will probably go to neocore.KeyPair.

Steps:

• Move Cryptography and KeyPair from neo-python to neocore, along with all the related tests, add more tests where applicable.
• Once merged, we release a new version of neocore to PyPI
• Then we make a PR to neo-python which uses the new neocore and replaces the references of the related classes

• neo-python-core version: master
• Python version: 3
• Operating System: Deepin

Description

I deployed this contract (in C#) and tested storage "size" and "value":

using Neo.SmartContract.Framework.Services.Neo;
using System;
using System.Numerics;
namespace NeoContract1
{
    public class Contract1 : SmartContract
    {
        public static int Main()
        {
            Runtime.Notify("oi");
            BigInteger bi = 1;
            Runtime.Notify(bi);
            bi -= 1;
            byte[] ba = bi.ToByteArray();
            Runtime.Notify(ba.Length);
            if(ba.Length > 0)
                Runtime.Notify(ba[0]);
            Storage.Put(Storage.CurrentContext, "size", ba.Length+10);
            Storage.Put(Storage.CurrentContext, "value", ba);
            
            return 3;
        }
    }
}

According to Python RPC, "size is 10" (because Bigint 0 to bytearray is empty), but according to C# RPC, "size is 11" (because BigInt 0 in C# is b'\x00', not empty).

What I Did

I used neocompiler.io Eco platform, that already integrates full neo-python and neo-cli + neo C# ecosystem.
It's easy to change the RPC node (on top of the screen), python is localhost:10332 and C# is localhost:30335 (if doing locally). Online is https://node1.neocompiler.io and https://eco.neocompiler.io (a current workaround for python rpc... will receive a better name in a few days :D)

It's worth mentioning that theses tests are part of the fork competition Vitor and I are promoting at NeoResearch, with the goal of fixing differences in Neo ecosystem modules that could cause future forks in the blockchain.

See also #26 and #21

ECCurve.py is currently hardly covered, but is proven to be functional by real world usage. #21 was initiated to look at a maintained ECDSA package to replace the homebrew instance, but we could not conclude for now.

This exclusion suggestion has been discussed with @localhuman on slack and we agreed to keep #21 open to stay reminded of the fact that we 1) have to replace the module some day or 2) fix coverage.

Would be great to write tests for full coverage of ECCurve.py as well.

Currently:

• Address to ScriptHash (see #40)

What else? :)

• neo-python-core version: 0.5.7-dev
• Python version: 3.6.3
• Operating System: OSX

Description

As described by user Vinc in Discord, the following code demonstrates two different results for Sign/Verify using the same input and private key:

from neocore.Cryptography.Crypto import Crypto
from neocore.KeyPair import KeyPair
import binascii

message = binascii.hexlify(b'Hello World')
signature = Crypto.Sign(message, '8631cd2635c416ba5f043561e9d2ff40b79c3bb2eb245e176615298b8372d0a4')
key = KeyPair(bytes.fromhex('8631cd2635c416ba5f043561e9d2ff40b79c3bb2eb245e176615298b8372d0a4'))

print(signature.hex())
print(Crypto.VerifySignature(message, signature, key.PublicKey, unhex = True))


message = binascii.hexlify(b'Hello World')
key = KeyPair(bytes.fromhex('8631cd2635c416ba5f043561e9d2ff40b79c3bb2eb245e176615298b8372d0a4'))
signature = Crypto.Sign(message, '8631cd2635c416ba5f043561e9d2ff40b79c3bb2eb245e176615298b8372d0a4')

print(signature.hex())
print(Crypto.VerifySignature(message, signature, key.PublicKey, unhex = True))

The only difference in the two tests is that in the first test, Sign is called before KeyPair, and it returns False when time for verification. The second test, with KeyPair called before Sign, returns True.

This is related to the Sign function not initializing the bitcoin library with the secp256r1 curve values as the initialization in KeyPair does. So the first test actually signs the data with secp256k1, the default for the bitcoin library.

I recommend adding code to initialize the bitcoin library with secp256r1 curve values in Sign (and any other operation that could be called where a private key could be passed in directly instead of as part of an already-initialized KeyPair object.

Done

• UIntBase, UInt160, UInt256
• KeyPair, depends on most of the Cryptography stuff, so that too ^^

Todo

• Basic string to address and address to UInt160 methods

See also https://github.com/CityOfZion/neo-python

@ixje is thinking about replacing ECCurve.py with the ECDSA implementation from cryptography.

Input from @localhuman: "If I was going to replace the ECDSA implementation, I would do it in neo-python first so that I can verify it works with all the various signatures throughout the application."

Description

The purpose of this issue is to brainstorm and collect what functions are useful to have as helper methods for cryptography related operations. Some of these might already be present, which is fine since we're trying to collect an overview.

• public key (ECPoint or bytes) to redeem script
• public key to script hash
• public key to public address
• redeem script to script hash
• redeem script to public address
• script hash to public address
• signature to public address
• WIF to public address
• WIF to script hash
• WIF to private key
• private key to WIF
• double SHA256 (convenience wrapper)

Crypto related, not necessarily as helper?
Some of these are arguably better suited to run/implement in KeyPair. Opening the discussion here to see if e.g. convenience wrappers should be provided.

• isValidWIF
• isValidPublicAddress
• encrypt WIF (NEP2)
• decrypt WIF (NEP2)