Milestone 1 Progress

Done: Storage of Hardware Wallet Root Public Keys in CKB-CLI

The account import command can be used to store the extended root public key (m/44'/309'/0') of a Ledger hardware wallet in CKB-CLI. Here’s the full list of commands we’ve adjusted as part of this shift:

• account import: This subcommand can be used to import the hardware wallet account.
• account list: Once imported, hardware wallet accounts now appear here even when the Ledger device is not connected.
• account extended-address: This subcommand is used to verify your receiving address before sharing it with someone so you are sure the address is correct. Non-default options which were required at the end of our first grant are no longer required.
• account bip44-addresses: This subcommand can now be used to list hardware wallet change and receiving addresses. Currently CKB-CLI prompts the user for their passphrase during this command, but our fork does not and soon neither will CKB-CLI.
• wallet get-capacity --derived: This subcommand can now be used with hardware wallets. Like account bip44-addresses, this command will not prompt the user for their passphrase or device confirmation.
• wallet transfer: While supported at the end of our first grant, this subcommand now uses the hardware wallet information stored in the client. It also knows when to use the default Ledger path m/44'/309'/0'
• DAO Operations: All 3 DAO operations now use hardware wallet stored in the client and will soon use the correct default path of m/44'/309'/0'
• Message Signing Subcommands: sign-message and sign-data subcommands both use hardware wallet data stored in the client. See ‘Message Signing’ below for more details on this feature.

Done: Pass Hardware Wallets Unhashed Transaction and Context Data

Now that hardware wallet information is being stored in CKB-CLI, we are using this information to clean up UX and make it easier to securely verify operations before signing them. In particular, we are:

• Passing raw transaction data to the hardware wallet. This informs the on-device prompt and is hashed on the device before signing.
• Passing context transactions to the hardware wallet. Context transactions are the transactions that create an operation’s input cells and they are necessary to properly calculate the capacity being transferred in an operation.
• Computing receiving and change addresses using the extended root public key. As a result, the user is no longer prompted to ‘Provide Public Key’ before doing other operations such as a transfer.

In Progress: List Multiple Connected Ledger Devices

We use ledger-rs to communicate between the rust client CKB-CLI and Ledger devices. Currently the library does not support listing multiple Ledger devices which are connected with the Nervos app open. We’ll be adding support for this to the library so account list shows all connected devices.

In Progress: Message Signing

We have completed the work described in our proposal related to message signing! Message signing operations are now prepended with a magic byte to differentiate them from other operations. You can also sign a raw string message with your Ledger device and verify the string on your hardware wallet’s UI! For instance, if you enter the command util sign-message --from-account <lock-arg> --message “Nervos message signing", the hardware wallet will ask you to ‘Sign Message’ and ask you to verify the exact message you entered: “Nervos message signing”.

In coordination with the Nervos’ CKB-CLI team, we’ve decided to expand upon this and cover additional use cases, such as messages that are generated from DApps which are formatted differently. In total, we’ll allow signing of three types of messages: raw strings (done), binary hex (not started), and pre-hashed data (not started). We’ve completed specification for these additional features and will be starting work on them soon!

The spec is as follows:

• To sign a raw string: util sign-data --from-account <lock-arg> --string <string>
• To sign binary hex data: util sign-data --from-account <lock-arg> --binary-hex <binary-hex>
• To sign hashed data: util sign-message --from-account <lock-arg> --message <message>

Both sign-data and sign-message subcommands will also accept the an extended-address flag to sign with extended addresses, which is not yet supported upstream but will be. sign-data will also support a no-magic-byte flag which will tell the client to not prepend the message with the magic byte, “Nervos Message:”.

Signing hashed data, or messages that are not prepended with the magic byte, is an advanced use case we don’t recommend for everyday users because the Ledger device cannot determine what it is signing. This is why we’ve put the effort into getting raw transaction data and context transactions sent to the hardware wallet for all common uses: it is necessary to securely display what you are signing. However, this simply isn’t possible in all use cases due to the variance in data that may be produced by DApps or use cases which have not yet emerged. For that reason, we’re also adding a configuration to the Ledger application to ‘Sign Hash’. With this enabled, you can sign hashed data. The hash of that data will appear on the device and in the client for you to confirm. Note that this doesn’t completely make signing hashed data secure! We recommend users confirm the same hash is generated in more than one client to be sure the client is not compromised and thus the hashed data is not malicious.

In Progress: Multisig Lock Script Support / Transaction Variants

We’ve made good progress towards supporting multisigs in our Ledger application. This is two-fold: both signing operations from a multisig address and sending funds to one since multisig addresses are formatted differently.

Supporting multisigs is part of a broader initiative to support all the transaction variants someone can reasonably expect to create. After conversations with Nervos’ CKB-CLI team, we’ve decided it is best to support all of them as a part of Milestone 1 to our grant. This includes:

• Multisigs and Timelock addresses: Timelock addresses essentially are multisig addresses. They can be created with a 1 of 1 signing requirement.
• Transactions with inputs from different addresses: Transactions created in a JSON file can have inputs from different accounts/addresses, meaning the Ledger device user may not be signing for the entire transaction or the inputs may all be from addresses they own but must each be signed with their respective key. Both of these use cases will be supported.
• Transaction with multiple outputs: We’ll allow the user to verify each output that’s part of their transaction so they will be able to verify exactly how much CKB is being sent to each destination.
• Self-transfers: These are a unique case because both the destination and change address are associated with the same account which makes calculating the amount being ‘transferred’ tricky. This can be especially useful for miners looking to consolidate many small cells. Support for this feature was recently completed.

Supporting all of these variants increases this project’s scope which will take more time than originally estimated, but fits our broad goals of being feature complete before beginning Milestone 2, providing strong security in all use cases, and making Ledger’s security review and listing of our application easier.

Furthermore, we’ve become very familiar with constructing complex transactions using CKB-CLI and wanted to make it easier for others in the community to do so as well. For that reason, we’ll be publishing a series of guides focusing on the different transaction variants we’ve described above. The first of which, which covers Multisigs, was just published last week!

Looking Ahead

Everything we’ve described above contributes to the checkpoints which are a part of Milestone 1: 1) Client Changes Complete Natively and 2) Ledger Features Complete. When they are complete, we’ll present progress and produce a video demonstration for the community. At that time we’ll also begin Milestone 2’s checkpoints: 1) Moving Ledger-specific code in CKB-CLI to a plugin and 2) updating LedgerJS to support new features and upstream changes.

While we haven’t yet begun development of the Ledger plugin, we’ve been actively working with the CKB-CLI team to specify how their plugin system will work with hardware wallet plugins. As a result, they have been able to add the features we’ll need to the plugin system, paving the way for us to make the Ledger plugin during Milestone 2. We’d like to take this opportunity to thank them for their excellent cooperation and support!

We originally estimated this grant would take up to 8 weeks to complete with the first milestone taking the majority of that time. While we are on track to complete our original specifications within that time frame, the added message signing features and transaction variants will require additional development. As a result, Milestone 1 should be completed near the end of July and Milestone 2 in mid-August. As always, we remain committed to delivering high quality, comprehensive solutions as quickly as we can.

Acknowledgements

We’d like to thank Nervos for their grant to work on this application and the Nervos community for their enthusiasm surrounding this project!

If you have any questions or feature requests, we encourage you to email us at nervos@obsidian.systems.

Later in this series we’ll also be publishing guides on topics like timelock addresses and transactions with multiple outputs.

This guide was made with git hash b2c35a486ec766008acfea778a4d33c87acf2724 of CKB-CLI and is based on this guide for Handling Complex Transactions. Let’s get started!

About Multisig Addresses

A multisig address is a Nervos address that requires the signatures of one or multiple keys based on the requirements established when the address was created. It generally includes all signing schemes that don’t only require a single signature, although that is also possible! For instance, you can require that every signer (ex. 3 of 3) sign for a transaction to be valid. Or, you can set it so only one of many signatures (ex. 1 of 3) is needed to sign a transaction. Or, you can only require a single signature (ex. 1 of 1).

Let’s look at the command used to create a multisig address to understand these options better:

CKB> tx build-multisig-address --help

tx-build-multisig-address

Build multisig address with multisig config and since(optional) argument

USAGE:
     tx build-multisig-address [OPTIONS] --sighash-address <sighash-address>…

FLAGS:
     -h, --help Prints help information

OPTIONS:
     --sighash-address <sighash-address>… Normal sighash address
     --require-first-n <require-first-n> Require first n signatures of corresponding pubkey [default: 0]
     --threshold <threshold> Multisig threshold [default: 1]
     --since-absolute-epoch <since-absolute-epoch> Since absolute epoch number

Looking at the different options we have:

• --sighash-address is where we list any addresses that should be able to sign for this multisig. These can be listed in order separated by a space with as many addresses as we choose.
• --require-first-n sets a requirement that some signatures of the set must sign for the multisig for the signature to be valid. This is most useful when combined with threshold.
• --threshold sets how many of our potential signers (provided with --sighash-address) are necessary to produce the multisig addresses’ signature. For instance, if we have 6 total addresses with a threshold of 4, then 4 of those 6 signatures are necessary to sign for the multisig address.
• --since-absolute-epoch prevents the cells held at this address from being spent before a given time, defined by the absolute epoch when they unlock. For more information on setting restrictions on when a cell’s can be spent, see RFC17: Transaction valid since (as use with caution so you don’t accidentally lock your funds for longer than you wanted!).

This small set of features can create many different configurations to suit an application’s needs!

Getting Set Up

We are going to create a multisig address with 2 signers, both of which are required (threshold = 2). Note that this means you’ll need the keys to both addresses locally if you’d like to follow along. You may first want to run account list to see how many accounts you have set up:

CKB> account list

- “#”: 0
  address:
     mainnet: ckb1qyqv8256ceslzzp72rxfz5wutpsfk35jzdas5tn693
     testnet: ckt1qyqv8256ceslzzp72rxfz5wutpsfk35jzdasfwd9fd
  lock_arg: 0xc3aa9ac661f1083e50cc9151dc58609b4692137b
  lock_hash: 0x386815b600bc6064b9333105a331af34c376ed60264e14fc6f4717889bcf58ec
- “#”: 1
  address:
     mainnet: ckb1qyqru2kkvk3vk35k607y5gtsglwjtccdw0xsdhhzuv
     testnet: ckt1qyqru2kkvk3vk35k607y5gtsglwjtccdw0xssjfass
  lock_arg: 0x3e2ad665a2cb4696d3fc4a217047dd25e30d73cd
  lock_hash: 0x47e22ab140292a7bc7aa4959e049fd138b60e2e9a38921df27f44cdc761de50e

If you need additional accounts (you might want a 3rd for your destination), just run account new until you have enough.

You will also need funds on at least one of these accounts. If you’d like to do this on a local devnet, follow this Dev Chain guide. If you are using Aggron, you can get CKB from the faucet.

Remember — since both of these are considered ‘testnet’, we’ll use testnet addresses throughout the guide — not mainnet addresses.

Create and Fund the Multisig Address

The first step is to create the multisig address with the command we detailed above:

tx build-multisig-address --sighash-address <sighash-address>…

For --sighash-address we will list all the 2 addresses we want to sign for this multisig account. We also want all signatures to be required, so we’ll set the optional threshold parameter equal to the number of sighash addresses:

CKB> tx build-multisig-address --sighash-address ckt1qyqv8256ceslzzp72rxfz5wutpsfk35jzdasfwd9fd ckt1qyqru2kkvk3vk35k607y5gtsglwjtccdw0xssjfass --threshold 2

lock-arg: 0x74573da67951f1192dccbf76bfea95b5766009a4
lock-hash: 0x2de9aac553771d51d865f9862cf6bcb0f7d00913fdd10cda9f6525a1be6fd95b
mainnet: ckb1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjq3ty9au
testnet: ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q

As the output shows, the testnet multisig address we created is ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q.

The address is created with a balance of 0, so we’ll now have to fund it. We can do this with the wallet transfer subcommand, which we’ll use to send funds from one of our two accounts:

CKB> wallet transfer --from-account 0xc3aa9ac661f1083e50cc9151dc58609b4692137b --to-address ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q --capacity 500 --tx-fee 0.0001

Password:

0x7645a048504fcf495a2c42a0c8387e7be52c048ae1172b554daf272e29c89af8

After entering our password, we get the transaction hash returned by the client. (Note: if you are using a local dev chain, remember to run your miner now so the operation gets included in a block!) We can confirm this operation succeeded by looking at the live cells of our multisig address:

CKB> wallet get-live-cells --address ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q

current_capacity: 500.0 (CKB)
current_count: 1
live_cells:
     - capacity: 500.0 (CKB)
       data_bytes: 0
       index:
          output_index: 0
          tx_index: 1
       lock_hash: 0x2de9aac553771d51d865f9862cf6bcb0f7d00913fdd10cda9f6525a1be6fd95b
       mature: true
       number: 1054
       tx_hash: 0x7645a048504fcf495a2c42a0c8387e7be52c048ae1172b554daf272e29c89af8
       tx_index: 0
       type_hashes: ~
total_capacity: 500.0 (CKB)
total_count: 1

(Interested in learning more about cells and Nervos’ Cell Model? Here is the documentation and a helpful Medium Post).

This multisig address is now created and funded with 500 CKB!

Transferring from the Multisig

Transferring from a multisig is different than transferring from a normal address. Instead of using the wallet transfer subcommand, we are going to use CKB-CLI to create a JSON file which we’ll populate with the inputs, outputs, and signatures we’d like until the transaction is fully formed.

First, let’s decide what to call our transaction file and create it. ‘multisig.json’ seems good:

CKB> tx init --tx-file multisig.json

status: success

Let’s now populate it with the elements that form this transaction. We’ll start by telling it the signatures we’ll be providing with the following command:

tx add-multisig-config [OPTIONS] --sighash-address <sighash-address>… --tx-file <tx-file>

In our case we want to set the threshold to 2 as well because we need signatures from both sighash addresses. Note that we’re not deciding we want both signatures now (that was decided when we made the multisig address), we’re just telling the transaction what it should expect:

CKB> tx add-multisig-config --sighash-address ckt1qyqv8256ceslzzp72rxfz5wutpsfk35jzdasfwd9fd ckt1qyqru2kkvk3vk35k607y5gtsglwjtccdw0xssjfass --threshold 2 --tx-file multisig.json

status: success

The transaction file is now set up to expect signatures from both addresses, which is required by the input cell owned by our multisig address. Let’s now add that input cell owned by our multisig address to this transaction with this command:

tx add-input --tx-hash <tx-hash> --index <index> --tx-file <tx-file>

We can get both tx-hash and index from the result of tx get-live-cells which we ran earlier:

CKB> tx add-input --tx-hash 0x7645a048504fcf495a2c42a0c8387e7be52c048ae1172b554daf272e29c89af8 --index 0 --tx-file multisig.json

status: success

Now we need to tell the transaction file where to send CKB from the multisig. The capacity of the output must be less than the capacity of the input with enough CKB to spare to pay the transaction fee. If no change output is added, any CKB inputs not sent to outputs are considered fees paid to the miner. By default, fees of over 1 CKB are not allowed to prevent accidentally sending too much fee to the miner, but this is also configurable. Let’s send 400 CKB, pay a fee of 0.001 CKB, and send the rest back to one of our accounts as change. We’ll use this command to set the outputs:

tx add-output [OPTIONS] --capacity <capacity> --tx-file <tx-file>

There are a few ways to set the destination of these funds, so none of them are listed as defaults. They are:

--to-sighash-address <to-sighash-address>
          To normal sighash address
--to-short-multisig-address <to-short-multisig-address>
          To short multisig address
--to-long-multisig-address <to-long-multisig-address> 
          To long multisig address (special case, include since)

Our destination is a normal sighash address, so we’ll use the first option:

CKB> tx add-output --to-sighash-address ckt1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kszxshna --capacity 400 --tx-file multisig.json

status: success

We’ve now created our transaction file, set the signing requirement, added an input, and added an output. Now seems like a fine time to check the status of our transaction file with tx info --tx-file <tx-file>. This is a helpful command you can use at any time to check the state of our JSON file:

CKB> tx info --tx-file multisig.json

[input] ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q => 500.0, (data-length: 0, type-script: none, lock-kind: multisig without since)
[output] ckt1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kszxshna => 400.0, (data-length: 0, type-script: none, lock-kind: sighash(secp))
input_total: 500.0 (CKB)
output_total: 400.0 (CKB)
tx_fee: 100.0 (CKB)

As expected, we see our input cell with a capacity of 500 CKB and an output of 400 CKB to the destination we set. The transaction fee is currently 100 CKB as we haven’t yet told the transaction where to send our change. Let’s do that next.

First, we’ll need a change address associated with one of our accounts:

CKB> account extended-address --lock-arg 0xc3aa9ac661f1083e50cc9151dc58609b4692137b --path “m/44'/309'/0'/1/0”

Password:

address:
  mainnet: ckb1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs6xv5w6
  testnet: ckt1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs8rjtzx
lock_arg: 0xb4411a9ab8a00c75b8e1bf14b16edade1ca7fb53

Now let’s create an output cell for that address so that only 0.001 CKB remains as the transaction fee:

CKB> tx add-output --to-sighash-address ckt1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs8rjtzx --capacity 99.999 --tx-file multisig.json

Status: success

Let’s make sure we have our transaction fee correct now:

CKB> tx info — tx-file multisig.json

[input] ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q => 500.0, (data-length: 0, type-script: none, lock-kind: multisig without since)
[output] ckt1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kszxshna => 400.0, (data-length: 0, type-script: none, lock-kind: sighash(secp))
[output] ckt1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs8rjtzx => 99.999, (data-length: 0, type-script: none, lock-kind: sighash(secp))
input_total: 500.0 (CKB)
output_total: 499.999 (CKB)
tx_fee: 0.001 (CKB)

Looks great! With our transaction properly constructed, it’s now time to sign it and add the signatures.

Signing the Transaction

Now that we know the transaction is finalized, it’s time to sign it with each signature. Note that we aren’t signing with the multisig address, we are signing with each account that makes up the multisig. We’ll need as many signatures as we set the threshold to when creating our multisig, which in this case is two. Here’s the operation to sign:

tx sign-inputs --from-account <from-account> --tx-file <tx-file>

Let’s use it to sign with our first account:

CKB> tx sign-inputs --from-account 0xc3aa9ac661f1083e50cc9151dc58609b4692137b --tx-file multisig.json

Password:

- lock-arg: 0x74573da67951f1192dccbf76bfea95b5766009a4
  signature: 0x9afd86f6ac3022bbab1b6c05743f6a647005d91b358d78decff9ffa6b5f860692e04a655c21bd9bcd54cd02380eaa105667ed4d70659ccaeef74f08ccd313be000

After entering our password for that account, the operation’s response gives us a lock-arg and a signature associated with it. Notice the lock-arg in the response is not the lock-arg provided in the --from-account field — it is the lock-arg of our multisig! Just like inputs and outputs, this signature also needs to be added to our transaction file. Here’s the command:

tx add-signature --lock-arg <lock-arg> --signature <signature> --tx-file <tx-file>

For both --lock-arg and --signature we can use the response from our previous command. —-tx-file is the same we’ve used up until this point:

CKB> tx add-signature --lock-arg 0x74573da67951f1192dccbf76bfea95b5766009a4 --signature 0x9afd86f6ac3022bbab1b6c05743f6a647005d91b358d78decff9ffa6b5f860692e04a655c21bd9bcd54cd02380eaa105667ed4d70659ccaeef74f08ccd313be000 --tx-file multisig.json

status: success

Excellent! That first signature is added. Let’s now add the second signature. However, this time let’s condense the two-step process of signing and adding the signature to the JSON file into one step using the--add-signatures option for tx sign-intputs:

CKB> tx sign-inputs --from-account 0x3e2ad665a2cb4696d3fc4a217047dd25e30d73cd --tx-file multisig.json --add-signatures

Password:

- lock-arg: 0x74573da67951f1192dccbf76bfea95b5766009a4
  signature: 0x3ee146e3f8386c005e8a921a97b1bbf126346e1d07f36b8aec340de64d0f90a17be4c4eae9fd083113846d47373583bdae89817e1b4f250c8950c1da9c5f8b8d00

Great! With both signatures added, this operation should be ready to go. Let’s do one final check to make sure our inputs are signed:

CKB> tx info — tx-file multisig.json

[input(signed)] ckt1qyqhg4ea5eu4ruge9hxt7a4la22m2anqpxjqvw663q => 500.0, (data-length: 0, type-script: none, lock-kind: multisig without since)
[output] ckt1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kszxshna => 400.0, (data-length: 0, type-script: none, lock-kind: sighash(secp))
[output] ckt1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs8rjtzx => 99.999, (data-length: 0, type-script: none, lock-kind: sighash(secp))
input_total: 500.0 (CKB)
output_total: 499.999 (CKB)
tx_fee: 0.001 (CKB)

This operation is ready to be sent to the node!

Submitting the Transaction to the Node

With our transaction JSON file finalized, all that’s left is submitting it to the blockchain. It will then be included in a block and reflected in the network’s state.

CKB> tx send --tx-file multisig.json

0x8d3bf4eb2d61408241092e451cff375b188b709e34ea77e56e4d44e81d150700

Confirming the Transaction

Our operation has been submitted to the chain! Let’s make sure it actually happened. There are a few ways we can do this, but let’s start by just looking at the transaction itself:

CKB> rpc get_transaction --hash 0x8d3bf4eb2d61408241092e451cff375b188b709e34ea77e56e4d44e81d150700

transaction:
  cell_deps:
     - dep_type: dep_group
       out_point:
         index: 1
         tx_hash: 0x10212028a561ca990f0cc007ca7f1e3e7c6bbf0aa9a68f5a47ec47c01b4cf38a
  hash: 0x8d3bf4eb2d61408241092e451cff375b188b709e34ea77e56e4d44e81d150700
  header_deps: []
  inputs:
    - previous_output:
        index: 0
        tx_hash: 0x7645a048504fcf495a2c42a0c8387e7be52c048ae1172b554daf272e29c89af8
      since: 0x0 (absolute block(0))
  outputs:
    - capacity: “400.0”
      lock:
        args: 0x533d23813da928934a97de92b0810f437b4cdd6d
        code_hash: 0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8 (sighash)
        hash_type: type
      type: ~
    - capacity: “99.999”
      lock:
        args: 0xb4411a9ab8a00c75b8e1bf14b16edade1ca7fb53
        code_hash: 0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8 (sighash)
        hash_type: type
      type: ~
  outputs_data:
    - 0x
    - 0x
  version: 0
  witnesses:
    -
0xc200000010000000c2000000c2000000ae00000000000202c3aa9ac661f1083e50cc9151dc58609b4692137b3e2ad665a2cb4696d3fc4a217047dd25e30d73cd3ee146e3f8386c005e8a921a97b1bbf126346e1d07f36b8aec340de64d0f90a17be4c4eae9fd083113846d47373583bdae89817e1b4f250c8950c1da9c5f8b8d009afd86f6ac3022bbab1b6c05743f6a647005d91b358d78decff9ffa6b5f860692e04a655c21bd9bcd54cd02380eaa105667ed4d70659ccaeef74f08ccd313be000

tx_status:
  block_hash: 0x003b6b86e725d94256fa618a7bb794e04eae687e1d25ac75638989754b89ca3a
  status: committed

These transaction details show us the two output cells we expected: the first for 400 CKB which is now owned by the lock-arg associated with the--to-address we set (ckt1qyq9x0frsy76j2ynf2taay4ssy85x76vm4kszxshna). The second is for 99.999 CKB to on of our change addresses (ckt1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs8rjtzx) which is owned by the lock-arg of this extended-address (0xb4411a9ab8a00c75b8e1bf14b16edade1ca7fb53).

Balance checks on any of the addresses or lock-args also confirm things we exactly as we intended:

CKB> wallet get-capacity --lock-arg 0x533d23813da928934a97de92b0810f437b4cdd6d

total: 400.0 (CKB)

CKB> wallet get-capacity --address ckt1qyqtgsg6n2u2qrr4hrsm7993dmddu898ldfs8rjtzx

total: 99.999 (CKB)

That’s it! See below for the final contents of the multisig.json file we created during this guide.

Final File Contents — multisig.json

{   
  "transaction": {     
    "version": "0x0",
    "cell_deps": [
       {
         "out_point": {
           "tx_hash": "0x10212028a561ca990f0cc007ca7f1e3e7c6bbf0aa9a68f5a47ec47c01b4cf38a",
           "index": "0x1"
         },
         "dep_type": "dep_group"
       }     ],
     "header_deps": [],
     "inputs": [
       {
         "since": "0x0",
         "previous_output": {
           "tx_hash": "0x7645a048504fcf495a2c42a0c8387e7be52c048ae1172b554daf272e29c89af8",
           "index": "0x0"
         }
       }
     ],
     "outputs": [
       {
         "capacity": "0x9502f9000",
         "lock": {
           "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8",
           "hash_type": "type",
           "args": "0x533d23813da928934a97de92b0810f437b4cdd6d"
         },
         "type": null
       },
       {
         "capacity": "0x2540a5d60",
         "lock": {
           "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8",
           "hash_type": "type",
           "args": "0xb4411a9ab8a00c75b8e1bf14b16edade1ca7fb53"
         },
         "type": null
       }
     ],
     "outputs_data": [
       "0x",
       "0x"
     ],
     "witnesses": []   },
   "multisig_configs": {
     "0x74573da67951f1192dccbf76bfea95b5766009a4": {
       "sighash_addresses": [
         "ckt1qyqv8256ceslzzp72rxfz5wutpsfk35jzdasfwd9fd",
         "ckt1qyqru2kkvk3vk35k607y5gtsglwjtccdw0xssjfass"
       ],
       "require_first_n": 0,
       "threshold": 2
     }
   },
   "signatures": {
     "0x74573da67951f1192dccbf76bfea95b5766009a4": [
      "0x3ee146e3f8386c005e8a921a97b1bbf126346e1d07f36b8aec340de64d0f90a17be4c4eae9fd083113846d47373583bdae89817e1b4f250c8950c1da9c5f8b8d00",
       "0x9afd86f6ac3022bbab1b6c05743f6a647005d91b358d78decff9ffa6b5f860692e04a655c21bd9bcd54cd02380eaa105667ed4d70659ccaeef74f08ccd313be000"
     ]
   }
 }

Please stay tune for other guides covering how to do transactions with CKB-CLI!

Interested in learning more about our Nervos development? You can follow us on Twitter and Medium!

We’d like to thank Nervos for their support as we develop a Ledger application for Nervos and add hardware wallet support to CKB-CLI.

Where is the code?

Adding support for hardware wallets requires more than just the application itself. It also involves teaching the client how to communicate with the device and providing wallet developers the tools they need to support Ledger devices. Our work thus far has touched on all of these points:

• Ledger-App-Nervos: This repository contains the Ledger application and our automated tests
• Our Fork of CKB-CLI: We’ve prepared substantial contributions to Nervos’ command line interface and added many changes to support Ledger devices
• Our Fork of LedgerJS: This is the library used by wallet developers to communicate with Ledger devices. We’ve added support for Nervos in our fork

What’s the current status?

As of v0.1.0, the Ledger app, along with our fork of CKB-CLI, has all the functionality we described in our proposal:

• The command line interface can find the connected hardware wallet
• The client can provide a public key hash, lock arg, and lock hash from the device
• Transfers can be confirmed on the device and signed
• All DAO functions (deposit, prepare, withdraw) can be confirmed on the device and signed
• All operations can be signed through LedgerJS

Can we use it yet?

Not quite! There are some additional steps remaining before Ledger support is widely available. We do not recommend storing mainnet CKB on the application at this time as this app is still considered under development and experimental until it is supported in the upstream CKB-CLI.

First, we’re working with Nervos to add hardware wallet support to CKB-CLI. Here’s the issue we’ve opened to coordinate our efforts.

We’re also working with Ledger to have the application available for download in Ledger Live. It will first be available in ‘Developer Mode’ before eventually being added to their production App Manager. This submission process is underway, but a timeline is not yet available.

In the meantime, we encourage interested parties who are technically inclined to experiment with the current version on test networks and the devnet! In fact, you’ll find documentation in our app that walks you through all of the app’s features. We greatly value the community’s feedback and hope some of you will give it a try!

Acknowledgements

We’d like to thank Nervos for their grant to work on this application and the Nervos community for their enthusiasm surrounding this project!

If you have any questions or feature requests, we encourage you to email us at nervos@obsidian.systems!

Kiln v0.8.0 is here! This release adds support for the Carthage protocol and upgrades the Kiln Node’s storage backend. If you would like to bake after Carthage takes effect at block level 851,969, you must upgrade. You will also need to recreate your Kiln Node to adopt the new storage backend. This means upgrading will take more time than usual so we recommend 1) timing your upgrade so missed opportunities are minimized and 2) using a recent snapshot so your node is quickly in sync with the network again.

Carthage Support

Carthage introduces less jarring changes to the protocol than the Babylon upgrade. As such, there are few adjustments to Kiln’s code in this release.

More importantly, v0.8.0 contains the binaries for Carthage and protocol itself. With this upgrade, Kiln will begin running the baker and endorser for Carthage so it can seamlessly transition to the new protocol. Once the transition has happened, Kiln will automatically stop the baker and endorser for Babylon. Some of you may have already noticed benign errors from Kiln attempting to run the baker and endorser for Carthage as soon as the Promotion Period started! Those will go away with this upgrade.

Want to confirm Kiln has transitioned protocols when it happens? If you hover over ‘Network’ in the header, you can see the current protocol!

Node Backend Upgrade

Tezos’ mainnet now includes a new storage backend for the Tezos node. Previously LMDB was used exclusively, and we now see the introduction of the irmin-pack backend. One of the most obvious benefits that comes with this change is a reduction in disk space consumed by the Tezos node.

Non-Kiln users will see manual instructions for upgrading the node vary depending on what history mode (archive, full, rolling) or branch they were previously using, but all upgrades generally involve restarting your node from a snapshot. For Kiln, we’ve followed a somewhat simplified path which boils down to the same solution — you must remove your node and start anew, preferably from a snapshot so downtime is minimized! Some snapshot providers we know of are Tezos Shots, Bake Tz for Me, Phlogi (new snapshots daily!), Tulip Tools, and Tezziland.

Note: The node’s upgrade is a breaking change for Kiln. If you rollback to a previous version, not only will you not have the Carthage protocol and binaries, your node will be of a different storage backend and fail to start properly. Please plan accordingly! If for some reason you have an issue upgrading, we recommend wiping Kiln from your machine and starting fresh with v0.8.0.

Tezos Baking Ledger App

Current versions of Tezos Baking will continue to work great on Carthage! There is no need to upgrade your baking Ledger device with this protocol transition.

If you have upgraded your Ledger Nano S to firmware 1.6.0 and you are having issues with it, Ledger has released a web based tool so you can upgrade your MCU firmware to v1.12. It can be found here — https://ledger-live-tools.now.sh/mcu-repair. This is a temporarily tool until Ledger Live uses the fixed MCU firmware by default.

We only recommend this tool for bakers who have already upgraded to firmware 1.6.0. If you are still on firmware 1.5.5, please wait for this fixed MCU firmware to be the default for installation through Ledger Live.

Have an issue? Please email us (tezos@obsidian.systems), tweet us (@obsidian_llc), or join our Baker Slack!

Kiln v0.8.0 — Carthage and New Node Storage Backend was originally published in kiln on Medium, where people are continuing the conversation by highlighting and responding to this story.

• New ‘Ledger Disconnected’ Notification
• Usability Improvements
• Post-Babylon Clean Up

Ledger Improvements

Kiln now notifies if your ledger device is disconnected! We’ve also added a status icon to the header which reports your connection status.

Ledger connectivity, particularly after voting or otherwise leaving the Baking app, is the most commonly reported issue. This notification will help combat this problem and dive deeper into diagnosing the issue. It is also helpful for dealing with curious cats who decide to hit ledger devices or gnaw on cables!

We’ve also updated the udev rules that our Debian distribution configures on your machine to be compatible with Ledger firmware 1.6.0. This configuration was updated with their firmware release, so this update makes sure the full stack of software remains compatible without any need for manual intervention.

Usability

We’ve listened to user suggestions and made several improvements!

Refined ‘New Version of Tezos Available’ Notification

The ‘New Tezos software” notification has been updated so checks if individual monitored nodes aren’t running the latest version of Tezos. This means bakers who are only running a Kiln Node won’t get a notification to upgrade since they can’t do it on their own. Bakers running many monitored nodes will see exactly which nodes of theirs need upgrading!

Gathering Baker Data…

When you add a baker to Kiln, it begins asking the blockchain about all the information it can get about your baker. That includes its baking history (what blocks have you baked, if any?) and baking rights (what blocks are you supposed to bake? Which blocks were you supposed to bake?). There were some cases where Kiln would report that it was “Gathering baker data’ even though it had already retrieved all available information. This has been fixed!

Snapshot Imports can be cancelled

If a snapshot import ran into an issue or was simply taking too long, there was no way to exit out and you could get stuck in a bad state. That’s alleviated now that snapshot imports can be cancelled!

New bip-ed25519 Derivation Scheme Baking Support

A few months ago we announced support for an improved bip-ed25519 derivation scheme in the Tezos protocol and on Ledger devices. You can now bake with that derivation scheme on Kiln! To see which addresses Kiln finds with on this new derivation scheme, you can hover over addresses to see the curve and path used to generate each address.

Mac Support

If you have the Nix Package Manager installed, you can now build Kiln from source on MacOS! Just don’t try on Catalina, as nix is not currently supported on that operating system. This is not recommended for your average user, as it is a more technical process than nicely packaged version of Kiln, such as our debian package for Ubuntu.

Unfortunately this is the only update we can provide regarding Mac support at this time. Due to shifting priorities, we will not be releasing a distribution of Kiln for mac in 2019, but we hope to in 2020.

Post-Babylon Clean Up

Leading up to Babylon, we made several improvements to the core logic that handles block data and node RPC communications. Written in Haskell, we’ve moved this logic to a separate project that anyone can use for their own Tezos projects! We’ve already used it on several and we’ve received a merge request from the community, too!

We’ve also disabled support for the alphanet test network and instead now support babylonnet, however Carthagenet is not yet supported. We’ve also removed the Tzscan Public Node and updated block hash links so they now point to tzstats.com.

Questions? Encountered a bug? Email us at tezos@obsidian.systems, tweet us @obsidian_llc, join our slack group (just ask for an invite), or post your question on Tezos Stack Exchange! We’d love to hear from you.

Kiln v0.7.3: Usability, Ledger, and Protocol Improvements was originally published in kiln on Medium, where people are continuing the conversation by highlighting and responding to this story.

In case you missed it, you can now send, receive, or delegate your XTZ directly in Ledger Live! We’re thrilled that this functionality is now available to the Tezos community and would like to thank TQ Tezos and Ledger for making this possible.

In addition to that release, we’ve added several new features to Tezos’ Ledger applications recently! You can now download v2.2.5 from Ledger Live or Github, which includes:

• Manager.tz Operation Support (v2.2.1+)
• Named Delegates via the Baker Registry Smart Contract
• Nano X Bluetooth Communication
• Ledger Firmware 1.6.0 Support

While Ledger Firmware 1.6.0 support spans both applications, the rest of these changes only apply to Tezos Wallet. Nonetheless, we increment the version of both apps in lockstep with each release to preserve everyone’s sanity. These changes have been spread out across several releases, some internal, starting with v2.2.1 and ending with v2.2.5. For the full changelog for each release, see our releases page!

Important: Bakers should NOT upgrade the firmware on their baking Ledger device. For more information, see below.

Note: You’ll have to upgrade your Ledger device to firmware 1.6.0 to download this new version from Ledger Live, otherwise you’ll see v2.2.0 with firmware 1.5.5. This is currently only recommended for the Tezos Wallet App.

Manager.tz Operation Support

Versions v2.2.1+ display manager.tz smart contract operations in the device UI so users have improved security when using newly-scriptful KT1 originated accounts! There are 4 operations the manager.tz contract supports which needed special parsing:

• Set delegate
• Withdraw delegate
• Transfer to contract
• Transfer to implicit

Pre-Babylon, a KT1 account was delegated with the operation tezos-client set delegate for my-account to my-baker. During the recent protocol change, all scriptless KT1 accounts were upgraded to scriptful managert.tz contracts and implicit accounts (tz*) became delegatable. This delegation operation can now be used to delegate an implicit account and, thanks to some tezos-client pleasantries, it still works for originated accounts, too.

But under the hood, delegating KT1 accounts has fundamentally changed. Like many other interactions with a smart contract, the new operation is a call to the contract’s code in the form of a 0 XTZ transfer with a Michelson parameter:

tezos-client transfer 0 from <src> to <dst> --entrypoint ‘do’ --arg ‘{ DROP ; NIL operation ; PUSH key_hash <dlgt> ; SOME ; SET_DELEGATE ; CONS }’

In this operation:

• <src> is the implicit managers of the manager.tz contract (i.e. your tz* address)
• <dst> is the manager.tz contract destination of the operation (i.e. your KT1 address)
• <dlgt> is the baker to whom you wish to delegate

Parsing the Michelson parameters on operations like this the first instance of Tezos Wallet reading Tezos’ smart contract language! We’re excited to expand upon this to support other great use cases such as token standard interfaces.

Named Delegates

Sticking with the delegation theme, Tezos Wallet v2.2.2+ will now show you the name of the Delegation Service to whom you’re delegating!

Let’s use the same example operation as before: tezos-client set delegate for my-account to my-baker. When signing this operation you’ll be prompted to ‘Confirm Delegation’ before being shown the fee, source PKH (your address), the PKH of the delegate you’re delegating, and the operation’s storage limit. It is always important to verify this information on the Ledger device to be sure you’re doing what you think you’re doing. In this case, its paramount that you confirm you’re delegating to the right baker.

This new feature makes this validation step more secure and more pleasant by showing an additional field, ‘Delegate Name’ , which displays the name of the delegation service associated with that PKH. For example, if you’re delegating to “Sample Baker”, you’ll see “Sample Baker” here. If the app doesn’t associate the PKH you provided with a baker, it will show a message encouraging you to verify the delegate’s address is correct. There are over 100 delegation services currently recognized, and you can still delegate to any baker you like, named or not.

We’re very pleased to have the Baker Registry Smart Contract as the data source for this feature, the contents of which you can see here thanks to Tulip Tools! Originated by the Tezos Commons Foundation, this smart contract aggregates information about delegation services which they independently provide without the need for a central authority. It is the ideal, decentralized data source for a feature like this.

For now a hardcoded list of baker names and their PKHs is stored in Tezos Wallet, but we’ll be shifting to a more scalable solution in future releases.

Other Release Notes

These latest applications are designed to run on Ledger’s newest firmware (1.6.0). Tezos Wallet for the Nano X also now supports bluetooth communication! Mobile wallet apps (like Ledger Live for Apple and Android) can now communicate with the app wirelessly.

There are two addition changes we’ve made under the hood. v2.2.4 relies on the blake2b cryptographic hashing function provided by the Ledger firmware instead of using a version in the app. We needed this function before it was provided by Ledger’s firmware in 1.5.5 and we’re just making the switch now to make room in the app for new features. We’ve also adjusted our parser so it is able to handle bigger operations, such as those that involve smart contracts.

Tezos Baking App: Wait to Upgrade!

Bakers should wait until further notice before upgrading their baking Ledger to firmware 1.6.0. We’ve found an issue localized to the MCU firmware for the device and we will inform the community when a fixed firmware is available. Until then, Ledger has temporarily taken the app out of Ledger Live’s Manager.

The issue: we’ve observed that the Ledger device’s screen can go blank while Tezos Baking is running. When the screen goes blank, the device may stop responding to requests from the baker and endorser. If it does stop responding, these opportunities will be missed. Should this happen to you, simply unplug the device, plug it back in, and return to the Baking App. The issue will be temporarily solved.

Beyond this issue, there are no new features for Tezos Baking in this release and thus no need for bakers to upgrade.

A Note on Troubleshooting Wallet Issues

Since the Babylon protocol upgrade, we’ve seen many users reporting issues using their ledger device with their wallet provider. Not being able to move your crypto can be a frustrating experience, and everyone in the community wants to make sure these types of problems are minimized. In this case, some breaking changes have posed a challenge.

If you are still having trouble using your Ledger device with a wallet provider, we recommend reaching out to them for assistance — here are Galleon, Tezbox, and Magnum Wallet’s dedicated Telegram support channels! We’ll work closely with them to make sure ledger support is as good and stable as it can be. If you are having issues using your ledger device with tezos-client, please let us know by opening an issue on our Github or emailing us at tezos@obsidian.systems.

In addition to Babylon support, this release introduces an improved bip32-ed25519 derivation scheme. We’ve also taken this opportunity to mention changes in how tezos-client represents hardened paths. We recommend all users upgrade at their earliest convenience.

Babylon Support

The Babylon amendment introduces changes to the binary format in common operations including transactions, delegations, originations, and reveals. v2.2.0 is the first release which can parse operations from both the Athens and the Babylon protocol. Prior versions will still be able to sign operations on Babylon, but they will not be able to parse them and show them on the Ledger device’s screen.

New bip32-ed25519 Derivation Scheme

Tezos now supports a new bip32-ed25519 derivation scheme! This feature was made possible by Ledger’s most recent firmware update (v1.5.5), support within the Tezos repository (!1164), and this update to our Tezos applications. We recommended all wallet providers, exchanges, and other services generating many addresses use this new ed25519 derivation scheme over the existing one because it provides better account security than the previous method. Another benefit is that it supports non-hardened paths, whereas the old ed25519 scheme is the only one which does not support them.

This feature is only visible if you are using a ledger application and version of tezos-client which supports it, otherwise tezos-client will not show it as an option. When available on the device, running list connected ledgers suggests 4 import secret key commands:

tezos-client import secret key ledger_user “ledger://major-squirrel-thick-hedgehog/bip25519/0h/0h”

tezos-client import secret key ledger_user “ledger://major-squirrel-thick-hedgehog/ed25519/0h/0h”

tezos-client import secret key ledger_user “ledger://major-squirrel-thick-hedgehog/secp256k1/0h/0h”

tezos-client import secret key ledger_user “ledger://major-squirrel-thick-hedgehog/P-256/0h/0h”

The first import command listed uses the new derivation scheme, bip25519. We’ve purposefully not changed the existing ed25519 scheme to preserve backwards compatibility. If you change nothing in your Tezos setup, expect no changes. However, we recommend that all new accounts use the bip25519 command instead of the legacy ed25519. After it is imported, the address can be treated the same as any other.

New Representation of Hardened Paths in tezos-client

Across all Tezos networks (mainnet, alphanet, and zeronet), hardened paths in ledger URIs are now represented with an (h) instead of a tick mark (').

Up until !1165, import secret key commands have been formatted as:

tezos-client import secret key ledger_user “ledger://major-squirrel-thick-hedgehog/ed25519/0'/0'”

The ' near the end of the URI indicates that the derivation path is hardened. In almost all cases, this formatting of hardened paths works fine. But there can be instances where terminal shells (like bash) interpret the tick marks on the hardened derivation paths as quotation marks, which changes the imported address. In the worst case, this can result in a different address being imported than the one you expect. To avoid this, we’ve switched to to denoting hardened paths with an h:

tezos-client import secret key ledger_user “ledger://major-squirrel-thick-hedgehog/ed25519/0h/0h”

Similar to the ed25519 derivation scheme, you can continue to use the legacy /0'/0' representation and it will still work, but we recommend upgrading to the new syntax.

Questions? Feedback? Email us at tezos@obsidian.systems, tweet us @obsidian_llc, join our slack group, or post your question on Tezos Stack Exchange! We’d love to hear from you.

The major updates in this release are:

1. The Kiln Node can be started from a snapshot
2. The Kiln Node runs in Full Mode
3. Kiln can monitor full nodes
4. The Obsidian Public Node cache is now enabled by default
5. Notifications reminding the Kiln Baker to vote
6. A Notification when an update to Kiln is available

Kiln Node Updates

The Kiln Node now runs in full mode and can be started from a snapshot! Snapshots are taken at a given block level and represent the chain’s history up until that block level.

When syncing a node from a snapshot, you only need to sync from that block level instead of syncing from the genesis block. Only needing to sync, for example, 500 blocks instead of 500,000 blocks drastically reduces the amount of time it takes to sync with the network. The Kiln Node can now sync in minutes instead of days!

This also has a huge impact on storage requirements. As the Tezos blockchain grows larger, it takes more disk space to store chain history. For instance, as of July 2019 an archive node requires 188GB of disk space. Snapshots can bring that number down to the single digits.

Over time the node will store more chain history and that number will grow, but don’t worry — you can always recreate your node from a more recent snapshot to reduce storage requirements again!

If you are a Kiln user looking to upgrade your Kiln Node to full mode, you will need to delete your existing archive node and start a new node from a snapshot. You can find detailed instructions on how to upgrade here!

If you’d like to learn more about snapshots and how they work, we recommend reading this post by Nomadic Labs. We are able to bring this great feature to Kiln because of their excellent work!

Data Source Updates

In addition to running the Kiln Node in full mode, Kiln can monitor full nodes too!

Some backstory — Kiln keeps a cache of chain data that it builds from the nodes it runs or monitors. This cache builds its chain history from the collective state of all the nodes it is monitoring and re-evaluates its correctness every time it sees a new block. Not only does this offer the highest guarantees of accuracy, it allows Kiln to acknowledge states where monitored nodes recognize multiple chain heads, spot reorganizations effortlessly, and correct itself if its history is found to be incorrect due to a reorganization.

This cache is what serves the information you see in Kiln’s dashboard for existing features and lots of other potential features we’d love to introduce in the future. For instance, showing your baker’s efficiency would require that we know all your previous opportunities to bake (your rights), as well as all the times you successfully baked. We’d also want to know instances where a lower priority than yours was baked for your non-priority 0 rights (i.e. was a priority 2 block baked when you had priority 1 rights). Retrieving that information from a node can be costly and time consuming, which is why it must be stored in a cache. Additionally, Kiln recognizes nodes it is monitoring could be used for baking, so it politely polls for information as necessary rather than hammering it with requests. This means it can take a bit longer to build a cache of chain history, but we view that as a better alternative to missing opportunities due to an overloaded node.

Prior to this release, Kiln assumed it could grab all chain data from any node. This was a fine assumption when there were only archive nodes, but the introduction of two new, more lightweight history modes has challenged that assumption. Not only do they keep less chain history as an archive node, they could have been started from a recent snapshot resulting in partial history, too. Current Kiln users monitoring a full node started from a snapshot may have seen the results of this — Kiln indefinitely reporting that it is ‘Gathering Baker Data’ while it tries to retrieve information that is unavailable. That won’t happen anymore.

We’ve made Kiln smarter about what information it can get from monitored nodes so its cache can remain robust and correct no matter the data sources it has available. But that didn’t completely solve the issue; there was still the opportunity that the user’s nodes wouldn’t be sufficient for Kiln to correctly report chain data. For instance, if a user has a full node started from a snapshot only a few blocks ago, that isn’t enough information for us to see details of previous voting periods in the current amendment process or what your rights were several cycles ago.

To permanently fix this for all users, the OS Public Node now serves all the data Kiln needs to operate! This public node, which is really just an instance of Kiln with an exposed API for other instances of Kiln, has chain data cached and immediately available for other instances of Kiln. Since this will be a critical data source for most users we’ve enabled the OS Public Node by default, but you can disable it via the command line if you choose. Just know that you’ll need your own archive node for Kiln to behave correctly in this case.

Notification Updates

The overarching goal of Kiln is to make participating in Tezos as easy as possible. An important part of that means making sure our users are active and engaged participants in the protocol amendment process. For that reason, Kiln now sends voting notifications! You should generally expect notifications 1) at the start of a voting period, 2) half way through the voting period and 3) 90% through the voting period. I say ‘generally’ because the logic takes into account which amendment period it is and whether or not you have already voted. For instance, if you have already voted in the Proposal Period and new proposals are injected after that, we’ll let you know there are new proposals for you to consider — you can vote for up to 20!

We’ve also added a notification when a new version of Kiln is available! Kiln updates can be critical to ensuring it continues to work properly. For example, protocol amendments may introduce changes that will break older versions of Kiln. We’ve added this notification to make sure you are aware of these updates and can upgrade in time to keep your baker running smoothly.

Other Updates and Next Steps

Like all Kiln releases, we’ve made some UI improvements and bug fixes along the way. You might also notice the browser tab now has a favicon and a page title!

For our next release, we’re making it easier to export logs from the node, baker, and endorser from Kiln’s UI. This should help us assist anyone who thinks they are having a problem with Kiln and root out any bugs more efficiently. This feature, along with the ability to run commands against tezos-client and tezos-admin-client (which is already in place), provide lots of flexibility for our users to do their own debugging, get assistance from our team, and fix issues.

We’re also making progress on distributions — an OVA file to run in Virtualbox, a Mac version, and a dedicated website! We don’t have release dates for these yet, but we are making progress on having them available.

Questions? Encountered a bug? Email us at tezos@obsidian.systems, tweet us @obsidian_llc, join our slack group (just ask for an invite), or post your question on Tezos Stack Exchange! We’d love to hear from you.

Kiln v0.6.0: Snapshots, Full Nodes, and Revamped Public Nodes was originally published in kiln on Medium, where people are continuing the conversation by highlighting and responding to this story.

Depending on the speed of your machine and the recency of your snapshot, this upgrade process will take some time. It would be best to time it when you don’t have many baking or endorsing rights! 1 to 2 hours should do.

Step 1: Download a Tezos Node Snapshot

Before you begin upgrading the node you should download the snapshot you’ll be starting your node from. Doing this first helps minimize your node’s downtime and thus the chances of missing a bake or endorsement.

You should get your snapshot form a source you trust. Some reputable community members make these available, such as Tezos Shots, TzDutch, and Bake ꜩ for Me. You can also have someone else you know who has a node export one for you. Either way, it is important that you 1) trust the location you get your snapshot from and 2) verify the snapshot with a 3rd party. We’ll touch on number 2 later on.

Step 2: Delete the Archive Node

Now that you have your snapshot, you can delete the existing archive Kiln Node. As of this writing (July 2019) an archive node uses 188GB, so this will clear out a lot of disk space! You will not be able to recover this data once it is deleted, but don’t worry — your Kiln Node will be in sync with the network again soon.

To delete the node, click the menu icon in the top right corner of the Kiln Node’s tile. Select ‘Remove Node’ from the dropdown menu. In the modal that appears, click ‘Stop and Remove Node’.

Step 3: Import the Snapshot

Now that you’ve removed the Kiln Node, you can re-add it using the snapshot you downloaded earlier. Click ‘Add Nodes’ in the left column to begin. In the modal that appears, click ‘Start Node’ on the far left to add a Kiln Node. That will open a modal with the options to initialize chain data from a snapshot or via peer-to-peer download from genesis. Click ‘Select Snapshot File’, select the snapshot from your machine and click ‘Add Node’ to start the import process! This step will take some time, depending on you machine’s specifications.

Step 4: Verify the Snapshot

Once the snapshot has finished uploading, you are in the closing stretch! All that’s left is to verify the snapshot. Click ‘Start Verification’ to begin.

This will open a modal with details about the snapshot for you to verify. Be sure to read the instructions on this modal! You want to make sure this snapshot’s block hash — the hash of the highest block of the snapshot — is part of the chain’s history and is at the block level that you expect. This brief but important step helps protect the integrity of the Tezos blockchain.

Once you’ve verified the snapshot and hit ‘Start Node’, you’re done! Kiln will automatically generate an identity for your node and begin syncing.

The longer your node is running, the more disk space it will use. Over time, if you would like to reduce the amount of disk space your Kiln Node uses, you can repeat this process to free up space again.

Let us know if you have questions or run into any issues! You can reach us at tezos@obsidian.systems, tweet us @obsidian_llc, join our slack group (just ask for an invite), or post your question on Tezos Stack Exchange! We’d be happy to help.

How to Upgrade Your Kiln Node to Full Mode from a Snapshot was originally published in kiln on Medium, where people are continuing the conversation by highlighting and responding to this story.