You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/btcli/btcli-permissions.md
+17-17Lines changed: 17 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,16 +8,16 @@ This page details the requirements for all of the `btcli` commands.
8
8
9
9
See also the `btcli` permissions guides for specific Bittensor personas:
10
10
11
-
-[Staker's Guide to `BTCLI`](./staking-and-delegation/stakers-btcli-guide)
12
-
-[Miner's Guide to `BTCLI`](./miners/miners-btcli-guide)
13
-
-[Validator's Guide to `BTCLI`](./validators/validators-btcli-guide)
14
-
-[Subnet Creator's Guide to `BTCLI`](./subnets/subnet-creators-btcli-guide)
15
-
-[Senator's Guide to `BTCLI`](./governance/senators-btcli-guide)
11
+
-[Staker's Guide to `BTCLI`](../staking-and-delegation/stakers-btcli-guide)
12
+
-[Miner's Guide to `BTCLI`](../miners/miners-btcli-guide)
13
+
-[Validator's Guide to `BTCLI`](../validators/validators-btcli-guide)
14
+
-[Subnet Creator's Guide to `BTCLI`](../subnets/subnet-creators-btcli-guide)
15
+
-[Senator's Guide to `BTCLI`](../governance/senators-btcli-guide)
16
16
17
17
Other resources:
18
18
19
-
-[Introduction to Wallets, Coldkeys and Hotkeys in Bittensor](./getting-started/wallets)
20
-
-[Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
19
+
-[Introduction to Wallets, Coldkeys and Hotkeys in Bittensor](../keys/wallets)
20
+
-[Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
21
21
22
22
## Bittensor work environments and security requirements
23
23
@@ -28,19 +28,19 @@ The workstations you use to do this work can be referred to as a permissionless
28
28
1. A **permissionless workstation** has only coldkey _public keys_ on it. Public keys are sufficient for viewing all information about a wallet, such as TAO and alpha stake balances. Information about wallets, subnets, miners, and validators can and should be viewed without initializing your private keys on a device, to avoid the security risk of compromising your keys.
29
29
30
30
:::tip coldkey workstation security
31
-
See [Permissionless workstation](./getting-started/coldkey-hotkey-security#permissionless-workstation)
31
+
See [Permissionless workstation](../keys/coldkey-hotkey-security#permissionless-workstation)
32
32
:::
33
33
34
34
1. A **coldkey workstation** contains one or more coldkey private key in the `wallet_path`. For any coldkey associated with mainnet TAO, the coldkey workstation should be held to the highest possible security standards.
35
35
36
36
:::tip coldkey workstation security
37
-
See [Coldkey workstation](./getting-started/coldkey-hotkey-security#coldkey-workstation)
37
+
See [Coldkey workstation](../keys/coldkey-hotkey-security#coldkey-workstation)
38
38
:::
39
39
40
40
1.**A hotkey workstation**—which is generally a server used for mining or validation—contains a hotkey private key in the `wallet_path` located in the `btcli config`, as well as a coldkey public key for the corresponding coldkey. Compromised hotkeys can damage your reputation if they are used to maliciously to submit inaccurate weights as a validator, or bad work as a miner. However, ownership of TAO or alpha stake can only be transferred with a coldkey, and a leaked hotkey can be swapped using the coldkey; therefore hotkey leaks are far less dangerous than coldkey leaks.
41
41
42
42
:::tip hotkey workstation
43
-
See [Hotkey workstation security](./getting-started/coldkey-hotkey-security#hotkey-workstation)
43
+
See [Hotkey workstation security](../keys/coldkey-hotkey-security#hotkey-workstation)
44
44
:::
45
45
46
46
## Requirements for `btcli` functions
@@ -49,7 +49,7 @@ The workstations you use to do this work can be referred to as a permissionless
49
49
50
50
Your coldkey is your primary, fully privileged key; important for all users. This key should be handled on a maximum security **coldkey workstation** only, to avoid catastrophic loss or malicious actions if compromised.
51
51
52
-
See [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security).
52
+
See [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security).
53
53
54
54
Required for:
55
55
@@ -85,11 +85,11 @@ Some operations require a TAO balance or alpha stake balance to execute.
85
85
86
86
### Validator Permit
87
87
88
-
To set weights, a validator must meet several requirements. See [Requirements for validation](./validators/#requirements-for-validation).
88
+
To set weights, a validator must meet several requirements. See [Requirements for validation](../validators/#requirements-for-validation).
89
89
90
90
### Senate requirements
91
91
92
-
See [Senate: Requirements](./senate#requirements)
92
+
See [Senate: Requirements](../governance/senate#requirements)
93
93
94
94
## `btcli` commands
95
95
@@ -102,7 +102,7 @@ The `btcli config ...` commands are used to configure `btcli`, including:
102
102
103
103
These commands don't require any permissions to run. Rather, you run these commands on all `btcli` workstations to initialize them.
104
104
105
-
See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
105
+
See: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
106
106
107
107
<details>
108
108
<summary>btcli config</summary>
@@ -129,7 +129,7 @@ See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-
129
129
The `wallet` command is required to provision keys to `btcli`, so it can access your wallet. This is essentially the equivalent of logging in/authentication. This is true for both coldkeys, which all users require, and hotkeys, which are required only by miners and validators as well as for advanced functions.
130
130
131
131
:::tip mind your keys
132
-
See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
132
+
See: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
133
133
:::
134
134
135
135
#### Provisioning keys
@@ -288,7 +288,7 @@ See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-
288
288
Read operations require public keys. Write operations (stake add, move, remove...) require a coldkey private key.
289
289
290
290
:::tip mind your keys
291
-
See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
291
+
See: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
292
292
:::
293
293
294
294
<details>
@@ -442,7 +442,7 @@ Miner and validator registering a hotkey uses a coldkey, has a TAO cost unless p
442
442
443
443
Reading weights with `reveal` is permissionless.
444
444
445
-
To set weights with `commit`, a validator must meet several requirements. See [Requirements for validation](./#requirements-for-validation).
445
+
To set weights with `commit`, a validator must meet several requirements. See [Requirements for validation](#validator-permit).
Command line interface (CLI) for Bittensor. Uses the values in the configuration file. These values can be overriden by passing them explicitly in the command line.
8
8
9
-
See [Getting Started](./getting-started/install-btcli.md) to install `btcli`.
9
+
See [Getting Started](../getting-started/install-btcli.md) to install `btcli`.
10
10
11
11
:::note Transaction Fees
12
-
Many btcli operations incur transaction fees. See [Transaction Fees in Bittensor](./fees.md) for details.
12
+
Many BTCLI operations incur transaction fees. See [Transaction Fees in Bittensor](../learn/fees.md) for details.
13
13
:::
14
14
15
15
Command line interface (CLI) for Bittensor. Uses the values in the configuration file. These values can be
Copy file name to clipboardExpand all lines: docs/btcli/overview.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,10 +4,10 @@ title: "Bittensor CLI Overview"
4
4
5
5
# Bittensor CLI Overview
6
6
7
-
The Bittensor command line interface (CLI), `btcli`, provides the simplest way to interact with the Bittensor network and its subnets from the command line. This includes managing [wallets (coldkeys and hotkeys)](../getting-started/wallets), TAO balances, transfer, staking and unstaking functions, node registration, governance functions, and more.
8
-
7
+
The Bittensor command line interface (CLI), `btcli`, provides the simplest way to interact with the Bittensor network and its subnets from the command line. This includes managing [wallets (coldkeys and hotkeys)](../keys/wallets), TAO balances, transfer, staking and unstaking functions, node registration, governance functions, and more.
|**Network Purpose**| Transactions with financial value | Test transactions with no value, constrained by tokenomics | Development and testing in fully user-controlled environment |
18
-
|**Test TAO**| None | Available on request (not compatible with devnet test TAO) | Available in Alice wallet. See [Access the Alice account](./local-build/provision-wallets#access-the-alice-account). |
18
+
|**Test TAO**| None | Available on request (not compatible with devnet test TAO) | Available in Alice wallet. See [Access the Alice account](../local-build/provision-wallets#access-the-alice-account). |
Copy file name to clipboardExpand all lines: docs/concepts/commit-reveal.md
+8-13Lines changed: 8 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,38 +1,37 @@
1
-
2
1
import ThemedImage from '@theme/ThemedImage';
3
2
import useBaseUrl from '@docusaurus/useBaseUrl';
4
3
5
4
# Commit Reveal
6
5
7
6
This page describes the **commit reveal** feature: a configurable waiting period that elapses between a) when consensus weights set by subnet validators are first committed, and b) when they are revealed publicly and included in Yuma Consensus.
8
7
9
-
This feature was designed to address the issue of *weight copying* by validators.
8
+
This feature was designed to address the issue of _weight copying_ by validators.
10
9
11
10
## Weight copying
12
11
13
-
In each Bittensor subnet, each validator scores—or *'weights'*—each miner, producing what is referred to as a [weight vector](../glossary.md#weight-vector). The weight vectors for each validator in a subnet are combined into a weight matrix. This matrix determines emissions to miners in the subnet based on the consensus evaluation of their performance, according to [Yuma Consensus](../glossary.md#yuma-consensus).
12
+
In each Bittensor subnet, each validator scores—or _'weights'_—each miner, producing what is referred to as a [weight vector](../resources/glossary.md#weight-vector). The weight vectors for each validator in a subnet are combined into a weight matrix. This matrix determines emissions to miners in the subnet based on the consensus evaluation of their performance, according to [Yuma Consensus](../resources/glossary.md#yuma-consensus).
14
13
15
14
The weight matrix is public information, and must be, so that emissions in the Bittensor platform can be transparently fair. However, this transparency makes it possible for subnet validators to free-ride on the work of other validators by copying the latest consensus rather than independently evaluating subnet miners. This is unfair and potentially degrades the quality of validation work, undermining Bittensor's ability to incentivize the best miners and produce the best digital commodities overall.
16
15
17
16
The commit reveal feature is designed to solve the weight copying problem by giving would-be weight copiers access only to stale weights. Copying stale weights should result in validators departing from consensus. However, it is critical to note that this only works if the consensus weight matrix changes sufficiently on the time scale of the commit reveal interval. If the demands on miners are too static, and miner performance is very stable, weight copying will still be successful. The only solution for this is to demand continuous improvement from miners, requiring them to continuously evolve to maintain their scoring. Combined with a properly tuned Commit Reveal interval, this will keep validators honest, as well as producing the best models.
18
17
19
18
## Commit Reveal and Immunity Period
20
19
21
-
The [Immunity Period](../glossary.md#immunity-period) is the interval (measured in blocks) during which a miner or validator newly registered on a subnet is 'immune' from deregistration due to performance. The duration of this period value should always be larger than the Commit Reveal interval, otherwise the immunity period will expire before a given miner's scores are available, and they may be deregistered without having their work counted.
20
+
The [Immunity Period](../resources/glossary.md#immunity-period) is the interval (measured in blocks) during which a miner or validator newly registered on a subnet is 'immune' from deregistration due to performance. The duration of this period value should always be larger than the Commit Reveal interval, otherwise the immunity period will expire before a given miner's scores are available, and they may be deregistered without having their work counted.
22
21
23
22
When creating a new subnet, ensure that the miner immunity period is larger than the commit reveal interval. When updating the immunity period or commit reveal interval hyperparameters for a subnet, use the following formula:
24
23
25
24
```
26
25
new_immunity_period = (new_commit_reveal_period x tempo - old_commit_reveal_period x tempo) + old_immunity_period
27
26
```
28
27
29
-
See [Subnet Hyperparameters](./subnet-hyperparameters.md).
28
+
See [Subnet Hyperparameters](../subnets/subnet-hyperparameters.md).
30
29
31
30
## Commit reveal in detail
32
31
33
-
When commit reveal is enabled, it works as follows:
32
+
When commit reveal is enabled, it works as follows:
34
33
35
-
1. A subnet validator sets the weights normally by using [`set_weights`](pathname:///python-api/html/autoapi/bittensor/core/extrinsics/set_weights/index.html).
34
+
1. A subnet validator sets the weights normally by using [`set_weights`](pathname:///python-api/html/autoapi/bittensor/core/extrinsics/set_weights/index.html).
36
35
37
36
2. Instead of publishing weights openly, an encrypted copy of these weights is committed to the blockchain, using an internal method called [`commit_weights`](pathname:///python-api/html/autoapi/bittensor/core/extrinsics/commit_weights/index.html).
38
37
@@ -62,22 +61,20 @@ style={{width: 750}}
62
61
/>
63
62
</center>
64
63
65
-
66
64
## How to use the commit reveal feature
67
65
68
66
As a subnet owner, set the below hyperparameters to use the commit reveal feature:
69
67
70
68
1.`commit_reveal_weights_enabled` (boolean): Set this to `True` to activate the commit reveal feature for the subnet. Default value is `False`.
71
69
2.`commit_reveal_period` (int): Set this to an integer number. This is the number of subnet tempos to elapse before revealing the weights by submitting them again to the blockchain, but now openly for everyone to see. Default value is `1`.
72
70
73
-
See [Setting subnet hyperparameters](subnet-hyperparameters#setting-the-hyperparameters).
71
+
See [Setting subnet hyperparameters](../subnets/subnet-hyperparameters.md#set-hyperparameters).
74
72
75
73
:::danger Ensure that the commit reveal interval is less than your immunity period to avoid unintended miner de-registration!
76
74
See [Commit Reveal and Immunity Period](#commit-reveal-and-immunity-period).
77
75
:::
78
76
79
-
80
-
Weights will be revealed immediately at the beginning of the tempo after the `commit_reveal_period`. For example, if `commit_reveal_period` value is set to `3`, then the reveal will occur at the beginning of the fourth tempo from the current tempo. The current tempo is counted as the first tempo. See the below diagram for this example:
77
+
Weights will be revealed immediately at the beginning of the tempo after the `commit_reveal_period`. For example, if `commit_reveal_period` value is set to `3`, then the reveal will occur at the beginning of the fourth tempo from the current tempo. The current tempo is counted as the first tempo. See the below diagram for this example:
81
78
82
79
<center>
83
80
<ThemedImage
@@ -92,10 +89,8 @@ style={{width: 750}}
92
89
93
90
<br />
94
91
95
-
96
92
## Technical papers and blog
97
93
98
94
- ACM CCS2024 Poster PDF [Solving the Free-rider Problem In Bittensor](pathname:///papers/ACM_CCS2024_Poster.pdf).
99
95
- See [Weight Copying in Bittensor, a technical paper (PDF)](pathname:///papers/BT_Weight_Copier-29May2024.pdf).
100
96
- Blog post, [Weight Copying in Bittensor](https://blog.bittensor.com/weight-copying-in-bittensor-422585ab8fa5).
Copy file name to clipboardExpand all lines: docs/concepts/root-network.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ title: "Root Network"
6
6
7
7
:::tip
8
8
9
-
The Root Network no longer is in operation, so this doc is a kind of historical artifact. The Root Network was decommisioned with the [Dynamic TAO](./dynamic-tao) upgrade in February 2025
9
+
The Root Network no longer is in operation, so this doc is a kind of historical artifact. The Root Network was decommisioned with the [Dynamic TAO](../dynamic-tao/index.md) upgrade in February 2025
10
10
:::
11
11
12
12
The root network was a special kind of subnet. The root network has the `netuid` of 0.
It is designed for users who prefer quick terminal commands or those managing multiple nodes and subnet interactions.
32
-
**See [Bittensor CLI reference](./btcli.md)** for detailed usage instructions.
34
+
**See [Bittensor CLI reference](../btcli/btcli.md)** for detailed usage instructions.
33
35
34
36
---
35
37
36
38
## Wallets and Keys
37
39
38
-
In Bittensor (like other cryptocurrency applications), a *wallet* is a tool for managing the cryptographic key-pairs required to prove your identity, sign transactions, and access your currency
40
+
In Bittensor (like other cryptocurrency applications), a _wallet_ is a tool for managing the cryptographic key-pairs required to prove your identity, sign transactions, and access your currency
39
41
40
42
Bittensor uses a dual-key wallet structure:
41
-
-**Coldkey** for secure storage of TAO and high-security operations
43
+
44
+
-**Coldkey** for secure storage of TAO and high-security operations
42
45
-**Hotkey** for operational tasks like validation, mining, and day-to-day transactions
43
46
44
47
Both keys are crucial for safeguarding and participating in the network.
45
-
**For a complete guide, see [Wallets & Keys](./getting-started/wallets)** and [Working with Keys](./working-with-keys).
46
-
48
+
**For a complete guide, see [Wallets & Keys](../keys/wallets)** and [Working with Keys](../keys/working-with-keys).
0 commit comments