-
Notifications
You must be signed in to change notification settings - Fork 2
[s 1] Simple instructions to bake and keep (most of) your tezzies offline
Here I put some basic simple instructions to setup the necessary accounts to bake your own tezzies safely. I assume a tezos node is available and accessible, regardless of the OS (with or without docker). For docker users the commands are slightly different, for example (docker) "./alphanet.sh client" is equivalent to (no docker) "./tezos-client".
First an overview of the task. The idea is to have a [primary_account] (in the Tezos Dev Res it is of a type called "implicit") secured offline. Only a fraction of the total tezzies that are needed for the bonds are kept online in a different account, which is called [baking_account] (another implicit account). The rest of the tezzies are transferred from the [primary_account] to another account [secondary_account] (in the Tezos Dev Res it is of a type called "originated" also called "contract") which is managed by the [primary_account] but delegated to the [baking_account]. Once the private key of the [primary_account] is removed from the tezos node, it is impossible to move or "steal" the tezzies stored in the [secondary_account] while they are still contributing to the rolls entitled for baking.
It is strongly recommended to try experimenting first on the zeronet network (virtual xtz) before making real changes on the betanet (real xtz)
Here is how it is done.
For the zeronet:
After acquiring one or more json files (free xtz from the faucet),
the first step is to activate one or more [primary accounts]:
./tezos-client activate account [primary_account] with [dir]/.tezos-client/tz1---initial-wallet----------------.json
where [dir] is the location of the json file.
For the betanet use the following command:
./tezos-client import fundraiser secret key <primary_account>
./tezos-client activate fundraiser account <primary_account> with <activation key from verification>
For both zeronet and betanet the next step is to generate an empty [baking_account]:
./tezos-client gen keys [baking_account]
These commands will create a pair of keys for each account. A password needs to be created and it will be required for any operation started from the baking_account. The public and secret keys of these two accounts are stored in the files secret_keys, public_keys and public_key_hash located in in folder /.tezos-client. At this point a certain amount of tezzies are transferred to the [baking_account] to cover for the various deposits that may be needed. How much? hard to say precisely, one can start with a certain amount and, while the node is running, see if it is too much or too little, then adjust accordingly (the so-called empirical approach). In the following example let's assume that the [primary_account]s has/have 20000 xtz in total and 10% is put out for bonds with the following command:
./tezos-client transfer 2000 from [primary_account] to [baking_account]
After a minute or two check the balance in the two accounts:
./tezos-client get balance for [baking_account]
./tezos-client get balance for [primary_account]
At this point the [baking_account] needs to be registered for baking:
./tezos-client register key [baking_account] as delegate
Now the tricky part. We transfer the rest of the xtz in a [secondary_account] that is delegated to the [baking_account] but the manager, who has control over the [secondary_account], is still the [primary_account]. This is the command that will do the job:
./tezos-client originate account [secondary_account] for [primary_account] transferring 18000 from [primary_account] --delegate [baking_account] --delegatable
The command should be self-explanatory. The last flag (--delegatable) is highly recommended because it allows in future to change the baker to whom the contract is delegated.
Find out that everything is correct:
./tezos-client get manager for [secondary_account]
./tezos-client get delegate for [secondary_account]
and check again the balance:
./tezos-client get balance for [baking_account]
./tezos-client get balance for [primary_account]
./tezos-client get balance for [secondary_account]
Additional info are provided by these commands:
./tezos-client list known identities
the output is something like this:
output: tz1-----[primary_account]------
output: tz1-----[baking_account]-------
and
./tezos-client list known contracts
this is the output:
output: KT1------[secondary_account]-------
where tz1---- and KT1---- are the public hash tags of the various accounts. Now the secret key of the [primary_account] can be removed from the node, and stored in a safe usb flash drive, ledger, paper wallet, etc. Before removing the key, the file secret_keys looks like this:
[ { "name": "[primary_account]",
"value":
"unencrypted:edsk45Uwb8UwAoHFUdQv8wwZHwYfoUz7Ac7qfCjwPbkAwPxRri8Dmb" },
{ "name": "baking_account]",
"value":
"unencrypted:edsk3KpR233RzJ9EnZHWr2j9ZV8CYFFkhE6Epj1nQZe3Q55HU48koepM" } ]
after removing the key it looks like this:
[ { "name": "baking_account]",
"value":
"unencrypted:edsk3KpR233RzJ9EnZHWr2j9ZV8CYFFkhE6Epj1nQZe3Q55HU48koepM" } ]
By removing the secret key that manages the [secondary_account], the xtz in the [secondary_account] will remain safe as long as the key stays in a safe place. In the meantime the xtz are used for baking and nothing else.
A simple test for example is to try a transfer from the [secondary_account] to the [baking_account] (or any other account):
./tezos-client transfer 1234 from [secondary_account] to [baking_account]
the operation will not be completed and an error message will be displayed.
To get a complete view of the [baking_account], this is the command:
./tezos-client rpc get /chains/main/blocks/head/context/delegates/tz1------[baking-account]-----------
the output is something like this:
{ "balance": "2000000002", "frozen_balance": "0",
"frozen_balance_by_cycle": [], "staking_balance": "20000000002",
"delegated_contracts": [ "KT1----[secondary-account]----------" ],
"delegated_balance": "18000000000", "deactivated": false,
"grace_period": 63 }
where balance is the xtz in the [baking_account] (2000 xtz), delegated balance the xtz from the [secondary_account] (18000 xtz) and staking balance is the sum of the two (20000 xtz) which is the actual amount considered for baking (2 rolls).
Grace period is the cycle at which the [baking_account] is no longer considered an active baker. It can happen when no baking/endorsing activities are registered for 5 cycles. If this is the case, then simply re-register the delegate account:
./tezos-client register key [baking_account] as delegate
On the zeronet it takes at least 6hrs to have the delegate process activated (currently blocks are created every 20 seconds).
On the betanet it takes ~3 weeks. Until then the [baking_account] will have only the deposit funds
(in the example above 2000 xtz) and the account won't be selected for baking or endorsing (no rolls, no baking).
The Tezos block explorer tzscan.io gives a nice overview of the [baking_account],
the current web-link on the zeronet is something like this:
zeronet.tzscan.io/tz1------[baking-account]-----------
When the node is selected for baking/endorsing the previous rpc get
command will create an output similar to this:
{ "balance": "1940000002", "frozen_balance": "64000000",
"frozen_balance_by_cycle":
[ { "cycle": 61, "deposit": "64000000", "fees": "0",
"rewards": "2000000" } ], "staking_balance": "20000000002",
"delegated_contracts": [ "KT1----[secondary-account]----------" ],
"delegated_balance": "18000000000", "deactivated": false,
"grace_period": 67 }
where the frozen balance taken from the [baking_account] is 64 xtz and the reward for this particular block endorsement is 2 xtz.
Final note: since the baking account is password encrypted, the programs tezos-baking-xxx and tezos-endorsing-xxx, which manage the baking and endorsing operations, will require to input the password to access the funds when the programs are launched.
The baking and endorsing managers are called differently on the zeronet and betanet. On the zeronet: tezos-baking-alpha and tezos-endorsing-alpha, on the betanet: tezos-baking-002-PsYLVpVv and tezos-endorsing-002-PsYLVpVv
Further steps:
- On page [s-2] Learn how to use the tezos-signer daemon which supervise the baking and endorsing managers.
- On page [s-3] Add a bit more security to protect the secret key of the baking account.
This wiki site has been developed by people not affiliated to the Tezos Blockchain Development Team or the Tezos Foundation or the Fedora Project or the Raspberry Pi Foundation
(archived NEWS on page [j])
- 02/17/20 This is the end of the road for the tezos-rpi3 wiki, see the announcement in the UPDATES page [i]
- 10/18/19 A new Tezos protocol has been activated (005). Some essential info in the UPDATES page [i]
- 09/06/19 Next page [h] on forging and signing operations offline using Tezos
- 09/02/19 New page [g] on using the Nitrokey HSM 2 with the Tezos-hsm-signer from Polychain Labs
- 07/01/19(revised 07/04/19) New info on how to poke a node remotely on a local network (page [b] F-24), how to use the Tezos remote-signer locally and remotely (page [b] F-25), and how to restart automatically the Tezos programs using a crontab script (page [b] F-26 and page [d])
- 06/06/19 Make permanent changes to the scheduler for the external hard drive (page [f])
-
05/30/19 New protocol (004-Pt24m4xi) activated on May-30th-2019.
Some changes on page [b] section F-18) about zram and page [f] about SSD and swap file. - 05/10/19 Kernel 5.x.x, new scheduler options. And also SSD, is it worth it? page [f]
- 03/27/19 RPI3 back on the baking track after some tuning of the HDD I/O. See page [f]. These changes are essential.
- 01/04/19 In the [g] Updates page few hints to keep the RPI3 node in sync while running the baking/endorsing daemons (revised 01/27/19)