iov-one/iov-core

Client library for secure key management and multi-blockchain communication

IOV-Core

This repo is provides core functionality to all clients in a cross-platform typescript library. This can be used to build cli/gui clients, automated scripts, or help build bcp-proxy apps.

Main functionality provided:

• Solid crypto library with HD support for ed25519 (following SLIP-0010, ledger compatible)
• Secure private key management, including encrypted local storage for both browser and node
• Generic, type-safe adaptor to read/write on tendermint rpc server (with http/s and ws/s support)
• Adaptor to query / create transactions for IOV's testnet of the BNS blockchain
• Adaptor for key management using IOV's BNS ledger app
• High level controller for managing multiple user profiles and various key material
• High level controller for managing read/write connections to multiple blockchains (CoreWriter)
• Integration with REPL environment for quick prototyping for developers

This is still in pre-alpha state and will evolve quickly as we add support for multiple blockchains, more transactions types, and better extensibility. However, all attempts have been made that the foundational code is quite solid. A security audit and stable release will occur along with the timeline of IOV's mainnet launch, but developers looking for client-side libraries can do initial prototypes with the current state.

We are actively building out multiple clients on top of this library and shaking out usability issues in the API.

Users

The following projects use IOV-Core (add yourself via a PR):

Project	Tech stack / JavaScript environments
TokenFinder	TypeScript / React / Browsers
iov-faucet	TypeScript / NodeJS 10
@iov/ledger-bns	TypeScript / NodeJS / Browsers

Compatibility

The compiled code from this package, which is published on npm, should work on any modern (2018) browser, and node 10.13+. The development environment has been tested on node 10.13.

Yarn not Npm Please npm install -g yarn and use yarn install, yarn build, etc. Developers who installed with npm i have reported problems in compiling, so wipe out node_modules and enjoy yarn.

CI Tests:

• Linux: node 10.13, chrome, (electron manually)
• OSX: node 10.13, chrome, firefox, safari, (electron manually)
• Windows: node 10.13, (edge, electron manually)

Getting Started

The best way to learn about code is to use it. You can read some examples in @iov/multichain. And you can use a REPL to interactively try the code.

Once you understand the basics, you can dig in deeper with the API documentation.

API Docs

Documentation is published at https://iov-one.github.io/iov-core-docs/.

To build the documentation locally, run yarn install && yarn build && yarn docs in this repository. This will generate a ./docs directory in each package that you can browse locally to see API docs on the various packages.

Contributing

We are more than happy to accept open source contributions. However, please try to work on existing issues or create an issue and get feedback from one of the main contributors before starting on a PR. If you don't know where to start, we try to tag "good first issues" that provide a nice way to get started with the IOV-Core repo.

Development Environment

If you go into a subpackage and try to yarn build or yarn test, chances are it will fail. The reason is that we only check in *.ts files, while we need the compiled *.js files to import other packages. We push these to npm but do not check them into git to avoid commit noise.

To get started, please go to the root directory and run:

yarn install
yarn build
yarn test

Once that passes, you have the code built and can go into any subdirectory, edit code and verify the changes with yarn test on that one package.

Integration Tests

There are a number of integration tests involving communication with tendermint (in @iov/tendermint-rpc) and the BNS blockchain (in @iov/bns) that require a test server to run and are skipped by default. If you are working on those packages, please run those tests. (They require docker to be installed and executable by the current user)

Tendermint

./scripts/tendermint/start.sh
export TENDERMINT_ENABLED=1

cd packages/iov-tendermint-rpc
yarn test
cd ../..

unset TENDERMINT_ENABLED
./scripts/tendermint/stop.sh

BNS

If you are working on @iov/bns, you can run the tests against a local BNS devnet. See scripts/bnsd/README.md for instructions on how to start the BNS devnet. Then run the tests as follows:

cd packages/iov-bns
yarn test

Lisk

If you are working on @iov/lisk, you can run the tests against a local Lisk devnet. See scripts/lisk/README.md for instructions on how to start the Lisk devnet. Then run the tests as follows:

cd packages/iov-lisk
yarn test

Browser tests

The CI runs all code not only under node, but also in various browsers.

These work almost all of the time, but if you CI test fails in the browser, or if you are just curious to see this work, you can run the browser tests locally with any of the following, in any package you are working on:

yarn test-chrome
yarn test-firefox
yarn test-safari  # osx only
yarn test-edge    # windows only

Developing under Windows 10

Most of the developers working on this project in windows are also using Windows Subsystem for Linux (WSL), which should have maximum compatibility, as CI is linux and osx. However, we do attempt to ensure that this code also compiles on the normal windows shell, if you have set up git, node, yarn etc. correctly. (Note this has only be verified under windows 10, no guarantees for older versions).

Line endings (CRLF vs LF)

All the code in the repo should use LF not the windows-specific CRLF as a line ending. tsc is currently set up to output properly. However, you should also make sure your editor saves with LF line endings rather than CRLF.

A bigger issue is git changing the endings upon commit. Here is a short workaround, adapted from a stackoverflow discussion:

git config --global core.autocrlf false
git config --global core.eol lf

FAQ For Potential Issues

Libusb fails to build, why?

If you are running on linux, you may not have the proper dependencies installed. For Ubuntu, try the following: sudo apt-get install libudev-dev libusb-1.0-0 libusb-1.0-0-dev. These are needed to compile the usb driver.

Sometimes compiling native code with node-pre-gyp causes issues in very recent versions of Node.js. At the moment, Node.js 10 and 11 should work.

Docker fails to run a test server

If you're using OSX and Docker Desktop for Mac and you get an error like the following, you'll need to add your $TMPDIR path to the list of shared paths:

docker: Error response from daemon: Mounts denied:
The path /path/to/tmpdir is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.

In a terminal, run this command to find out your $TMPDIR:

echo $TMPDIR

Then add it to the list of shared paths in Docker -> Preferences ... -> File Sharing. Apply and restart, and try to start the test server again.

My PR works but the CI rejects it

Make sure you at least ran yarn test in all the directories where you modified code. The CI will reject any PR if type definitions change after compiling the code to ensure it was build and committed prior to pushing.

License

This repository is licensed under the Apache License 2.0 (see NOTICE and LICENSE).

iov-core's Issues

Finalize generic blockchain interface

This interface will be implemented by bcp-demo/bns direct connection, as well as bcp-proxy client connection.

• Standardize on the types returned from bcp-proxy.
• Define a nice API around it, with subscriptions as well as queries
• Focus on usability and Observable/reactive patterns

Add CI tests on Windows (node + Edge)

#42 is basically done, we will need windows support sometime, but this is not done so well in Travis, so let's pull this out to a later long-term issue.

Test different browsers in CI

Right now we only test Safari.

• Firefox
• Chrome
• Edge

Update Keyring Diagram

It is out of date from the final implementation and needs to be revised.

https://github.com/iov-one/web4/blob/master/docs/KeyBaseDiagram.JPG

Implement ed25519 HD keyring

Like #23, except instead of generating a random key each time, we generate a unique seed on initialization, which we expose as a bip39 mneumonic. We then use a bip32 hd key derivation to generate a sequence of keys, based on a path that can be provided in the constructor.

We can generate new keys from this seed at will, and we can sign with any of them.

Please verify that you can generate a key in this KeyRing, properly sign a message, and verify the signature with @iov/crypto:Ed25519 using the public key returned from the keyring. This serves mainly as an example of normal usage of the HD Keyring, as well as a sanity check.

Rename Repo to iov-core

We need to update the repo name, package.json, some docs and probably 100 little things.

We want to go live with the repo and the main api package named iov-core bzw. @iov/core we can use iov-cli/@iov/cli for the cli for now.

We will focus on final name and branding effort closer to mainnet launch. No need to push a branch with alpha version.

Keyring Architecture Discussion

Keyring Architecture

Web4 needs to support a variety of chains, each with their own specifications for how addresses (accounts) are derived.

Key Terms:

• UserProfile: A collection of User materials. Includes multiple Keyrings associated with a UserIdentity.
• SecretIdentity: Private materials, used for signing transactions and deriving identities. Examples: privateKey, Secret Mnemonic (Passphrase), Hardware Device
• PublicIdentity: Public materials. Contains the master publicKey for the SecretIdentity + Algo pair. Used to compute address space components
• Personality: Derived Addresses that are chain specific. Usually defined via the HD specifications

JSON Def: 0d2d018
Other docs: https://github.com/iov-one/web4/pull/48/files

Specification Docs

Hierarchical Deterministic Wallets

• https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

Multi-Account Hierarchy for Deterministic Wallets

• https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
• https://github.com/satoshilabs/slips/blob/master/slip-0044.md

Make Sha256.digest synchonous

Right now, there is no good reason it needs to be asynchronous.

Also, renaming the method would be good to better differentiate between the static convenience hash function and the instance member digest().

This change affects a bunch of callers in this repo.

Basic UserProfile Controller with persistence

We produce a key controller that allows us to add multiple keyrings, of the same or different type, under multiple "usernames". It can dispatch requests to sign to any keyring. (It may also maintain some functions to verify signature based on algorithm, but these don't require access to any secrets... probably another issue?).

For now, we don't worry about encryption, just serialization/deserialization. We should be able to create a set of keys, persist to disk, then reload and sign messages with the same keys.

We will want to use this persistence mechanism at least in modern browsers (indexeddb) and via a node cli (leveldb/sqlite). I am partial to the https://github.com/Level/levelup interface with a number of backing stores, to which I have added an up-to-date indexeddb wrapper.

If you have another storage abstraction to work across browser, node (and ideally react native), please propose it here with a reason why it is better.

This may force us to clean up the API from #22 a little bit.

Implement connector to bcp-proxy API

This should implement the same interface that we have when talking to bcp-demo directly, but the backend can provide an adapter to any chain.

Raise Argon2 parameters for password hashing

The password to encryption key parameters in Argon2 are weak at the moment. We should increase to something that runs ~5 seconds and consumes ~50 MiB of memory. However, this must be done on a different thread.

I once implemented this is a WebWorker in a different project. It works in all modern browsers including Edge, where some hacking is needed to make libsodium run in a WebWorker. So this can be done.

However, it would be good to get a better idea of the use cases and JavaScript environments before fixing parameters and implementing the threading.

Create "meta codec" for serializing transactions

Scope: iov-write

We want to be able to add new transaction formats for blockchains, without requiring that all the code goes into web4 (with PRs) and must be published and updated on all clients... We also don't want to allow plugins of arbitrary code in web4-write, as it has access to the keys and is very sensitive.

Up to know, we define a custom code for each chain. Following #114, we now want to abstract that into "meta-codec" for serializing transactions that works for a "blockchain family". Thus we could use the weave format and sign byte calculations with dynamically loaded protobuf defintions, and then use that for bcp-demo, bns, and any other weave-based chain. We could set a list of contracts and APIs for the ethereum family and allow the same "meta-codec" to generate implementations pointing to specific contracts on eg. Rinkeby, ETH, and ETC.

• Define format for weave-based chains and implement "meta-codec"
• Add any "meta" into lisk based codec
• Define format (using standard eth tools) and define "meta-codec" for all ethereum/web3/rlp chains
• Test this is compatible with current bcp/bns implementation
• Add type-safety for bcp-basic and bns queries

This is maybe many issues, definitely many, many PRs

CLI for BNS

We need to add support for BNS (not just BCP), and a CLI to register chains, update them, etc.

Add support for HD keys to iov-crypto

Add the following primitives:

• Random byte generator (make clear where it comes from)
• Bip39 Mneumonic encoding/decoding
• Slip0010 Support ed25519 keys
• Bonus: secp256k1 Bip32/Bip44 HD derivation from master key

Allow imports of @iov/crypto

I get the following error in bns-codec package:

src/index.ts:1:24 - error TS2307: Cannot find module '@iov/crypto'.

1 import { Sha256 } from "@iov/crypto";

I do include it in package.json:

  "dependencies": {
    "@iov/crypto": "^0.0.0",

I think the issue happens to be the package.json for @iov/crypto:

  "main": "index.js",

I try the following:

  "main": "build/src/crypto.js",

And get a different error:

src/index.ts:1:24 - error TS7016: Could not find a declaration file for module '@iov/crypto'. '/home/ethan/js/web4/packages/iov-crypto/build/src/crypto.js' implicitly has an 'any' type.
  Try `npm install @types/iov__crypto` if it exists or add a new declaration (.d.ts) file containing `declare module 'iov__crypto';`

1 import { Sha256 } from "@iov/crypto";

Can you please improve the build/dist process?

Implement Node streaming API on top of tendermint

Building on #31 we will want to produce a nice streaming API with parsed data types to fulfill the desired generic Node interface.

We can wrap the tendermint rpc api with a higher-level functionality that:

• Transparently subscribes/unsubscribes as well as query to produce event streams (query state and watch changes)
• Encodes Transactions to proper byte format, and Decode transaction bytes into something for the end-user
• Decode state information from bytes into json representation (generic)
• Provide simple end-points to query or watch the state represented by any of the bcp data types

This should not only serve inside web4 to provide transaction history, account balance, nonce, etc for a secure wallet. But also it should be easily extendible by blockchain authors to support additional data types they wish to add.

Move devDependencies to root package.json

See https://github.com/lerna/lerna#common-devdependencies

"Manual" atomic swap

CLI should allow for easy command-line execution of Atomic Swaps

Write TypeScript wrapper for tendermint rpc

• Cover all endpoints
• Provide nice syntax
• Don't add transforms, but only what is exposed by tendermint
• (maybe add helpers for building subscriptions and queries?)

Upgrade @ledgerhq/hw-transport-node-hid to 4.22+

Starting with 4.22, @ledgerhq/hw-transport-node-hid includes the usb package, that causes an exception when required in an environment without USB (e.g. Travis).

Create iov-encoding

Rename

• asAscii -> toAscii for consistency

Move

• hex encode/decode
• ascii encode/decode
• class Uint32
• class Integer?

Create

• base64 encode/decode
• utf8 encode/decode
• RFC3339 encode/decode

Web 4 Specification

We need a proper specification of the web4 library.

The components and API (typescript definitions) and highlevel architecture

Clarify if we want to prehash before signing messages

NOTE This issue is not to do any coding, but just make a decision on our architecture

The original golang code uses https://godoc.org/golang.org/x/crypto/ed25519 which will produce the ed25519 signature of whatever we enter it. There is no prehashing here.

Every ledger code I have seen does prehashing on the transaction before signing. I am not sure if this is required, or just a convention. Maybe @rudi-cilibrasi knows better.

I did a little investigation and it seems there is a prehash step (using keccack) in ethereum as well:

• https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sign
• https://github.com/ethereumjs/ethereumjs-util/blob/master/index.js#L358-L385

When I worked on the first demo ledger app for cosmos, we had to use some flag to specify:

• this public key is in software, verify signature against full sign bytes
• this public key is in ledger, verify signature against sha256(sign bytes)

Needless to say this was clunky and didn't seem right. Let's discuss if we will need this prehashing step, and if so, consider doing it everywhere. This will update the signing algorithm used in weave, weave-js and in web4/@iov-keycontrol. We can pass the unhashed sign bytes to the keyring entries so they can verify the content (eg. ledger app), but then hash before signing them.

I would like some feedback here, especially anyone who has dealt with this issue before.

Upgrade TypeScript to 2.9

With TypeScript 2.9, our code does not compile anymore. The problematic piece is

  constructor(data?: KeyDataString) {
    const identities: PublicIdentity[] = [];
    const privkeys = new Map<string, Ed25519Keypair>();
    if (data) { // data is always of type undefined
      const decodedData = JSON.parse(data); // data is always of type undefined

Both constructor(data?: KeyDataString) and constructor(data: KeyDataString | undefined) do not work anymore, while constructor(data?: string) and constructor(data: string | undefined) are not problem.

I guess this is a bug in Typescript, so the next steps would be to write a minimal example and file a bugreport.

Expose API to iov-wallet (in process)

We need to deprecate weave-js and have the iov-wallet team use web4. To do so, they need to reproduce the current functionality with the new library.

• Review iov-wallet code to see what they need
• Meet with iov-wallet team to coordinate on the effort
• Implement missing endpoints (wrappers over our functionality)
• Integrate on a branch of iov-wallet
• Package and release (0.0.1? 0.1.0?) so they can use this code externally

Create "meta-codec" for parsing bns state

Scope: web4-read

We want to allow very flexible queries with iov-core.
With BCP-proxy we have access to json and can build dynamic queries easily.
If we want to allow the same power with a direct connection, we need a way of defining that.

• Define format for "codec definition": protobuf plus json transform plus?
• Write "meta-codec" that takes static files and initializes a chain-specific bcp/bns/??? read proxy
• Test this is compatible with current bcp/bns implementation
• Add type-safety for bcp-basic and bns queries

Perform sha512 on signbytes before signing / verifying sigs

This is tied to discussions on the signing process in order to get ledger compatibility

#70

Each KeyringEntry implementation should perform sha512 on the signbytes passed in before calculating the signature (to be compatible with a future v0.6 release of weave). The software implementations should do the Sha512 step software. The ledger implementation will do it on the embedded ledger firmware and gets the unhashed signbytes to parse and sign.

Write light-client proofs for tendermint rpc

We can actually prove all responses are tied to a header that is signed by the validator set, and quickly validate new headers. This code is working in golang in tendermint core https://github.com/tendermint/tendermint/tree/master/lite It would be interesting to expand this into our stack, so we can get these guarantees without trusting a proxy.

Cool stuff, but totally not on needed path for launch.

Make KeyringEntry plugins possible

All implementations of entries share the same interface KeyringEntry, which allows the Keyring to handle all entries equally. This way the Keyring does not need to know which entries exist at all and new entry types can be created as a plugin later on.

This plugin makes sense if we want to keep the ledger+usb support out of the web4/core package.

This decentralized entry setup is currently broken by the deserialization method of the Keyring, where the Keyring needs to know how to construct an Entry from a serialization string. In order to make the plugin mechanism work again, Keyring needs a registry on implementation ID -> deserializer and allow the user to register new entry types by passing an implementation ID and a deserialization function of type (data: KeyringEntrySerializationString) => KeyringEntry.

PoC/research ERC20 compatibility

Create KeyringEntry for Bns-Ledger app

https://github.com/iov-one/ledger-bns/issues/4 is done and there are typescript api for the ledger app in the web4 repo.

Now, we can make a keyring entry that exposes multiple accounts, using the "universal" purpose. And works well with the UserProfile.

Depends on: #132

Encode transactions and append signatures

The KeyRings and KeyController are working with Uint8Arrays to sign and verify. We want to sign transactions. This needs working codec.

Transactions are defined in json by the requester, serialized into bytes to sign (including a nonce) with a codec, which is passed to the keycontroller to generate a signature. The signature is appended to the transaction data and the whole thing is serialized to be posted to the blockchain.

We should have a working flow from a sendtx json to codec to keycontroller to a final, serialized transaction bytes, which can be validated by weave golang code.

We will need other codecs (for eg. ethereum, lisk) later, but easiest to start with the code we are running and control both sides.

Review dependencies

Old versions: 2018-07-21

Current dependency graph looks relatively solid. Some points to discuss

• cli should depend on api
• some @types/* dependencies should not be required by the user (move to dev dependencies)
• rename @iov/api and @iov/cli to @iov/web4 and @iov/web4-cli, otherwise we restrict ourselves to a single product inside the iov namespace
• review @iov/types
• review dependency on levelup/leveldown
• pull type tagger out of @iov/types

@Isabello @ethanfrey @rudi-cilibrasi do you have additions thoughts on that graph?

Implement ed25519 keyring

Basic implementation and complete tests for an implementation of a keyring (defined in #22) that used libsodium to sign. Ideally verify signatures are compatible with a test suite generated from weave (golang), but at least internally consistent.

Add tx codec support for lisk format

Add full support for entire BNS API

Building on #114 and #115, add defintions for the full BNS API, and some type-safe wrappers so we have access to all the funcitonality

Updating signbytes calculation in bns-codec

There is a proposal to modify the SignByte calculation in confio/weave: iov-one/weave#71

We must update the signing logic in @iov/bns-codec to remain compatible.

Define keyring/keycontroller API

Output is to define a TypeScript API and maybe stubs inside a new package in this repo. Also define the algorithms we will use (eg. scrypt + nacl secretbox for persisting secrets to disk) and libraries (eg. libsodium.js vs js-nacl, level-up?, etc.).

Inspired by the set of abstractions in metamask:

https://github.com/MetaMask/KeyringController
https://github.com/MetaMask/eth-simple-keyring
https://github.com/MetaMask/eth-hd-keyring
https://github.com/ethereumjs/ethereumjs-wallet

Each keyring just maintains a set of public/private keypairs and is responsible for signing messages as requested by the controller. There can be many implementations (here: secp256k1 hd keys, and a set of individual secp256k1 keys). We will want to focus on ed25519 keys, and ed25519 hd sequences. We will also want to support signing with hardware devices (eg ledger), so the sign functions should be async, like the MetaMask defintions.

The key controller maintains a set of keyrings and is responsible for managing them and directing requests to each one. The KeyController can read and write to disk (or indexdb in browser) for persistence, and should handle all encryption (I recomment the level-up abstraction as in weave-js). Each KeyRing may be encrypted with a unique passphrase. Each keyring may have a unique name, and we can present a username/passphrase "login" to decrypt a keyring. Once we have "logged in", we can use those keys for signing.

Here is a link to a golang implementation of a key manager, it has been somewhat audited, so may provide some direction to how to manage the secret material. https://github.com/tendermint/go-crypto/blob/master/keys/keybase.go

Add tx codec support for ethereum/rlp

• Support one known testnet with some hard-coded contract addresses and ABIs
• Assume we have full bcp-proxy support for all queries against ethereum

Find, integrate and test crypto library

Requirements

• sha256
• ed25519
• Argon 2 (key derivation)
• Authenticated encryption (for encrypted storage)
• (secp256k1?)

• Add testing setup
• Integrate libsodium-js
• Find sha256 implementation
• Integrate secp256k1

Write TxCodec for bcp-demo

This should transform the user requests into something we can sign and post to the blockchain

• We can use same/similar protobuf definitions as in bcp-proxy (bov.json).
• Handle all requests specified in the .d.ts files (send, atomic swap, ??)
• Provide encoding for signing (with nonce and chain_id, but no sigs)
• Provide encoding for posting (real tx plus all sigs)
• Provide decoding from posting (committed) to the user format

This should provide a first implementation of the interface so we can start to build a simple end-to-end tracer bullet check. Also it will be the needed implementation for the next overhaul of the existing iov-wallet ui.

web4 library stable

Get the web4 library stable, no UI yet, but all APIs implemented.
This is a milestone and tracks a number of other issues

• KeyBase Controller / encrypted storage
• KeyRing ed25519 simple
• KeyRing ed25519 hd
• Tx Registry (per chain)
• BCPDemo buildTx function
• Tendermint-trust client
• BCP client
• web4 private API
• web4 public API
• ts-repl bindings for developer cli (use both public/private)
• TESTS!

Find Observable implementation

In 2870cdf I tried to convert the property KeyringEntry.canSign into an Observable type in order to get notified about changes. In order to be able to always get the current value and receive updates, I used BehaviorSubject from rxjs.

Now the question is which Observable library we want. The only one I am familiar with (from Angular) is rxjs. Alternatives are xstream and zen-observable (by @ethanfrey).

I have no preference here. The only requirement I see right now is a type that supports current value + updates.

Open source repository

• Reach 1000 commit goal 🎉
• Review dependencies (#186)
• Change license to Apache 2
• Clear commit history to avoid publishing earlier software states as AGPL-3.0?
• Review licenses of dependencies yarn licenses list
• Finalize name of the library (see #208 )
• Commit build dirs to source control
• Set up .npmignore files on all repos
• Claim @Iov name on npm (or other if taken)
• Figure out how to publish lerna packages
• Verify we can import and build code in other repo (eg. iov-wallet)
• Add README to the repo for devs
• Add README to each sub-package for npm (with basic explanation of main entry point)
• (once we are satisfied it works) Set version to 0.1.0 on all packages and tag repo
• Remove currently uploaded releases https://github.com/iov-one/iov-core/releases for licensing reasons

Move "As" type tagger into iov-types

Securely encrypt stored private keys

We need to make the KeyController from #25 production quality, which means not leaking any private keys to other (malicious) process on the same machine.

We should use a secure algorithm (scrypt + nacl secretbox or better) to encrypt the data from the keyrings before persisting to disk. This passphrase will be needed to decrypt it, rendering all keys unusable if the passphrase is lost.

We should also think of how to handle key recovery sometime later (sure, write down an bip39 mneumonic, but for non-hd keys, that is unlikely to happen each time.... just a thought, maybe this inspires a new issue).

Make use of appropriate assertions when testing errors

CLI for web4-write against bcp-demo

Once all the components are ready, build a cli (or better repl) that works similar to the weave-js repl
(or the bov version in bcp-proxy), but is entirely based on web4.

This is our first dev tool to see if we can perform all operations using web4. This task is both to start building the developer tooling for web4, as well as to flesh out what features are missing and what APIs need to be adjusted.

ERC20 support for @iov/ethereum

Web4 library published (documented and supported)