I thought num2VarInt was doing the right thing until my invocations started failing at the most inconvenient time. After debugging the node I realised that it was trying to read too much of the byte array, failing on GAS cost deserialization because there was no buffer left. Swapping the bytes around fixed it and the txes went through fine.

This is where the wrong var int was coming through - fd00fd should be 253 but was becoming 64768 in the node.

I've noticed that we aren't using var ints for big values right now (mostly short array lengths) so I wonder if this was the wrong endianness all along and we are just missing a reverseHex.

i generate invocation script used neon.create.script

CODE:

if (typeof transferAmount === 'string') { transferAmount = parseInt(transferAmount); } var script = neon.create.script({scriptHash: assetHash, operation: 'transfer', args: [fromAddrScriptHash, toAddrScriptHash, transferAmount]});

when the value is 999000000000 , the script is not correct.
the error script start with : 0500460a99e8 (amount)
the correct is : 0600460a99e800 (amount)

Current Behaviour

When calling e.g. getBalance(network, address) without valid parameters no errors are given. It just gracefully fails. In my case my the address parameter to getBalance() turned out to be empty/undefined, but I was still getting a result back with 0 NEO, 0 GAS.
Example getBalance call I was dealing with: Click

Expected Behaviour

I expect an error to be thrown when parameters are invalid.

I haven't tried this on other API calls, but I noticed that none of them seem to have any error checking.

Proposal

I personally believe an SDK should do sanity checking but that's just my opinion. So before I make any PR, do we agree that parameters should be validated by the SDK? Would Promise based rejection do an acceptable solution?

The endpoint of getting a price of a coin needs an id, not a symbol, so this will fail:
https://api.coinmarketcap.com/v1/ticker/eth/
while this will work:
https://api.coinmarketcap.com/v1/ticker/neo/ <-- because id is neo

The tests don't show this because they only use NEO/GAS, which both have the same id/symbols.

All these will fail:
https://api.coinmarketcap.com/v1/ticker/btc/
https://api.coinmarketcap.com/v1/ticker/xrp/
https://api.coinmarketcap.com/v1/ticker/ltc/

A solution might be to use only the getPrices, and filter the coin you want.

Do a pass and add proper logging where required.

Do a pass and add proper logging where required.

The current params required for building a txn uses an encoded public key instead of a script hash.
(See: https://github.com/CityOfZion/neon-js/blob/master/src/transactions/create.js#L53)

This causes problems when trying to use the library to build dapps where the smart contract to withdraw from / interact with will not have a public key.

Since the only usage of this key seems to be in calculateInputs where it is converted back to a scriptHash anyway, it would be nice to just accept a scriptHash from the start instead.

(See: https://github.com/CityOfZion/neon-js/blob/master/src/transactions/create.js#L126)

Feature

Transactions creation to use Wallet as an argument. This will realise the functionality of default change address and locked addresses.

Specifics

• Transaction.createTx to use Wallet, Account or Balance as first arg.
• Wallet to determine the change address.
• Wallet to allow pulling of coins from multiple addresses.
• Wallet to block using coins from locked addresses.

Self explanatory. Looks like default_sidebars was removed in sphinx-doc/sphinx#3590

$ npm run build:docs

> @cityofzion/[email protected] build:docs /home/ubuntu/dev/neon-js
> cd source && sphinx-versioning -g ../ -l ./conf.py build source ../docs

=> Reading config from ./conf.py...
Running Sphinx v1.6.5
WARNING: The config value `scv_whitelist_tags' has type `str', defaults to `tuple'.
loading pickled environment... not yet created

Exception occurred:
  File "/usr/local/lib/python2.7/dist-packages/sphinxcontrib/versioning/sphinx_.py", line 60, in builder_inited
    app.config.html_sidebars['**'] = StandaloneHTMLBuilder.default_sidebars + ['versions.html']
AttributeError: type object 'StandaloneHTMLBuilder' has no attribute 'default_sidebars'

Full trace:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/sphinx/cmdline.py", line 305, in main
    opts.warningiserror, opts.tags, opts.verbosity, opts.jobs)
  File "/usr/local/lib/python2.7/dist-packages/sphinx/application.py", line 234, in __init__
    self._init_builder()
  File "/usr/local/lib/python2.7/dist-packages/sphinx/application.py", line 312, in _init_builder
    self.emit('builder-inited')
  File "/usr/local/lib/python2.7/dist-packages/sphinx/application.py", line 489, in emit
    return self.events.emit(event, self, *args)
  File "/usr/local/lib/python2.7/dist-packages/sphinx/events.py", line 79, in emit
    results.append(callback(*args))
  File "/usr/local/lib/python2.7/dist-packages/sphinxcontrib/versioning/sphinx_.py", line 60, in builder_inited
    app.config.html_sidebars['**'] = StandaloneHTMLBuilder.default_sidebars + ['versions.html']
AttributeError: type object 'StandaloneHTMLBuilder' has no attribute 'default_sidebars'

This refactor will split the NeonDB's API methods away from NEO RPC methods, allowing this library to be more flexible and less biased. NeonDB's methods can be seen as examples on how to use NeonJS methods.

RPC

• Exposed as Neon.rpc or import {rpc} from 'neon-js

• RPCClient

  • Class pointing towards a specific NEO node. Instantiate with node URL (optional version can be used to guard against new implementation methods)
  • Has RPC methods implemented using Query class. eg. Client.getBlock(1)
  • Accepts a custom RPC request through Client.query(customRequest).
  • Accepts a custom Query through Client.execute(customQueryObject)
  • Contains history of past queries made, accessed through Client.history

• Query

  • Class to serve as wrapper around request and response.
  • Attach a parser method with parseWith(parsingMethod) to parse the response.
  • Has static RPC methods for quick init. eg Query.getBlock(1) is equivalent to new Query({method: 'getBlock, params: [1]})
  • Quick querying without RPCClient : Query.getBlock(1).execute('https://seed1.neo.org:10332)

API

• Exposed as import {api} from 'neon-js'
• NeonDB
  • Shift all methods for Neon wallet to here.
  • Separation of custom logic from general logic makes the library more readable. (I always mess up getAPIEndpoint with getRPCEndpoint)
  • API folder can contain other APIs from external sources (eg. coinmarketcap for prices?)

Hi there,
I'm using
"@cityofzion/neon-js": "^3.1.0",
node -v v8.9.4
tryin to sing & send sweep transactions with this code as described here ;

            const filledBalance = await api.getBalanceFrom({address:addr,net:"TestNet"}, api.neonDB)

        if(   filledBalance.balance.assets.NEO.balance.toNumber() > 0 ){
                addresser.getAddress(addr).then(async  function (dbAddres) {
                    let tx = Neon.create.tx({type: 128, version:2})
// Now let us add an intention to send 1 NEO to someone

                    tx   .addOutput('NEO',  filledBalance.balance.assets.NEO.balance.toNumber(),"ANTZ7qbbXFWxZaBLKUtjsPDa9B1uHMJRMv")
                    tx    .addRemark('I am sending 1 NEO to someAddress') // Add an remark
                    tx     .calculate(filledBalance.balance) // Now we add in the balance we retrieve from an external API and calculate the required inputs.
                    tx   .sign(dbAddres.privatekey) // Sign with the private key of the balance

                    const hash = tx.hash
                    const serializedTx = tx.serialize(true);
                  const url =  await api.neonDB.getRPCEndpoint("TestNet");
                    neonjs.rpc.Query.sendRawTransaction(serializedTx)
                        .execute(url)
                        .then(function (data) {

                        })
                        .catch(function (err) {

                        })
                })
        }

always returning an error with message (One of the identified items was in an invalid format.)
my dbAddr object is

{"address":"AKrwhvR6k4qkzGAXcyzmAnvkA8YW98qB7m","privatekey":"a56c53d70072f142cd15abf10cbe63a5ba67ff0f2207f3bfe5382788cb7212b1"}
I'm getting value for variables like this
hash:5f7ce9f4433e7b6fbb422cf84975d0e35b9625169f1a47b4bd45429a56b6927a
and
serializedTx:800201f0214920616d2073656e64696e672031204e454f20746f20736f6d65416464726573730166971150b4ef4909857161ef1a42bece9a33ccef290a3ded0975900ee4bcd4d10000019b7cffdaa674beae0f930ebe6085af9093e5fe56b34a5c220ccdcf6efc336fc500c2eb0b000000004951ed1fc0cf48165ff05ce45d0b8bdb9d37ae73014140207b62d9584ab8f04168233cab5fad5dddb3acfe7559fe73fbb374789f8aee1d273e50d6b89e4eb8aeb952b432499f1a72f95153906bcc1d5f536d27c2b6b4022321022100bac1b9fd93575befb2f7c2fa27b9128922c9f074f38ed78c6b92f9ac053dac

What am I doing wrong ? Which item was this ? What is the proper way to prepare & sing and send a tx ?

I do not see it been used in the codebase and appears that it may have been replaced with CONST.ASSET_ID.

I can see CONST.ASSETS been refactored and populated by array of objects oppose to key value pairs. Example:

export const ASSETS = [
  { symbol: 'NEO', hash: 'c56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b', type: 'GoverningToken' },
  { symbol: 'GAS', hash: '602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7', type: 'UtilityToken' },
]

This will allows more advanced query, such as finding symbol by asset hash:

const symbol = CONST.ASSETS.find((a) => (a.hash === 'c56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b')).symbol

Currently, it is possible to chain multiple scripts together using the ScriptBuilder:

  const sb = new ScriptBuilder()
  sb
    .emitAppCall(scriptHash, 'name')
    .emitAppCall(scriptHash, 'symbol')
    .emitAppCall(scriptHash, 'decimals')
    .emitAppCall(scriptHash, 'totalSupply')

However, doing this requires you to be exposed to the raw working tools which is not what everyone wants to handle. This functionality is not yet exposed at a high level.

This would be similar to the createScript method but take in an array of props instead.

Specifics

• Define a interface describing the props object used in createScript.
• Implement a helper method with signature: (Array<props>) => string
• Helper method should call emitAppCall on each props object and return the final string produced by ScriptBuilder.
• Instead of a new helper method, it is ok to modify createScript if you cannot think of a better name.

This is an open discussion on adding Flow (https://flow.org) static checker for JavaScript.
I'm currently working on implementing it on Neon Wallet (Its especially super awesome for React based apps), and was wondering if it should also be implemented here.

@snowypowers did a fantastic job by documenting all the types, so it will be pretty easy.

What are your thoughts on this?

We want to have some sort of logging that is not console.log so we can capture errors, send warnings and debug easily.

This logging interface will live in its own file at the root of src.

We can pull in an existing logger available on npm and wrap around it.

Specifics

• Create logging.js
• Setup a default logging configuration for dev and prod.
• Write basic tests to make sure the default configs are working fine.

Seems to be running old versions of both yarn and npm. Let's try to fix this so that we're testing against the correct dependencies.

Transaction will be overhauled to be presented as an ES6 class. This will allow us to package the module tightly around a singular class (like how wallet is packaged around Account).

With the Transaction object:

• Static methods for creation of different transactions
• Simple serialization, hashing and signing.
• Dynamically add recipients, remarks and balances.

Side notes:

• Split out core methods from index.js. The index file should only deal with exports and not have any logic.
• Addition of human-friendly methods (methods that accept human friendly arguments). For example, using address instead of scriptHash because address is more recognizable.
• Maximum backward compatibility can be achieved as Transaction class is similar to the old Transaction object (just with more methods).

I was trying to include this SDK into my react-native application but ran into all kinds of bundling and import errors. i.e.

error: bundling failed: "Unable to resolve module assert from /code/neonwallet/node_modules/neon-js/lib/index.js

Googling the errors people seem to suggest that it's related to importing modules from node core. I tried using https://github.com/mvayngrib/rn-nodeify which attempts to shim all that stuff but it didn't work out and just throws new errors.

Unfortunately I'm hardly familiar with the ins and outs of Node. I was wondering if there are any plans to make this compatible with react-native? It would be great if I would not have to re-invent the wheel.

Looking forward to your thoughts

This will make some interactions with wallet cleaner, especially two-step things like claim

Looking at the NEP2 implementation (nice work, thanks!) I noticed that encrypt and decrypt had progressCallbacks (which have since been removed in #17 ).

Given that they can take a while, especially on low-powered machines:

a) Why weren't they passed to higher functions for more convenient use?
b) Why have they been removed altogether?

There will always be moments where the neon-db has connectivity issues. Adding neoscan as a fallback will increase the reliability of the service, we are in desperate need for that. Every time there is a down period, no matter how small people go crazy and council loses 5 days of life.

neoscan API is supposed to offer all the needed info to neon-js, if it is not there - it is a issue. https://neoscan.io/doc/Neoscan.Api.html

Do a pass and add proper logging where required.

In order to manipulate assets from a smart contract address, we need certain addons to a normal ContractTransaction. We would like to have this as a single method under the Transactions class that appends the necessary addons.

Given an adminKey (The privatekey of the admin address) and contractScriptHash (the scripthash of the smart contract),

• Add an attribute of type Script, data being the scripthash of the adminKey.
• Add an signature where:
  • The invocationScript is 00 + standard invocationScript signed by adminKey.
  • The verificationScript is result.script retrieved from the getcontractstate call using the contractScriptHash.

Specifics

• Implement method Transaction.signAsAdmin (name is up for discussion)
• This method should have the params: Transaction.signAsAdmin(privateKey: string, contractScriptHash: string)
• This method will append the relevant items mentioned above and return the Transaction object.

If you try to get the price of RPX, it will not work, because cmc api returns by default only the top 100 results.
Try to look for RPX here: https://api.coinmarketcap.com/v1/ticker/ its not there.

However, if you pass a ?limit=0 to the query, it will appear - https://api.coinmarketcap.com/v1/ticker/?limit=0

Should I make a PR, introducing the limit param? or this should be just the default? (show all)

All CoZ repos need to have an MIT license.

This may be a bug or may just be something we should document more. Below is a little snippet that shows an address working and returning a balance on TestNet. On MainNet this code throws an exception apparently because there's no balance. Is this expected or should it return the correct token info + a 0 balance?

    const [_ignore1, mainNetRpcEndpoint] = await asyncWrap(api.neonDB.getRPCEndpoint("MainNet"))
    const mainNetRpxScriptHash = 'ecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9'
    const addressWithRpxTestNetOnly = 'ALq7AWrhAueN6mJNqk6FHJjnsEoPRytLdW'
    const [mainNetErr, mainNetTokenResults] = await asyncWrap(api.nep5.getToken(mainNetRpcEndpoint, mainNetRpxScriptHash, addressWithRpxTestNetOnly))
    if (mainNetErr) {
      console.log('We get here because on MainNet balance is empty')
    }

    const [_ignore2, testNetRpcEndpoint] = await asyncWrap(api.neonDB.getRPCEndpoint("TestNet"))
    const testNetRpxScriptHash = '5b7074e873973a6ed3708862f219a6fbf4d1c411'
    const [testNetErr, testNetTokenResults] = await asyncWrap(api.nep5.getToken(testNetRpcEndpoint, testNetRpxScriptHash, addressWithRpxTestNetOnly))
    if (testNetErr) {
      console.log('We DO NOT get here because on TestNet we have a balance')
    }

Feature

Balances are very dependent on the 3rd party API to be in sync with the blockchain. We need a method to verify the coins against the blockchain in cases where we are doing back-to-back transactions. gettxout is a good RPC call to verify unspent coins. If the coin is unspent, the RPC call will return its value. Else. it will return null.

Furthermore, each Balance currently can only be used once to construct a transaction. Creating multiple spends will cause the system to attempt to multi-spend the same coin. neon-js should remove the spent coins upon creating a transaction.

Specifics

• Implement verifyBalance - For each coin in Balance, check if spent. Remove if spent.
• Change Transactions to shift coins that it spends from unspent to spent`.

Too many inputs might cause Tx failure. A hard limit is already in place for claims but there is no limit currently on inputs.

There might be a limit on number of outputs too. This should be investigated.

A solution would be to add methods to attach inputs/outputs/attributes so that an error can be thrown if length exceeds max.

The response.GAS.balance of API.getBalance() method may be suffering from float imprecision bug.

To replicate:

• Attempt to fetch balanceOf ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s from TESTNET.
• Notice request to http://testnet-api.neonwallet.com/v2/address/balance/ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s,
• and response as (or similar):

{ Neo: 66,
  Gas: 56.076767890000006,
  unspent: ... TRUNCATED ...

• Compare with direct request to NEO's JSON-RPC:

result: { version: 0,
  script_hash: '0x5df31f6f59e6a4fbdd75103786bf73db1000b235',
  frozen: false,
  votes: [],
  balances:
   [ { asset: '0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b',
       value: '66' },
     { asset: '0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7',
       value: '56.07676789' } ] }

In api.core the methods sendAsset, claimGas and doInvoke chains promises to determine which API to call first. To switch the order, we have to adjust 3 places in code. We would like to refactor such that there is a way to determine the order in a central location for these methods to refer to.

Specifics

• Create a function that references an array for the API order
• This function returns a promise which calls the given function with the APIs in order, returning the data required by the 3 functions mentioned above.

I will be proceeding to refactor wallet.js to :

1. Account

• A class that represents a keypair. This is a high level abstraction that allows us to lazily create and store keypairs.
• Within the code, the relationship between the different formats can be easily understood.

2. core

• This is the file where the core methods for manipulating keys will live.
• Methods will follow the getThisFromThat naming convention.

3. verify

• A set of methods to verify key formats.
• This demonstrates how we can use unique features of each format to verify.

Feature

Implement the new NEP : Wallet standard. This standard is pretty easy to implement as it is:

1. JSON format
2. Similar to NEP-2

In addition, we can expand Account to include the information found in the file.

NEP2 support might now need to be generalized as encrypting/decrypting private keys as variable Scrypt parameters are accepted. Thus, the NEP2 standard will refer to that specific set of Scrypt parameters. (might need clarification)

Specifics

1. Ability to read wallet JSON file.
2. Ability to write wallet JSON file.
3. Enhance Account class to include the additional fields: label and extra
4. Export NEP2 Scrypt parameters to CONST
5. Refactor NEP2 methods to accept variable Scrypt parameters.

References

neo-project/proposals#13

http://api.wallet.cityofzion.io

Wouldn't all API calls be unencrypted to this link? Couldn't that introduce a possibility for a man-in-the-middle attack?

Do a pass and add proper logging where required.

While integration neon-js into neo-js, I've noticed the following RPC methods has not been implemented:

• getBlockHash(index)
• getBlockSystemFee(index)
• sendToAddress()

Are they excluded purposely?

Right now, NeonJS transaction construction depends heavily on neon-wallet-db nodes ran by CoZ. In order to be more flexible, there should be a outline of what NeonJS wants in order to construct transactions so that other people can build APIs to support NeonJS methods.

Why

Currently, there is only 2 sets of information that is important - Claims and Balance. Claims allow us to see the unclaimed transactions and thus form a ClaimTransaction. Balance allows us to see all unspent coins and send assets around. These 2 pieces of information are not readily available from the NEO node with a single API call. Creating a light wallet purely dependent on NEO nodes will cause too many calls to be efficient.

Use case

For example, neoscan.io might want to publish a set of API that light wallets can consume and use. This set of guidelines would allow the API creator to understand what are the information needed and craft an API endpoint that allows us to retrieve such information with a single call.

Format

A document (.rst) that details the information required. This will be placed in the NeonJS documentation. This document can evolve with NeonJS as different versions might shake things up.

Hi, is an unminified version of lib/browser.js available or can it be created?

Thanks!

Take the above code and set orderedCoins to (biggest first)

            {
                index: 0,
                txid: '1fe78a9a89c72e2a296b0476a3801ae0f3a10c88e74f14236fd522d7af72832c',
                value: 10.0
            },
            {
                index: 1,
                txid: '88e873ce8e8fb00f446ded8eb82521cc7c4285973d950f5112630598b09b1bbd',
                value: 4.0
            }

Say we wish to transfer 12 units of some asset. amount will be 12. According to our funds we have 14in total available. The current implementation will return only 1 input for a total amount of 10, while needing both to be able to reach 12.

First round:
10 <= 12 (true)
amount = is 12-10 = 2

Round 2:
4 <= 2 (false)

Loop ends

We now only add 1 input for a total amount of 10, where we requested 12 and we do have the funds for it.

How this library is used? Do I need babel or something? I am trying run simple example with node x.js

import Neon, {wallet} from '@cityofzion/neon-js'
const a = Neon.create.Account('ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s')
console.log(a.address) // ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s
const b = new wallet.Account('9ab7e154840daca3a2efadaf0df93cd3a5b51768c632f5433f86909d9b994a69')
console.log(b.privateKey) // 9ab7e154840daca3a2efadaf0df93cd3a5b51768c632f5433f86909d9b994a69

And it doesn't work

(function (exports, require, module, __filename, __dirname) { import Neon, {wallet} from '@cityofzion/neon-js'
                                                              ^^^^^^
SyntaxError: Unexpected token import

There will a transition to using Fixed8 for most of the value storage that requires decimals. The main criteria will be for coin values. If the number is a coin value, it will become a Fixed8. If it for an index, it will remain a javascript number.

Other than that, most of the class based objects will also have their constructor changed to accept a generic JS object that looks like it in shape. For example, Transaction constructor will accept a Transaction-like object (have the keys type, version, inputs, outputs, etc). This is to allow easy transformation of external API objects into neon-js native objects.

This should ease the transition and make it simpler for neon-js as a whole to interact with the outside world.

Specifics

• Modify calculations to use Fixed8 notation
• Modify most class objects to accept a -like object (not all required, only those affected by Fixed8)
• Fix all tests

@ixje in slack mentioned that neon-js has problems integrating with react-native (also that @totalvm may have some experience with this)

it would be great to resolve these issue so that other app developers can use the library

Feature

Account class should be the central object that interactions revolve around. Thus, I would like to have Transaction construction accept an Account class instead of a Balance object. This allows us to reduce the number of arguments as well as make it easy on the mind by centralising the data store (no more maintaining reference to balance, publickey, etc)

Specifics

• Balance to be under Account.balance
• Transaction.createTx to use Account or balance for creation

Lint

I see a PR for linting but it does not introduce any code standards. The current lint is not working due to absence of a .eslintrc file.

I would like to use StandardJS as the default style. It is clean and proven.

Refactor+Cleanup

Do a general cleanup and refactor. There is a lot of rough code and unused deps that should be cleaned. A refactoring will allow us to restructure the code before we start writing more testcases.

Testing

We need more tests.

JS vs TS

While it is nice to have both repos, I think that it is a duplicated effort to maintain both repos considering that they offer the same thing in the end (a JS file). I think we should maintain only one for the sake of consistency.

Any thoughts?

Currently, neon-js parses NEP5 tokens without respecting the decimals field. The code simply assumes fixed8 notation (a fixed point number with 8 decimal places) and parses it.

It has served us well for the time being as the tokens being implemented so far have been using all 8 decimals places.

However, a contract has appeared which uses zero decimal places and thus, decided to store their data as integers. Thus, from neon's perspective, we see a single token as 0.00000001 token. This will need to be rectified. Currently neotracker parses this correctly, respecting the decimals field.

This, however, raises the issue that a contract cannot be parsed properly without knowing certain properties of the contract. In this case, decimals becomes an implementation detail and determines how we parse the rest of the data.

• Easy for contract writer as there is no need to guard against weird decimals.
• API writers will have to check decimals before parsing.

The other option is that all contracts observe the fixed8 notation and enforce this within the contract.
decimals is now a safeguard.

• Contract will have to guard against decimals attacks manually (costing cycles)
• Ease on API writers as we can easily parse contract outputs.

Either ways, both have their pros/cons. Saving cycles is always a good reason and thus, going with the first option is the goal.

This is a fix that will go into master as this is considered as a bug.

getTransactionHistory() only returns up to 25 transaction records regardless of numbers of transactions within an address. Method also doesn't seems to take optional parameters for pagination supports.

To replicate:

• Attempt to fetch getTransactionHistory ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s from TESTNET.
• Notice request to http://testnet-api.neonwallet.com/v2/address/history/ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s,
• and also notice the result array length at 25, despite https://neoscan-testnet.io/address/ALfnhLg7rUyL6Jr98bzzoxz5J7m64fbR4s shows there are 1000+ transaction records.

Problem

As seen here within the NEO codebase.

The second argument to the getstorage RPC endpoint is the storage key, and it should be a hex encoded string.

Currently neon-js does not hex encode the string or provide documentation above the function to outline the format of the argument.

Therefore this fails:

api.getStorage(
  'TestNet', 
  '0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9',
  'totalSupply'
).then((response) => {
  console.log(response)
});

With the following error:

{
  jsonrpc: '2.0',
  id: 1,
  error: {
    code: -2146233033,
    message: 'One of the identified items was in an invalid format.',
    data: 'at Neo.Helper.HexToBytes(String value) in C:\\Users\\me\\NEO\\neo\\neo\\Helper.cs:line 59\n   at Neo.Network.RPC.RpcServer.Process(String method, JArray _params) in C:\\Users\\me\\NEO\\neo\\neo\\Network\\RPC\\RpcServer.cs:line 181\n   at Neo.Network.RPC.RpcServerWithWallet.Process(String method, JArray _params)\n   at Neo.Network.RPC.RpcServer.ProcessRequest(JObject request) in C:\\Users\\me\\NEO\\neo\\neo\\Network\\RPC\\RpcServer.cs:line 371'
  }
}

Solution

Hex encode the argument before calling queryRPC().

I think this is an easy fix. I'm working with a fork of the master branch right now, but I will try to submit a PR for the dev branch later.

Right now, the util method fixed82num does not accept an empty string as a valid input. That is a valid train of thought.

However, NEO nodes truncate their fixed8 strings when they send it over by cutting off the trailing zeroes. For example, 0.00000020 tokens is received as 14 and not the full 1400000000000000

Following this train of thought, the base-10 number 0 will be translated and truncated as '' (empty string) by NEO node.

TLDR: NEO node gives us empty string for fixed8 ZERO. We should recognise that.

@notatestuser FYI since this was your contributions. Would be good to hear your thoughts but I will accelerate this patch for now.

Gas and NEO transaction tests are broken. Not sure why.