nervosnetwork/ckb-cli

CKB command line interface

ckb-cli

CKB command line tool

Features

    rpc         Invoke RPC call to node
    account     Manage accounts
    mock-tx     Handle mock transactions (verify/send)
    tx          Handle common sighash/multisig transaction
    util        Utilities
    molecule    Molecule encode/decode utilities
    wallet      Transfer / query balance (with local index) / key utils
    dao         Deposit / prepare / withdraw / query NervosDAO balance (with local index) / key utils

All second level sub-commands are listed in wiki page.

Build this project

git clone https://github.com/nervosnetwork/ckb-cli.git
cd ckb-cli
cargo install --path . -f --locked

Usage

Better export an env first (or give in argument)

export API_URL=http://127.0.0.1:8114

Directly go to gorgeous interactive mode:

ckb-cli

Show available commands

# Top level help doc
ckb-cli --help
# RPC help doc
ckb-cli rpc --help

Example: Get tip header (yaml output format)

ckb-cli rpc get_tip_header

Response:

version: "0"
parent_hash: 0xb379bf3d369fccadfa69fa2273a8f596489b69dab996ca02a3eb1ae4cf765ca3
timestamp: "1567775474688"
number: "102"
epoch: "0"
transactions_root: 0xc4991d3e261c27a0ce7ea9801de5f0a5f56ffb82a29d7a6e8e7cf44dbb2db114
witnesses_root: 0x39116bc1a56f5ca82cf5226f172f97ff8a8d9626ca7e41d8cd92e76666e069f8
proposals_hash: 0x0000000000000000000000000000000000000000000000000000000000000000
difficulty: 0x4000000
extra_hash: 0x0000000000000000000000000000000000000000000000000000000000000000
uncles_count: "0"
dao: 0x0100000000000000af9a31ce318a230000cc083d71c4350000d774f0356a0000
nonce: "1876243812404095811"
hash: 0x0384ebc55b7cb56e51044743e05fb83a4edb7173524339c35df4c71fcdb0854d

Example: Get live cell (json output format)

ckb-cli rpc get_live_cell --tx-hash 0x4ec75b5a8de8d180853d5046760a99285c73283a5dc528f81d6ee056f5335172 --index 0

Response:

{
  "cell": {
    "capacity": "125000000000",
    "lock": {
      "args": [
        "0x64257f00b6b63e987609fa9be2d0c86d351020fb"
      ],
      "code_hash": "0x1892ea40d82b53c678ff88312450bbb17e164d7a3e0a90941aa58839f56f8df2",
      "hash_type": "type"
    },
    "type": null
  },
  "status": "live"
}

Example: Indexer get cells (yaml output format)

Prepare file searchkey.json as input parameters:

{
    "script": {
        "code_hash": "0xbbad126377d45f90a8ee120da988a2d7332c78ba8fd679aab478a19d6c133494",
        "hash_type": "data1",
        "args": "0x"
    },
    "script_type": "type",
    "script_search_mode": "prefix",
    "filter": {
        "output_data": "0xa58618a553",
        "output_data_filter_mode": "partial"
    },
    "with_data": false
}

ckb-cli rpc get_cells --json-path ./searchkey.json --order asc --limit 1

Response:

last_cursor: 0x60bbad126377d45f90a8ee120da988a2d7332c78ba8fd679aab478a19d6c1334940215a27c046d5994a234629566f7e813c76a6ba9f9ec0338a11cbcc6629695ef7500000000009f78950000000100000001
objects:
  - block_number: 10451093
    out_point:
      index: 1
      tx_hash: 0x05a29ec877603526c25744634359fda6ba8d390b48a8c4830fcc7a196fccb9c3
    output:
      capacity: "22381.0"
      lock:
        args: 0x01cc0af0af911dd40853b8c8dfee90b32f8d1ecad600
        code_hash: 0xf329effd1c475a2978453c8600e1eaf0bc2087ee093c3ee64cc96ec6847752cb
        hash_type: type
      type:
        args: 0x15a27c046d5994a234629566f7e813c76a6ba9f9ec0338a11cbcc6629695ef75
        code_hash: 0xbbad126377d45f90a8ee120da988a2d7332c78ba8fd679aab478a19d6c133494
        hash_type: data1
    output_data: ~
    tx_index: 1

Example: Indexer get transactions (yaml output format)

Prepare file searchkey.json as input parameters:

{
    "script": {
        "code_hash": "0xbbad126377d45f90a8ee120da988a2d7332c78ba8fd679aab478a19d6c133494",
        "hash_type": "data1",
        "args": "0x"
    },
    "script_type": "type",
    "script_search_mode": "prefix",
    "with_data": false
}

ckb-cli rpc get_transactions --json-path ./searchkey.json --order asc --limit 3

Response:

last_cursor: 0xa0bbad126377d45f90a8ee120da988a2d7332c78ba8fd679aab478a19d6c13349402013368282f4cde04254a3a6a2027b33f7c974046a4d5cbd96bc47d7f058c18090000000000b29e04000000050000000000
objects:
  - block_number: 10375179
    io_index: 1
    io_type: output
    tx_hash: 0x551ec96717c336b74bbb2e56a1cb9c73e2a9d4b56321079b454cfc1c0e6036ac
    tx_index: 7
  - block_number: 11705844
    io_index: 0
    io_type: output
    tx_hash: 0xd690aa336c0d05808e08a97ba2f3031b7691341df9002b305c2d27cb116e2705
    tx_index: 5
  - block_number: 11705860
    io_index: 0
    io_type: input
    tx_hash: 0xa3282c23227992933eee0a07e5cbf52ca62006b98f2d113ebf579c5e59cf5a62
    tx_index: 5

ckb-cli's Issues

mock-tx not work well

Using mock-tx to debug my script on Testnet, when I tried
ckb-cli mock-tx complete --tx-file debug-tx.json
I get

Can not find data hash in mock deps:
Byte32(0x0017038a0dbe0b8bcbdd4fd500cacea7884c4cd6ec58394c6d1ad3db1397179f)

---

data hash 0x0017038a0dbe0b8bcbdd4fd500cacea7884c4cd6ec58394c6d1ad3db1397179f is my script binary hash, located in tx 0x98de8fc20b8cde2cac709d75658cf534eb4e06be4fdefc7e9826491e372d0480 ,
any thing wrong here ?

---

here is my debug-tx.json

{
  "mock_info": {
    "cell_deps": [
      {
        "cell_dep": {
          "dep_type": "code",
          "out_point": {
            "index": "0x0",
            "tx_hash": "0x98de8fc20b8cde2cac709d75658cf534eb4e06be4fdefc7e9826491e372d0480"
          }
        },
        "data": "0x31323334",
        "output": {
          "capacity": "0xdf8475800",
          "lock": {
            "args": "0x591507c15a342092f529d34836d035e04d626582",
            "code_hash": "0x0017038a0dbe0b8bcbdd4fd500cacea7884c4cd6ec58394c6d1ad3db1397179f",
            "hash_type": "data"
          },
          "type": null
        }
      }
    ],
    "header_deps": [
      {
        "compact_target": "0x20800000",
        "dao": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "epoch": "0x0",
        "hash": "0xec82455dc74efffccfaca1cc987867c319e9a1e17863ca4371db19a4ff21b0e0",
        "nonce": "0x0",
        "number": "0x0",
        "parent_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "proposals_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "timestamp": "0x0",
        "transactions_root": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "uncles_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "version": "0x0"
      }
    ],
    "inputs": [
      {
        "data": "0x61626364",
        "input": {
          "previous_output": {
            "index": "0x0",
            "tx_hash": "0x000000000000000000000000000000000000000000000000000000000000ff02"
          },
          "since": "0x0"
        },
        "output": {
          "capacity": "0x6fc23ac00",
          "lock": {
            "args": "0x591507c15a342092f529d34836d035e04d626582",
            "code_hash": "0x0017038a0dbe0b8bcbdd4fd500cacea7884c4cd6ec58394c6d1ad3db1397179f",
            "hash_type": "data"
          },
          "type": null
        }
      }
    ]
  },
  "tx": {
    "cell_deps": [
      {
        "dep_type": "code",
        "out_point": {
          "index": "0x0",
          "tx_hash": "0x98de8fc20b8cde2cac709d75658cf534eb4e06be4fdefc7e9826491e372d0480"
        }
      }
    ],
    "header_deps": [],
    "inputs": [
      {
        "previous_output": {
          "index": "0x0",
          "tx_hash": "0x000000000000000000000000000000000000000000000000000000000000ff02"
        },
        "since": "0x0"
      }
    ],
    "outputs": [
      {
        "capacity": "0x2cb417800",
        "lock": {
          "args": "0x591507c15a342092f529d34836d035e04d626582",
          "code_hash": "0x0017038a0dbe0b8bcbdd4fd500cacea7884c4cd6ec58394c6d1ad3db1397179f",
          "hash_type": "data"
        },
        "type": {
          "args": "0x591507c15a342092f529d34836d035e04d626582",
          "code_hash": "0x0017038a0dbe0b8bcbdd4fd500cacea7884c4cd6ec58394c6d1ad3db1397179f",
          "hash_type": "data"
        }
      }
    ],
    "outputs_data": [
      "0x"
    ],
    "version": "0x0",
    "witnesses": [
      "0x1212"
    ]
  }
}

Plugin System: WitnessArgs are not provided in the SignTarget Object

The Ledger plugin (and thus Ledger device/app) is not receiving witness args in a multi-sig context from the plugin system. As a result, multisig operations cannot currently be signed by the Ledger app.

The Ledger app needs the witness args, which can be provided before signing by leaving the signatures zeroed out.

Here is a patch we applied to our fork to address this, use as much of it as you like! obsidiansystems@6b1c4dc

`tx sign-inputs` does not take sighash address as an option (on testnet)

Tested on b2c35a486ec766008acfea778a4d33c87acf2724

It seems either the --help command is incorrect, there is a bug when trying to use a sighash address in --from-account, or testnet addresses are not supported. The --help states sighash addresses should work:

        --from-account <from-account>    The account's lock-arg or sighash address (transfer from this account)

But if you try to use one as the --from-account, the operation results in a parse failure:

CKB> tx sign-inputs --from-account ckt1qyqv8256ceslzzp72rxfz5wutpsfk35jzdasfwd9fd --tx-file tx.json
parse hex string failed: Invalid character

Switching to the account's lock-arg will work, however:

CKB> tx sign-inputs --from-account 0x3e2ad665a2cb4696d3fc4a217047dd25e30d73cd --tx-file tx.json
Password:
- lock-arg: 0x3e2ad665a2cb4696d3fc4a217047dd25e30d73cd
  signature: 0x3c37421080ad3c3e5a9488acbb2cd84806a33e273388b255495d118edc87df85095aa37af7518fd20896884722f632cd1923a7180440bcfa4724686de32c06f501

Thanks in advance!

ckb-cli crashes at dao prepare

When issuing a well formed dao prepare command, ckb-cli crashes like this:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/macros/mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

ckb version: 0.32.1
ckb-cli version: 0.32.0

TUI error

RUST_BACKTRACE=1

Check ckb version for compatibility when startup (by local_node_info)

{
  "addresses": [
    {
      "address": "/p2p/QmWBeLYcnVJqhDkeMEf64QFx43inHGEtLToUdTFrNxpqHy",
      "score": "255"
    },
    {
      "address": "/ip4/0.0.0.0/tcp/8116/p2p/QmWBeLYcnVJqhDkeMEf64QFx43inHGEtLToUdTFrNxpqHy",
      "score": "1"
    }
  ],
  "is_outbound": null,
  "node_id": "QmWBeLYcnVJqhDkeMEf64QFx43inHGEtLToUdTFrNxpqHy",
  "version": "0.12.0 (v0.12.0-11-g4f5ec5f7 2019-05-18)"
}

ckb-cli should support time locked multi-sign address

ckb-sdk：TxHelper need a function to reorder input cell by input group

Reorder input cell by input group will reduce transaction size, because it wll reduces witnesses size.

• For inputs [g1, g2, g1], we need 2 witnesses [witness1, witness2].
• For inputs [g1, g2, g1, g3], we need 4 witnesses includes an empty bytes to align witness3 for g3 [witness1, witness2, (empty bytes), witness3].
• For inputs [g1, g2, g2, g1], we need witnesses [witness1, witness2].
• For inputs [g1, g1, g1, g1], we need witnesses [witness1].

Feature Request: Show testnet addresses with `account bip44-addresses`

account bip44-addresses is a useful subcommand for showing change and receiving addresses with their derivation path, but it only shows mainnet addresses. It would be great if you could pass an optional --network argument which defaults to mainnet but also accepts testnet to show ckt... addresses.

Current behavior was confirmed as of 856af0b8a29043f36f06d4f5be7744a293ae24d2. Thanks!

Support encode molecule / blake2b data from stdin

Supporting stdin can make integration with other commands easer.

--json-path can accepts value - as stdin. The blake2b command can read hex binary from stdin if it is not specified as command line argument.

Example:

The cell 0xc7813f6a415144643970c2e88e0bb6ca6a8edc5dd7c1022746f628284a9936d5.outputs[0x0] matches the information in the sUDT RFC, which type is

{
    "args": "0xcf37df53ec0eb890937879ad5587521f737dc3d95eb1c22194b958ecbcf39a8b",
    "codeHash": "0x00000000000000000000000000000000000000000000000000545950455f4944",
    "hashType": "type"
}

Its type hash is expected to be 0x5e7a36a77e68eecc013dfa2fe6a23f3b6c344b04005808694ae6dd45eea4cfd5 and can be verified by

echo '{ "args": "0xcf37df53ec0eb890937879ad5587521f737dc3d95eb1c22194b958ecbcf39a8b", "code_hash": "0x00000000000000000000000000000000000000000000000000545950455f4944", "hash_type": "type" }' > 0x5e7a36a77e68eecc013dfa2fe6a23f3b6c344b04005808694ae6dd45eea4cfd5.json
ckb-cli molecule encode --json-path 0x5e7a36a77e68eecc013dfa2fe6a23f3b6c344b04005808694ae6dd45eea4cfd5.json --type Script --output-type hash

Originally posted by @doitian in nervosnetwork/rfcs#202 (comment)

Help wanted: Err : TokioCoreError("Unable to create")

Running ckb-cli (2a7ed95) on MacOS 10.15.4 and get this error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:   
Error(TokioCoreError("Unable to create"), State { next_error: Some(Os { code: 24, kind: Other,   
message: "Too many open files" }), backtrace: InternalBacktrace { backtrace: None } })',   
src/libcore/result.rs:1188:5

Backtrace as follow:

1: backtrace::capture::Backtrace::new_unresolved
2: error_chain::backtrace::imp::InternalBacktrace::new
3: <core::result::Result<T,E> as jsonrpc_client_http::ResultExt>::chain_err
4: jsonrpc_client_http::create_standalone_core
5: std::sys_common::backtrace::__rust_begin_short_backtrace
6: std::panicking::try::do_call
7: __rust_maybe_catch_panic
8: core::ops::function::FnOnce::call_once{{vtable.shim}}
9: <alloc::boxed::Box as core::ops::function::FnOnce>::call_once
10: std::sys::unix::thread::Thread::new::thread_start
11: _pthread_start
) } })', src/libcore/result.rs:1188:5
stack backtrace:
0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::panicking::default_hook::{{closure}}
4: std::panicking::default_hook
5: std::panicking::rust_panic_with_hook
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::result::unwrap_failed
9: ckb_sdk::rpc::client::RawRpcClient<jsonrpc_client_http::HttpHandle>::from_uri
10: ckb_cli::interactive::InteractiveEnv::from_config
11: ckb_cli::main
12: std::rt::lang_start::{{closure}}
13: std::panicking::try::do_call
14: __rust_maybe_catch_panic
15: std::rt::lang_start_internal
16: main
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

Are there any way to fix this error?

The command line mode has no warning message about the out-dated index

Chat log from Telegram

Kenny Bambridge, [May 18, 2020 at 7:40:51 AM]:
ckb-cli wallet get-capacity --address ckt1**wgna
total: 0.0 (CKB)

thats what it outputs

but thats what it shows in ckb studio

Matt Quinn, [May 18, 2020 at 7:41:40 AM]:
does the balance for the other address come back correct?

Kenny Bambridge, [May 18, 2020 at 7:41:45 AM]:
no

ckb-cli just doesn't seem to output it correctly

Matt Quinn, [May 18, 2020 at 7:42:06 AM]:
can you check if the block fields are matching up?

like latest block?

Kenny Bambridge, [May 18, 2020 at 7:48:25 AM]:
yep they match closely

20978

20984

it just updates every 5s

Kenny Bambridge, [May 18, 2020 at 7:50:16 AM]:
so I can see the two transactions from ckb-cli: ckb-cli 
rpc get_transactions_by_lock_hash --hash 0x2b0f**366419 --page 0
- created_by:
    block_number: 20593
    tx_hash: 0x5930e**13516c
    index: 0
  consumed_by: ~
- created_by:
    block_number: 20659
    tx_hash: 0x3f833**4c08
    index: 0
  consumed_by: ~

I sent two transactions with 20000 ckb

transaction:
  version: 0
  cell_deps:
    - out_point:
        tx_hash: 0xace5**13058555b708
        index: 0
      dep_type: dep_group
  header_deps: []
  inputs:
    ...
  outputs:
    - capacity: "20090.0"
      lock:
        code_hash: 0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8 (sighash)
        args: 0x2fa3c***b7249
        hash_type: type
      type: ~
  outputs_data:
    - 0x
  witnesses:
    ...
  hash: 0x3f833d***2f7464c08
tx_status:
  status: committed
  block_hash: 0x41fd***e1e3aa03cd4

Kenny Bambridge, [May 18, 2020 at 7:53:36 AM]:
^ proof that it actually sent 20009 ckb

I think something is wrong with the get-capacity function in ckb-cli

Kenny Bambridge, [May 18, 2020 at 8:03:55 AM]:
Okay @MattQuinn I found the issue...

I didn't run ckb-cli server

the command should probably warn you if that's not running

all it does is report 0 CKB LOL

ian, [May 18, 2020 at 8:16:30 AM]:
I think that's not the reason. CKb-cli will synchronize data from the node and build its own index. The command line option --wait-for-sync tells ckb-cli to block until the index is up-to-dated. Ckb-cli needs to run in the background to build the index, the interactive mode and ckb-cli server will do the trick. I believe in the interactive mode, ckb-cli does throw warning when the index is not ready yet, it seems that such warning is absent in command line mode.

Should the `--wait-for-sync` option be enabled defaultly?

Suggestion:

• Make wait-for-sync default enabled.
• Provides a negative option --no-sync to disable wait-for-sync.

Reasons:

• User expect the correct result, but without the option, ckb-cli often returns the unexpected result, which confuses users.
• Mostly subcommand depend on the index state, which often can't work properly if index is lack of syncing.
• We should make the program safe and usable default.

ckb-cli should support 2-phase DAO

Support using `stdin` as a input argument (shell pipe)

Now, a lot of sub-commands of ckb-cli require exporting data into files before pass them into next sub-commands.

In current, I have to write code like this:

ckb-cli tx init --tx-file "${ckb_tmp_txfile}"

echo "${privkey}" > "${privkey_file}"
ckb-tx sign-inputs --tx-file "${ckb_tmp_txfile}" \
    --privkey-path "${privkey_file}" \
    --add-signatures
rm "${privkey_file}"

cat "${ckb_tmp_txfile}" \
    | jq -r ".transaction.outputs[0].lock.code_hash = \"0x${lock_code_hash}\"" \
    | jq -r ".transaction.outputs[0].lock.hash_type = \"data\"" \
    | jq -r ".transaction.outputs[0].lock.args = \"0x\"" \
    | jq -r ".transaction.outputs[0].type = null" \
    | jq -r ".transaction.outputs_data[0] = \"0x\"" \
    > "${ckb_tmp_txfile}.tmp"
mv "${ckb_tmp_txfile}.tmp" "${ckb_tmp_txfile}"
ckb-cli tx send --tx-file "${ckb_tmp_txfile}" --skip-check
rm "${ckb_tmp_txfile}"

But, if ckb-cli support using stdin as a input argument, all temporary files are unnecessary.

For example, if - means stdin, the above code can be rewrite like this:

ckb-cli tx init --tx-file - \
    | ckb-tx sign-inputs --tx-file - --privkey "${privkey}" --add-signatures \
    | jq -r ".transaction.outputs[0].lock.code_hash = \"0x${lock_code_hash}\"" \
    | jq -r ".transaction.outputs[0].lock.hash_type = \"data\"" \
    | jq -r ".transaction.outputs[0].lock.args = \"0x\"" \
    | jq -r ".transaction.outputs[0].type = null" \
    | jq -r ".transaction.outputs_data[0] = \"0x\"" \
    | ckb-cli tx send --tx-file - --skip-check

Could I provide a `ckb.toml` to input some arguments (for example: RPC port)

For example, I use an argument or an environment variable to provide the ckb data directory, then ckb-cli can fill some arguments automaticlly.

Associated Issues: #283

Using the lock-arg of a keyfile extended-address in a transfer reports a Ledger error

I'm using:

• CKB-CLI: 0.35.0
• Ledger Plugin: v0.2.0

Recognizing that the proper way to construct a wallet transfer command that uses capacity from derived addresses is to use the root account's lock-arg as the --from-account, if you use the lock-arg of an extended-address you will see a Ledger error even though key from local file storage is used. This has proven confusing at times while testing Ledger features and comparing results with keys from local file storage.

Reproduction Steps

Here are my addresses and their balances

CKB> account list
...
- "#": 3
  address:
    mainnet: ckb1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kslrwglp
    testnet: ckt1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kszxshna
  has_ckb_root: false
  lock_arg: 0x533d23813da928934a97de92b0810f437b4cdd6d
  lock_hash: 0x8438647a667fcd57dd31f259f751e7e5af9924c8d4a8bc56b5b685e2586d2217
  source: Local File System

CKB> account extended-address --lock-arg 0x533d23813da928934a97de92b0810f437b4cdd6d --path "m/44'/309'/0'/0/0"
Password:
address:
  mainnet: ckb1qyqzjk834kaayapnzfq9ejxudpc2fscfruzqpv9xkq
  testnet: ckt1qyqzjk834kaayapnzfq9ejxudpc2fscfruzqufme6u
lock_arg: 0x2958f1adbbd2743312405cc8dc6870a4c3091f04

CKB> wallet get-capacity --address ckt1qyqzylky4l68z9gqc8wu0zfjvcj8ujjlzfksju6dka
total: 3000.0 (CKB)

CKB> wallet get-capacity --address ckt1qyqzjk834kaayapnzfq9ejxudpc2fscfruzqufme6u
total: 3000.0 (CKB)

CKB> account extended-address --lock-arg 0x533d23813da928934a97de92b0810f437b4cdd6d --path "m/44'/309'/0'/1/0"
Password:
address:
  mainnet: ckb1qyq2pxlsn0nmzx7s3f2pua3x5aj3teqxwkmqmk585n
  testnet: ckt1qyq2pxlsn0nmzx7s3f2pua3x5aj3teqxwkmqxn2cc0
lock_arg: 0xa09bf09be7b11bd08a541e7626a76515e40675b6

Actual Result: Attempting to transfer from the extended-address lock-arg reports a Ledger error, even though the accounts in question are all stored in the local file system:

CKB> wallet transfer --from-account 0x2958f1adbbd2743312405cc8dc6870a4c3091f04 --to-address ckt1qyqg64fqws0sdgrz2s7da2dzrlpq6plw9xcq2e8e5l --capacity 1000 --tx-fee 0.001 --derive-change-address ckt1qyq2pxlsn0nmzx7s3f2pua3x5aj3teqxwkmqxn2cc0
Ledger account for lock_arg: H160 ( [ 0x29, 0x58, 0xf1, 0xad, 0xbb, 0xd2, 0x74, 0x33, 0x12, 0x40, 0x5c, 0xc8, 0xdc, 0x68, 0x70, 0xa4, 0xc3, 0x09, 0x1f, 0x04 ] ) not found

Expected Result: The error message would reference that it cannot find the lock-arg in a way that is inclusive of all the local file system.

As you might expect, using the lock-arg of the root account works!

CKB> wallet transfer --from-account 0x533d23813da928934a97de92b0810f437b4cdd6d --to-address ckt1qyqg64fqws0sdgrz2s7da2dzrlpq6plw9xcq2e8e5l --capacity 1000 --tx-fee 0.001 --derive-change-address ckt1qyq2pxlsn0nmzx7s3f2pua3x5aj3teqxwkmqxn2cc0
Password:
Password:
0xa2a4a24cfcffd8634612cf6793099cb64ea895fb1b87f2e33ce68541de42e9b1

After installing plugin the default keystore does not work due to missing password

If a plugin is installed which does not need a password, the ckb-cli does not prompt for password for the default keystore.
So most of the commands stop working for the default keystore account.

The logic of this API should be fixed to decide the password requirement based on the keystore being used (default or plugin)

ckb-cli/src/plugin/manager.rs

Lines 227 to 231 in 6622443

	pub fn keystore_require_password(&self) -> bool {
	self.actived_keystore()
	.map(|(_, _, require_password)| require_password)
	.unwrap_or(true)
	}

wallet get-capacity --address <address> 命令报 Rocksdb error

Rocksdb error: IO error: lock : /root/.ckb-cli/index/0x82b930c957d4f98f8e8214d567a964e3e2814e4a09243eedfe727f/LOCK: No locks available

Messages cannot be signed by extended addresses, only accounts

Tested on 856af0b

Messages can be signed by accounts, but it seems they cannot be signed by extended addresses.

CKB> account list
...
- "#": 3
  address:
    mainnet: ckb1qyqzylky4l68z9gqc8wu0zfjvcj8ujjlzfks0eyj6p
    testnet: ckt1qyqzylky4l68z9gqc8wu0zfjvcj8ujjlzfksju6dka
  lock_arg: 0x227ec4aff4711500c1ddc7893266247e4a5f126d
  lock_hash: 0x7e7142b84f567039b7fc1a7186bee9f4be30efdca46e3e8c4f8efb058040135d

I then derive an address from this account

CKB> account extended-address --lock-arg 0x227ec4aff4711500c1ddc7893266247e4a5f126d --path "m/44'/309'/0'/0/0"
Password:
address:
  mainnet: ckb1qyq8ma3xf7x7unls4a9l0uq8huz8h2k8j4jqdurvwf
  testnet: ckt1qyq8ma3xf7x7unls4a9l0uq8huz8h2k8j4jqseanz4
lock_arg: 0x7df6264f8dee4ff0af4bf7f007bf047baac79564

I can sign a message with the account's sighash:

CKB> util sign-message --from-account ckt1qyqzylky4l68z9gqc8wu0zfjvcj8ujjlzfksju6dka --message 435cf99e6d25fb179264edfdeb11261f406be3c7350d9031d07ec10f1695b393
Password:
recoverable: false
signature: 0xa7fb4d4390058cd84f8fa9face08f4c6ed035b0a2ba1f19699625deb072cc97c42a69685951512ac0bdba71f6870fa293ce40d507bea3078e952c6fbc71d903a

or its lock-arg:

CKB> util sign-message --from-account 0x227ec4aff4711500c1ddc7893266247e4a5f126d --message 435cf99e6d25fb179264edfdeb11261f406be3c7350d9031d07ec10f1695b393
Password:
recoverable: false
signature: 0xa7fb4d4390058cd84f8fa9face08f4c6ed035b0a2ba1f19699625deb072cc97c42a69685951512ac0bdba71f6870fa293ce40d507bea3078e952c6fbc71d903a

But signing a message with an extended address does not seem to work:

CKB> util sign-message --from-account ckt1qyq8ma3xf7x7unls4a9l0uq8huz8h2k8j4jqseanz4 --message 435cf99e6d25fb179264edfdeb11261f406be3c7350d9031d07ec10f1695b393
Password:
Account not found: 7df6264f8dee4ff0af4bf7f007bf047baac79564

And neither does the extended address' lock-arg:

CKB> util sign-message --from-account 0x7df6264f8dee4ff0af4bf7f007bf047baac79564 --message 435cf99e6d25fb179264edfdeb11261f406be3c7350d9031d07ec10f1695b393
Password:
Account not found: 7df6264f8dee4ff0af4bf7f007bf047baac79564

Thanks in advance for your help!

Virtual workspace root and [patch]

Have you all considered using a non-package virtual workspace root (https://doc.rust-lang.org/cargo/reference/manifest.html#virtual-manifest) along with the [patch] section? It makes it easier to not repeat patch dependencies or overrides of crates.io dependencies in each crate.

add lock hash in wallet key-info

get_cells_by_lock_hash need lock hash, but there is no cmd to get it.

Upgrade to nervosnetwork/rust-rocksdb 6.7.3

nervosnetwork/rust-rocksdb has bumped to 6.7.3

DAOBuilder handle the change problems

ckb-cli/src/subcommands/dao/builder.rs

Line 65 in 7534073

if change_capacity > 0 {

We cannot handle the change problems when the change amount is less than MIN_SECP_CELL_CAPACITY, which will cause an "InsufficentCapacity" error because the change cell does not have sufficient occupied capacity.

if change_capacity >= MIN_SECP_CELL_CAPACITY { would be OK.

Invalid cell status: dead, out_point: OutPoint { tx_hash: Byte32(xxxxxx), index:Uint32(xxxx) }

When I use ckb-cli to transfer some CKB, I got this error: "Invalid cell status: dead, out_point: OutPoint { tx_hash: Byte32(xxxxxx), index:Uint32(xxxx) }". And I do these operations in dev chain. Thank you!

Cli should be able to migrate the database schema

Cli should be able to migrate the database schema, refer to how ckb implement it.

Originally posted by @doitian in #218 (comment)

Return `ok` for no-outputs commands is terrible

Some commands return ok when do successful execution

For example:

• ckb-cli tx init
• ckb-cli tx add-input
• ckb-cli tx add-output
• ckb-cli tx sign-inputs

Why it is terrible

• The ok is not YAML or JSON format, so it means --output-format < json | yaml > doesn't work for these commands.
  For example, ckb-cli tx send returns TX_HASH without --output-format and it returns "TX_HASH" with --output-format json.
  So I can't define a function to wrap ckb-cli --output-format json to use json format to parse outputs.
  If I have to add parsing statements after each ckb-cli commands, it is terrible.
  In current, I have to write code like this (pseudo code):

  def call_ckb_cli(args):
      let (return_code, output) = execute("ckb-cli", "--output-format", "json", args)
      if return_code != 0:
          return Err(())
      if output == "ok":
          return Ok(JSON::null())
      else
          return Ok(JSON::new(output))
  

• Sometimes ckb-cli returns data and sometimes it returns executing states.
  It's disunity.
• When using ckb-cli in bash, the result can be checked with the return code. But I have to add >/dev/null for some ckb-cli commands when I want to redirect the outputs.
  I have to remember which returns executing states and which returns data, it is terrible.

Suggestions

I think there are few solutions:

• Add --quiet argument.
• (I prefer to this) Returns "ok" when use --verbose.
• (and this) Output ok to stderr.
• Output nothing for these commands.

Add eaglesong subcommand

Inputs from a HW Wallet extended-address are not recognized as such during 'tx sign-inputs'

CKB-CLI recognizes the lock-arg of the root Ledger account m/44'/309'/0' is from the Ledger device, but it does not recognize that extended-addresses, such as m/44'/309'/0'/0/0 are associated with the hardware wallet. As a result, they cannot be signed with during tx sign-inputs.

Here are both the root and an extended-address:

CKB> account extended-address --lock-arg 0x8d5520741f06a062543cdea9a21fc20d07ee29b0 --path "m/44'/309'/0'"
address:
  mainnet: ckb1qyqg64fqws0sdgrz2s7da2dzrlpq6plw9xcqhuexcr
  testnet: ckt1qyqg64fqws0sdgrz2s7da2dzrlpq6plw9xcq2e8e5l
lock_arg: 0x8d5520741f06a062543cdea9a21fc20d07ee29b0

CKB> account extended-address --lock-arg 0x8d5520741f06a062543cdea9a21fc20d07ee29b0 --path "m/44'/309'/0'/0/0"
address:
  mainnet: ckb1qyqw2fsdswd8s6kz4yy3s80e5s3lrma7sc7sugcvv9
  testnet: ckt1qyqw2fsdswd8s6kz4yy3s80e5s3lrma7sc7spdxnqe
lock_arg: 0xe5260d839a786ac2a909181df9a423f1efbe863

I've used them each as inputs in a transaction:

CKB> tx info --tx-file multi-input.json
[input] ckt1qyqg64fqws0sdgrz2s7da2dzrlpq6plw9xcq2e8e5l => 1000.0, (data-length: 0, type-script: none, lock-kind: sighash(secp))
[input] ckt1qyqw2fsdswd8s6kz4yy3s80e5s3lrma7sc7spdxnqe => 1000.0, (data-length: 0, type-script: none, lock-kind: sighash(secp))
[output] ckt1qyqru2kkvk3vk35k607y5gtsglwjtccdw0xssjfass => 1999.99, (data-length: 0, type-script: none, lock-kind: sighash(secp))
input_total: 2000.0 (CKB)
output_total: 1999.99 (CKB)
tx_fee: 0.01 (CKB)

I can sign with the root path:

CKB> tx sign-inputs --from-account 0x8d5520741f06a062543cdea9a21fc20d07ee29b0 --tx-file multi-input.json
- lock-arg: 0x8d5520741f06a062543cdea9a21fc20d07ee29b0
  signature: 0x22a9b459e114b712f97a491739e0fe5c682dbe73cecd246fc3e6184c81701de70e2626bc022558900aadf1cabd618e6b06986fd3f24284da8c1dbe45ffea47f601

But signing fails with the extended-address, as CKB-CLI does not know it is from the hardware wallet:

CKB> tx sign-inputs --from-account 0xe5260d839a786ac2a909181df9a423f1efbe863d --tx-file multi-input.json
Ledger account for lock_arg: H160 ( [ 0xe5, 0x26, 0x0d, 0x83, 0x9a, 0x78, 0x6a, 0xc2, 0xa9, 0x09, 0x18, 0x1d, 0xf9, 0xa4, 0x23, 0xf1, 0xef, 0xbe, 0x86, 0x3d ] ) not found

Note: The error message above is incorrect as reported here - #343. I'll update this issue after testing this again on https://github.com/nervosnetwork/ckb-cli/tree/ledger-support

Suggested Solution

Since CKB-CLI has the ability to search derived (extended) addresses, perhaps the user can have the option of supplying information about the root Ledger address during tx sign-inputs.

For instance:

CKB> tx sign-inputs --from-account 0xe5260d839a786ac2a909181df9a423f1efbe863d --root-address ckt1qyqg64fqws0sdgrz2s7da2dzrlpq6plw9xcq2e8e5l --tx-file multi-input.json

A simpler flag such as --ledger wouldn't work here as the user can have multiple accounts in the same client tied to different Ledger devices. Any suitable solution should reference a specific account for CKB-CLI to search.

ckb-cli open too many threads

Number of threads jumps crazy after the two steps.

1. Open the interactive mode and leave.
2. shutdown the ckb node.

Seems like the index threads hangs.

Mock-tx for lock script verify failed when ckb-standalone-debugger succeed

Recently I'm developing a script which aims at unlock tx using BLS signature . The script validated successfully using ckb-standalone-debugger, consumed 3429643889 cycles. When trying verify script by using ckb-cli mock-tx verify , script do not exit normally, instead script execute again and finally failed , throw

Error { kind: InternalError { kind: Compat { error: ErrorMessage { msg: "InvalidEcall(57)" } }

I don't know where is the problem, can you help me ?

Screen shot

script binary and mocked-tx.json

blsverify.zip

Suggestion: Add functionality to automatically clear cache when necessary.

It would be beneficial to automatically clear the ckb-cli cache when it is detected that the active ckb instance differs from what was cached.

As seen below, I had performed a full reset on the dev chain, but the wallet command was still returning information from the deleted chain.

CKB> rpc get_tip_block_number
507
CKB> wallet get-live-cells --lock-hash 0x5094cc3c0e78c997c9c4ed53cdba443739c83cbca9e2487ff3b17b821e61dad9 --limit 1
current_capacity: 2009.88422898 (CKB)
current_count: 1
live_cells:
  - capacity: 2009.88422898 (CKB)
    data_bytes: 0
    index:
      output_index: 0
      tx_index: 0
    lock_hash: 0x5094cc3c0e78c997c9c4ed53cdba443739c83cbca9e2487ff3b17b821e61dad9
    mature: false
    number: 12
    tx_hash: 0x29190882a3975e35bad66ebd57d34f65a135635b250c2ad69ab8014291330b86
    tx_index: 0
    type_hashes: ~
total_capacity: 62565512.94281988 (CKB)
total_count: 55235

Default path for hardware wallets must include the chain code

The default path currently used by CKB-CLI cannot be used for hardware wallets. I recommend the default path m/44'/309'/0' for hardware wallets instead.

This issue can be circumvented over the command line through the --path command, but improving the default makes the most sense.

Impacted subcommands include (but may not be limited to)

• account extended-address
• wallet transfer
• dao deposit, dao prepare, dao withdraw
• util sign-data, util sign-hash
• tx sign-inputs

Use an argument or an environment variable to control the data directory

When I want to start more than one ckb instances and execute more than one ckb-cli commands in parallel, I want to use different data directories.

For example, run some tests in parallel.

ckb-cli server wasn't expected?

can not export `Export master private key and chain code as hex plain text`

I have used the account export --lock-arg 0xcafebabe --extended-privkey-path (my path) cmd

Password: ...
File exists: mypath

but in mypath there is nothing

Provide a way to ensure the index-store already sync to the tip

We need to ensure the index-store already synchronizes to the tip in some of the scenes, e.g. query the capacity, transfer a new cell to others.

• One style is that add an argument --wait-for-sync=true for commands like wallet get-capacity, wallet transfer, dao deposit.
• One style is that add a sub-commands, like util wait-for-sync --number=[number] | tip, to wait for the index-store synchronizes to number or tip.

I prefer the first one.

Hardware Wallet Support in `ckb-cli`

We (Obsidian Systems) have been making a Ledger application for Nervos.

While doing so, we’ve been adding support for hardware wallets to the client in parallel. Here’s a link to our work so far—we recommend reviewing changes we’ve made in our fork for a full understanding of the scope in discussion.

Note that there are many changes, and perhaps not all are strictly necessary. Our focus thus far has been on building the BOLOS application. Now that we have our first version complete, we’d like to turn our attention to distilling our changes in ckb-cli to clean and concise support for hardware wallets, such as our Ledger BOLOS app.

Our shared goal is for all Ledger-specific code to live in a plugin. However, regardless of whether or not we use a plugin, additional changes are necessary in ckb-cli to support Ledger devices or any other hardware wallet with on-device verification (e.g. Trezor). Here are the major examples:

1. To be secure, hardware wallets need to see the context of what they will sign; information beyond the signed message digest, or even the underlying message.

2. Software private keys are optionally extended into derived private keys, but it is Ledger’s policy (and also good practice) that only sign with derived private keys. This means a stricter differentiation between the “accounts” vs “keys” than currently exists in ckb-cli.

3. We cannot purely on the client extend a concrete private key from a hardware wallet’s seed, like we do with software key pairs, as that seed must stay on the hardware wallet. The good news is the client usually doesn’t need the private key itself, but the ability to sign. So we can provide that ability abstractly instead, side stepping the differences between hardware and software based wallets in the client. (We can extend unhardened public keys client-side in either case, but that doesn’t help us sign anything.)

We’re under the impression the plugins PR already does (3), and may do (2), but (1) is not yet done by either.

We recommend the following in sequence:

1. Always use tx_helper

   To address #1 above, all signing should happen through tx_helper’s functionality instead of directly via a SignerFn. By ensuring the client never tries to sign arbitrary bytes, we are well along the path to ensuring we always havie that context that the hardware wallet will need.

   Ideally this work would be done from a “common ancestor” commit to develop and our branch, such as 07b812e or 6815e0f. We can then merge it into both branches without prematurely forcing a major merge between the latest develop commit and our branch, and the extra work that entails.

2. Make our ckb-sdk hardware-wallet-agnostic

   We have mentioned our work strives, and generally succeeds, at separating the ledger-specific and ledger-agnostic parts of the code base. The exception is a few is_ledger booleans we put in ckb-cli which we’d like to remove. We know how to get rid of them, and can finish that once recommendation (1) is done. More information on how these can be removed can be shared upon request.

   We may want to rethink things a bit for e.g. plugins or other reasons, but it is our opinion that we should just do this work prior to any other next steps, against our branch (with the improvements from Recommendation (1)) as-is. The reason is it shouldn’t take too much time, and with that in place we’ll have a consistently high quality example working version from which to gather requirements for a plugin system or other refactors.

3. Merge hardware-wallet-agnostic changes from our branch to develop

   We previously had to rearrange some code in the wallet transfer function to better separate gathering up lock args and other signing concerns vs building the transaction proper. That will be a somewhat difficult merge but the rest should be much easier.

4. Ship and/or transform to plugin

   Finally, we recommend either reworking the ckb-ledger crate into a plugin, or merging it and then reworking into a plugin. The ledger code should be well-contained and by no means strewn throughout the rest of the code base, so we see little risk to the second option; it’s mainly a question of the desired timeline.

CKB> wallet get-capacity --address ckb1xxxx got error

version:ckb_v0.25.2_x86_64-unknown-linux-gnu, mainnet;

CKB> wallet get-capacity --address ckb1xxxx
index database may not ready, sync process: Processed block#102599 (tip#213280)

The `stdout` output is not well formed when `--debug` enabled

Perhaps ckb-cli can output all debug messages into stderr or a file under .ckb-cli?

Associated Issues: #286 and #287.

Unable to submit udt minting transaction with ckb-cli

After running

ckb-cli rpc get_transaction --hash 0x4071f6fef87c950b4a83fbe39c6e0f0690750a7ee8bdf3ca2099206b8121543c

I get the following output: https://gist.github.com/k/ff786ceb63b1acf7bcc81e3db10d3fa3#file-udt_tx-yaml-L100

I took the hex data from line 100 in the gist above and ran it through

ckb-cli util blake2b --binary-hex $HEX_DATA
# 0xca93acdc343757364848dac54bd9cadd9cb9c1b85c1c409fef368d10c3e6b109

Then I took that code hash and put it into this transaction:

{
  "transaction": {
    "version": "0x0",
    "cell_deps": [
      {
        "out_point": {
          "tx_hash": "0xace5ea83c478bb866edf122ff862085789158f5cbff155b7bb5f13058555b708",
          "index": "0x0"
        },
        "dep_type": "dep_group"
      }
    ],
    "header_deps": [],
    "inputs": [
      {
        "since": "0x0",
        "previous_output": {
          "tx_hash": "0x9648ae83fd3c26356633f64ebec76ae32632b9fedc60b5b977d2d7caa288ba1f",
          "index": "0x0"
        }
      }
    ],
    "outputs": [
      {
        "capacity": "0x2ec692b900",
        "lock": {
          "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8",
          "hash_type": "type",
          "args": "0x2fa3c15e74615be1141470f05f2d2905d57b7249"
        },
        "type": {
          "code_hash": "0xca93acdc343757364848dac54bd9cadd9cb9c1b85c1c409fef368d10c3e6b109",
          "hash_type": "type",
          "args": "0x2fa3c15e74615be1141470f05f2d2905d57b7249"
        }
      }
    ],
    "outputs_data": [
      "0x01000000000000000000000000000000"
    ],
    "witnesses": []
  },
  "multisig_configs": {},
  "signatures": {
    "0x2fa3c15e74615be1141470f05f2d2905d57b7249": [
      "0xfb9a434b2852ceb146b776c2e0c934dcd49f99b673b92269e3b92688ca1588c10ae4b7e629933d672008ba6a23f6989127989694ca06be209de17c36a83096fe01"
    ]
  }
}

Note the type field I added:

{
        "type": {
          "code_hash": "0xca93acdc343757364848dac54bd9cadd9cb9c1b85c1c409fef368d10c3e6b109",
          "hash_type": "type",
          "args": "0x2fa3c15e74615be1141470f05f2d2905d57b7249"
        }
}

However, when I submit this I get:

ckb-cli tx send --tx-file mint.json
# Send transaction error: Server error: Script: InvalidCodeHash

And on my server I see

INFO ckb-script  Error validating script group Byte32(0x71b8e4ec04af2ba8a64f8ac6b5b05716423b9d961c1226e7d9b376ef51fff588) of transaction Byte32(0x1d5f61dd19171b98fee9501c8cdf9f02d416d0d6e459c911945827feab03e3d4): Script(InvalidCodeHash)

I pulled the data directly from the rpc call so there's no way I have the wrong data inputted into the blake2b hash function. Why am I still getting InvalidCodeHash?

Use consistent capacity unit

Now ckb-cli uses different units in different locations. For example get_capacity prints capacity in Shannons, but wallet transfer requires capacity and fee in CKBytes.

Request more features for subcommands

• I didn't find a way to input witness via ckb-cli tx.
  I want to use ckb-cli in bash script, so I don't want to edit the tx-file manually.
• Export private key as hex plain text via ckb-cli account.

Add molecule serialize/deserialize utils

Make sure that the index-store sync completely before "sync-complete-required" commands executing

bash devtools/ci/integration.sh v0.25.1
     Running `target/debug/cli-test --ckb-bin /home/ckb-cli-integration/ckb_v0.25.1_x86_64-unknown-linux-gnu/ckb --cli-bin /home/ckb-cli/target/release/ckb-cli`
[2019-12-04T06:48:05Z INFO  cli_test::util] [Execute]: /home/ckb-cli-integration/ckb_v0.25.1_x86_64-unknown-linux-gnu/ckb "-C /tmp/.tmprnvrTg init --chain dev --rpc-port 8114 --p2p-port 9114"
[2019-12-04T06:48:07Z INFO  cli_test::spec] [Execute]: dao deposit --privkey-path ./privkey --capacity 1103 --tx-fee 1
dao deposit: Capacity not enough: ckt1qyqvsv5240xeh85wvnau2eky8pwrhh4jr8ts8vyj37 => 0

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `73`,
 right: `66`: Capacity not enough: ckt1qyqvsv5240xeh85wvnau2eky8pwrhh4jr8ts8vyj37 => 0
', src/spec/dao.rs:21:9
stack backtrace:
   0:     0x5647e24dc7bb - backtrace::backtrace::libunwind::trace::h89fcc71e59e3bc5b
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1:     0x5647e24dc7bb - backtrace::backtrace::trace_unsynchronized::h0bad9be1379e729a
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2:     0x5647e24dc7bb - std::sys_common::backtrace::_print::hd3382a1f33c473da
                               at src/libstd/sys_common/backtrace.rs:47
   3:     0x5647e24dc7bb - std::sys_common::backtrace::print::h0ec6f03cfb8e76a6
                               at src/libstd/sys_common/backtrace.rs:36
   4:     0x5647e24dc7bb - std::panicking::default_hook::{{closure}}::h96cbf7b454e3f557
                               at src/libstd/panicking.rs:200
   5:     0x5647e24dc496 - std::panicking::default_hook::h95a8f00337383d83
                               at src/libstd/panicking.rs:214
   6:     0x5647e24dcf2d - std::panicking::rust_panic_with_hook::h92f98b46e22f14ed
                               at src/libstd/panicking.rs:477
   7:     0x5647e24dcab2 - std::panicking::continue_panic_fmt::h25abfbb4e5b7043a
                               at src/libstd/panicking.rs:384
   8:     0x5647e24dc9ff - std::panicking::begin_panic_fmt::hc33ce01c7f7cd52d
                               at src/libstd/panicking.rs:339
   9:     0x5647e13e7510 - <cli_test::spec::dao::PrepareInFirstPeriod as cli_test::spec::Spec>::run::h84c47627836c5ea8
                               at src/spec/dao.rs:21
  10:     0x5647e13a4f12 - cli_test::run_spec::h7ee89005cf993642
                               at src/main.rs:97
  11:     0x5647e13a4769 - cli_test::main::h02cce07211e30b0f
                               at src/main.rs:57
  12:     0x5647e13c4840 - std::rt::lang_start::{{closure}}::h22d524cf69006697
                               at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/rt.rs:64
  13:     0x5647e24dc933 - std::rt::lang_start_internal::{{closure}}::h4e93c1949c7a1955
                               at src/libstd/rt.rs:49
  14:     0x5647e24dc933 - std::panicking::try::do_call::h9440ccd4dc467eaa
                               at src/libstd/panicking.rs:296
  15:     0x5647e24e4fda - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:80
  16:     0x5647e24dd43d - std::panicking::try::hc046e7ee42ee744f
                               at src/libstd/panicking.rs:275
  17:     0x5647e24dd43d - std::panic::catch_unwind::h27dfc457c200aee0
                               at src/libstd/panic.rs:394
  18:     0x5647e24dd43d - std::rt::lang_start_internal::hea1b49a567afe309
                               at src/libstd/rt.rs:48
  19:     0x5647e13c4819 - std::rt::lang_start::hedc7a246c4fc3887
                               at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/rt.rs:64
  20:     0x5647e13a593a - main
  21:     0x7f969aeb7b97 - __libc_start_main
  22:     0x5647e139abaa - _start
  23:                0x0 - <unknown>
Makefile:16: recipe for target 'integration' failed
make: *** [integration] Error 101

It seems that the command executes before index-store synchronizing completely.

Is it possible to send CKB from derived addresses?

If I have a file-based key account, and want to receive funds from someone, best practices say that I should give the other person an extended address:

CKB> account list
- "#": 0
  address:
    testnet: ckt1qyqfer8qr6hnjy9ckxxr9f87cdln6d0cgpqs8pwkc9
  lock_arg: 0x9c8ce01eaf3910b8b18c32a4fec37f3d35f84041

CKB> account extended-address --lock-arg 0x9c8ce01eaf3910b8b18c32a4fec37f3d35f84041 --path "m/44'/309'/0'/0/1"
Password:
address:
  testnet: ckt1qyqw87pst0w6vuqumzqsq4z5q7fzxgjtlkuq2xlvfs
lock_arg: 0xe3f8305bdda6701cd881005454079223224bfdb8

At this point, I give the derived address to the person who is sending me the funds. They do so, and I can verify that in the CLI as well:

CKB> wallet get-capacity --address ckt1qyqw87pst0w6vuqumzqsq4z5q7fzxgjtlkuq2xlvfs
total: 499.999 (CKB)

Now how do I spend from this account? One thing I've tried, that didn't work, includes specifying the specific derived account the funds are in. It appears that there is no record kept of the matching private key to the address I derived before:

CKB> wallet transfer --from-account ckt1qyqw87pst0w6vuqumzqsq4z5q7fzxgjtlkuq2xlvfs --to-address ckt1qyqygts28uuvmaqd5nvrzm3qc03zlrymje4sypz5un --capacity 499.998 --tx-fee 0.001
Password:
Account not found: e3f8305bdda6701cd881005454079223224bfdb8

CKB> wallet transfer --from-account 0xe3f8305bdda6701cd881005454079223224bfdb8 --to-address ckt1qyqygts28uuvmaqd5nvrzm3qc03zlrymje4sypz5un --capacity 499.998 --tx-fee 0.001
Password:
Account not found: e3f8305bdda6701cd881005454079223224bfdb8

If I try to instead provide the root/main account, I only have access to the funds in that account directly:

CKB> wallet get-capacity --lock-arg 0x9c8ce01eaf3910b8b18c32a4fec37f3d35f84041
total: 150.0 (CKB)

CKB> wallet transfer --from-account 0x9c8ce01eaf3910b8b18c32a4fec37f3d35f84041 --to-address ckt1qyqygts28uuvmaqd5nvrzm3qc03zlrymje4sypz5un --capacity 499.998 --tx-fee 0.001
Password:
Capacity(mature) not enough: ckt1qyqfer8qr6hnjy9ckxxr9f87cdln6d0cgpqs8pwkc9 => 15000000000

How can I sign things with the extended-address private key, so that I can spend CKB sent to me on an extended address? Is there a way to get wallet transfer to derive extended private keys?

Thank you in advance for your help and consideration!

Contract development tools (debug, deploy)

Command line interface design

Key management

key generate --privkey-path ../keys/xxx.key

key info --privkey-path ../keys/xx.key --public-key
  [public-key]: 0x33333
  [address]: cktxxxxx
  [block_assembler]:
     xxxx

key add --privkey-path ../keys/xxx.key

key remove --pubkey 0xabcdef

key list
  {public-key}: {address}, {privkey-path}
  {public-key}: {address}, {privkey-path}
  {public-key}: {address}, {privkey-path}
  {public-key}: {address}, {privkey-path}

Local script management

script add --code-hash {H256} --args 0x123abcdef --args 0x456def --args ...

script remove --script-hash {H256}

script list
  {script-hash}: [code-hash], args.len()
  {script-hash}: [code-hash], args.len()
  {script-hash}: [code-hash], args.len()

script show --script-hash {H256}
  {script-hash}
    [code-hash]: H256
    [args]
      - 0x3333abc
      - 0x4444abc

Local cell management

cell add \
  --name hello-world
  --data ../hello-world.bin
  --lock {script-hash}
  --type {script-hash}
  --capacity {u64}

cell remove --name {name}

cell list
   {name} => {data-hash}, {added_at}
   {name} => {data-hash}, {added_at}

cell show --name {name}
  [out-point]:
    [tx-hash]: 0x3342cdabcdef
    [index]: 0
  [capacity]: u64
  [data]: data.len() (usize)
  [lock]:
    [script-hash]: H256
    [code-hash]: H256
    [args]
      - 0xabcdef
      - 0x44444
  [type]:
    [script-hash]: H256
    [code-hash]: H256
    [args]
      - 0x13af0bcdfe00
      - 0x2342ddfea

cell dump --name {name} --path some-cell.json
cell load --name {name} --path some-cell.json

Local transaction management

tx add \
  --deps {tx_hash}-{index} --deps {tx_hash}-{index} --deps ... 
  --inputs {tx_hash}-{index} --inputs {tx_hash}-{index} --inputs ...
  --outputs {name} --outputs {name}
  "{tx-hash}"

tx set-witness \
  --tx-hash {tx_hash}
  --input {tx_hash}-{index}
  --witness 0x334234234abc --witness 0xabc33418 --witness ...

tx set-witnesses-by-keys --tx-hash {tx_hash}

tx list
  {tx-hash}: version: 0, deps.len(), inputs.len(), outputs.len(), witnesses.len()
  {tx-hash}: version: 0, deps.len(), inputs.len(), outputs.len(), witnesses.len()

tx show --tx-hash {tx-hash}
  version: 0
  deps:
    out_point: {tx-hash}, {index}
    out_point: {tx-hash}, {index}
  inputs:
    out_point: {tx-hash}, {index}
    out_point: {tx-hash}, {index}
  outputs:
    cell: {name}, {tx-hash}, {index}
    cell: {name}, {tx-hash}, {index}
  witnesses:
    witness:
      - 0x32342abc
      - 0x3423423adef
    witness:
      - 0xabcd342
      - 0x3b8ac4f

tx verify --tx-hash {tx-hash}
[debug]: hello world
[debug]: hello world 2
[debug]: all done
[return code]: 0

tx dump --tx-hash {tx-hash} --path some-tx.json
tx load --path some-tx.json

Fix bugs with ckb v0.14.0

• Capacity calculation

`output_index` is duplicated to `LiveCellInfo::index`

LiveCellInfo::tx_index is duplicated to LiveCellInfo::index which already contains tx_index and output_index.

Changing to LiveCellInfo will introduce the incompatibility of storage. So we do this small change once we decide to make an incompatible update.

Mining with CKB-Cli (for dev chain)

When we have to send a series of transactions to implement a complete feature, we can't control the speed of producing blocks, so we can't test the cases with boundary conditions.

For example:
When we develop a dApp in CKB, we construct a transaction tx1, send it to dev chain, then wait a block to package it.
And we want to test what will happen if another transaction tx2 was packaged in the next block.

It's a bit complex:

1. Start a dev chain.
2. Start a miner and set a bigger delay time.
3. Send tx1.
4. Construct tx2 as quick as we can.
5. Try send tx2 before the next block was produced.

But, if ckb-cli can mine blocks, we can do it easier.

The pseudo steps are as follow:

miner.start()
// do something that don't care the height
miner.stop()
send(tx1)
miner.mine(1)
send(tx2)
// check the result of tx2
miner.start()