cryptonomic / conseiljs Goto Github PK

Once Tezori can successfully pull from ConseilJS using the GitHub oauth url in package.json and compile the imported typescript on their end, there is no need for the compiled javascript folder, dist, to be in ConseilJS anymore.

Tests should be performed for both Software and Hardware (Ledger) wallets. It should cover at least 60%.

For TezosHardwareOperations.spec.ts in the develop branch, when a transaction is attempted from ledger into a dummy account on alphanet, the id of the injected transaction operation reads "proto.002-PsYLVpVv.contract.counter_in_the_past". This should be amended so counters are incremented correctly.

https://github.com/Cryptonomic/ConseilJS/blob/master/src/types/KeyStore.ts#L16 should export strings

export const MNEMONIC = 'Mnemonic';
export const FUNDRAISER = 'Fundraiser';

The most notable changes are the additions of the operations and transactions routes.

Currently, createWallet() in TezosWallet only checks for password length but not the characters. It is, for example, possible to enter eight spaces as the password. This should be fixed by ensuring all supplied passwords only contain upper case & lower case letters, numbers or a fixed set of symbols.

The Conseil backend has been enhanced with a new v2 API. ConseilJS should allow for querying this API.

Are we doing this on purpose?

We need more detailed error messages, especially during the importing fundraiser account scene.

Currently, we can't display anything other than 'Provided string does not look like hex data'

The zxcvbn library should be used to enforce password strengths. Each supplied password should be tested and any passwords with a score of less than three should be rejected. https://github.com/dropbox/zxcvbn#usage explains the usage of the library.

• Add new function to CryptoUtils for testing password strength.
• Invoke the new function from encryptMessage() in 'CryptoUtils`
• Remove the eight character check from createWallet() in TezosWallet

Rather than using static values as #69 does, calculate fee defaults.

Update the individual Reveal as well.

Due to a recent merge in the Tezos zeronet codebase, there should be a ConseilJS deployment which constructs origination payloads compliant with zeronet.

This change should be made on a issue-specific branch which should then be merged into a zeronet branch, upon which a specific NPM package deployment can be made.

At the moment, all back end queries are transmitted in an unencrypted manner.

Review the Coveralls results, and expand coverage in the following:

• /reporting/ConseilDataClient.ts
• /reporting/ConseilMetadataClient.ts
• /chain/tezos/TezosNodeWriter.ts

These should be unit tests, they will require nock'ed responses.

Wrap head/helpers/scripts/run_operation RPC call. Add explicit return types in src/types/tezos/TezosChainTypes.ts.

As conseiljs is used in an Electron wallet app and Electron doesn't seem to work with fsPromises', all file operations should be reverted to using fs`.

We want users to be able to deploy smart contracts on the tezos node with conseiljs using actual Michelson scripts. To do this, we have to send a json-ified version of the Michelson code to comply with the Tezos RPC.

Review the outdated dependencies and bring them in line with current versions.
https://david-dm.org/Cryptonomic/ConseilJS
Confirm that aws-sdk is unused and remove it.

All code in the master branch should be compatible with the Tezos mainnet and should be published as the ConseilJS NPM package.
All code in the staging branch should be compatible with the Tezos zeronet and should be published as the ConseilJS-staging NPM package.
All code in the develop branch should be compatible with the Tezos alphanet and should be published as the ConseilJS-dev NPM package.*

The above information should be included in the root README file.

*As Cryptonomic is not yet running alphanet nodes, we must use zeronet for now.

Pleas implement the following suggestion:

In saveWallet() in TezosWallet, please implement the following:

We want to allow ConseilJS users to originate smart contracts. Here is some informational material which will help us develop this feature.

1. Recently TezosTeam launched TST token on Tezos. Investigating their transaction and smart contracts will help.

They originated 2 contracts:
Origination Operation 1 -> Smart Contract 1
Origination Operation 2 -> Smart Contract 2

When investigated on chain, these are the fields to the operations:

Script field includes the contract code written in Michelson parsed in JSON. (Serialization/Deserialization process of the Michelson code will be taken care of by the Conseil team.)
I've sent the whole json of the origination operations to you on Riot.

You may consider following this tutorial to write a simple smart contract to test.

The NPM package settings for ConseilJS should be verified for correctness.

Any project importing conseiljs should have access to everything in TezosOperations, TezosConseilQuery, TezosNodeQuery and TezosWallet.

Changes per Protocol 003_PsddFKi3

The Conseil and Nautilus backend servers are hard coded. Instead, they should be selectable from a group of presets and the choice of server parametrized in every function call.

Currently storage and execution gas limits are hard-coded. Instead, we should set them in a principled manner.

The Conseil backend now allows the calculation of high, medium and low fees based on some parameters. ConseilJS should wrap this functionality and make it available to downstream clients.

sendTransactionOperation(), sendDelegationOperation() and sendOriginationOperation() are not following the DRY principle and should be refactored so the operation payloads are not duplicated several times.

ConseilJS should be integrated into Travis CI.

Consider using Nock.

At the moment, only origination operation is burning gas and the gas burnt for this operation is constant, 0.257 tz.

But this might change in the future. We need to have a function to estimate the burn.

https://github.com/Cryptonomic/ConseilJS/blob/master/src/tezos/TezosNodeQuery.ts#L8 's name should be consistent with https://github.com/Cryptonomic/ConseilJS/blob/master/src/tezos/TezosConseilQuery.ts#L35

getKeysFromMnemonicAndPassphrase() in CryptoUtils does not enforce a mnemonic length and this should be changed. The mnemonic should be a fifteen word string, e.g.:

clerk rhythm bonus fabric vital luggage team engine stairs palm degree gossip hour say tenant`

The relevant unit test should also be added.

The password supplied for creating wallets must be at least eight characters long.

This should be done in createWallet() in TezosWallet.

The relevant unit test should also be added.

When the user creates a new identity using a fifteen-word mnemonic, they should be asked in a subsequent screen to type in some set of the words to validate they backed up their identity correctly.

As we want to maintain optionality for creating HD wallets, the KeyStore object must persist seeds (when available) along with the generated keys.

In loadWallet() in TezosWallet, we are returning a promise which performs a set of operations. However, as one of lines could throw an exception. We do not catch any expectations so they die silently. The code should be changed so that any exception will lead to the promise being rejected.

The Tezos Wallet is not working on Ubuntu at the moment due to hanging back end queries. The general speculation is the cause is the handling of node-fetch promises within Electron. To test this hypothesis, let us switch to electron-fetch in a branch. We will publish a version of ConseilJS from this branch and then test it with the wallet code in Ubuntu.

Apparently, the protocol allows delegating to a null address (undelegate)

We need to implement this in ConseilJS

The latest API spec is available at http://doc.tzalpha.net/api/rpc_proposal.html. ConseilJS must adhere to the changes described in the document.

Looking to use your client side library but it looks like the NPM package isn't available. Any idea when this will be available again?

To invoke contracts, a user will select custom fee, gas limit, and storage limits. Besides these three parameters, a user will have the option to provide additional parameters. Although we don't have the designs ready for the Galleon, I can say that it will somewhat look similar to what TezBox has at the moment:

As agreed on Riot, this ticket will be implemented after we figure out the smart contract originations.

This ticket requires two headline changes:

1. The TezosOperations module has been written with the assumption that is called only by file-based wallets with access to a user's keys. Instead, it should support operation functionality without assuming the keys are transparently available.
2. The operation signing algorithm currently requires explicit keys. There should be an alternative that submits the actual signing to a hardware device.
3. The TezosWallet module currently only supports mnemonic-based address retrieval for file-based wallets. It should also support the BIP39 / BIP32 retrieval of addresses from hardware wallets.

• There should be a new enum called HardwareDeviceType with a single member for now called Ledger. Options such as Trezor can added later.
• There should be a new unlockHardwareIdentity() function should take a device type, a derivation path and an index. If the device type is 'Ledger', Ledger.js is invoked to get the corresponding public key hash.
• A new getAllActiveDerivedHardwareAddresses() function should take as parameters - a device type, a seed and a derivation path - and return all derived addresses which can be found on the Tezos blockchain.
• There should be a new signOperationGroupWithHardware() function which takes a forged operation, a device type, a derivation path and an index. If the device type is 'Ledger' then invokes Ledger.js to sign the operation.
• There should be a new sendOperationWithHardware() function which is similar to sendOperation() but takes a derivation path and index instead of a key store.
• For each sendXOperation() instance, there should be a corresponding new sendXOperationWithHardwareWallet() which does not take a KeyStore and, instead, takes a derivation path and index.

Reveal appended for the second time- https://zeronet.tzscan.io/oneNGWX3Ui4PfwYMQPfXjvsWkYvKHmGZnduguotY1C3FC4DavEN

Currently, reveals incur fees, and since reveals are now bundled with transactions, delegations, and originations, there can be unexpected doubling of fees. We want reveals to not insure any fees, even when bundled with other operations.

Ledger being a dependency in conseilJS is causing troubles with Arronax's webpack.
Make Ledger (also Trezor in the future) package a peer dependency

A delegated address and a smart contract look almost identical (both start with KT1) but they are two completely different entities. The simplest way to determine if a KT1 address is a smart contract or a delegated address is to run a getAccount and check the script field.

If script is null then this KT1 address is a delegated address
If script is not null then this KT1 address is a smart contract

We need to make this distinction to determine the following two things:

1- Did the user enter a valid address whilst invoking a contract

If the user enters an invalid smart contract address, Tezori should warn the user.
Tezori is already making the offline checks (is the address 36 chars long, are there any special characters in the address etc.). Please add the second tier check mentioned above.

Also, can you please change the below offline validation rule, and only allow KT addresses to be entered in this field.

2- To list the originated contract in the correct section

Currently, any originated contract will be listed as a Delegated Address in Tezori. Currently, any originated contract will be listed as a Delegated Address in Tezori. We need to list the smart contracts and delegated addresses separately as shown belown.

Remove dependence on base-n.

The TezosWallet module was written with the option of adding HD wallet support. The logic must now be extended to allow HD support to prepare for hardware wallet support.

• Incorporate BIP32 library for supporting derivation paths and refactor getKeysFromMnemonicAndPassphrase() to explicitly use BIP32.
• Split getKeysFromMnemonicAndPassphrase() into two functions - getSeedFromMnemonicAndPassphrase() and getKeysFromSeed()
• 'getKeysFromMnemonicAndPassphrase()' should also take an optional derivation path argument.
• `getSeedFromMnemonicAndPassphrase()' should take as parameters - a fifteen or twenty-four word mnemonic, an optional passphrase, - and return a seed.
• 'getKeysFromSeed()' should take as parameters - a seed and a derivation path- and return a key store corresponding to the root account.*
• A new getDerivedAddress() function should take as parameters - a seed, a derivation path and an index - and return a key store corresponding to a derived account.
• A new getAllActiveDerivedAddresses() function should take as parameters - a seed and a derivation path - and return all derived addresses which can be found on the Tezos blockchain.

HD wallet usage of the above:

• Ask user for a mnemonic
• Call getKeysFromMnemonicAndPassphrase() with above to get the root address and seed.
• Call getAllActiveDerivedAddresses() with the above seed and a derivation path to get a list of all derived addresses.
• To create a new derived address, call getKeysFromSeed() with the above seed and the next index.
• To load an existing wallet, fetch the seed of the root address from disk and then call getAllActiveDerivedAddresses().

The Wallet interface currently supports an arbitrary number of KeyStores. Any client is free to add as many KeyStores, therefore as many seeds, to a wallet file as they want. However, in HD mode, we want a wallet file to contain no more than a single seed. Therefore, we must implement a new HDWallet interface which essentially inherits from Wallet but constrains the number of KeyStores to a maximum of one and the KeyStore object to contain a non-null seed.