diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md index e8a8ff40603..724739abfbc 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/academy-intro/academy-overview.md @@ -132,10 +132,10 @@ Chia学院的课程页面经过精心设计，以增强学生的学习体验。 所有适用的课程都提供了Chialisp和clvm的可运行插件。 花些时间熟悉这些工具，并学习如何在整个课程中最好地利用它们。 每个插件都有一系列组件： -**语言：** 插件的语言（Chialisp或clvm）位于右上角。 -**解决方案(Solution)：** 顶部部分是输入或解决方案。 -**谜题(Puzzle)：** 底部部分是谜题。 -**运行：** 每个插件在语言标识符右侧都有一个播放/运行按钮。 +**语言：** 插件的语言（Chialisp或clvm）位于右上角。 +**解决方案(Solution)：** 顶部部分是输入或解决方案。 +**谜题(Puzzle)：** 底部部分是谜题。 +**运行：** 每个插件在语言标识符右侧都有一个播放/运行按钮。 **结果：** 单击运行后，谜题的结果将出现在谜题下方。 :::info diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md index 68b0c0373a4..d7154d67932 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-inner-puzzle.md @@ -123,7 +123,7 @@ import Runnable from '@site/src/components/Runnable.tsx'; ### 可运行的Chialisp和clvm插件 -有关使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件)。 +有关使用这些插件的信息，请参阅[学院概述](/academy-overview#runnable-chialisp-and-clvm-plugins)。 #### Chialisp 插件 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md index 1aeacb7250b..24cb0162787 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-intro.md @@ -78,7 +78,7 @@ So let's get started, the first thing you'll want to do is make sure you have th ## 常见问题 - **run vs brun:** `run` 用于序列化并运行 Chialisp 谜题，而 `brun` 用于运行 clvm 序列化的谜题，通常用于传递参数。 -- **括号（Parentheses）：**Chialisp 是完全括号前缀表示法编程语言家族的一部分，可以[追溯]()到上世纪 50 年代的 LISP 1。 这些语言的一个显而易见的特点是它们使用括号来表示列表（lists）。 建议在编写这些语言时使用具有适当语法高亮功能的集成开发环境，以确保所有括号都处于正确的位置。 为了帮助解决这个问题，这里有一个适用于 Visual Studio 的 [Chialisp 语言服务器扩展](https://marketplace.visualstudio.com/items?itemName=ChiaNetwork.chialisp)。 +- **括号（Parentheses）：**Chialisp 是完全括号前缀表示法编程语言家族的一部分，可以[追溯](https://en.wikipedia.org/wiki/Lisp_(programming_language))到上世纪 50 年代的 LISP 1。 这些语言的一个显而易见的特点是它们使用括号来表示列表（lists）。 建议在编写这些语言时使用具有适当语法高亮功能的集成开发环境，以确保所有括号都处于正确的位置。 为了帮助解决这个问题，这里有一个适用于 Visual Studio 的 [Chialisp 语言服务器扩展](https://marketplace.visualstudio.com/items?itemName=ChiaNetwork.chialisp)。 - **前缀表示法：**Chialisp 作为 LISP 家族的一部分，使用前缀表示法。 这意味着函数或运算符首先出现，其参数紧随其后。 --- @@ -180,7 +180,7 @@ So let's get started, the first thing you'll want to do is make sure you have th ### 可运行的Chialisp和clvm插件 -有关如何使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件) +有关如何使用这些插件的信息，请参阅[学院概述](/academy-overview#runnable-chialisp-and-clvm-plugins) #### Chialisp 插件 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md index e5e6179f097..f474bec6623 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-signatures.md @@ -142,7 +142,7 @@ import Runnable from '@site/src/components/Runnable.tsx'; ### 可运行的Chialisp和clvm插件 -有关使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件)。 +有关使用这些插件的信息，请参阅[学院概述](/academy-overview#runnable-chialisp-and-clvm-plugins)。 #### Chialisp 插件 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md index 08fc495eb2d..52c5a781b9f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/chialisp/chialisp-smart-coin.md @@ -195,7 +195,7 @@ True ### 可运行的Chialisp和clvm插件 -有关使用这些插件的信息，请参阅[学院概述](/academy-overview#可运行的chialisp和clvm插件)。 +有关使用这些插件的信息，请参阅[学院概述](/academy-overview#runnable-chialisp-and-clvm-plugins)。 #### Chialisp 插件 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/block-creation.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/block-creation.md new file mode 100644 index 00000000000..0ed1ffb3bc8 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/block-creation.md @@ -0,0 +1,105 @@ +--- +title: Block Creation +slug: /chia-blockchain/architecture/mempool/block-creation +--- + +:::info + +Keep in mind that the logic discussed here is only guaranteed to be valid on farms that use the default mempool, as described in the [intro](/chia-blockchain/architecture/mempool/#default-mempool) section. Farmers are allowed to customize, or even remove, their own mempools, so the default logic is not universal. + +::: + +When the farmer makes a block, they will select the highest fee-per-cost transactions from the mempool until they reach the maximum block size. These spend bundles are combined into one large spend bundle, which is guaranteed to be valid, since all spend bundles in the mempool must spend disjointed coins. + +For example, in the coin set model, Coin A can have a rule that says "I can only be spent in the same block as Coin B is spent," but Coin A is not allowed to spend Coin B directly. This property allows for the parallelization of validation and block creation -- as long as a block's input and output amounts match up, and every coin that is spent in the same block follows its own rules, the block will be valid. Because of this, the aggregate spend bundle has a single aggregate signature, which is a combination of every signature from every transaction in that block. + +### Implementation + +This logic is implemented in [chia/full_node/mempool.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool.py) in `create_block_generator2()` + +Creating a block is time sensitive. It already requires disk seeks and compute work to form the proof of space. We want to make sure creating the block generator, with appropriate transactions, takes as little time as possible. + +The algorithm for picking transactions has been designed to have linear complexity (`O(n)`). + +### Picking transactions + +As stated above, the mempool data structure maintains all mempool items ordered by fee per cost, highest fee first. + +This lets the mempool pick transactions one at a time until either the mempool is empty, or the block is full (the cost limit is reached), which therefore will maximize the fee the farmer collects. + +Prior to version 2.5.4, the mempool picked transactions as a separate step from serializing the resulting block generator. This limited the mempool to picking transactions until it estimated to have reached the block cost limit, assuming CLVM compression would not save anything. The problem with this was that if puzzles compressed well, the size cost of the block was overestimated. The final block therefore was not as full as it could have been. This was noted on testnet11 with a full mempool, but some blocks were farmed only 11% full. + +This logic is implemented in [chia/full_node/mempool.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool.py) in `create_block_generator()`. + +Beginning in version 2.5.4 (Q2 2025), the mempool uses a new algorithm (`create_block_generator2()`) which interleaves picking transactions and serializing them (in compressed form). This way, we have a good understanding of the exact cost of the bloc, and can keep filling it with more transactions if the previous ones compressed well. + +Additionally, we use a new algorithm for serialization and compression which has an order of magnitude speedup. Some of this is eaten up more effectively filling blocks, so there’s more to serialize. + +For more info about these changes, see [clvm_rs PR #562](https://github.com/Chia-Network/clvm_rs/pull/562) (the speedup itself) and [chia-blockchain PR #19270](https://github.com/Chia-Network/chia-blockchain/pull/19270) (the mempool block-building algorithm). + +### Fast forward spends + +As we build the block generator, fast forward spends must be chained together. i.e. all but the first spend must be rebased to spend the output singleton of the previous spend. This applies to spends of a standard singleton that satisfies the conditions to be eligible for fast-forward. For more details, see the section on fast forward spends. + +Fast forward was implemented in [chia/full_node/eligible_coin_spends.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/eligible_coin_spends.py) as part of [PR #16919](https://github.com/Chia-Network/chia-blockchain/pull/16919). It was first added to version 2.2.0 in February 2024. + +For more information, see the [fast forward](/chia-blockchain/architecture/mempool/fast-forward) page. + +### Dedup spends + +When we encounter a spend that’s eligible for deduplication, we record the exact solution it’s being spent with. Any subsequent mempool items spending the same coin must also use an identical solution. Otherwise, the mempool item is not considered for inclusion in the block. The dedup spend that has the highest fee-per-cost decides which solution will be used in the block, as it’s deduplicated. Spends eligible for deduplication are allowed to conflict in the mempool. For details, see the section on identical spend deduplication below. + +Implemented in [chia/full_node/eligible_coin_spends.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/eligible_coin_spends.py) + +:::info + +Identical [Spend Deduplication](/chia-blockchain/architecture/mempool/identical-spend-deduplication/) (ISD) is separate from [Replace by Fee](/chia-blockchain/architecture/mempool/replace-by-fee/) (RBF), even though they both replace one spend with another. + +In the case of RBF, a spend bundle is replaced by a different spend bundle with a higher fee. The replacement spend can include additional coin spends, as long as the rules listed in the RBF page are followed. + +In the case of ISD, the spends must be identical. Because of this constraint, the RBF rules do not apply. + +::: + +### Serializing + +Until Q1 2025, serialization of the block generator happened as a separate step. This takes the CLVM tree structure and flattens it into a buffer. This can be expensive because we also deduplicate identical sub-trees (referred to as CLVM compression). The original algorithm could take multiple seconds to serialize a full block, even on fast computers. Since Q1 2025, serialization has been integrated with picking transactions, to make sure we keep adding more until we hit the cost limit in *serialized form*. + +The updated serialization was prepared in [chia-blockchain PR #29207](https://github.com/Chia-Network/chia-blockchain/pull/19207) and completed in [chia-blockchain PR #19270](https://github.com/Chia-Network/chia-blockchain/pull/19270) as part of version 2.5.5. This latter PR introduced `create_block_generator2()` in the `Mempool` class, which picks transactions and serializes/compresses them incrementally. This allows blocks to be filled up to the cost limit, even with compression applied. + +### Compute cost + +Until Q1 2025, after creating the block generator, we would run it, just to measure its cost. We need to specify the cost in the `TransactionsInfo` field. In the new block creation function we predict the exact cost of the block by knowing the cost of the bytes, conditions and executing each puzzle. + +The first hard fork, where we no longer pay for the generator ROM, greatly simplified this task. This fork occurred in version 2.1.0. It activated at block `5'496'000`, as documented in the [forks](/chia-blockchain/consensus/forks/) page. + +Implemented in [chia/simulator/block_tools.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/simulator/block_tools.py) in `compute_block_cost()` + +### Validation + +Implemented in [chia/full_node/full_node.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/full_node.py) in `add_unfinished_block()` + +### Enhanced Block Creation (Chia 2.5.5+) + +Starting in Chia 2.5.5, a new, more efficient block creation algorithm was made available. Starting in 2.6.1 ([PR #20578](https://github.com/Chia-Network/chia-blockchain/pull/20578)), this became the default. This algorithm provides improved performance and better resource utilization during block creation by picking and serializing incrementally in batches. It also handles [Identical Spend Deduplication](/chia-blockchain/architecture/mempool/identical-spend-deduplication/) and [singleton fast-forward](/chia-blockchain/architecture/mempool/fast-forward/) inline. + +**Configuration** (default): Set `full_node:block_creation` to `1` in your config file to enable the new algorithm. + +**Benefits**: + +- Improved block creation performance +- Better memory management during block creation +- Enhanced handling of high-transaction-volume scenarios +- More efficient resource utilization + +**Configurable Timeout**: Block creation now supports a configurable timeout setting (default: [two seconds](https://github.com/Chia-Network/chia-blockchain/blob/0d5a394cf996a49626e009b3f8ac10ed645b74c3/chia/util/initial-config.yaml#L330)) via `full_node:block_creation_timeout`, allowing node operators to fine-tune the process based on their network conditions and requirements. + +**Example Configuration**: + +```yaml +full_node: + block_creation: 1 # Enable new algorithm + block_creation_timeout: 2 # 2 second timeout +``` + +In the legacy mode (`full_node:block_creation: 0`), all transactions are first picked, and then serialized in one shot. Compression savings aren't known during selection, so blocks may be under-filled. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/fast-forward.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/fast-forward.md new file mode 100644 index 00000000000..6a75e765a1c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/fast-forward.md @@ -0,0 +1,159 @@ +--- +title: Fast Forward +slug: /chia-blockchain/architecture/mempool/fast-forward +--- + +Fast-forward spends is a way for a singleton transaction to be applied to future versions of the singleton. This enables offer files to refer to singletons by coin ID, even though the coin ID changes for every singleton spend. + +Spending a coin whose outer puzzle is the `singleton_top_layer_v1_1`, is automatically considered eligible for fast-forward by the mempool, as long as it satisfies certain restrictions: + +- [Immutable puzzle](#immutable-puzzle) +- [Immutable amount](#immutable-amount) (other than the singleton layer) +- [Certain conditions excluded](#conditions) + - [Specific coin ID](#coin-id) + - [Coin announcements](#coin-announcements) + - [AGG*SIG_PARENT*\*](#parent-coin-id) (other than the singleton layer) + - [Relative timelocks](#relative-timelocks) + - [ASSERT*BIRTH*\*](#created-height-and-timestamp) + - [ASSERT_CONCURRENT_SPEND](#concurrent-spends) + - [\*\_MESSAGE](#messages) + - [ASSERT_EPHEMERAL](#ephemeral-spends) + +Singletons are documented in [chialisp.com/singletons](https://chialisp.com/singletons/) + +### Overview + +A spend whose outer puzzle is `singleton_top_layer_v1_1` has a known shape of its solution. With the fast forward feature, the mempool changes the solution to match another coin belonging to the same singleton. + +The singleton puzzle has `SINGLETON_STRUCT` and `INNER_PUZZLE` curried into it. The `SINGLETON_STRUCT` contains `(MOD_HASH . (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH))`. We can use this to uncurry this information from the puzzle reveal. + +The solution passed to the puzzle contains `lineage_proof`, `my_amount` and `inner_solution`. The lineage proof consists of `(parent_parent_coin_info parent_inner_puzzle_hash parent_amount)`. We don’t support fast forward for the eve spend (wherein `parent_inner_puzzle_hash` would be missing), the lineage proof must have this form. + +When changing which coin is being spent, we simply create a new lineage proof using the parent-parent ID and parent amount of the new coin to spend (the inner puzzle remains the same). + +As long as the inner puzzle doesn’t make any commitments to anything related to the coin being spent or its parent, the new solution should be valid. + +The function to parse the puzzle and solution and to generate a new solution can be found in `chia_rs`, in [chia-consensus/src/fast_forward.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/fast_forward.rs). + +Singleton fast forward was introduced in [PR #16919](https://github.com/Chia-Network/chia-blockchain/pull/16919) in January 2024. The first release to include it was 2.2.1. As stated previously, this documentation only covers the reference mempool. Other mempools may choose to omit singleton fast forward as a feature. + +### Use cases + +With a wallet consisting of individual coins locked up with the "standard transaction", it's very straightforward to spend them separately, even as multiple transactions in the same block. However, Chia Vaults use a singleton to "authorize" the spends of coins, which means that every time you spend a coin you also need to spend the associated vault and send a message from the vault to the coin. + +Because you can only spend a coin a single time, you quickly run into issues with that. For example, if you try to make multiple transactions in a block, you'll run into `MEMPOOL_CONFLICT` errors since they both spend the same vault coin. And if you have multiple offers outstanding that spend the vault coin to authorize other spends, one may effectively cancel the other since there would be a `DOUBLE_SPEND` when submitting to the mempool. + +Fast forward is a solution to these issues. The mempool can effectively *rebase* singleton spends on the fly, so if you spend the same vault multiple times it won't be rejected by the mempool (provided the spend itself is eligible for the fast forward rules). + +### Immutable puzzle + +The new singleton coin must have the same puzzle hash as the coin being spent. This restriction makes it (relatively) easy for a mempool to find the most recent coin for a singleton. + +1. Look up all unspent coins with the puzzle hash, whose parent coin have the same puzzle hash +2. If there isn’t exactly 1 coin, the spend is invalid + +This lookup is implemented in [/chia/full_node/coin_store.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/coin_store.py), in `get_unspent_lineage_info_for_puzzle_hash()`. The coin table has an index for puzzle hash which is used to make this lookup fast. + +Alternative ways of finding the unspent coin for a singleton would be to record and maintain a table for all launcher IDs -> Coin. This was deemed unreasonably expensive. But it would likely have offered more flexibility. + +### Immutable amount + +The new singleton coin must have the same amount as the coin being spent. This restriction makes it easy to ensure that fast-forward spends can be chained together without becoming invalid. + +### Conditions + +Some conditions are incompatible with fast-forward. We want to eliminate the risk of fast-forwarding a spend invalidates it. Since these properties can change during fast-forward, the spend will not be considered eligible for fast forward if it emits any of the following conditions. + +#### Coin ID + +When fast forwarding a spend onto the latest coin of a singleton, the Coin ID will change. If an inner puzzle commits to a specific coin ID, it is not eligible for fast-forward. + +Conditions: `AGG_SIG_ME`, `ASSERT_MY_COIN_ID` + +#### Coin Announcements + +Making a coin announcement enables other coins to commit to the coin’s ID. It’s not mandatory, so there may not be a corresponding `ASSERT_COIN_ANNOUNCEMENT`, which would definitely disqualify the spend from being eligible for fast forward. However, postponing the check to only disqualify a spend for fast forward if there is an assertion is a bit more risky, as there are more scenarios to take into account. We can’t think of a use case for this. So, coins issuing coin announcements are not eligible for Fast forward. + +Conditions: `CREATE_COIN_ANNOUNCEMENT` + +#### Parent Coin ID + +Similar to the coin ID itself, the parent coin will change when fast-forwarding a spend onto the latest coin of a singleton. + +Conditions: `AGG_SIG_PARENT`, `AGG_SIG_PARENT_PUZZLE`, `AGG_SIG_PARENT_AMOUNT`, `ASSERT_PARENT_ID` + +#### Relative Timelocks + +When we fast forward the coin, the creation time will also change. If the spend commits to the coin being older than a certain age, it won’t necessarily be valid to move it onto a different coin, which may be younger. We don’t allow relative time locks for this reason. + +Timelocks asserting that the coin is young enough wouldn’t make the spend invalid by moving it up to a newer coin, however, it might be unexpected that it effectively disables the functionality. There’s also an implementation reason to avoid this. We don’t re-compute relative time locks, we assume the coin to spend stays unchanged and resolve the relative time into an absolute one for purposes of knowing when to expire a spend. This feature doesn’t combine well with fast forward. See function `compute_assert_height()` in [/chia/full_node/mempool_manager.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py) + +Conditions: `ASSERT_HEIGHT_RELATIVE`, `ASSERT_SECONDS_RELATIVE`,`ASSERT_BEFORE_HEIGHT_RELATIVE`, `ASSERT_BEFORE_SECONDS_RELATIVE` + +#### Created Height and Timestamp + +When we fast forward the coin, it necessarily changes the birth time for the coin, invalidating any commitment to the coin creation/birth time. + +Conditions: `ASSERT_BIRTH_HEIGHT`, `ASSERT_BIRTH_SECONDS` + +#### Concurrent spends + +If a spend in a SpendBundle asserts that another coin is also being spent in the same block, that’s a commitment to that coin ID. The spend of that coin ID cannot be eligible for fast forward, as it would invalidate the concurrent spend assertion. + +Conditions: `ASSERT_CONCURRENT_SPEND` + +#### Messages + +`SEND_MESSAGE` and `RECEIVE_MESSAGE` committing to one’s own coin ID or parent are also restricted for being considered eligible for fast forward. Both coin ID and parent coin must be allowed to change in a fast-forward spend. + +This is implemented in `MempoolVisitor::condition()`, in [chia-consensus/src/conditions.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/conditions.rs) + +#### Ephemeral Spends + +Any spend asserting its coin to be ephemeral cannot be eligible for fast forward (FF) because FF spends don’t have an order. We order them, arbitrarily, in block generation. This is implemented in the `parse_conditions()` function found in [chia-consensus/src/conditions.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/conditions.rs) + +Additionally, any spend whose output coin is also spent by the same spend bundle should also not be eligible for fast-forward, as it would invalidate the spend bundle. + +Technically, two FF spends could be chained and bundled together. Since both can change the coin they spend, they could still be considered eligible for fast-forward. However, checking this is not trivial, and greater than `O(n)` complexity. To keep the rules simple and efficient, any coin whose output is ephemeral (spent in the same bundle) is not considered eligible for FF. + +This is implemented in `MempoolVisitor::post_process()`, in [chia-consensus/src/conditions.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/conditions.rs) + +Conditions: `ASSERT_EPHEMERAL` + +### Singleton layer is exempt + +The singleton layer itself will commit to both the coin amount and parent ID. The conditions are controlled by the solution. When we fast-forward a spend, we update the solution to reflect the new coin being spent. Therefore, the singleton layer’s own commitments to the parent ID and Amount are valid. + +We know that the singleton top layer puzzle will emit its conditions first in the conditions list, so we simply allow the first condition to be `ASSERT_MY_AMOUNT` and the second condition to be `ASSERT_MY_PARENT_ID`. + +This logic is implemented in [chia-consensus/src/conditions.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/conditions.rs), in `MempoolVisitor`. + +### Mempool validation + +Supporting fast forward is a mempool feature. + +When you submit a transaction into the mempool, eligibility for fast forward is checked according to the above rules. However, there are additional validations the mempool needs to have: + +1. We check that there is an unspent coin with the same puzzle hash, which would represent the latest singleton coin to rebase on top of. If it's missing, the singleton may have been spent in a non-fast forward fashion, or never existed in the first place. +2. We ensure that the parent of the latest unspent coin also has the same puzzle hash and amount, because anyone can create a coin with the singleton's puzzle even if it doesn't have the correct lineage. The parent being spent implies that the lineage has already been validated. +3. A spend bundle submitted to the mempool is not allowed to entirely consist of spends that are eligible for fast forward. The other coin is the primary way to evict the fast forward spend bundle from the mempool. A spend bundle with only fast-forward spends might never become invalid, and be spent in every block. In fact, nothing would prevent it from being spent multiple times per block. + +(1) and (2) are implemented in [chia/full_node/coin_store.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/coin_store.py), `get_unspent_lineage_info_for_puzzle_hash()`. + +(3) is implemented in [chia/full_node/mempool_manager.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py), `validate_spend_bundle()`. + +Since a spend’s eligibility for fast forward can be affected by another spend committing to its coin ID (e.g. via `ASSERT_CONCURRENT_SPEND`) an attacker may attempt to replace a Vault spend (or some other spend relying on supporting fast forward) with a super set that also includes a commitment to its coins ID, effectively disabling its fast forward support. + +To prevent this attack, the mempool’s super set rule must also reject replacements that alter the `ELIGIBLE_FOR_FF` flag of a spend. + +This is implemented in [chia/full_node/mempool_manager.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py), `can_replace()`. + +### Replays + +Transactions that support fast-forward can’t use `AGG_SIG_ME`, so we need some other mechanism to prevent the spend to be replayed in the future. + +For example, when you spend a vault singleton that is eligible for fast forward, you send messages from the vault and receive it from the coins you are spending. This 1:1 relationship between sent and received messages prevents the spend from being replayed, since the other asset coins can only be spent a single time. Using regular announcements wouldn't protect against replays in the same way. + +### Replacement + +A coin spend that supports fast forward is not considered in conflict with an existing spend of the same coin that also supports fast forward. If the existing spend and the new spend differ in support for fast-forward, replacement will not be allowed according to the fast-forward rule. See the section on replacement rules. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/fees.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/fees.md new file mode 100644 index 00000000000..e9e638061ca --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/fees.md @@ -0,0 +1,79 @@ +--- +title: Fees Required for Inclusion +slug: /chia-blockchain/architecture/mempool/fees +--- + +When you submit a transaction, one of several possible scenarios will play out, depending on how full the mempool is, how large of a fee was included, the CLVM cost of the transaction, and other factors. Keep in mind that each farmer has its own copy of the mempool, with its own set of rules. The default mempool behavior discussed in this section will apply to most, but not all, nodes. It is up to each individual farmer to decide which transactions to include upon creating a block. + +To view the current status of the mempool, see the dashboard for [mainnet](https://dashboard.chia.net/d/46EAA05E/mempool-transactions-and-fees?orgId=1&var-network=mainnet) and [testnet11](https://dashboard.chia.net/d/46EAA05E/mempool-transactions-and-fees?orgId=1&var-network=testnet11). + +:::info + +- By default, the total size of the mempool is 10 blocks. This true for both [mainnet](https://github.com/Chia-Network/chia-blockchain/blob/99d4993306b2d46dfe6e025b0536fec784ede5ce/chia/consensus/default_constants.py#L63) and [testnet11](https://github.com/Chia-Network/chia-blockchain/blob/99d4993306b2d46dfe6e025b0536fec784ede5ce/chia/util/initial-config.yaml#L35). +- Prior to version 2.2, the block size was artificially capped at 50% of its capacity. +- Starting in version 2.2, the block size cap was increased to 60%. +- Starting in version 2.3, the block size cap was increased to 70%. +- In version 2.5, the artificial cap was [lifted entirely](https://github.com/Chia-Network/chia-blockchain/pull/19005). The limit is now 11 billion cost, which is enforced by the consensus rules. +- The size (in CLVM cost) of the mempool is `mempool blocks * max cost per block * block size limit`. + - There is no longer a block size limit, so for versions 2.5 and newer, this amounts to `10 * 11 billion = 110 billion`. + +::: + +### Scenario 1: Mempool Not Busy + +If the transaction you just submitted -- plus the entire contents of the mempool -- can fit into one block, then your transaction will be added to the next block. This is true even if you don't include a transaction fee. This is true even if you don't include a transaction fee. + +:::info + +The mempool currently doesn't currently use compression. This calculation could change when/if compression is taken into account. + +::: + +The reason for this is straightforward -- the farmer has nothing to gain by excluding certain transactions, so it will include everything. Note that some proprietary software takes the opposite approach: the farmer will *only* include transactions that pay a fee, regardless of mempool size. + +The mempool for Chia's mainnet is often in this state. This does not mean that no transactions are being submitted. It simply means that the network's speed of around 20 transactions per second is sufficient to keep up with demand. + +### Scenario 2: Mempool Busy But Not Full + +If the mempool's contents will occupy more than one block, but the mempool is not full, then it is considered *busy*. In this case: + +- Transactions that don't include fees will be added to the mempool, but they won't make it into the next block. Instead, they will have to "wait in line" for higher-priority transactions to be cleared. They likely will eventually be included in a block, but this is not guaranteed. Instead, they will have to "wait in line" for higher-priority transactions to be cleared. They likely will eventually be included in a block, but this is not guaranteed. +- Transactions with fees will be added to the mempool and prioritized according to the size of their fee-per-cost. Transactions with fees will be added to the mempool and prioritized according to the size of their fee-per-cost. For example, a transaction with a 1-mojo fee will enter the queue ahead of zero-fee transactions. (As stated previously, this is the default behavior. Some custom mempools require a larger fee for inclusion in this scenario.) + +:::info Testnet11 info + +Testnet11 is often being "dusted" (thousands of small transactions are being included) in order to simulate a busy network, which can be useful for testing. The dust transactions do not include any fees, so in order for your transaction to be prioritized ahead of the dust, you simply have to include a 1-mojo fee. In this case, your transaction will likely be included in the next transaction block. However, if you don't include a fee, it will likely need to wait ~40-60 minutes before being included. + +::: + +### Scenario 3: Mempool Full + +If the mempool is completely full, then in order for your transaction to be added, it will need to kick out one or more transactions. In this scenario: In this scenario: + +- Transactions with no fee will not be added to the mempool. +- Transactions with a fee of less than five mojos per cost (~100 million mojos for 2-input, 2-output transactions) will be treated as zero-fee transactions, i.e. they will not be added to the mempool. +- Transactions with a fee of at least five mojos per cost will be added to the mempool, prioritized by fee-per-cost, *if* they are not the lowest priority transactions (see Scenario 4 in this case). For info on specific transaction types, see the [costs](/chia-blockchain/coin-set-model/costs/#estimated-transaction-costs) page. + +This scenario often occurs on testnet11. This scenario often occurs on testnet10. When the mempool is completely full, the dusters stop submitting transactions until some of the dust has been cleared. This scenario might occasionally happen on mainnet as well, in which case a minimum fee would be required. This scenario might occasionally happen on mainnet as well, in which case a minimum fee would be required. + +If you see `INVALID_FEE_TOO_CLOSE_TO_ZERO` in your log file, the mempool was likely full when you submitted your transaction, and you did not include a sufficient fee to kick out an existing transaction. Try resubmitting your transaction with a higher fee. + +### Scenario 4: Mempool Full of Transactions with Fees + +This is the final scenario, where not only is the mempool completely full, but every transaction in the mempool has a fee of at least five mojos per cost. In order for your transaction to be added to the mempool, it will need to kick out one or more transactions. In this scenario: + +- Transactions with no fee will not be added to the mempool. +- Transactions with a fee of less than five mojos per cost (~100 million mojos for 2-input, 2-output transactions) will be treated as zero-fee transactions, i.e. they will not be added to the mempool. +- Transactions with a fee of at least five mojos per cost *might* be added to mempool. For this to happen, they will need to kick out one or more transactions with a lower fee-per-cost ratio. For example: + - If the "cheapest" transaction currently in the mempool has a fee per cost of 10, and your transaction's fee per cost is 9, then your transaction will not be added to the mempool. + - If the "cheapest" transaction is 10, and yours is 15, then it likely will be added. However, even in this case, there are scenarios where your transaction might not be added, such as when the lowest-cost transaction currently in the mempool is quite large. + +If the mempool from Chia's mainnet reaches this state, the competition for block space will be strong. In order for your transaction to be included, the minimum fee might be significantly higher than it would be in the other scenarios. + +### Fast Forward Processing + +Starting in Chia 2.5.5, certain transaction types support fast-forward processing, allowing them to be included in blocks more efficiently when specific conditions are met. For more info, see the page dedicated to [fast forward](/chia-blockchain/architecture/mempool/fast-forward/). + +**Singleton Fast Forward**: Singleton transactions now support optimized processing, improving block inclusion rates and handling of high-frequency operations. + +**Vault Fast Forward**: Vault transactions support enhanced processing with optimized validation and faster state transitions, improving overall mempool throughput for vault operations. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/intro.md new file mode 100644 index 00000000000..1a153d85e40 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/intro.md @@ -0,0 +1,32 @@ +--- +title: Intro +slug: /chia-blockchain/architecture/mempool/ +--- + +The mempool (a portmanteau of "memory pool") is a collection of transactions stored by full nodes, usually in memory, before they are confirmed on the blockchain. + +:::info + +### Default Mempool + +The mempool is not dictated by the consensus rules; a farmer can change how their personal mempool functions and customize the rules without obtaining any permissions. Farmers can even decline to use a mempool altogether. + +However, the majority of farmers opt to use the default mempool, which ships with the default farming software. The documentation in the following pages therefore only pertains to this version. + +While you may be tempted to simplify your mental model of the mempool by thinking of the *default* as the *only* version, do keep in mind that some farmers will, in fact, use a customized version that doesn't follow all of (or any of) the logic discussed here. + +::: + +The mempool is a recommended facet of Chia due to the decentralized nature of the blockchain. Transaction blocks occur approximately every 52 seconds, and it's impossible to predict who will win a block. Therefore, all transactions must be broadcast to the whole network and stored locally until they are confirmed. Additionally, it is normal to have more pending transactions than can fit in a single block, so the mempool also acts as a queue for inclusion into the blockchain. + +For more information about the mempool, see our [blog post](https://www.chia.net/2024/01/12/getting-to-know-the-mempool-and-transaction-fees/) on this subject. + +:::info +How many transactions can fit into a block? Due to the varying size of transactions, and the different definitions of what even counts as a "transaction," there is not an exact number. But just for a bit of rough guidance, approximately 1000 transactions with two inputs and two outputs, or 2000 transactions with one input and one output can fit into a single block. +::: + +When a user makes a transaction, it gets sent to a full node, which then verifies it, adds it to the mempool, and broadcasts it to all of its peers. Therefore, transactions get propagated to the whole network in a very short period of time. + +### Updates + +After a new block is added to the blockchain, all full nodes must look at the coins that were spent in that new block, and remove them from the mempool. The full node does not need to reapply every transaction again, since Chia coin spends are deterministic and sandboxed (see the [Coin Set Intro page](/chia-blockchain/coin-set-model/intro) for more information). The full node only needs to look at the spent coins in the new block, and if there are any transactions that spend one of those coins, they are removed from the mempool. This means the mempool can be very large, the codebase can be simple, and high performance can be achieved. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/isd.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/isd.md new file mode 100644 index 00000000000..f67d77edbdf --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/isd.md @@ -0,0 +1,81 @@ +--- +title: Identical Spend Deduplication +slug: /chia-blockchain/architecture/mempool/identical-spend-deduplication +--- + +Only valid transactions are allowed to enter the mempool. The process of validating transactions is similar to the process of validating blocks. This includes running CLVM, checking conditions, validating signatures, and checking that the coins to be spent are currently unspent and valid. + +The transaction is also checked against other transactions in the mempool, to ensure there are no conflicts. + +### Transaction Deduplication + +Beginning in Chia 1.8.2, and upgraded in 2.5.5, the mempool automatically detects and deduplicates identical spend transactions. When multiple transactions attempt to spend the same coin with identical parameters, only one will be kept in the mempool, reducing memory usage and improving overall performance. + +**Behavior**: + +- Identical spend transactions are automatically deduplicated +- The transaction with the highest fee is prioritized +- Duplicate transactions are rejected with appropriate error messages + +### Use cases + +If you have a singleton that represents an oracle, you would need to be able to rely on an announcement created by spending it. You could in theory use replace by fee to do so, but this doesn't scale well when many people spend the oracle simultaneously. Fast forward is an approach that could work as well, although this creates many spends and takes up space in blocks unnecessarily. With spend deduplication, you can provide the same exact coin spend and they will all be deduplicated when creating the block, while still fulfilling the announcements the other transactions relied upon. + +### Constraints + +#### Identical solution + +Spends are only deduplicated if they have identical puzzles and identical solutions. Technically, it would be possible to deduplicate a puzzle with `any` solution that produces the same conditions as another one. However, running the puzzle and comparing conditions with a different spend is not cheap. It’s much simpler to just compare the bytes of the serialized solution. If they match, it’s safe to dedup, otherwise, we don’t assume it’s possible. + +#### Transferring amount + +One way to trick a farmer into including lower fee spends could be to include a spend, that’s eligible for deduplication, that pays a large fee. Any spend bundle including that spend would have a higher fee-per-cost and get preferential treatment. However, once the block is created, the dedup coin is only spent `once`. The effective fee paid by these transactions could be materially lower than the mempool expected. + +Similarly, if a coin eligible for deduplication has a net out-flow of coin amount, it could be transferred to a new coin. But once collapsed into a single spend, the block would be invalid, failing with `MINTING_COIN`. + +To mitigate this risk, a CoinSpend whose output coins have a lower total amount than the coin it’s spending, is not eligible for deduplication. + +A spend that creates more coin amount than its input coin is fine, this has to be made up for by other coins in the spend bundle, and once collapsed, the farmer will take the left-over amounts as fees. + +This is implemented in the `MempoolVisitor::post_spend()` function, in [chia-consensus/src/conditions.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/conditions.rs) + +#### RESERVE_FEE + +Even though the dedup coin is not allowed to pay any fee (or pay for anything really), it `is` allowed to issue RESERVE_FEE conditions. Each spend bundle including the dedup coin will have to pay such a fee, and once the block is created, the farmer will take the fee, even though it’s not all reserved with the condition. + +#### Fee-per-cost + +For purposes of computing the fee-per-cost of a spend bundle, we don’t take into account whether a spend may be deduplicated. The transaction is still treated as if it would incur the full cost on the final block, if included. This is a conservative assumption that benefits the farmer, but maintains the simple rule of ordering transactions by fee-per-cost, and no other consideration. +It would be possible to let the dedup coin also pay the fee, but it would be more complicated for the mempool to keep track of it. Since the dedup coin will only be included once per block, the actual fee received by the farmer would vary depending on the number of times the spend is deduplicated (and you don't know in which order transactions will be included in a block beforehand). Every time, the effective fee-per-cost decreases. This would make it more complicated than to just order mempool items along a single dimension. + +### Conditions + +Coin spends issuing the following conditions are not eligible for deduplication. The constraints on conditions are implemented in `MempoolVisitor::condition()` in [chia-consensus/src/conditions.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/conditions.rs) + +#### AggSigs + +All agg sig conditions require the appropriate signature to be aggregated into the block signature, the correct number of times. Deduplicating a spend that includes a signature would likely be impossible to deduplicate from the aggregate signature (only if the spend bundle did not have any other `AGG_SIG_*` conditions). Since the signature can’t be deduplicated, neither can the spend issuing them. + +Conditions: `AGG_SIG_ME`, `AGG_SIG_PARENT`, `AGG_SIG_PARENT_AMOUNT`, `AGG_SIG_PARENT_PUZZLE`, `AGG_SIG_PUZZLE`, `AGG_SIG_AMOUNT`, `AGG_SIG_PUZZLE_AMOUNT`, `AGG_SIG_UNSAFE` + +#### Messages + +All sent messages must be received exactly once, and every received message must be sent exactly once. Because of this, sending or receiving a message cannot be deduplicated. We would end up missing a sent or received message. In theory, it would be possible for two spends that both are eligible for deduplication to send messages between each other, but this check would be more complex and expensive to perform. For now we just disallow any message sent or received from deduplication. + +Conditions: `SEND_MESSAGE`, `RECEIVE_MESSAGE` + +### Replacement + +A spend that supports dedup is not considered in conflict with an existing spend of the same coin that also supports dedup. The new spend must also use the exact same solution as the existing spend. The mempool implementation checks that the solution `bytes` are identical. + +### Security considerations + +Since the mempool “locks in” the solution for a dedup-spend based on whichever is submitted first, authors of oracles (or other puzzles that intend to make use of dedup) should ensure that only a single solution is valid at a time. + +#### Canonical serialization + +Solutions are compared byte-for-byte in serialized form, so the serialized form must be canonical. CLVM serialization, much like UTF-8, uses a variable-length length-prefix when encoding atoms. This lets you encode small values very space-efficiently. However, it also means you can choose to encode a small atom with a length-prefix that’s longer than necessary. This could be way for an attacker to encode the exact same CLVM tree solution in a slightly different byte form, thus subverting the identical-solution check in the mempool. + +Canonical form means that all atoms use the shortest possible length-prefix encoding. + +If a spend supports dedup, its solution must be encoded in canonical form, and may not include back-references (which would be another way to encode identical CLVM trees with different bytes). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/migration.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/migration.md new file mode 100644 index 00000000000..8f6eb0ce8d1 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/migration.md @@ -0,0 +1,37 @@ +--- +title: Migration +slug: /chia-blockchain/architecture/mempool/migration +--- + +## Schema Changes and Migration (Chia 2.5.5+) + +Starting in Chia 2.5.5, the mempool has undergone backwards incompatible schema changes to support the new fast-forward functionality and optimizations. + +### Backwards Incompatible Changes + +**Available in**: Chia 2.5.5 and later versions + +The mempool schema has been updated to support: + +- **Fast-forward processing** for singleton and vault transactions +- **Enhanced transaction deduplication** mechanisms +- **Improved memory management** and performance optimizations + +### Migration Notes + +**Important**: These changes are backwards incompatible. Nodes running versions prior to 2.5.5 may experience issues when connecting to nodes running 2.5.5+. + +**Required Actions**: + +- **Upgrade all nodes** to Chia 2.5.5+ simultaneously +- **Clear mempool data** if upgrading from versions prior to 2.5.5, this will occur automatically after restarting services +- **Restart services** after upgrade to ensure new schema is applied + +**Downgrade Instructions**: +If you need to downgrade from Chia 2.5.5+ back to an earlier version, you must first fix the database schema incompatibility. See the [Database Schema Compatibility Issues section](/reference-client/troubleshooting/node-syncing#database-schema-compatibility-issues) for the required database fix command and detailed instructions. + +**Impact**: + +- Existing mempool data may not be compatible with new schema +- Transaction processing behavior has changed (see optimizations above) +- Performance improvements require full network adoption diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/rbf.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/rbf.md new file mode 100644 index 00000000000..975fc42bf6c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/rbf.md @@ -0,0 +1,37 @@ +--- +title: Replace by Fee +slug: /chia-blockchain/architecture/mempool/replace-by-fee +--- + +A transaction can replace another transaction in the mempool if it spends at least the same coins as the original one. + +For example, if the original transaction spent coins A and B, then another transaction that spends A, B, and C can replace it. However, a transaction that spends B and C cannot. This prevents denial-of-service (DOS) attacks, as well as censorship of transactions. There is also a minimum fee bump which might depend on mempool software being used. In `chia-blockchain`, this is set to 5 fee-per-cost. This prevents spam replacement transactions. + +The full conditions for replace by fee are: + +1. The new spend bundle needs to include at least all the spends in the original one (the super set rule) +2. The new spend bundle needs to pay a higher fee per cost than the original one (and higher than the [minimum fee required for inclusion](/chia-blockchain/architecture/mempool/fees/) + /chia-blockchain/architecture/mempool/#fee-required-for-inclusion +3. The new spend bundle needs to pay at least 10000000 mojos more in fees than the original one +4. If there were any time-locks associated with the original spend, the new spend bundle has to have the same time lock (the time lock rule) +5. The new spend bundle must not change any of the existing spend’s eligibility for fast forward or dedup (the fast forward rule) + +Spends eligible for Dedup and Fast-forward are not considered conflicts, and are not treated as being replaced and subject to the above restrictions. Conflicts in such spends are deferred to block creation. + +Implemented in [chia/full_node/mempool_manager.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py) in `can_replace()` + +### Super set rule + +The super set rule is important to mitigate an attack where a user issues spend A, an attacker replaces it with AB, with a higher fee. The attacker then replaces it with B, effectively evicting transaction A. + +### Time lock rule + +The time lock rule is important to mitigate an attack where a user issues spend A, an attacker replaces it with AB, where B has a very short expiration time. If B is evicted, it will take A with it, effectively evicting transaction A. + +Time locks that start out invalid and become valid (and stay valid) are simple to check. We just ensure they are valid at the time we receive them, before adding them to the mempool. Both time and seconds are checked before adding a mempool item. If we’re replacing a transaction with another, both have already been validated with regards to valid-after conditions. + +The time lock rule does not look at `ASSERT_SECONDS_*`. + +### Fast forward rule + +The fast forward rule mitigates an attack where a user issues a fast-forward spend A, an attacker replaces it with AB which causes A to no longer support fast forward. For example, spending the output of A will prevent it from supporting fast forward. This is likely to cause A to fail to spend its singleton, effectively evicting it. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/time-locks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/time-locks.md new file mode 100644 index 00000000000..3a5d88d5510 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool/time-locks.md @@ -0,0 +1,54 @@ +--- +title: Time Locks +slug: /chia-blockchain/architecture/mempool/time-locks +--- + +MempoolItems may issue time lock conditions. That’s any of: + +- [ASSERT_HEIGHT_ABSOLUTE](https://chialisp.com/conditions/#assert-height-absolute) +- [ASSERT_HEIGHT_RELATIVE](https://chialisp.com/conditions/#assert-height-relative) +- [ASSERT_SECONDS_ABSOLUTE](https://chialisp.com/conditions/#assert-seconds-absolute) +- [ASSERT_SECONDS_RELATIVE](https://chialisp.com/conditions/#assert-seconds-relative) +- [ASSERT_BEFORE_HEIGHT_ABSOLUTE](https://chialisp.com/conditions/#assert-before-height-absolute) +- [ASSERT_BEFORE_HEIGHT_RELATIVE](https://chialisp.com/conditions/#assert-before-height-relative) +- [ASSERT_BEFORE_SECONDS_ABSOLUTE](https://chialisp.com/conditions/#assert-before-seconds-absolute) +- [ASSERT_BEFORE_SECONDS_RELATIVE](https://chialisp.com/conditions/#assert-before-seconds-relative) +- [ASSERT_MY_BIRTH_HEIGHT](https://chialisp.com/conditions/#assert-my-birth-height) +- [ASSERT_MY_BIRTH_SECONDS](https://chialisp.com/conditions/#assert-my-birth-seconds) + +Relative timestamps and heights are relative to the creation of the coin being spent. All relative time locks are resolved to absolute ones and then checked. + +### Valid After + +Conditions checking that the time is *later* than some specified time are compared against the timestamp and height of the previous transaction block and potentially rejected immediately. Except `ASSERT_HEIGHT_*`, we have a pending cache where we store transactions that are about to become valid soon. + +Implemented in `check_time_locks()` imported from `chia_rs` (Rust). Called from `mempool_manager.py`: + +- Rust: [crates/chia-consensus/src/check_time_locks.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/check_time_locks.rs) +- Python: [chia/full_node/mempool_manager.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py) + +### Valid Before + +Conditions checking that the time is *before* some specified time need to be added to their own index, to cheaply evict them if they expire before being included in a block. + +Transactions that expire need some special treatment. Consider the entire mempool being filled with transactions that all expire at the same time. As that expiration time approaches, we don’t want to add more transactions that also expire around the same time, because we won’t necessarily be able to fit them all in a block before they expire. Thus, wasting space in the mempool, pushing out other transactions. + +When adding a block that will expire within 900 seconds (15 minutes) or 48 blocks, we make it compete against all other transactions that also expire within this time-window. If there are more than 1 block worth of transaction cost, we evict the lowest fee-per-cost transactions. If the new transaction has a high enough fee-per-cost (or there are few enough transactions that expire within this window) it will be added to the mempool. + +Implemented in [chia/full_node/mempool.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool.py), `add_to_pool()` + +### Pending Cache + +Mempool items with `ASSERT_HEGHT_ABSOLUTE` or `ASSERT_HEIGHT_RELATIVE` conditions that are not yet valid are added to the pending cache. Every time there’s a new peak, mempool items that now satisfy their time lock are popped from the cache (`drain()`) and attempted to be inserted into the regular mempool. + +When the cache is full, items whose valid height is the farthest into the future are evicted first. + +Having a pending cache allows wallets to propagate transactions slightly ahead of time, to get them included as soon as they become valid. + +Implemented in [chia/full_node/pending_tx_cache.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/pending_tx_cache.py) + +### Conflict Cache + +New transactions that fail to be added to the mempool because of a conflict may be stored in the conflict cache. Every time we receive a new block, transactions in the conflict cache are re-tried. The conflict cache has a limited size and will evict the oldest transactions first. + +Implemented in [chia/full_node/pending_tx_cache.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/pending_tx_cache.py) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/clvm-vs-evm.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/clvm-vs-evm.md index 172b19f1e45..1799534a3d9 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/clvm-vs-evm.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/clvm-vs-evm.md @@ -12,17 +12,17 @@ We'll start with a brief description of CLVM. For details on the inner workings ## Comparison -| Design decision | EVM (Solidity) | CLVM (Chialisp) | -| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| The blockchain contains... | Smart contracts (compiled programs) as well as accounts. | The root hash of a binary tree, not source code. | -| Money | Smart contracts _contain_ money. | Standard Chia coins don't _contain_ money. They _are_ money. That said, more complex functionality is possible, allowing coins to contain state, such as money. | -| Determinism | Less deterministic because multiple people can execute code within the same contract. Depending on the order of execution, the result won't always be the same. | More deterministic because coins can only be spent once. However, it's possible to have a coin that multiple people can spend, which would reduce determinism. | -| Centralization | Multiple people interact with the same contract. Centralized by design. | Only the owner interacts with a smart coin. Decentralized by design. | -| Sandboxing | No sandboxing. If a contract is hacked, all users can lose their money. | Strong sandboxing. Spending is the only action allowed on an unspent coin, and only by the owner(s). If a coin is hacked, only that coin's owner(s) lose(s) their money. | -| Composability | Composition is supported, so it is possible to set rules temporarily governing how money may be spent. However, if money is moved outside of the contract, it will follow different rules.

(Note that it is possible to create a contract that “traps” ETH inside of it by only allowing money to be sent from the contract to specific types of addresses. However, by definition this limits the functionality of that money to whatever is contained within the contract.) | Composition is handled through inner puzzles. A puzzle's creator could say, “As long as these rules are followed, an inner puzzle can add any functionality.” Thus, it is possible to set rules that are intrinsic to the money itself, which must be followed _forever_. | -| MEV | Changing transaction order is both profitable and common. MEV is high. | Transactions all occur simultaneously in a block. MEV is low. | -| Reentrancy | Contracts can call functions on other contracts. Withdrawals can happen multiple times. Reentrancy is possible and must be carefully guarded against. | Coins interact with each other through announcements. They cannot call functions on other coins. Spends are atomic. Reentrancy is not possible. | -| Auditability/Security | Weak. Multiple points of failure. Numerous hacks prove this. | Strong. If an attacker changes a coin's puzzle, the hash also changes. The attacker is thus attempting to spend a coin that does not exist. The attacker can modify the solution, but the programmer can counter this by using assertions, which will make any such modifications fail. | +| Design decision | EVM (Solidity) | CLVM (Chialisp) | +| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| The blockchain contains... | Smart contracts (compiled programs) as well as accounts. | The root hash of a binary tree, not source code. | +| Money | Smart contracts _contain_ money. | Standard Chia coins don't _contain_ money. They _are_ money. That said, more complex functionality is possible, allowing coins to contain state, such as money. | +| Determinism | Less deterministic because multiple people can execute code within the same contract. Depending on the order of execution, the result won't always be the same. | More deterministic because coins can only be spent once. However, it's possible to have a coin that multiple people can spend, which would reduce determinism. | +| Centralization | Multiple people interact with the same contract. Centralized by design. | Only the owner interacts with a smart coin. Decentralized by design. | +| Sandboxing | No sandboxing. If a contract is hacked, all users can lose their money. | Strong sandboxing. Spending is the only action allowed on an unspent coin, and only by the owner(s). If a coin is hacked, only that coin's owner(s) lose(s) their money. | +| Composability | Composition is supported, so it is possible to set rules temporarily governing how money may be spent. However, if money is moved outside of the contract, it will follow different rules.

(Note that it is possible to create a contract that “traps” ETH inside of it by only allowing money to be sent from the contract to specific types of addresses. However, by definition this limits the functionality of that money to whatever is contained within the contract.) | Composition is handled through inner puzzles. A puzzle's creator could say, “As long as these rules are followed, an inner puzzle can add any functionality.” Thus, it is possible to set rules that are intrinsic to the money itself, which must be followed _forever_. | +| MEV | Changing transaction order is both profitable and common. MEV is high. | Transactions all occur simultaneously in a block. MEV is low. | +| Reentrancy | Contracts can call functions on other contracts. Withdrawals can happen multiple times. Reentrancy is possible and must be carefully guarded against. | Coins interact with each other through announcements. They cannot call functions on other coins. Spends are atomic. Reentrancy is not possible. | +| Auditability/Security | Weak. Multiple points of failure. Numerous hacks prove this. | Strong. If an attacker changes a coin's puzzle, the hash also changes. The attacker is thus attempting to spend a coin that does not exist. The attacker can modify the solution, but the programmer can counter this by using assertions, which will make any such modifications fail. | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-account.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-account.md index 66c4f348d9f..48de4377906 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-account.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-account.md @@ -25,12 +25,12 @@ A typical Chia transaction would look like the following: Alice wants to send 1 XCH to Bob. Alice has five coins in her wallet: four worth 0.2 XCH apiece, and one worth 0.7 XCH. Her wallet automatically selects two of the coins worth 0.2 XCH and the 0.7 XCH coin to be spent. All three coin spends happen simultaneously, along with two new coin creations: one worth 1 XCH which goes to Bob's wallet, and one worth 0.1 XCH which goes to Alice's wallet as "change." Alice now has two coins worth 0.2 XCH and one worth 0.1 XCH. Bob has one coin worth 1 XCH. The total value owned by Alice and Bob has not changed -- it was 1.5 XCH both before and after the transaction was processed. -| Owner | Before | After | -| ----- | ----------------- | ---------------- | +| Owner | Before | After | +| ----- | ---------------------------------------------------- | --------------------------------------------------- | | Alice | 1.5 XCH (5 coins) | 0.5 XCH (3 coin) | -| Bob | 0 XCH | 1.0 XCH (1 coin) | -| | | | -| Total | 1.5 XCH | 1.5 XCH | +| Bob | 0 XCH | 1.0 XCH (1 coin) | +| | | | +| Total | 1.5 XCH | 1.5 XCH | ## Advantages of the account model diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/costs.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/costs.md index 62a509abff6..38fa0456ff0 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/costs.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/costs.md @@ -69,10 +69,8 @@ Now that we've established that a Raspberry Pi 4 can, indeed, sync and farm, eve There are three categories that go into determining a block's maximum cost: 1. Generator program cost, which is split into two parts - -- Execution cost -- Signature validation cost - + - Execution cost + - Signature validation cost 2. Generator program size (each byte has a cost) 3. Generator program coins (each new coin has a cost) @@ -145,31 +143,31 @@ Even this number is not realistic because it assumes that a single program will The below chart contains costs for various transactions on the blockchain, each of these assumes the inputs and outputs have been optimized and represent a best case scenario. :::note -The [minimum effective](/chia-blockchain/architecture/mempool/fees) fee represents 5 x the clvm cost and is the minimum fee recognized by the default consensus rules (any fee less would be the same as 1 mojo). +The [minimum effective](/chia-blockchain/architecture/mempool/fees/) fee represents 5 x the clvm cost and is the minimum fee recognized by the default consensus rules (any fee less would be the same as 1 mojo). This means one needs to use at least the fees listed below during moderate fee pressure but greater fees might be needed for time sensitive transactions to process in a timely manner. Please note that the costs and fees listed are for vanilla versions of these transactions, they can vary based on the number of input and output coins needed so consider these the bare minimum. Transactions with a '\*' are listed with a fee of 3 x the minimum effective fee. This is to ensure the fees are more realistic for how coins are distributed in users wallets but note that vanilla versions of these would be 1/3 that which is listed. ::: -| Transaction Type | clvm Cost | Minimum Effective Fee | -| ----------------------------------------- | ------------- | --------------------------------- | -| **Full Block (with 50% cap)** | 5,500,000,000 | 27,500,000,000 mojo (0.0275 xch) | -| **Standard Transaction** | 6,000,000 | 90,000,000 mojo (0.00009 xch) \* | -| **PlotNFT Creation** | 18,000,000 | 90,000,000 mojo (0.00009 xch) | -| **Minting NFT with DID** | 123,000,000 | 615,000,000 mojo (0.000615 xch) | -| **Minting NFT without DID** | 53,000,000 | 265,000,000 mojo (0.000265 xch) | -| **Adding URI to NFT with DID** | 71,000,000 | 355,000,000 mojo (0.000355 xch) | -| **Adding URI to NFT without DID** | 41,000,000 | 205,000,000 mojo (0.000205 xch) | -| **Transfer NFT with DID** | 67,000,000 | 335,000,000 mojo (0.000335 xch) | -| **Assign DID to NFT** | 107,000,000 | 535,000,000 mojo (0.000535 xch) | -| **Send Clawback Transaction** | 10,000,000 | 150,000,000 mojo (0.00015 xch) \* | -| **Claim Clawback Transaction** | 1,400,000 | 7,000,000 mojo (.000007 xch) | -| **Clawback Clawback Transaction** | 15,600,000 | 75,800,000 mojo (.0000758 xch) | -| **Combine 500 Farming Rewards** | 3,100,000,000 | 15,500,000,000 mojo (.0155 xch) | -| **Split 1 Coin into 2** | 11,000,000 | 55,000,000 mojo (.000055 xch) | -| **Send 1 CAT** | 37,000,000 | 555,000,000 mojo (.000555 xch) \* | -| **Offer 1 CAT coin for 1 CAT coin + fee** | 135,000,000 | 675,000,000 mojo (.000675 xch) | +| Transaction Type | clvm Cost | Minimum Effective Fee | +| ------------------------------------------------ | ------------- | -------------------------------------------------------------------- | +| **Full Block (with 50% cap)** | 5,500,000,000 | 27,500,000,000 mojo (0.0275 xch) | +| **Standard Transaction** | 6,000,000 | 90,000,000 mojo (0.00009 xch) \* | +| **PlotNFT Creation** | 18,000,000 | 90,000,000 mojo (0.00009 xch) | +| **Minting NFT with DID** | 123,000,000 | 615,000,000 mojo (0.000615 xch) | +| **Minting NFT without DID** | 53,000,000 | 265,000,000 mojo (0.000265 xch) | +| **Adding URI to NFT with DID** | 71,000,000 | 355,000,000 mojo (0.000355 xch) | +| **Adding URI to NFT without DID** | 41,000,000 | 205,000,000 mojo (0.000205 xch) | +| **Transfer NFT with DID** | 67,000,000 | 335,000,000 mojo (0.000335 xch) | +| **Assign DID to NFT** | 107,000,000 | 535,000,000 mojo (0.000535 xch) | +| **Send Clawback Transaction** | 10,000,000 | 150,000,000 mojo (0.00015 xch) \* | +| **Claim Clawback Transaction** | 1,400,000 | 7,000,000 mojo (.000007 xch) | +| **Clawback Clawback Transaction** | 15,600,000 | 75,800,000 mojo (.0000758 xch) | +| **Combine 500 Farming Rewards** | 3,100,000,000 | 15,500,000,000 mojo (.0155 xch) | +| **Split 1 Coin into 2** | 11,000,000 | 55,000,000 mojo (.000055 xch) | +| **Send 1 CAT** | 37,000,000 | 555,000,000 mojo (.000555 xch) \* | +| **Offer 1 CAT coin for 1 CAT coin + fee** | 135,000,000 | 675,000,000 mojo (.000675 xch) | ### Exact spend bundle costs diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/attacks-and-countermeasures.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/attacks-and-countermeasures.md index 8514e41933f..22a8aa3a429 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/attacks-and-countermeasures.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/attacks-and-countermeasures.md @@ -78,21 +78,21 @@ Finally, the formula to calculate the minimum netspace percentage required for t The following table shows the minimum required proportion of the total netspace an attacker must have in order to succeed in a majority attack. This table is valid for attacks lasting any amount of time, though sometimes it's overly conservative for attacks lasting more than one epoch. It uses fixed values for the first two columns. -| Number of Timelords | VA (relative to VH) | DD | SA | Percent of netspace required | Comment | -| :-----------------: | :-----------------: | :-----: | :---: | :--------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 0 | N/A | 1 | ∞ | N/A | Without a timelord, the attack is not possible. | -| 1 | 0.5 | 1 | 2 | 66.7% | With a 0.5x timelord, the attacker must control twice as much space as the rest of the network combined. | -| ∞ | 0.5 | 1.34313 | 1.489 | 59.8% | With infinite 0.5x timelords, the attacker gains a double-dip advantage, so less space is required versus having a single timelord of the same speed. | -| 1 | 1 | 1 | 1 | 50.0% | If the attacker has one timelord that's tied with the fastest honest timelord, then the attacker must control more space than the network's honest space. | -| ∞ | 1 | 1.34313 | 0.745 | 42.7% | With infinite timelords tied with the fastest honest timelord on the network, the attacker gains a double-dip advantage. | -| 1 | 2 | 1 | 0.5 | 33.3% | If the attacker has one timelord that's twice as fast as the fastest honest timelord, the attacker must control half as much space as the rest of the network. | -| ∞ | 2 | 1.4678 | 0.341 | 25.4% | With infinite 2x timelords, the attacker gains the maximum double-dip advantage. | +| Number of Timelords | VA (relative to VH) | DD | SA | Percent of netspace required | Comment | +| :-----------------: | :------------------------------------: | :---------------------: | :-------------------: | :--------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 0 | N/A | 1 | ∞ | N/A | Without a timelord, the attack is not possible. | +| 1 | 0.5 | 1 | 2 | 66.7% | With a 0.5x timelord, the attacker must control twice as much space as the rest of the network combined. | +| ∞ | 0.5 | 1.34313 | 1.489 | 59.8% | With infinite 0.5x timelords, the attacker gains a double-dip advantage, so less space is required versus having a single timelord of the same speed. | +| 1 | 1 | 1 | 1 | 50.0% | If the attacker has one timelord that's tied with the fastest honest timelord, then the attacker must control more space than the network's honest space. | +| ∞ | 1 | 1.34313 | 0.745 | 42.7% | With infinite timelords tied with the fastest honest timelord on the network, the attacker gains a double-dip advantage. | +| 1 | 2 | 1 | 0.5 | 33.3% | If the attacker has one timelord that's twice as fast as the fastest honest timelord, the attacker must control half as much space as the rest of the network. | +| ∞ | 2 | 1.4678 | 0.341 | 25.4% | With infinite 2x timelords, the attacker gains the maximum double-dip advantage. | For attacks lasting longer than one epoch, `DD` will not exceed 1.34313. In such an attack, the final row from the preceding table will change to the following: -| Number of Timelords | VA (relative to VH) | DD | SA | Percent of netspace required | Comment | -| :-----------------: | :-----------------: | :-----: | :---: | :--------------------------: | :------------------------------------------------------------------------------- | -| ∞ | 2 | 1.34313 | 0.372 | 27.1% | If the attack longer than one epoch, the double-dip advantage will be minimized. | +| Number of Timelords | VA (relative to VH) | DD | SA | Percent of netspace required | Comment | +| :-----------------: | :------------------------------------: | :---------------------: | :-------------------: | :--------------------------: | :----------------------------------------------------------------------------------------------- | +| ∞ | 2 | 1.34313 | 0.372 | 27.1% | If the attack longer than one epoch, the double-dip advantage will be minimized. | Note that if we continue to increase `VA`, `DD` will always remain at 1.4678 for the first table, and 1.34313 for the second table. The percent of netspace required will decrease linearly. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-format.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-format.md index 8c21c941423..a262c90ab93 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-format.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-format.md @@ -9,12 +9,12 @@ The full block is the data structure that contains all information required for 完整块拥有区块链的trunk和foliage的全部字段。 The `header_hash`, which is used as the block identifier, is the hash of the `foliage` field in streamable format (see the [Serialization Protocol page](/chia-blockchain/protocol/serialization-protocol)). 这样便以确保当前区块和前序区块的数据不被篡改。 -- **finished_sub_sots**: List[EndOfSubSlotBundle]: This contains all sub-slots that have been completed since the previous block in the chain (block `N-1`). +- **finished_sub_slots**: List[EndOfSubSlotBundle]: This contains all sub-slots that have been completed since the previous block in the chain (block `N-1`). - **reward_chain_block**: RewardChainBlock: This is trunk data for the reward chain and challenge chain, including vdf outputs and proof of space. -- **challenge_chain_sp_proof**: Optional[VDFProof]: Proof of the VDF for the challenge chain signage point, not provided for the first signage point, since that is and end of sub slot. -- **challenge_chain_ip_proof** VDFProof: VDF proof from the previous cc infusion, up the infusion point. -- **reward_chain_sp_proof**: Optional[VDFProof]: Proof of the VDF for the reward chain signage point, not provided for the first signage point, since that is and end of sub slot. -- **reward_chain_ip_proof** VDFProof: VDF proof from the previous rc infusion, up to the infusion point. +- **challenge_chain_sp_proof**: Optional[VDFProof]: Proof of the VDF for the challenge chain signage point, not provided for the first signage point, since that is an end of sub slot. +- **challenge_chain_ip_proof**: VDFProof: VDF proof from the previous cc infusion, up the infusion point. +- **reward_chain_sp_proof**: Optional[VDFProof]: Proof of the VDF for the reward chain signage point, not provided for the first signage point, since that is an end of sub slot. +- **reward_chain_ip_proof**: VDFProof: VDF proof from the previous rc infusion, up to the infusion point. - **infused_challenge_chain_ip_proof**: Optional[VDFProof]: The ICC proof, only present if deficit < 16 - **foliage**: Foliage: Foliage data for the reward chain block, the hash of this is the `header_hash`. - **foliage_transaction_block**: Optional[FoliageTransactionBlock]: Transaction related metadata that is relevant for light clients (not actual transactions), only for tx blocks. @@ -22,6 +22,35 @@ The full block is the data structure that contains all information required for - **transactions_generator**: Optional[SerializedProgram]: A clvm/rust program that generates all transactions (spends). See the next section for an important [update](#transactions_generator-update) due to the 2.1.0 hard fork. - **transactions_generator_ref_list**: List[uint32]: A list of block heights of previous generators referenced by this block's generator. +### FullBlock nested streamable types (subtypes) + +In the protocol and RPC responses, `FullBlock` is one concrete streamable struct (implemented in `chia_rs`). Here “subtypes” means the nested streamable types below, not distinct inheritance subclasses. + +#### Transaction blocks versus non-transaction blocks + +Whether a `FullBlock` carries transactions is determined by `reward_chain_block.is_transaction_block`: + +- When that flag is false (not a transaction block), `foliage_transaction_block`, `transactions_info`, and `transactions_generator` are unset (`null` in JSON), and `transactions_generator_ref_list` is empty. +- When it is true (a transaction block), those optional fields contain transaction-related metadata and the block generator program (see the next section for generator serialization). + +A JSON example of a non-transaction block is shown under [`get_block`](/reference-client/rpc-reference/full-node-rpc#get_block) in the full node RPC reference. + +#### What each nested type holds + +- `EndOfSubSlotBundle` (each element of `finished_sub_slots`): describes completed sub-slots between the previous block and this one. +- `RewardChainBlock` (`reward_chain_block`): trunk data (height, weight, cumulative `total_iters`, signage index, proof of space, VDF outputs and related signatures, and `is_transaction_block`). +- `Foliage` (`foliage`): chain linkage and farmer or pool layer (`prev_block_hash`, reward and pool targets, signatures, and hashes tying foliage to the trunk). +- `FoliageTransactionBlock` (`foliage_transaction_block`, optional): light-client metadata for a transaction block (for example timestamp-related fields), not the spends themselves. +- `TransactionsInfo` (`transactions_info`, optional): validation-oriented aggregates such as fees and cost associated with the generator. +- `VDFProof` (each `*_proof` field): witness material for the corresponding VDF output where the protocol requires a proof. + +#### Related block-shaped protocol types + +Other consensus messages use similar building blocks but are not extra subclasses of `FullBlock`: + +- `UnfinishedBlock`: block still being assembled or propagated before it becomes a full block (see [`respond_unfinished_block`](/chia-blockchain/protocol/peer-protocol#respond_unfinished_block) in the peer protocol). +- `HeaderBlock`: header material without the full transactions generator, used when a wallet asks the node for headers only (see [`respond_block_header`](/chia-blockchain/protocol/wallet-protocol#respond_block_header) in the wallet protocol). + ## transactions_generator update Chia underwent a hard fork in version 2.1.0. This included updates to the `transactions_generator` code. @@ -54,6 +83,7 @@ The code for these changes is held in two primary locations: Two important changes went into this update: 1. Allow serializing CLVM in a new, more compact form. This doesn't affect how CLVM is executed, it's just a matter of encoding. It does have some important consequences: + - Farmers can effectively stuff more transactions into blocks, because with a more compact encoding, you can fit more for the same byte-cost. - The new implementation can take advantage of the de-duplication in the new serialization format, by caching tree-hashes. This effectively de-duplicates the work of hashing puzzles. @@ -64,6 +94,7 @@ Two important changes went into this update: 2. The generator ROM implementation was ported from CLVM to Rust. This also doesn't affect the behavior of anything (other than the CLVM cost, as explained below). It just speeds up block validation. About the generator ROM: + - It is the code that invokes the generator in a block. - The return value is a list of spends. - The ROM validates all spends by checking the puzzle hashes and calling into all puzzles passing in their solutions. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-rewards.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-rewards.md index b3d4c447097..4027213425a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-rewards.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-rewards.md @@ -49,12 +49,12 @@ The second coin, with 7/8 of the value, is called the _pool coin_. This coin can As detailed in the [Business white paper](https://www.chia.net/whitepaper), the network's emissions schedule is as follows (where `year 0` is the first year of mainnet's existence): -| Years | Final
Block | Final Month
(Approx.) | Block Reward
(total) | Pool
Reward | Farmer
Reward | -| ------: | --------------: | ------------------------: | -----------------------: | --------------: | ----------------: | -| 1 - 3 | `5 045 760` | March 2024 | 2 XCH | 1.75 XCH | 0.25 XCH | -| 4 - 6 | `10 091 520` | March 2027 | 1 XCH | 0.785 XCH | 0.125 XCH | -| 7 - 9 | `15 137 280` | March 2030 | 0.5 XCH | 0.4375 XCH | 0.0625 XCH | -| 10 - 12 | `20 183 040` | March 2033 | 0.25 XCH | 0.21875 XCH | 0.03125 XCH | -| 13 - ∞ | ∞ | ∞ | 0.125 XCH | 0.109375 XCH | 0.015625 XCH | +| Years | Final
Block | Final Month
(Approx.) | Block Reward
(total) | Pool
Reward | Farmer
Reward | +| ------: | --------------: | -----------------------------------------------------------: | ------------------------------------------: | ---------------------------: | ---------------------------: | +| 1 - 3 | `5 045 760` | March 2024 | 2 XCH | 1.75 XCH | 0.25 XCH | +| 4 - 6 | `10 091 520` | March 2027 | 1 XCH | 0.785 XCH | 0.125 XCH | +| 7 - 9 | `15 137 280` | March 2030 | 0.5 XCH | 0.4375 XCH | 0.0625 XCH | +| 10 - 12 | `20 183 040` | March 2033 | 0.25 XCH | 0.21875 XCH | 0.03125 XCH | +| 13 - ∞ | ∞ | ∞ | 0.125 XCH | 0.109375 XCH | 0.015625 XCH | Note that the rewards are adjusted according to a block height, not a timestamp. The `Final Block` column is therefore accurate as the last block before the rewards are modified. The months and years are only estimates based on when the block heights are likely to be reached. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-validation.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-validation.md index b3ff76fbbd9..ed32baf02ba 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-validation.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-validation.md @@ -94,10 +94,8 @@ The following sections list all of the required checks to ensure validity of a b 18. Check unfinished reward chain block hash 19. Check pool target max height 20. Check pre-farm puzzle hashes for genesis block. - -- If pospace has a pool pk, check pool target signature. Should not check this for genesis block. -- Otherwise, the plot is associated with a contract puzzle hash, not a public key, so check pool contract ph - + - If pospace has a pool pk, check pool target signature. Should not check this for genesis block. + - Otherwise, the plot is associated with a contract puzzle hash, not a public key, so check pool contract ph 21. Check extension data if applicable. None for mainnet. 22. Check if foliage block is present 23. Check foliage block hash @@ -138,7 +136,7 @@ The following sections list all of the required checks to ensure validity of a b 13. Check for duplicate outputs in additions. 14. Check for duplicate spends inside block. 15. Check if removals exist and were not previously spent. (coin_db up to the fork point + fork block + this_block). - Be careful with forks and with ephemeral coins (added and removed in same block). + Be careful with forks and with ephemeral coins (added and removed in same block). 16. Check that the total coin amount for added is \<= removed. 17. Check that the assert fee sum \<= fees, and that each reserved fee is non-negative. 18. Check that the fee amount + farmer reward \< maximum coin amount. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/foliage.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/foliage.md index d45d4db0750..49d3c13bb9d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/foliage.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/foliage.md @@ -66,7 +66,7 @@ The average time between transaction blocks is 52 seconds. Several values are re - Sub-slot time = 600 seconds - Signage point time = 64 per sub-slot, or 600/64 = 9.375 seconds - Average block time = 32 per sub-slot, or 600/32 = 18.75 seconds -- Minimum signage points from current signage point until infusion_iterations is reached = 3 (See the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points) for more info.) +- Minimum signage points from current signage point until infusion_iterations is reached = 3 (See the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md) for more info.) - Minimum time for infusion_iterations to be reached (and therefore, minimum time between transaction blocks) = 3 \* (600/64) = 28.125 seconds - Average signage points until infusion_iterations is reached is slightly more than 3.5 (must wait 3 signage points, plus an average wait of about 50% of the next signage point), or around 3.5 \* 9.375 = 32.8125 seconds. - To create a transaction block, infusion_iterations first must be met, and then the next block some seconds afterwards will be a transaction block. The total average time for this to happen is around 52 seconds. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/harvester-algorithm.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/harvester-algorithm.md index 930b09b5fa0..b7c3e6a1ef6 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/harvester-algorithm.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/harvester-algorithm.md @@ -26,5 +26,5 @@ class NewSignagePointHarvester: `plot filter bits = sha256(plot_id + challenge_hash + sp_hash)`. -If the resulting bits start with 9 zeroes, then the plot passes the filter. This does not require disk access, since the plot_ids are stored in memory. 2. For each of the plots passing the filter, a new thread is started, which performs the quality lookups. Recall that this requires around 7-9 random reads into the plot, one for each table. This is where the majority of the disk activity will be. On average, 1 of every 512 plots will perform this step. 3. required_iterations is computed, as explained in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points). If the farmer is currently farming for a pool, then the pool will use custom values for both `difficulty` and `sub-slot_iterations`. These values make it more likely that a proof will be found. The reason to use these values is to make it easier for the pool to determine the amount of storage a farmer currently has dedicated. +If the resulting bits start with 9 zeroes, then the plot passes the filter. This does not require disk access, since the plot_ids are stored in memory. 2. For each of the plots passing the filter, a new thread is started, which performs the quality lookups. Recall that this requires around 7-9 random reads into the plot, one for each table. This is where the majority of the disk activity will be. On average, 1 of every 512 plots will perform this step. 3. required_iterations is computed, as explained in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md). If the farmer is currently farming for a pool, then the pool will use custom values for both `difficulty` and `sub-slot_iterations`. These values make it more likely that a proof will be found. The reason to use these values is to make it easier for the pool to determine the amount of storage a farmer currently has dedicated. If required_iterations is less than the interval_iterations, this proof of space is good (it has won either a pool partial or a block). Most proofs will not pass this step. 5. For winning proofs, the whole proof is fetched on disk (approximately 64 random reads in the plot). 6. The proof is sent back to the farmer. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/multiple-blocks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/multiple-blocks.md index 5993e8f4344..1027c69e167 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/multiple-blocks.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/multiple-blocks.md @@ -19,7 +19,7 @@ VDF proofs span: In the example in Figure 7, B2 contains a VDF proof from B1 to sp2, and from B1 to B2. B3 contains a proof from B1 to sp3, and from B2 to B3. B2 does not depend at all on B3, but B3 depends on B2, since its VDF is from B2's infusion point. -As discussed in [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points), the blocks get created at the signage points, but they are missing the infusion point VDF. Once this VDF is added, the block is finished, and forms part of the blockchain. +As discussed in [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md), the blocks get created at the signage points, but they are missing the infusion point VDF. Once this VDF is added, the block is finished, and forms part of the blockchain. The signatures get created and added by the farmers at the signage points, and broadcast to the whole network. There are no signatures at the infusion point; the only things added at the infusion point are the VDFs. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/overflow-blocks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/overflow-blocks.md index 00bbff125da..af75d2e564e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/overflow-blocks.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/overflow-blocks.md @@ -5,7 +5,7 @@ slug: /chia-blockchain/consensus/chains/overflow-blocks ## Overflow Blocks -For a farmer to create a block, their required_iterations must be less than sub-slot_iterations / 64, as described in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points). This means that infusion_iterations might be greater than the sub-slot_iterations, and therefore the infusion must happen in the next sub-slot. +For a farmer to create a block, their required_iterations must be less than sub-slot_iterations / 64, as described in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md). This means that infusion_iterations might be greater than the sub-slot_iterations, and therefore the infusion must happen in the next sub-slot. **Overflow block**: a block whose infusion point is in a different sub-slot than its signage point. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/signage-and-infusion-points.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/signage-and-infusion-points.md index 8a355fb90ea..b72aa57628f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/signage-and-infusion-points.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/signage-and-infusion-points.md @@ -92,7 +92,7 @@ Recall that in this example, - _sub-slot_iterations = 100,000,000_ - _sp_interval_iterations = 1,562,500_ -For each of the 64 signage points, as they are released to the network every 9.375 seconds, or every 1.5625M iterations, the farmer computes the plot filter and sees how many plots pass. For each passing plot, the farmer calculates required*iterations. For each passing plot, the farmer calculates \_required_iterations*. +For each of the 64 signage points, as they are released to the network every 9.375 seconds, or every 1.5625M iterations, the farmer computes the plot filter and sees how many plots pass. For each passing plot, the farmer calculates required_iterations. For each passing plot, the farmer calculates _required_iterations_. Let's say the farmer calculates _required_iterations < 1,562,500_ once in the sub-slot. (We'll assume the exact _required_iterations = 782,800_ in this instance.) Figure 5 shows this happening at the 20th signage point. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/forks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/forks.md index 723e5425a04..700bc480e7f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/forks.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/forks.md @@ -3,15 +3,17 @@ title: Forks slug: /chia-blockchain/consensus/forks --- -The following table is a comprehensive list of all forks (planned and activated) on Chia's blockchain. It was last updated on 2023-09-10. It was last updated on 2024-12-19. +The following table is a comprehensive list of all forks (planned and activated) on Chia's blockchain. It was last updated on 2023-09-10. It was last updated on 2026-05-21. -| Activation Block | Activation Date | Type | Build | Status | Description | -| :--------------- | :-------------- | :--- | :---- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `2 300 000` | 2022-07-22 | Soft | 1.3.0 | Activated | [Disallow negative division](https://www.chia.net/2022/03/04/divided-we-fork/) | -| `3 630 000` | 2023-05-07 | Soft | 1.7.0 | Activated | [Restrict `AGG_SIG_UNSAFE` message](https://github.com/Chia-Network/post-mortem/blob/main/2023-05/2023-05-08-AGG_SIG_UNSAFE-can-mimic-AGG_SIG_ME-condition.md) | -| `3 886 635` | 2023-07-01 | Soft | 1.8.0 | Activated | [CHIP-14](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0014.md) -- `ASSERT_BEFORE_*` conditions | -| `4 510 000` | 2023-11-12 | Soft | 2.0.0 | Activated | [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md) -- BLS/SECP CLVM Operators | -| `5 496 000` | 2024-06-13 | Hard | 2.1.0 | Activated | [CHIP-12](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0012.md) -- Decrease plot filter | -| `5 716 000` | 2024-07-30 | Soft | 2.3.0 | Activated | [CHIP-25](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0025.md) -- Chialisp Message Conditions | -| `5 940 000` | 2024-09-17 | Soft | 2.4.0 | Activated | Disallow infinity G1 points | -| `6 800 000` | 2025-03-22 | Soft | 2.5.0 | Activated | [CHIP-36](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0036.md) -- keccak256 CLVM operator | +| Activation Block | Activation Date | Type | Build | Status | Description | +| :--------------- | :-------------- | :--- | :-------------------------------------------------------------------------------- | :-------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `2 300 000` | 2022-07-22 | Soft | 1.3.0 | Activated | [Disallow negative division](https://www.chia.net/2022/03/04/divided-we-fork/) | +| `3 630 000` | 2023-05-07 | Soft | 1.7.0 | Activated | [Restrict `AGG_SIG_UNSAFE` message](https://github.com/Chia-Network/post-mortem/blob/main/2023-05/2023-05-08-AGG_SIG_UNSAFE-can-mimic-AGG_SIG_ME-condition.md) | +| `3 886 635` | 2023-07-01 | Soft | 1.8.0 | Activated | [CHIP-14](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0014.md) -- `ASSERT_BEFORE_*` conditions | +| `4 510 000` | 2023-11-12 | Soft | 2.0.0 | Activated | [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md) -- BLS/SECP CLVM Operators | +| `5 496 000` | 2024-06-13 | Hard | 2.1.0 | Activated | [CHIP-12](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0012.md) -- Decrease plot filter | +| `5 716 000` | 2024-07-30 | Soft | 2.3.0 | Activated | [CHIP-25](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0025.md) -- Chialisp Message Conditions | +| `5 940 000` | 2024-09-17 | Soft | 2.4.0 | Activated | Disallow infinity G1 points | +| `6 800 000` | 2025-03-22 | Soft | 2.5.0 | Activated | [CHIP-36](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0036.md) -- keccak256 CLVM operator | +| `8 655 000` | 2026-04-29 | Soft | 2.6.0
2.7.0 | Activated | [Security Updates](https://www.chia.net/2026/03/26/chia-2-7-0-combatting-the-ai-siege/), Postmortems for [2.6.0](https://github.com/Chia-Network/post-mortem/blob/main/2026-02/2026-02-11-chia-blockchain-2.6.0-security-release-post-mortem.md), [2.6.1](https://github.com/Chia-Network/post-mortem/blob/main/2026-03/2026-03-18-chia-blockchain-2.6.1-security-release-post-mortem.md), [2.7.0](https://github.com/Chia-Network/post-mortem/blob/main/2026-03/2026-03-26-chia-blockchain-2.7.0-security-release-post-mortem.md) | +| `9 562 000` | 2026-11 | Hard | 3.0.0 | Planned | [CHIP-48](https://github.com/Chia-Network/chips/pull/160), [CHIP-49](https://github.com/Chia-Network/chips/pull/161) -- New Proof of Space | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-1.0.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-1.0.md index d7ed557b235..df3f6c0a587 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-1.0.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-1.0.md @@ -47,7 +47,7 @@ For each eligible plot (explained later), a farmer uses the following procedure 7. For each matching f7 value, read T7 at the same index where the f7 value was found in its own table, and grab that entry, which is an index into T6 8. The T6 index contains one _line point_ with two _back pointers_ to T5, four to T4, eight to T3, sixteen to T2 and thirty-two to T1. Each back pointer requires 1 read, so a total of 64 disk reads (1 index from T7, 63 back pointers) are performed to fetch the whole tree of 64 x-values. -Since most proofs generated by this process are not good enough (as discussed in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points)) to be submitted to the network for verification, we can optimize this process by only checking one branch of the tree. This branch will return two of the 64 x-values. The position of the x-values will always be consecutive and will depend on the signage point (eg x0 and x1... or x34 and x35). We hash these x-values to produce a random 256-bit "quality string." This is combined with the difficulty and the plot size to generate the required_iterations. If the required_iterations is less than a certain number, the proof can be included in the blockchain. At this point, we look up the whole proof of space. +Since most proofs generated by this process are not good enough (as discussed in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md)) to be submitted to the network for verification, we can optimize this process by only checking one branch of the tree. This branch will return two of the 64 x-values. The position of the x-values will always be consecutive and will depend on the signage point (eg x0 and x1... or x34 and x35). We hash these x-values to produce a random 256-bit "quality string." This is combined with the difficulty and the plot size to generate the required_iterations. If the required_iterations is less than a certain number, the proof can be included in the blockchain. At this point, we look up the whole proof of space. By only looking up one branch to determine the quality string, we can rule out most proofs. This optimization requires only around 7-9 disk seeks and reads, or about 70-90 ms on a slow hard drive. @@ -57,7 +57,7 @@ Throughout this website, we'll make a simple assumption that a single disk seek The 10ms estimate also takes into account the time required to transfer data after the seek. While storage industry specs typically assume that large files are being transferred, this does not hold true for Chia farming, where proof lookups only require a tiny amount of data to be transferred. Therefore, for this website, it's safe to assume the transfer is almost instant. ::: -Chia also uses a further optimization to disqualify a certain proportion of plots from eligibility for each challenge. This is referred to as the _plot filter_. The current requirement is that the hash of the plot ID, challenge, and signage point starts with 9 zeros. This excludes 511 out of every 512 plots. The filter hurts everyone equally (except for [replotting attackers](/chia-blockchain/consensus/attacks-and-countermeasures#replotting)), and is therefore fair. The plot filter is discussed in greater detail in the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points). +Chia also uses a further optimization to disqualify a certain proportion of plots from eligibility for each challenge. This is referred to as the _plot filter_. The current requirement is that the hash of the plot ID, challenge, and signage point starts with 9 zeros. This excludes 511 out of every 512 plots. The filter hurts everyone equally (except for [replotting attackers](/chia-blockchain/consensus/attacks-and-countermeasures#replotting)), and is therefore fair. The plot filter is discussed in greater detail in the [Signage and Infusion Points page](/docs/chia-blockchain/consensus/chains/signage-and-infusion-points.md). The plot filter effectively reduces the amount of resources required for farming by 512x -- each plot only requires a few disk reads every few minutes. A farmer with 1 PiB of storage (10,000 plots) will only have an average of 20 plots that pass the filter for each challenge. Even if these plots all are stored on slow HDDs, and connected to a single Raspberry Pi, the average time required to respond to each challenge will be less than two seconds. This is well within the limits to avoid missing out on any challenges. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md index 6190ddb7ae3..3656466cba1 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md @@ -9,7 +9,7 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: @@ -17,90 +17,167 @@ This page will answer your most common questions. Expect it to grow with time. ### What will this break/change? -Initially nothing, to give everyone time to upgrade. When the hard fork becomes activated six months after the release of Chia 3.0 there will be changes to the blockchain consensus which will cause non-upgraded full nodes and wallets to break. The upgrades software vendors will need to make before then are small and will be included in the reference codebase. Farmers will have to replot during the transition period and use upgraded plotters and harvesters. The computational requirements for harvesting will be slightly larger than with the original plot file format but vastly less than for compressed plots. +When the hard fork activates at block `9'562'000` (November 2026), there will be changes to the blockchain consensus which will cause non-upgraded full nodes and wallets to break. The upgrades software vendors will need to make before then are small and will be included in the reference codebase. Farmers will have to replot during the transition period. The min spec hardware from farming will be increased to a Raspberry Pi 5 with 8 GB of RAM (currently, it's a Pi 4). + +### If I use the reference wallet, but I’m not a farmer, will I need to upgrade anything? + +Yes, you will need to upgrade your wallet to version 3.0 before block 9,562,000. If you fail to do so, then your wallet may fall out of sync until you perform the upgrade. However, the funds contained within your wallet will remain secure. + +### If I use the Cloud Wallet, will I need to upgrade anything? + +CNI runs several nodes to host the Cloud Wallet infrastructure, so all you will need to do is occasionally refresh your browser window to pick up any changes. + +### How about if I use Sage or another ecosystem wallet? + +If you use any ecosystem wallet including Sage, you will need to make sure to stay upgraded to the latest version of your wallet software. The operators of those wallets will be responsible for upgrading their own infrastructure. ### When will I be able to farm with new plots on mainnet? -After the hard fork date, currently expected at height 8’800’000. This is expected to happen around 2026-06-01 (see [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline)). +You will be able to farm with PoS2 plots when the 3.0 hard fork activates. This is currently scheduled for block `9'562'000`, expected to occur in November 2026. See our [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline) for more details. ### When will the old plot format be fully phased out? -By the end of the transition period, currently expected 1H 2027 (see [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline)). +After the fork activates, there will be a transition period of 256 days, during which PoS1 plots will become less likely to win. The last block in which PoS1 plots are expected to be valid is `10'741'648`, which should occur in June or July 2027. See our [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline)) for more details. ### When should I replot? Sometime during the transition period. When will be best for you will depend on your setup, but there will be a long enough time that the plots compliant with the new format will be neutral in weight to your existing plots so you can do it at your leisure. We will provide guidelines on how to evaluate which time window would be ideal to transition for your setup. -### With a modern GPU such as a 3090, what will be my expected plot times? +### With a modern GPU such as a 5090, what will be my expected plot times? -Around - minutes for a - plot (Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day). See our table of [expected plot times](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements#plotting-performance-and-requirements). +Around 2 seconds per plot, or 40 TiB per day for minimum-strength plots. See our table of [expected plot times](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements#plotting-performance-and-requirements). ### Will you also support CPU plotting, and if so, what will be my expected plot times? -CPU plotting will be supported but will not be recommended for plotting any significant amount. A multi-threaded CPU will be about - slower than a 3090, potentially completing a k30 in - minutes. The more CPU threads and memory channels your system has will reduce this time. (Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day) +CPU plotting will be supported, but will be slower than GPU plotting. A 6-core Ryzen 5600 will plot create minimum-strength plots in around 30 seconds, or around 4 TiB per day. + +### How much RAM/VRAM will I need to plot? + +For all-RAM plotting with a GPU, the current usage without swapping is around 12 GB of VRAM. It might be possible to lower this number, but this is not a guarantee. As for all-RAM CPU plotting, 16 GB will be the maximum amount needed. ### What will the hardware requirements be for harvesters? -Harvesting consists of two main components: plot retrieval and proof solving when a good proof is found. +The minimum spec hardware for harvesting and farming is a Raspberry Pi 5 with 8 GB of RAM. This computer will be able to farm around 2 PiB of storage without any issues. + +See our [farming requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements) for more detailed information. -For plot retrieval, even large farms can use low-spec computers such as original Raspberry Pis, as most of the time is spent simply reading from storage, which uses minimal compute resources. +### What is plot strength? -The proof-solving hardware requirement depends on the largest plot size (k-size) in your farm, not the total number of plots. If a proof of space wins a block or pool partial, your hardware must be capable of solving proofs for the largest k-size plot within the required timeframe. +This term refers to the amount of compute that was needed to generate a plot. Each increment in strength will require around double the compute. The hardware requirements to create a plot, as well as its final size are unaffected. -For example, if your farm includes k28, k30, and k32 plots, your proof-solving machine must meet the requirements for solving k32 proofs, even if the majority of your plots are smaller. If you want a single machine for both harvesting tasks (plot retrieval and proof solving), it should meet the k32 specs for solving proofs and can also handle plot retrieval. +The minimum strength will begin at 0, and we will raise it as needed to maintain the network’s security. However, we do not intend to increase the minimum strength until at least 2036. -For large farms or setups with multiple harvesters, you can use low-spec devices like Raspberry Pis for plot retrieval and designate a higher-spec machine capable of solving proofs for your largest k-size as the central proof-solving service. If your farm contains only k28 plots, a Raspberry Pi 5 can serve as both a plot retrieval device and the central proof-solving service for your entire farm. +### Why would I want to plot at a higher strength than the minimum? -See our [farming requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements) for more detailed information. +The primary reason would be to reduce disk usage. Plots created at a higher strength will need to be accessed less frequently. A second reason would be to increase your plots’ longevity. However, we expect (though can’t guarantee) plots created at the minimum strength today to remain valid for a decade, so we don’t expect many farmers to plot at higher strengths for this reason alone. + +### Will there be a maximum plot strength? + +是的。 The maximum strength will start at 8, and will increment as the base filter is decreased. Strength needs to be capped in order to ensure that the network’s minimum spec hardware can validate all proofs in a timely manner. + +### Will “stronger” plots win more often? Less often? Neither? + +Neither. If plot B is twice as “strong” as plot A, then it will pass the filter half as often, and it will be twice as likely to find a valid proof once it does pass the filter. As a result, the long-term expected earnings of both plots will be identical. + +### How much longer will the creation time be for plots created at strengths higher than the minimum? + +At the lowest strength intervals, increasing the strength by one level will require slightly less than double the creation time. This is due to some overhead in the creation process. After around strength=4, the overhead will be negligible, so plots created at higher strengths will need almost exactly twice as long to be created. + +### Can I use an HDD as a temporary drive while creating large groups, or is RAM or an SSD required? + +An HDD will typically write at 250MB/s, which takes 4 seconds per plot in the group to write. This could be done in a background thread while creating the next plot for the group. So, it becomes a bottleneck only if you are plotting faster than 1 plot every 4 seconds. And even in that case, you could alleviate the bottleneck by increasing the plot strength so that it takes longer than 4 seconds to create each plot. + +Once all plots in the group have been written to temporary storage, you can run another single-thread to merge them into the final grouped plot. That will take as long as the HDD takes to read all data and rewrite it to the target destination. CPU load would only take 1 thread, and memory load could be less than 1 GB. During this process, you could begin creating plots for a new group with a different process. + +TLDR: Yes, you could use a spare HDD to make the big grouped plots without much impact on your plotting times. + +### How are groups stored on disk? As a single file? Multiple files? + +It’s possible to divide a group into as many files as needed. If you follow our recommendations and use groups of 64 or 128 plots, then you will probably want each of your groups to consist of a single file. + +### Why would I want to separate my group into multiple files? -### What is the difficulty level in the new format? +To avoid having to use a large temporary space. Recall that while creating plots to be included in a single group, you need to store the completed plots somewhere temporarily. -The new plot format allows us to tune a difficulty setting to directly influence plot time. The higher the plot time, the more compression resistant the format becomes. However, we need to balance the difficulty with what should be an acceptable plotting time for most farmers, yet still have enough difficulty for significant compression resistance. +Let’s say you have a 20 TB HDD and you decide to fill it with a single group of 20,000 plots. If you only created one file, then you would need another 20 TB on which to store the plots temporarily, before combining them into a single file. This could be slow and cumbersome to achieve. If instead, you created 200 files of 100 GB each, then you would only need 100 GB of storage, which would allow for in-RAM temp storage on many systems. In both cases, the result is a single group of 20 TB, but in the former case you have one file, and in the latter case you have 200 files. -Each plot in the new format has a difficulty setting, which must be between 0 and 255. With each increment of the setting, the plot will require approximately twice as much time to be created. (The hardware requirements to create a plot, as well as its final size are unaffected.) +### Why shouldn’t I break down a group even further? Why not use 1000 files? -After the hard fork activates, the network will have a minimum difficulty level for all plots created with the new format. Any plots that were created with an easier difficulty level will be invalid. In order to plan for advancements in technology, the minimum difficulty level will be set to increase every two years going forward. The timeline is intentionally aggressive -- we can relax this schedule with a soft fork if needed. +To prevent taking too long to submit a valid proof. By definition, each file from the same group will pass the filter together. When this happens, each file will undergo two disk seeks. On an HDD, each seek might take 10 ms. If you have 1000 files in the same group, then 2000 disk seeks will be needed, and this will require upwards of 20,000 ms, or 20 seconds. This is too much time – taking more than 8 seconds risks being too much time to find and submit a proof. -As a result of the minimum difficulty adjustments, each plot will have an effective expiration time. Farmers can use this data to replot to a difficulty level that makes sense for their setup. [CHIP-49](https://github.com/Chia-Network/chips/pull/161) contains a section titled `Plot difficulty adjustments`, which goes into greater detail. +### Will I need to use meta groups? Why or why not? + +Meta groups are not required. The primary use case for meta groups is to smooth disk usage as much as possible. The vast majority of farmers today can forgo meta groups without any noticeable difference. Meta groups should be considered an advanced feature. + +### Why even include meta groups if almost nobody will use them? + +They could be quite helpful in the future. Whereas today, most HDDs used for farming are around 20-24 TB, a decade from now they could be 200 TB, or even larger. A 200 TB HDD filled with groups of 128 plots would require over 1500 files to be stored on disk. In this case, the load might spike so much that the disk isn’t able to keep up at certain signage points. We wanted to include this feature today so that it will be available when it is needed in the future. + +### If I don’t want to use meta groups, will I still need to specify a meta group, or will there be a default? + +Each group will be assigned the default meta group of 0 if left unspecified. + +### If I have 10 groups with one meta group, are they guaranteed to pass the filter at the same time? + +No. If you have 10 groups with one meta group, then each group will pass (or not pass) the filter independently. It would be like rolling 10 dice. You might roll zero 1s or ten 1s, or anything in between. Each die acts independently of each other die. + +On the other hand, if you have 10 groups, each of which is assigned a unique meta group, then you have a guarantee that at most one of your plots groups will pass the filter at a given signage point. + +### What is the largest farm size supported in PoS v2? + +There is no effective limit. This is because each group can declare its own meta groups. For example, group A can have plots with group indices 0..65535 within meta group 0. The same group can then have an additional 65,536 plots within meta group 1, and so. Each of the 256 available meta groups can have 65,536 plots assigned to it, so the maximum group size is 2^8 \* 2^16 = 2^24 (16,777,216) plots, or around 16.8 PB for a single group. Farmers can create as many groups as they want, so there farm can grow arbitrarily large (there technically is a limit due to the length of a plot ID, but this is such a large number, it's essentially unlimited). ### How do you know that compression won’t be possible with the new format? Compression is always possible, but the incentive will be severely limited. For instance, you could compress 100% of the plot by constructing a plot on the fly in under 30 seconds when a signage point comes in. However, this would require a cluster of the latest GPUs to achieve, and would cost hundreds of thousands of dollars, just to spoof the space taken up by less than a TB. Alternatively, a farmer could make a plot with just 1 bit dropped per entry, and save ~0.5% of space. However, even this could incur more energy per TiB than the honest farmer. -In the future we expect extremely high efficiency in compute, however, storage will also improve in cost and efficiency during that time. With the advent of extremely low power SSDs when on idle, most farmers will be better off staying with the default plot format. Those farmers looking to squeeze the most out of their system by bit-dropping for extra levels of compression might achieve marginal gains despite higher energy costs per eTiB, but risk needing to replot and adjust their systems based on price fluctuations. If compute efficiency significantly outpaces gains in storage cost and efficiency, we could see bit-dropping with recompute reaching up to 10% space savings with marginal extra % gains in net rewards. +In the future we expect extremely high efficiency in compute, however, storage will also improve in cost and efficiency during that time. With the advent of extremely low power SSDs when on idle, most farmers will be better off staying with the default plot format. Those farmers looking to squeeze the most out of their system by bit-dropping for extra levels of compression might achieve marginal gains despite higher energy costs per eTiB, but risk needing to replot and adjust their systems based on price fluctuations. ### Will there still be a plot filter after the new format is available? -Yes -- it is a similar concept to the plot filter for the existing proof format. [CHIP-48](https://github.com/Chia-Network/chips/pull/160) provides the technical details of this filter. If required, we can push the dates of these adjustments further into the future with a soft fork. +In PoS2, there are two related filters to consider: the network's base filter, and the effective filter for a plot or a group. + +The base filter indicates the lowest filter allowed for all plots across the network. This filter will start `512` and will automatically be adjusted downward every 3-6 years at pre-defined block heights, until it reaches `1`, where it will remain. The following table shows the built-in reductions to the base filter: + +| Block height | 年份 | Base Filter Bits | Base Filter | +| :----------- | :--- | :--------------- | :---------- | +| ` 9'562'000` | 2026 | 9 | 512 | +| `19'663'000` | 2032 | 8 | 256 | +| `24'708'000` | 2035 | 7 | 128 | +| `29'759'000` | 2038 | 6 | 64 | +| `34'809'000` | 2041 | 5 | 32 | +| `39'860'000` | 2044 | 4 | 16 | +| `44'905'000` | 2047 | 3 | 8 | +| `49'956'000` | 2051 | 2 | 4 | +| `55'006'000` | 2054 | 1 | 2 | +| `60'056'000` | 2057 | 0 | 1 | -The current proposal is to start the plot ID filter at 32 and cut it in half every two years until it reaches 1. The block heights of the filter adjustments are shown in the table in the next section. +In the scenario where we feel comfortable with delaying these reductions, we will do so with a soft fork. -### How many times will I have to replot? +Each plot will also have its own `effective filter`, which determines the likelihood that it is eligible to participate in a challenge at a given signage point. The effective filter is calculated based on a given plot's strength -- for each level above the minimum strength, a plot's effective filter is doubled. For example, if a plot's strength is 1 level above the minimum, and the base filter is 512, then that plots's effective filter is 1024. -This depends on your plots' difficulty level, [as explained above](#what-is-the-difficulty-level-in-the-new-format). For example, if you want to delay replotting for at least six years, you can create your plots with a difficulty level at least three levels above the minimum. +There is also a `maximum effective filter` of `8192`, regardless of the plot's strength. This is imposed to prevent certain attacks that could occur with very high strengths. ### What's this about different HDD and SSD plot formats (i.e. what is benes compression)? -As the new Proof of Space was being developed, one consideration was whether Benes Compression would be possible on HDDs and initially it was proposed that there would be an HDD format without Benes compression and an SSD format with Benes compression.\ -Prior to publishing [CHIP-48](https://github.com/Chia-Network/chips/pull/160) it was determined that Benes Compression can be performed on HDDs so now there will be only one format for both HDD and SSD. +While our original thinking was to release two separate formats, we have now simplified the design so that only a single format is needed for both HDDs and SSDs. As for Benes compression, while it originally was an intriguing way to reduce plots by a few percent, this is no longer needed in our simplified design, so we have also dropped our plans to use it. ### How much space will someone be able to save using GPU compression? -It will be possible to save a few percent of space using bit dropping but the costs will go up exponentially. Currently we expect a 4090 on a large farm may be incentivized to compress up to 2-3% of the plot size, although this is still subject to change based on the final tuning parameters for the proof of space. +PoS2 uses a single-table design, in which plots are one continuous blob of sorted data, with no additional table pointers, back-references, or structural redundancies. This design effectively eliminates economically viable plot compression. In theory, one could save 2-3% via bit-dropping, but it would require multiple orders of magnitude in additional compute to reconstruct the plots in real time. ### For an energy-conscious farmer, what will be the optimal CPU or GPU for farming? -Smaller k-sizes, such as k28, lead to increased disk activity, which in turn raises the energy consumption of storage media. For SSDs, this extra activity is negligible, and a low-power device like a Raspberry Pi 5 is sufficient to handle even large farms spanning multiple petabytes. +A low-power device like a Raspberry Pi 5 is sufficient to handle even large farms spanning multiple petabytes. -For HDD-based farms, HDDs consume more power (typically around 50 to 100% more) when actively reading compared to being idle. For example, a large 20TiB HDD filled with k28 plots will be active approximately 6% of the time, compared to 0.4% for k32 plots. This would result in a 3-6% increase in energy consumption when using k28 instead of k32 plots. - -For farmers with a large number of drives, it may be more efficient to use a higher-performance recompute machine capable of handling larger k-size plots (e.g., k32) without consuming more power than the additional energy costs incurred by smaller plots. A system like a Mac Mini M1 offers low idle power usage and can efficiently handle k32 plots. - -The most energy-conscious approach is to leverage an existing system already online that meets the recomputation requirements for larger k-sizes. By running a solver on standby, this system can handle requests for full proofs as needed with negligible impact on its overall energy usage. This method avoids the need for additional dedicated hardware while keeping power consumption minimal. +For HDD-based farms, HDDs consume more power (typically around 50 to 100% more) when actively reading compared to being idle. While more benchmarking will be needed, it may make sense over the long run for some farmers to plot at a high difficulty level so that they can idle (or even power down) their HDDs most of the time. They will use more compute/energy when initially creating their plots, in exchange for reduced ongoing energy consumption; there is not a straightforward equation to determine which approach will be more energy-efficient without taking multiple factors into account. ### When do you expect the CHIP to be made publicly available? -On 05/19/2025 we published [CHIP-48](https://github.com/Chia-Network/chips/pull/160) for the new PoS specification and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) for the timelines associated with its integration. +There are two publicly available CHIPs related to PoS2: + +- [CHIP-48](https://github.com/Chia-Network/chips/pull/160) describes the specification for PoS2 +- [CHIP-49](https://github.com/Chia-Network/chips/pull/161) details the timelines for PoS2, as well as some other unrelated changes that will go into the hard fork ### When can I review the source code for plotting? @@ -108,34 +185,20 @@ The source code is located in the [pos2-chip](https://github.com/Chia-Network/po ### Have you decided how long the transition period will be? -6-12 months. To provide feedback and discuss this transition period please refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161). +The transition period will last 256 days, starting with the fork's activation. To provide feedback and discuss this transition period please refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161). ### How will grinding be prevented? -[CHIP-48](https://github.com/Chia-Network/chips/pull/160) contains a detailed analysis of various grinding attacks and how the new PoS protects from them. - -### What metrics should we look at in determining whether grinding will be possible (plot size, plot speed, filter size, etc)? - -The feasibility of grinding can be assessed by calculating the amount of space that could be spoofed and comparing it to the resources required to achieve this. +Plot grinding will be possible, but not economical. For example, a 5090 GPU `($3700)` will be only able to mimic around 20 TB `($20)` of storage via plot grinding. This nearly 200x price difference doesn't take into account the ongoing electricity usage of running a 5090 continuously, versus what an HDD might use. -First, we determine how quickly a system can generate plots and whether the generated space can meaningfully spoof a significant portion of netspace. Then, we assess the probability of passing filters (e.g., plot ID, scan, and proof chaining filters) and how many plots would need to be generated to spoof a given amount of space. And finally, we evaluate whether it is feasible to rent or acquire the required computational resources (e.g., GPUs or GPU clusters) to generate enough spoofed space to impact the network. - -While it’s straightforward to calculate spoofed space (as demonstrated in the previous answer), the primary question is whether sufficient resources can be obtained at scale. For example: spoofing **20 EiB** of netspace would require **300 million 3090 GPUs**, far exceeding the global availability of GPUs today. Controlling such a large number of GPUs at a financially viable price is unlikely in the foreseeable future. - -Thus, while grinding is theoretically possible, it remains economically and logistically infeasible to execute at a scale that could threaten the network. +[CHIP-48](https://github.com/Chia-Network/chips/pull/160) contains a detailed analysis of various grinding attacks and how the new PoS protects from them. ### Under the current settings for the new format, for how long do you expect to be able to support k-28? -Short answer: -K28 plots are expected to remain viable for as long as no significant vulnerabilities emerge. If any risks arise, they would likely apply to higher K-sizes as well over time, given advancements in hardware and technology. - -Long answer: -Under the current settings for the new format, the primary risk to continued support for K28 plots stems from the potential development of ASICs or FPGAs. These specialized devices could potentially reduce production costs for K28 plots compared to larger K-sizes, as smaller plots require less RAM. However, the viability of ASICs is a complex issue, heavily influenced by development costs and the financial rewards they might yield. While FPGAs, known for their high efficiency, could theoretically pose a risk if optimized, they are typically slower than high-end GPUs and face similar challenges. +We have no plans for dropping support for k28 plots. It is expected to be the only valid plot size going forward. The new plot format has been designed to resist both rental and compression attacks, even against more powerful GPUs that may be developed in the future. This makes it uncertain whether FPGAs or other specialized hardware would gain any meaningful advantage for plot compression. Reducing plot size through bit-dropping quickly becomes impractical, as the resources required to achieve even a modest reduction escalate to nearly the same as grinding full plots. -Given these safeguards, K28 plots are expected to remain viable for the foreseeable future under the current settings. However, advancements in hardware and unexpected vulnerabilities will continue to be monitored to ensure the format's long-term stability and security. - ### What are the settings that could be changed in a hard/soft fork to prevent grinding or other techniques to turn PoSpace into PoW? [CHIP-49](https://github.com/Chia-Network/chips/pull/161) contains a detailed analysis of the various settings that can be changed to protect from grinding and other techniques. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md index 1aa8acb108d..0969983462e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md @@ -9,32 +9,69 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: -In general, the larger your farm, the more powerful your harvesters will need to be. However, keep in mind that one farm can be broken into multiple harvesters, so it is possible to run a large farm without any high-end equipment. - ## Proof Solving Times -After a proof of sufficiently high quality is found it needs to be _solved_, which reconstructs the full proof so it can be verified by others. Proof-solving hardware requirements depend on the maximum k-size in the farm. Solve times should ideally stay under 8 seconds. Plot security has been tuned for the Pi 5 to solve a k28 proof in under 8 seconds. +After a sufficiently high-quality Quality String is found, the solver reconstructs the full 128 x-values for network verification. Solve time depends on the maximum plot strength in the farm. The Pi5 solves a k=28 proof in under 8 seconds at strengths up to +4. + +| Strength | Raspberry Pi 5 | M3 Pro | Ryzen 9 9950X | +| -------- | -------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------- | +| base | ~4.3 s | ~340 ms | ~220 ms | +| +1 | ~4.5 s | ~370 ms | ~240 ms | +| +2 | ~4.9 s | ~450 ms | ~280 ms | +| +3 | ~5.7 s | ~660 ms | ~400 ms | +| +4 | ~7.3 s | ~1.1 s | ~615 ms | +| +5 | ~10 s | ~1.9 s | ~1.1 s | +| +6 | ~17 s | ~3.7 s | ~1.9 s | +| +7 | ~30 s | ~7.3 s | ~3.7 s | +| +8 | — | ~14.5 s | ~7.3 s | +| +n | — | ~2^(n−8) × 14.5 s | ~2^(n−8) × 7.3 s | + +Strengths +5 and above are capped at effective plot filter 8192 until the scheduled filter adjustments take effect. :::note See the [reference code](https://github.com/Chia-Network/pos2-chip) for benchmarking your own system on the Solver. ::: -| Plot Size | Raspberry Pi 5 | Ryzen 5600 (6-core) | Threadripper | Nvidia 3060 | -| --------- | -------------- | ------------------- | ------------ | ----------- | -| k28 | ~6.8 seconds | ~1 seconds | < 1 second | 60 ms | -| k30 | ~15.6 seconds | ~3.3 seconds | < 3 seconds | 240 ms | -| k32 | N/A | ~11.7 seconds | < 8 seconds | 960 ms | +#### HDD Activity + +HDD activity depends on plot grouping, plot strength, and disk capacity. The table below assumes 10 ms random access and 250 MB/s sequential read. Higher plot strength increases the Effective Plot Filter proportionally, reducing average load. + +| Disk Capacity | Strength (eff. plot filter) | Group Size | Max load/challenge | Avg load | Bandwidth/day | +| ------------- | -------------------------------------------------------------- | ---------- | -------------------------------------- | -------------------------------------- | ----------------------- | +| 5 TB | base (512) | 1 | ~4.48% | ~2.09% | ~42 MB | +| 5 TB | base (512) | 16 | ~0.85% | ~0.13% | ~42 MB | +| 5 TB | +1 (1024) | 16 | ~0.64% | ~0.07% | ~21 MB | +| 5 TB | +2 (2048) | 16 | ~0.43% | ~0.03% | ~10 MB | +| 5 TB | +3 (4096) | 16 | ~0.21% | ~0.01% | ~5 MB | +| 20 TB | base (512) | 1 | ~12.4% | ~8.4% | ~170 MB | +| 20 TB | base (512) | 2 | ~7.4% | ~4.2% | ~170 MB | +| 20 TB | base (512) | 16 | ~2.2% | ~0.52% | ~170 MB | +| 20 TB | base (512) | 32 | ~1.31% | ~0.27% | ~170 MB | +| 20 TB | base (512) | 64 | ~0.89% | ~0.14% | ~170 MB | +| 20 TB | base (512) | 100 | ~0.69% | ~0.09% | ~170 MB | +| 20 TB | base (512) | 1000 | ~0.47% | ~0.01% | ~170 MB | +| 100 TB | base (512) | 32 | ~3.42% | ~1.32% | ~850 MB | +| 100 TB | base (512) | 64 | ~2.15% | ~0.65% | ~850 MB | +| 100 TB | base (512) | 100 | ~1.85% | ~0.46% | ~850 MB | +| 100 TB | base (512) | 1000 | ~0.47% | ~0.05% | ~850 MB | + +Plots in a group can be assigned a `meta_group` (up to 256). The effective plot filter guarantees that grouped plots with different meta groups never pass the same challenge, reducing peak load toward the average. For example, 202 meta groups × 100 grouped plots = 20,200 plots, where peak load converges to ~0.09%. + +Total daily bandwidth is low, so even large group counts can be read well within the challenge response window. -### HDD Activity +#### Harvester Farm Size Support -Lower k-sizes increase disk activity but reduce minimum hardware requirements for proof solving (see previous section). For SSDs, k28 plots are recommended due to their minimal impact on farming performance, although large farms could benefit from larger k sizes for a proportional reduction in harvesting compute energy to process the Quality Chains. The Plot ID Filter will tune HDD disk activity to the levels shown in the table. Depending on plot filter scheduling and further security analysis we may relax these requirements to lower hdd usage levels. +Chaining Proof Fragments at challenge time is the primary CPU cost. The table below shows single-thread Pi5 limits (conservative, since the Pi5 has 4 threads and other harvester tasks are comparatively light). -| Plot Size | Full 5TiB Disk Activity | Full 20TiB Disk Activity | -| --------- | ----------------------- | ------------------------ | -| k28 | ~2.5% | ~10% | -| k30 | ~0.6% | ~2.4% | -| k32 | ~0.23% | ~0.9% | +| CPU | Avg Plot Strength | Supported Farm Size (PiB) | +| ----------------- | ----------------- | ------------------------------------------------------------------------------------ | +| Pi5 single-thread | base | 1.2 | +| Pi5 single-thread | +1 | 2.4 | +| Pi5 single-thread | +2 | 4.8 | +| Pi5 single-thread | +3 | 9.6 | +| Pi5 single-thread | +4 | 19.2 | +| Pi5 single-thread | +n | 1.2 × 2^n (capped by effective plot filter at +4) | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md index 073d84cde05..b453515daac 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md @@ -9,13 +9,13 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: ## New Proof Format -In 2024 we announced that we were developing a new Proof of Space format. This is a long-term project which is not expected to be finalized until the end of 2026. All farmers will need to replot in the year leading up to that date. This will be a gradual process, so farmers will have plenty of time to plan ahead. +In 2024 we announced that we were developing a new Proof of Space format. This is a long-term project which is not expected to be finalized until 2027. All farmers will need to replot if they want to continue farming. This will be a gradual process, so farmers will have plenty of time to plan ahead. See our [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline) for more info. :::warning @@ -27,18 +27,13 @@ While the development of this technology is ongoing, we have put together severa ## Current Blogs and CHIPs -The best place to start learning about the new Proof of Space is to read the blogs. - -- The new Proof of Space [blog](https://www.chia.net/2025/05/19/understanding-the-next-generation-proof-of-space/) -- The timelines for the new Proof of Space [blog](https://www.chia.net/2025/05/19/the-future-of-farming-is-green-and-secure/) - -To dive more into the specifications and provide your feedback please refer to the appropriate CHIPs: +The best place to start learning about the new Proof of Space is our [latest blog post](https://www.chia.net/2026/02/27/changes-coming-to-3-0/) on the topic. To dive more into the specifications and provide your feedback, please refer to the appropriate CHIPs: - The new Proof of Space [CHIP-48](https://github.com/Chia-Network/chips/pull/160) -- The timelines for the new Proof of Space [CHIP 49](https://github.com/Chia-Network/chips/pull/161) +- The timelines for the new Proof of Space [CHIP-49](https://github.com/Chia-Network/chips/pull/161) :::note -All the latest information regarding the new Proof of Space and its associated timelines can be found in those CHIPs, if you have questions that you do not feel are appropriate for the CHIPs they can be asked in our [discord server's](https://discord.gg/chia) "Plot format discussion" thread. +All the latest information regarding the new Proof of Space and its associated timelines can be found in those CHIPs. If you have questions that you do not feel are appropriate for the CHIPs they can be asked in our [Discord server's](https://discord.gg/chia) "Plot format discussion" thread. ::: We have consolidated the high level information from the CHIPs into the below documents but please take note that the CHIPs will contain the most up-to-date information: @@ -52,5 +47,10 @@ We have consolidated the high level information from the CHIPs into the below do ## Blog Archive -- A [blog post](https://www.chia.net/2024/12/11/upcoming-changes-for-chias-new-proof-of-space-format) by Dr. Nick, which takes a deep dive into the plans as of 12/11/2024 -- The original [blog post](https://www.chia.net/2024/08/08/approaching-the-next-generation-of-proof-of-space/) by Dr. Nick, which takes a deep dive into the initial plans for the new Proof Format. Note that this blog is outdated and the new blog should be used for the latest information. +These blog poss are listed in reverse chronological order. The newest posts will contain the most up-to-date information. + +- [Changes Coming to 3.0](https://www.chia.net/2026/02/27/changes-coming-to-3-0/) -- 2026-02-27 +- [Understanding the Next Generation of Proof of Space](https://www.chia.net/2025/05/19/understanding-the-next-generation-proof-of-space/) -- 2025-05-19 +- [The Future of Farming is Green and Secure](https://www.chia.net/2025/05/19/the-future-of-farming-is-green-and-secure/) -- 2025-05-19 +- [Upcoming Changes for Chia’s New Proof of Space Format](https://www.chia.net/2024/12/11/upcoming-changes-for-chias-new-proof-of-space-format) -- 2024-12-11 +- [Approaching the Next Generation of Proof of Space](https://www.chia.net/2024/08/08/approaching-the-next-generation-of-proof-of-space/) -- 2024-08-08 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md index b97d6347748..afa483c0266 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md @@ -9,35 +9,64 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: ## Plot Sizes -The new proof of space format supports plots as small as 1.6 GiB. Due to symmetric properties of the format, only even-sized k-sizes are supported. While we currently have no plans to support sizes smaller than k28, larger k-sizes may be enabled in the future. +Whereas the original Proof of Space format supported a variety of plot sizes, Proof of Space 2 only supports k28 (around 1 GB per plot). The PoS2 documentation will rarely mention k-size because only a single size is supported. Future proofing will mainly come from automatically reducing the network's base filter, as described in [CHIP-49](https://github.com/Chia-Network/chips/pull/161). -:::note -Subject to change pending final parameters. -::: +## Other Settings -| Plot Size | All RAM | -| :-------- | :------------- | -| k32 | ~10.6 GiB | -| k30 | ~4.2 GiB | -| k28 | ~1.6 GiB | +Farmers will need to choose a _strength_ for their plots, as well as a group size and an optional meta group index. Each of these settings will be documented here when the specification is finalized. For now, refer to [CHIP-48](https://github.com/Chia-Network/chips/pull/160) and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) for more details. ## Plotting Performance and Requirements -CPU plotting will be possible but will be less efficient than GPU. All times shown are for all-RAM plotting, although farmers can trade cpu RAM for temporary SSD storage, which results in slightly slower performance. +CPU plotting is supported but less efficient than GPU. All times below are for all-RAM plotting; farmers may substitute temporary SSD storage for RAM at a modest speed penalty. -:::note -Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day -::: +| | Raspberry Pi 5 8GB | Mac M3 Pro 12GB | Ryzen 5600 (6-core) | Nvidia 5090 | +| ---------------------------------------------------- | ---------------------------- | -------------------------- | -------------------------------------- | --------------------------- | +| **Time per plot** (base strength) | 240s | 60s | 30s | 2s | +| **Plotted space/day** | ~360 GiB/day | ~2 TiB/day | ~4 TiB/day | ~40 TiB/day | + +Plotting time approximately doubles with each strength increment. At lower strengths, general memory-management overhead is still a factor; at higher strengths, matching performance dominates and doubling is consistent. + +| Strength | CPU Time (s) | GPU Time (s) | +| -------- | ------------------------------- | ------------------------------- | +| base | 21.8 | 1.1 | +| +1 | 35.5 | 1.9 | +| +2 | 64.7 | 3.7 | +| +3 | 124.4 | 7.3 | +| +4 | 243.1 | 14.4 | +| +5 | 481.3 | 28.6 | +| +6 | 955.8 | 57.0 | +| +7 | 1904.7 | 113.7 | +| +8 | 3802.5 | 227.3 | + +RAM and storage requirements depend on group size: + +| # plots in group | Min CPU RAM | Min GPU RAM (optional) | Total RAM + storage needed | +| ---------------- | ----------- | ----------------------------------------- | ------------------------------ | +| 1 | 4 GB | 2 GB | 12 GB | +| 2 | 4 GB | 2 GB | 13 GB | +| 5 | 4 GB | 2 GB | 16 GB | +| 21 | 4 GB | 2 GB | 32 GB | +| 53 | 4 GB | 2 GB | 64 GB | +| 117 | 4 GB | 2 GB | 128 GB | +| 245 | 4 GB | 2 GB | 256 GB | +| 1 + n | 4 GB | 2 GB | (12 + n) GB | + +Temporary storage can substitute for RAM. At higher strengths the relative impact of swap latency decreases. + +### MacOS Virtual Memory Compression + +When plotting on a MacOS device that uses Apple silicon, there is an important OS quirk to consider. As part of their unified memory approach, MacOS uses Virtual Memory Compression to "compress" programs in memory when they are inactive, and then decompress them when they are accessed again. Compression often begins when the program is closed. + +Virtual Memory Compression allows Apple silicon to use less RAM than its Intel counterparts in many situations. However, for Chia plotting, it degrades performance. Chia's plotting applications are designed to pull from as much available RAM as possible in order to speed up the process of creating a plot. The first time you open a plotting application after a fresh reboot, RAM is allocated as expected. When the application is closed, the OS remembers that it requires several GB of RAM. The next time the application is opened, the process is compressed in RAM, which degrades performance. + +For more info about Virtual Memory Compression, see Apple's [Memory Usage Performance Guidelines](https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html). This [blog post](https://blog.greggant.com/posts/2024/07/03/macos-memory-management.html) also explains what is happening at a high level. + +Unfortunately, CNI has no control over how memory is managed on MacOS. Fortunately, there's an easy fix for this issue. In order to avoid Virtual Memory Compression when running any plotting tools, only start the application after a fresh reboot. If this is the first time the application has been run since rebooting, MacOS will not have a record of how much memory is required to run it, so Virtual Memory Compression won't be applied. As long as the application remains open, it can continue to create plots without the application being compressed or decompressed. If you close the application, then you should reboot before running it again. -| Plot Size | RAM Requirement | Raspberry Pi 5 | Ryzen 5600 (6-core) | Nvidia 3090 | -| --------------------- | ----------------- | -------------- | ------------------- | ----------------------------- | -| k28 | - GiB (min - MiB) | ~- minutes | ~- minutes | ~ seconds _(min - MiB VRAM)_ | -| k30 | - GiB (min - MiB) | N/A | ~- minutes | ~- seconds _(min - MiB VRAM)_ | -| k32 | - GiB (min - GiB) | N/A | ~- hours | ~- minutes _(min - GiB VRAM)_ | -| **Plotted space/day** | — | Up to - GiB | Up to - GiB | Up to - TiB | +The quirk described in this section only applies to MacOS. Windows and Linux systems are unaffected. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md index a1d09268336..216235d898e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md @@ -9,16 +9,16 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. -For the latest information, refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161) +This information was updated on March 3, 2026. +For the latest information, refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161). ::: This table gives a _rough_ timeline of what to expect with the new format. We will know the exact timeline (to within a few days) when we enter the locked in period. -| Time frame | Name | Begins when | Ends when | Description | -| :----------------------- | :---------------------- | :------------------------------- | :------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1H 2024 -
2H 2025 | Proposal
period | New format
announced | Chia 3.0
released | \* [CHIP-48](https://github.com/Chia-Network/chips/pull/160) and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) released
\* Feedback welcome | -| 2H 2025 -
1H 2026 | Locked in
period | Chia 3.0
released | Hard fork
activated | \* CHIP is finalized
\* Farmers must upgrade to 3.0
\* Only old plots are valid | -| 1H 2026 -
1H 2027 | Replotting
period | Hard fork
activated | Old format
becomes invalid | \* New plots become valid
\* Old plots remain valid
\* Replot during this period | -| 2H 2027
and beyond | A new era | Old format
becomes invalid | - | \* Only new plots are valid | +| Time frame | Name | Begins when | Ends when | Description | +| :-------------------------------------------------------------------- | :---------------------- | :-------------------------------------- | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 1H 2024 -
1H 2026 | Proposal
period | New format
announced | Chia 3.0
released | \* [CHIP-48](https://github.com/Chia-Network/chips/pull/160) and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) released
\* Feedback welcome | +| 1H 2026 -
Nov 2026 (block `9'562'000`) | Locked in
period | Chia 3.0
released | Hard fork
activated | \* CHIPs are finalized
\* Farmers must upgrade to 3.0
\* Only old plots are valid | +| Nov 2026 -
Jun/Jul 2027 (block `10'741'648`) | Replotting
period | Hard fork
activated | Old format
becomes invalid | \* New plots become valid
\* Old plots remain valid
\* Replot during this period | +| 2H 2027
and beyond | A new era | Old format
becomes invalid | - | \* Only new plots are valid | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/constants-variables-notation.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/constants-variables-notation.md index bd6c68a7d53..9e20289ba8e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/constants-variables-notation.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/constants-variables-notation.md @@ -8,29 +8,29 @@ slug: /chia-blockchain/green-paper/constants-variables-notation ## 0.1 重要常数 -| 常数 | Description | -| ----------- | ------------------------------------------ | -| 10分钟 | target **duration of a sub-slot** | +| 常数 | Description | +| -------- | ------------------------------------------ | +| 10分钟 | target **duration of a sub-slot** | | 32个区块 | target **number of blocks per sub-slot** | -| 16/64个区块 | 每个时隙的最小/最大区块数量 | +| 16/64个区块 | 每个时隙的最小/最大区块数量 | | 4608个区块 | average number of **blocks per epoch** | | 384个区块 | average number of **blocks per sub-epoch** | -| 64个签名点 | number of **signage points per sub-slot** | +| 64个签名点 | number of **signage points per sub-slot** | 由上可得以下结论： -| 隐含的常数 | Description | -| ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| 1天 | **target time of an epoch** is $$10 {\ \sf min}\cdot\frac{4608{\ \sf blocks}}{32\ \sf blocks}=1440{\ \sf min}\quad (=1{ \sf day})$$ | -| 2小时 | **target time of sub-epoch** | -| 18.75秒 | **target average block arrival time** is $\frac{10{\sf\ min}}{32}=18.75 {\sf\ sec}$ | -| 9.375秒 | **target time between signage points** is $\frac{600}{64}=9.375 {\sf\ sec}$ | +| 隐含的常数 | Description | +| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| 1天 | **target time of an epoch** is $$10 {\ \sf min}\cdot\frac{4608{\ \sf blocks}}{32\ \sf blocks}=1440{\ \sf min}\quad (=1{ \sf day})$$ | +| 2小时 | **target time of sub-epoch** | +| 18.75秒 | **target average block arrival time** is $\frac{10{\sf\ min}}{32}=18.75 {\sf\ sec}$ | +| 9.375秒 | **target time between signage points** is $\frac{600}{64}=9.375 {\sf\ sec}$ | ## 0.2 重要变量 -| 变量 | Description | -| ------------------ | -------------------------------------------------------------------------------- | -| $D\in{\mathbb N}$ | 难度参数。 每个纪元重新校准一次，以满足每个时隙（slot）32个区块的目标 | +| 变量 | Description | +| ------------------ | ------------------------------------------- | +| $D\in{\mathbb N}$ | 难度参数。 每个纪元重新校准一次，以满足每个时隙（slot）32个区块的目标 | | $T\in {\mathbb N}$ | 时间参数（子时隙的VDF步数）。 每个纪元重新校准一次，以满足每个子时隙10分钟的目标 | ## 0.3 提示 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-abstract.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-abstract.md index 9f0a8084d3b..61414f5c346 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-abstract.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-abstract.md @@ -14,7 +14,7 @@ slug: /chia-blockchain/green-paper/green-paper-abstract 本文不是 $\textrm{{\sf Chia}}$ 的正式规范。 相反，它面向那些希望理解 $\textrm{{\sf Chia}}$ 共识设计选择的读者，以及对来自高效证明系统的无需许可的最长链区块链感兴趣的人。 -[Green Paper PDF](https://docs.chia.net/files/ChiaGreenPaper_20241008.pdf) - updated October 8, 2024 +[Green Paper PDF](https://docs.chia.net/files/ChiaGreenPaper_20260612.pdf) - updated June 12, 2026 --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-introduction.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-introduction.md index f123fccacdf..ee93ad0b837 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-introduction.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-introduction.md @@ -53,7 +53,7 @@ On the other hand, we make no assumptions about the number of VDFs controlled by This assumption comes at a price: there's a $1.47$ factor by which the adversarial resources are multiplied in eq.(2). This factor is there due to an attack we call "double dipping". This and other attacks will be discussed in §2. For now let us just mention that there's nothing special about the constant $1.47$, it can be lowered to $1+\epsilon$ for any $\epsilon>0$ by increasing the number of blocks that depend on the same challenge (in $\textsf{Chia}$ this is set to at least 16). -The bound in eq.(1) is not tight in the sense that we don't have an attack that works if we replace "$>$" with "$<$". We have an attack assuming giving the adversary a slightly lower boosting factor of $1.34$ +The bound in eq.(2) is not tight in the sense that we don't have an attack that works if we replace "$>$" with "$<$". We have an attack assuming giving the adversary a slightly lower boosting factor of $1.34$ $$ \textrm{double spending in {\sf Chia}\ possible if : }space_h\cdot vdf_h < space_a \cdot vdf_a \cdot 1.34 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-references.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-references.md index ab351b885b0..73e36fe610a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-references.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-references.md @@ -6,35 +6,35 @@ slug: /chia-blockchain/green-paper/green-paper-references # References -| Identifier | Publication | -| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Identifier | Publication | +| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AAC+17 | Hamza Abusalah, Joël Alwen, Bram Cohen, Danylo Khilko, Krzysztof Pietrzak, and Leonid Reyzin. Beyond Hellman’s time-memory trade-offs with applications to proofs of space. In Tsuyoshi Takagi and Thomas Peyrin, editors, _Advances in Cryptology - ASI- ACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II_, volume 10625 of _Lecture Notes in Computer Science_, pages 357–379. Springer, 2017. | -| BBBF18 | Dan Boneh, Joseph Bonneau, Benedikt Bu ̈nz, and Ben Fisch. Verifiable delay functions. In Hovav Shacham and Alexandra Boldyreva, editors, _Advances in Cryptology - CRYPTO 2018 - 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2018, Proceedings, Part I, volume 10991 of Lecture Notes in Computer Science_, pages 757–788. Springer, 2018. | -| BBF18 | Dan Boneh, Benedikt Bu ̈nz, and Ben Fisch. A survey of two verifi- able delay functions. _IACR Cryptol. ePrint Arch._, page 712, 2018. | +| BBBF18 | Dan Boneh, Joseph Bonneau, Benedikt Bu ̈nz, and Ben Fisch. Verifiable delay functions. In Hovav Shacham and Alexandra Boldyreva, editors, _Advances in Cryptology - CRYPTO 2018 - 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2018, Proceedings, Part I, volume 10991 of Lecture Notes in Computer Science_, pages 757–788. Springer, 2018. | +| BBF18 | Dan Boneh, Benedikt Bu ̈nz, and Ben Fisch. A survey of two verifi- able delay functions. _IACR Cryptol. ePrint Arch._, page 712, 2018. | | BDK+19 | Vivek Bagaria, Amir Dembo, Sreeram Kannan, Sewoong Oh, David Tse, Pramod Viswanath, Xuechao Wang, and Ofer Zeitouni. Proof- of-stake longest chain protocols: Security vs predictability. 2019. | -| BGK+18 | Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability. In David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang, editors, _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018_, pages 913–930. ACM, 2018. | -| BNPW19 | Jonah Brown-Cohen, Arvind Narayanan, Alexandros Psomas, and S. Matthew Weinberg. Formal barriers to longest-chain proof-of-stake protocols. In Anna Karlin, Nicole Immorlica, and Ramesh Johari, editors, _Proceedings of the 2019 ACM Conference on Economics and Computation, EC 2019, Phoenix, AZ, USA, June 24-28, 2019_, pages 459–473. ACM, 2019. | -| BP22 | Mirza Ahad Baig and Krzysztof Pietrzak. On the existence of proof of space longest chain protocols (working title), 2022. 2022. Manuscript in preparation. | -| CKWN16 | Miles Carlsten, Harry A. Kalodner, S. Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Edgar R. Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew C. Myers, and Shai Halevi, editors, _Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016_, pages 154–167. ACM, 2016. | -| CP19 | Bram Cohen and Krzysztof Pietrzak. The chia network blockchain. 2019. | +| BGK+18 | Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability. In David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang, editors, _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018_, pages 913–930. ACM, 2018. | +| BNPW19 | Jonah Brown-Cohen, Arvind Narayanan, Alexandros Psomas, and S. Matthew Weinberg. Formal barriers to longest-chain proof-of-stake protocols. In Anna Karlin, Nicole Immorlica, and Ramesh Johari, editors, _Proceedings of the 2019 ACM Conference on Economics and Computation, EC 2019, Phoenix, AZ, USA, June 24-28, 2019_, pages 459–473. ACM, 2019. | +| BP22 | Mirza Ahad Baig and Krzysztof Pietrzak. On the existence of proof of space longest chain protocols (working title), 2022. 2022. Manuscript in preparation. | +| CKWN16 | Miles Carlsten, Harry A. Kalodner, S. Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Edgar R. Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew C. Myers, and Shai Halevi, editors, _Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016_, pages 154–167. ACM, 2016. | +| CP19 | Bram Cohen and Krzysztof Pietrzak. The chia network blockchain. 2019. | | DFKP15 | Stefan Dziembowski, Sebastian Faust, Vladimir Kolmogorov, and Krzysztof Pietrzak. Proofs of space. In Rosario Gennaro and Matthew Robshaw, editors, _Advances in Cryptology - CRYPTO 2015 - 35th Annual Cryptology Conference, Santa Barbara, CA, USA, August 16-20, 2015, Proceedings, Part II, volume 9216 of Lecture Notes in Computer Science_, pages 585–605. Springer, 2015. | -| DKT21 | Soubhik Deb, Sreeram Kannan, and David Tse. Posat: Proof-of-work availability and unpredictability, without the work. In Nikita Borisov and Claudia Diaz, editors, _Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part II, volume 12675 of Lecture Notes in Computer Science_, pages 104–128. Springer, 2021. | +| DKT21 | Soubhik Deb, Sreeram Kannan, and David Tse. Posat: Proof-of-work availability and unpredictability, without the work. In Nikita Borisov and Claudia Diaz, editors, _Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part II, volume 12675 of Lecture Notes in Computer Science_, pages 104–128. Springer, 2021. | | DW13 | Christian Decker and Roger Wattenhofer. Information propagation in the bitcoin network. In _13th IEEE International Conference on Peer-to-Peer Computing, IEEE P2P 2013, Trento, Italy, September 9-11, 2013_, Proceedings, pages 1–10. IEEE, 2013. | | EFKP20 | Naomi Ephraim, Cody Freitag, Ilan Komargodski, and Rafael Pass. Continuous verifiable delay functions. In Anne Canteaut and Yuval Ishai, editors, _Advances in Cryptology - EUROCRYPT 2020 - 39th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10-14, 2020, Proceedings, Part III_, volume 12107 of _Lecture Notes in Computer Science_, pages 125–154. Springer, 2020. | -| ES18 | Ittay Eyal and Emin Gu ̈n Sirer. Majority is not enough: bitcoin mining is vulnerable. _Commun_. ACM, 61(7):95–102, 2018. | -| FZ17 | Lei Fan and Hong-Sheng Zhou. iching: A scalable proof-of-stake blockchain in the open setting (or, how to mimic nakamoto’s design via proof-of-stake). _IACR Cryptol. ePrint Arch._, page 656, 2017. | -| GKL15 | Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In Elisabeth Oswald and Marc Fischlin, editors, _Advances in Cryptology - EUROCRYPT 2015 - 34th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Sofia, Bulgaria, April 26-30, 2015, Proceedings, Part II_, volume 9057 of _Lecture Notes in Computer Science_, pages 281–310. Springer, 2015. | +| ES18 | Ittay Eyal and Emin Gu ̈n Sirer. Majority is not enough: bitcoin mining is vulnerable. _Commun_. ACM, 61(7):95–102, 2018. | +| FZ17 | Lei Fan and Hong-Sheng Zhou. iching: A scalable proof-of-stake blockchain in the open setting (or, how to mimic nakamoto’s design via proof-of-stake). _IACR Cryptol. ePrint Arch._, page 656, 2017. | +| GKL15 | Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In Elisabeth Oswald and Marc Fischlin, editors, _Advances in Cryptology - EUROCRYPT 2015 - 34th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Sofia, Bulgaria, April 26-30, 2015, Proceedings, Part II_, volume 9057 of _Lecture Notes in Computer Science_, pages 281–310. Springer, 2015. | | GKR18 | Peter Gazi, Aggelos Kiayias, and Alexander Russell. Stake-bleeding attacks on proof-of-stake blockchains. In _Crypto Valley Conference on Blockchain Technology, CVCBT 2018, Zug, Switzerland, June 20-22, 2018_, pages 85–92. IEEE, 2018. | -| Hel80 | Martin E. Hellman. A cryptanalytic time-memory trade-off. _IEEE Trans. Inf. Theory_, 26(4):401–406, 1980. | +| Hel80 | Martin E. Hellman. A cryptanalytic time-memory trade-off. _IEEE Trans. Inf. Theory_, 26(4):401–406, 1980. | | Lew21 | Andrew Lewis-Pye. Byzantine generals in the permissionless setting. _CoRR_, abs/2101.07095, 2021. | | LR21 | Andrew Lewis-Pye and Tim Roughgarden. How does blockchain security dictate blockchain implementation? In Yongdae Kim, Jong Kim, Giovanni Vigna, and Elaine Shi, editors, _CCS ’21: 2021 ACM SIGSAC Conference on Computer and Communications Security, Virtual Event, Republic of Korea, November 15 - 19, 2021_, pages 1006–1019. ACM, 2021. | -| Pie19a | Krzysztof Pietrzak. Proofs of catalytic space. In Avrim Blum, editor, _10th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA_, volume 124 of LIPIcs, pages 59:1–59:25. Schloss Dagstuhl - Leibniz- Zentrum für Informatik, 2019. | -| Pie19b | Krzysztof Pietrzak. Simple verifiable delay functions. In Avrim Blum, editor, 1*0th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA*, volume 124 of LIPIcs, pages 60:1–60:15. Schloss Dagstuhl - Leibniz-Zentrum fu ̈r Informatik, 2019. | -| PKF+18 | Sunoo Park, Albert Kwon, Georg Fuchsbauer, Peter Gazi, Joël Alwen, and Krzysztof Pietrzak. Spacemint: A cryptocurrency based on proofs of space. In Sarah Meiklejohn and Kazue Sako, editors, _Financial Cryptography and Data Security - 22nd International Conference, FC 2018, Nieuwpoort, Cura ̧cao, February 26 - March 2, 2018, Revised Selected Papers_, volume 10957 of _Lecture Notes in Computer Science_, pages 480–499. Springer, 2018. | +| Pie19a | Krzysztof Pietrzak. Proofs of catalytic space. In Avrim Blum, editor, _10th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA_, volume 124 of LIPIcs, pages 59:1–59:25. Schloss Dagstuhl - Leibniz- Zentrum für Informatik, 2019. | +| Pie19b | Krzysztof Pietrzak. Simple verifiable delay functions. In Avrim Blum, editor, 1_0th Innovations in Theoretical Computer Science Conference, ITCS 2019, January 10-12, 2019, San Diego, California, USA_, volume 124 of LIPIcs, pages 60:1–60:15. Schloss Dagstuhl - Leibniz-Zentrum fu ̈r Informatik, 2019. | +| PKF+18 | Sunoo Park, Albert Kwon, Georg Fuchsbauer, Peter Gazi, Joël Alwen, and Krzysztof Pietrzak. Spacemint: A cryptocurrency based on proofs of space. In Sarah Meiklejohn and Kazue Sako, editors, _Financial Cryptography and Data Security - 22nd International Conference, FC 2018, Nieuwpoort, Cura ̧cao, February 26 - March 2, 2018, Revised Selected Papers_, volume 10957 of _Lecture Notes in Computer Science_, pages 480–499. Springer, 2018. | | PS17 | Rafael Pass and Elaine Shi. The sleepy model of consensus. In Tsuyoshi Takagi and Thomas Peyrin, editors, _Advances in Cryptology - ASIACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II_, volume 10625 of _Lecture Notes in Computer Science_, pages 380–409. Springer, 2017. | -| SNM+21 | Caspar Schwarz-Schilling, Joachim Neu, Barnab ́e Monnot, Aditya Asgaonkar, Ertem Nusret Tas, and David Tse. Three attacks on proof-of-stake ethereum. _IACR Cryptol. ePrint Arch._, page 1413, 2021. | +| SNM+21 | Caspar Schwarz-Schilling, Joachim Neu, Barnab ́e Monnot, Aditya Asgaonkar, Ertem Nusret Tas, and David Tse. Three attacks on proof-of-stake ethereum. _IACR Cryptol. ePrint Arch._, page 1413, 2021. | | SSZ15 | Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal selfish mining strategies in bitcoin. _CoRR_, abs/1507.06183, 2015. | -| Wes20 | Benjamin Wesolowski. Efficient verifiable delay functions. _J. Cryptol._, 33(4):2113–2147, 2020. | +| Wes20 | Benjamin Wesolowski. Efficient verifiable delay functions. _J. Cryptol._, 33(4):2113–2147, 2020. | ## Additional Reading diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/hash-and-vdf-chains.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/hash-and-vdf-chains.md index 7d1671c022b..781ed860a7a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/hash-and-vdf-chains.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/hash-and-vdf-chains.md @@ -68,7 +68,7 @@ VDF chains give two basic security guarantees, the first is immutability analogo --- -**Proposition 3** (immutability and sequentiality of VDF chains). _Like a hash chain, a VDF chain is \_immutable_ in the sense that it's computationally infeasible to come up with two different VDF chains\_ +**Proposition 3** (immutability and sequentiality of VDF chains). _Like a hash chain, a VDF chain is _immutable_ in the sense that it's computationally infeasible to come up with two different VDF chains_ $$ {\cal V}=z_0,\tau_1,z_1,\tau_2,z_2,\ldots,\tau_\ell diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/recovering-from-51-percent-attacks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/recovering-from-51-percent-attacks.md index e87b9cbe735..0a8ee8b0c99 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/recovering-from-51-percent-attacks.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/recovering-from-51-percent-attacks.md @@ -13,10 +13,11 @@ We discussed in §2 the main security issues of a PoSpace based longest-chain b {' '}
- + ![](/img/green-paper/table-1.png)
Table 1: Summary of the ability to heal from malicious majority and provide security under dynamic availability of longest-chain protocols based various proof systems.
+
## 6.1 Recovery from $51\%$ Attacks @@ -72,11 +73,11 @@ A longest-chain protocol using only PoSpace (like Spacemint [14 (sometimes shown as UBER of 10-14). This means that if a consumer reads on 800TB of data, they would expect a single read error on average. -| Device | UBER | Data read per error | -| -------------- | ------ | ------------------- | +| Device | UBER | Data read per error | +| -------------- | ------- | ------------------- | | Consumer HDD | 10\-14 | 800 TB | | Enterprise HDD | 10\-15 | 8 PB | | SSD | 10\-17 | 800 PB | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/faq.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/faq.md index 694073fc0ec..0007e7cbf1a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/faq.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/faq.md @@ -32,7 +32,7 @@ A genesis challenge is the first VDF challenge on a network that uses the Proof ### What is XCH, TXCH, and mojos? -XCH is the currency symbol for Chia. TXCH is the currency symbol currently being used for testnet chias. TXCH has no value and is only used for testing purposes. Chias and testnet chias can be divided up to 12 decimal places (trillionths). The smallest unit of chia, a trillionth of a chia, is called a mojo, as a tribute to [Mojo Nation](), a decentralized file storage platform created in the early 2000s by Zooko Wilcox, Bram Cohen, and others. +XCH is the currency symbol for Chia. TXCH is the currency symbol currently being used for testnet chias. TXCH has no value and is only used for testing purposes. Chias and testnet chias can be divided up to 12 decimal places (trillionths). The smallest unit of chia, a trillionth of a chia, is called a mojo, as a tribute to [Mojo Nation](https://en.wikipedia.org/wiki/Mnet_(peer-to-peer_network)#Evil_Geniuses_for_a_Better_Tomorrow), a decentralized file storage platform created in the early 2000s by Zooko Wilcox, Bram Cohen, and others. ### Chia vs XCH vs mojo vs chia @@ -101,17 +101,17 @@ After the Chia pre-farm, Chia offers farming rewards of 64 chia every 10 minutes The Chia Blockchain comes together from a few different repositories: -| Repository | Contents | -| -------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | -| [chia-blockchain](https://github.com/Chia-Network/chia-blockchain) | Consensus code, networking, and reference Chialisp implementations. | -| [chia-blockchain-gui](https://github.com/Chia-Network/chia-blockchain-gui) | An Electron/React graphical user interface to the plotter, node, and wallets. | -| [clvm](https://github.com/Chia-Network/clvm) | Chialisp Virtual Machine in Python | -| [clvm-rs](https://github.com/Chia-Network/clvm_rs) | Chialisp Virtual Machine in Rust for security and performance. | -| [chiapos](https://github.com/Chia-Network/chiapos) | Creating plots and verifying Proofs of Space. | -| [chiavdf](https://github.com/Chia-Network/chiavdf) | Proofs of time/VDFs and Timelords. | -| [bls-signatures](https://github.com/Chia-Network/bls-signatures) | IETF standard BLS-12-381 signature scheme. | -| [clvm_tools](https://github.com/Chia-Network/clvm_tools) | Tools for Chialisp and CLVM. | -| [Chia Network Organization](https://github.com/Chia-Network) | Contains all of the public Chia repos released by Chia Network | +| Repository | Contents | +| ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | +| [chia-blockchain](https://github.com/Chia-Network/chia-blockchain) | Consensus code, networking, and reference Chialisp implementations. | +| [chia-blockchain-gui](https://github.com/Chia-Network/chia-blockchain-gui) | An Electron/React graphical user interface to the plotter, node, and wallets. | +| [clvm](https://github.com/Chia-Network/clvm) | Chialisp Virtual Machine in Python | +| [clvm-rs](https://github.com/Chia-Network/clvm_rs) | Chialisp Virtual Machine in Rust for security and performance. | +| [chiapos](https://github.com/Chia-Network/chiapos) | Creating plots and verifying Proofs of Space. | +| [chiavdf](https://github.com/Chia-Network/chiavdf) | Proofs of time/VDFs and Timelords. | +| [bls-signatures](https://github.com/Chia-Network/bls-signatures) | IETF standard BLS-12-381 signature scheme. | +| [clvm_tools](https://github.com/Chia-Network/clvm_tools) | Tools for Chialisp and CLVM. | +| [Chia Network Organization](https://github.com/Chia-Network) | Contains all of the public Chia repos released by Chia Network | ### When did Chia launch mainnet? @@ -562,19 +562,19 @@ We strongly urge using a fast ssd to store the blockchain database. Using a slow 1. Stop all chia processes. 2. Locate the database file you want to move. - Blockchain db: `~/.chia/mainnet/db/blockchain_v2_CHALLENGE.sqlite` - - Wallet db: `~/.chia/mainnet/wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite`\ - **Note:** `CHALLENGE` will either be mainnet or testnet based on your selected network.\ + - Wallet db: `~/.chia/mainnet/wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite` + **Note:** `CHALLENGE` will either be mainnet or testnet based on your selected network. **Note:** `KEY` will be the fingerprint of your wallet. 3. Copy the database file(s) you want to move to their new location. 4. Update the applicable config.yaml parameters from the table below. - Config file: `~/.chia/mainnet/config/config.yaml` -| Database | Config.yaml Parameter | Default | New Location | -| --------------------- | -------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------ | -| Blockchain | full_node: database_path: | db/blockchain_v1_CHALLENGE.sqlite | \/db/blockchain_v1_CHALLENGE.sqlite | -| Blockchain peer table | full_node: peer_db_path: | db/peer_table_node.sqlite | \/db/peer_table_node.sqlite | -| Wallet | wallet: database_path: | wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite | \/wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite | -| Wallet peer table | wallet: wallet_peers_path: | wallet/db/wallet_peers.sqlite | \/wallet/db/wallet_peers.sqlite | +| Database | Config.yaml Parameter | Default | New Location | +| --------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Blockchain | full_node: database_path: | db/blockchain_v1_CHALLENGE.sqlite | \/db/blockchain_v1_CHALLENGE.sqlite | +| Blockchain peer table | full_node: peer_db_path: | db/peer_table_node.sqlite | \/db/peer_table_node.sqlite | +| Wallet | wallet: database_path: | wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite | \/wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite | +| Wallet peer table | wallet: wallet_peers_path: | wallet/db/wallet_peers.sqlite | \/wallet/db/wallet_peers.sqlite | **Note:** This information has been adapted from the [Spacefarmers guide](https://wiki.spacefarmers.io/guides/farming/movedb). @@ -1361,6 +1361,16 @@ Chia Friends was an airdrop of 10,000 NFTs. While Chia Network Inc gave these NF The Holiday 21 tokens were an airdrop of CATs for farmers who farmed a block in 2021. These tokens are redeemable for a Holiday NFT until November 10th, 2023. For more information please refer to our blog article about the Holiday NFTs. These tokens are redeemable for a Holiday NFT until November 10th, 2023. For more information please refer to our blog article about the [Holiday NFTs](https://www.chia.net/2022/12/08/the-holiday-nfts-are-here/). +### Can I still redeem my CH21 token? + +The CH21 token had two redemption options: + +1. **Holiday 2021 NFT** - The NFT redemption window closed on November 10, 2023. + +2. **Chia Store discount (10% off)** - The Chia Store discount redemption at [ch21.chia.net](https://ch21.chia.net) will close on **April 30, 2026**. + +After April 30, 2026, CH21 tokens will no longer be redeemable for any goods or discounts from Chia Network. Unredeemed tokens will remain in your wallet and can be traded on the secondary market. For background on the original airdrop, see the [Happy Holidays from Chia!](https://www.chia.net/2021/12/21/happy-holidays-from-chia/) blog post. + ### Can I donate directly to the Marmot Recovery Foundation? You sure can! [The Marmot Recovery Foundation website](http://marmots.org/how-you-can-help/donate-now/) lists a variety of ways to donate to the cause of saving the Vancouver Island marmot from extinction. @@ -1543,14 +1553,13 @@ values={[ (Be sure to use powershell and update <username> to match the name of the user that installed Chia.)If installed just for your user:```powershell Set-Alias -Name chia "C:\Users\ - -```` +``` If installed just for your user: ```powershell Set-Alias -Name chia "C:\Users\\AppData\Local\Programs\Chia\resources\app.asar.unpacked\daemon\chia.exe" -```` +``` If installed for all users: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/analysis.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/analysis.md new file mode 100644 index 00000000000..7cf6b612de3 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/analysis.md @@ -0,0 +1,39 @@ +--- +title: Generator Identity Analysis +slug: /chia-blockchain/resources/generator-identity/analysis +--- + +This document has been abridged. The original, complete version can be found on [GitHub](https://github.com/richardkiss/generator-identity-hf-analysis). + +# Generator Identity Hard Fork: Analysis + +This is an analysis of the Generator Identity Hard Fork, which transitions generator identity and cost calculation from serialization-based to content-addressable methods. + +## Overview + +The Generator Identity Hard Fork makes two fundamental changes: + +| Aspect | Before | After | +| -------------- | -------------------------- | ------------------------ | +| **Identity** | `SHA256(serialized_bytes)` | `SHA256_tree_hash(tree)` | +| **Cost basis** | Serialized length | Interned tree structure | + +This decouples consensus from serialization format, enabling future compression improvements without hard forks. + +## Documentation + +| Document | Description | +| ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | +| **[Technical Specification](/chia-blockchain/resources/generator-identity/technical-specification)** | Complete design: problem statement, cost formula derivation, DoS analysis, implementation details | +| **[Gist](/chia-blockchain/resources/generator-identity/github-gist)** | GitHub Gist describing the proposal | +| [GitHub repository](https://github.com/richardkiss/generator-identity-hf-analysis) | Contains the complete analysis and implementation | + +## Implementation PRs + +| PR | Repository | Branch | Description | +| ------ | ----------------------------------------------------------------------- | ----------------------- | --------------------------------------------------------- | +| **#1** | [clvm_rs](https://github.com/Chia-Network/clvm_rs) | `generator-identity-hf` | Core interning infrastructure | +| **#2** | [chia_rs](https://github.com/Chia-Network/chia_rs) | `generator-identity-hf` | Chia-specific cost calculation | +| **#3** | [clvm_rs](https://github.com/Chia-Network/clvm_rs) | `serde_2026` | New serialization format (future work) | + +PR #2 depends on PR #1. PR #3 is independent. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/github-gist.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/github-gist.md new file mode 100644 index 00000000000..953aeec263e --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/github-gist.md @@ -0,0 +1,536 @@ +--- +title: Generator Identity GitHub Gist +slug: /chia-blockchain/resources/generator-identity/github-gist +--- + +The original copy of this document can be found on [GitHub](https://gist.github.com/richardkiss/59389ac2f96dd0665f2d7815baa7b30f). + +# Generator Identity and Cost Hard Fork: Complete Summary + +This document provides a comprehensive overview of the hard fork that transitions generator identity and cost calculation from serialization-based to content-addressable (tree-structure-based) methods. + +## Executive Summary + +This hard fork makes two fundamental changes to how generators are identified and charged: + +1. **Identity**: Generator identity changes from `SHA256(serialized_bytes)` to `SHA256_tree_hash(generator)` (content-addressable) +2. **Cost**: Generator cost changes from `len(serialized_bytes) × 12000` to a blended formula based on interned tree structure + +Both changes serve the same goal: **make consensus depend on the logical content of the generator, not its serialization format**. This decouples consensus from serialization, enabling future compression improvements without hard forks. + +--- + +## The Problem: Serialization-Coupled Consensus + +### Current State + +Today, generator identity and cost are both tied to serialization: + +``` +identity = SHA256(serialized_bytes) +cost = len(serialized_bytes) × COST_PER_BYTE (12000) +``` + +This creates several problems: + +1. **Format lock-in**: Any change to serialization format changes the generator's identity, breaking consensus compatibility. +2. **Compression penalties**: Better compression → smaller bytes → different hash. A more efficient representation of the *same logical tree* would have a different identity. +3. **Cost inconsistency**: The same logical tree serialized differently would have different costs, even though the actual work to process it is identical. + +### The Solution: Content-Addressable Identity + +After the hard fork: + +``` +identity = SHA256_tree_hash(generator) // Content-addressable +cost = f(interned_tree_structure) // Structure-based +``` + +**Key insight**: Two generators with the same tree hash contain the same logical content. They should have the same identity and cost, regardless of how they were serialized. + +This means: + +- Classic serialization (no compression) +- Backref serialization (some sharing) +- 2026 serialization (full interning) +- Future formats we haven't invented yet + +...can all represent the same generator with the **same identity and same cost**. + +--- + +## Interning: The Canonical Representation + +To ensure `same content = same cost`, we must **intern** the generator before computing cost: + +``` +Any serialization → deserialize → intern → canonical tree → deterministic cost +``` + +### What is Interning? + +**Interning** deduplicates a CLVM tree based on structural equality, an equivalence relation defined recursively: + +- **Atoms** are equal if their byte contents are identical +- **Pairs** are equal if their left children are equal AND their right children are equal (recursively) + +After interning, each equivalence class is represented by exactly one node. The cost formula counts each unique atom and pair once, making the result deterministic regardless of serialization format or how many times a subtree appears in the original tree. + +### Relationship to Tree Hash + +Structural equality implies tree hash equality (by definition of SHA256 tree hash). The reverse is not mathematically guaranteed, but holds in practice—a counterexample would require a SHA256 collision. + +### Block Validation Requirement + +**Critical**: Validation must start from the **interned** generator. Consensus enforces limits on atoms and pairs created; different serializations of the same logical generator could otherwise evade those limits. Using the canonical interned tree guarantees the atom/pair limits and cost calculation are applied to the same logical content for every validator. + +--- + +## The New Cost Formula + +### Why Not Just Use Serialized Size? + +With content-addressable identity, we can't use serialized size for cost because: + +1. Different serializations of the same tree would have different costs +2. We want `same tree hash = same cost` + +We need a cost formula based on the **interned tree structure**. + +### The Blended Formula + +``` +size_component = B×atom_bytes + A×atom_count + P×pair_count +sha_component = S×sha_blocks + I×sha_invocations + +total_cost = size_component × SIZE_COST_PER_BYTE + + sha_component × SHA_COST_PER_UNIT +``` + +**Constants:** + +| Constant | Value | Purpose | +| --------------------------------------------------------------------------------- | ----- | ---------------------------------------------- | +| B | 1 | Per byte of atom data | +| A | 2 | Per-atom overhead | +| P | 2 | Per-pair overhead | +| S | 1 | Per SHA256 block (64 bytes) | +| I | 8 | Per SHA256 invocation | +| SIZE_COST_PER_BYTE | 6000 | Size component multiplier | +| SHA_COST_PER_UNIT | 4500 | SHA component multiplier | + +### Why Two Components? + +The formula protects against **two distinct DoS vectors**: + +**1. Memory/Storage DoS** + +- Attack: Create structures expensive to store but cheap to hash +- Protection: Size component charges for structural overhead + +**2. CPU/Hashing DoS** + +- Attack: Create structures with many small nodes (cheap in bytes, expensive to hash) +- Protection: SHA component charges for hashing work + +By splitting ~50/50, neither attack vector can exploit the other's blind spot. + +### Why SHA Invocation Cost Matters + +SHA256 has significant per-invocation overhead beyond the per-block mixing cost: + +| 硬件 | Per Block | Per Invocation | Ratio | +| ---------- | --------- | -------------- | -------------------- | +| Apple M4 | 19 ns | 151 ns | 7.9× | +| Intel 2012 | 520 ns | 3,465 ns | 6.7× | + +A tree with 1000 tiny atoms incurs 1000 invocations regardless of total bytes. Without the `I=8` coefficient, such structures would be severely undercharged. + +**Note**: The I=8 ratio is based on hardware-accelerated SHA256 (SHA-NI on x86, crypto extensions on ARM). Software SHA256 has a much lower I/S ratio (~0.07), but we use I=8 to: + +1. Future-proof for when hardware acceleration is enabled +2. Protect against cross-platform DoS attacks +3. Maintain consistency across different hardware + +--- + +## DoS Analysis and Validation + +### Adversarial Structures Tested + +| Structure | Description | DoS Vector | +| ------------------- | ------------------------------- | --------------------- | +| `million_nil_atoms` | Many zero-byte atoms | High invocation count | +| `deep_nesting` | Deeply nested pairs | High pair count | +| `single_huge_atom` | One ~100KB atom | Large data payload | +| `many_small_pairs` | Many independent pairs | High pair count | +| `hash_sized_atoms` | Many 32-byte atoms | Typical puzzle data | + +### Results: New vs Old Cost + +``` +Ratio > 1.0 means new formula charges MORE (safer) +Ratio < 1.0 means new formula charges LESS + + ⚠ single_huge_atom: 0.51x (large data - NOT a DoS vector) + ⚠ hash_sized_atoms: 0.70x (typical data - NOT a DoS vector) + ✓ balanced_tree: 1.93x + ✓ million_tiny_atoms: 2.17x + ✓ many_small_pairs: 2.25x + ✓ deep_nesting: 2.37x + ✓ million_nil_atoms: 2.37x +``` + +**Key finding**: All adversarial structures (many small nodes, deep nesting) cost **2x+ more** than before. The structures that cost less are large-data payloads, which have the *lowest* work-per-cost ratio and are not DoS vectors. + +### Cross-Hardware Validation + +| 硬件 | Per Block | Per Invocation | I/S Ratio | +| --------------------------------------------- | --------- | -------------- | -------------------- | +| **Apple M4** (2024) | 19 ns | 151 ns | 7.9× | +| **Intel 2012** (no SHA-NI) | 520 ns | 3,465 ns | 6.7× | + +The I/S ratio is consistent (6.7-7.9×) across hardware. Using `I=8` is conservative on all tested platforms. + +### Worst-Case Validation Times + +For maximum-cost adversarial generators: + +| 硬件 | Size-Only Formula | Blended Formula | Protection | +| ------------------------------------------------------------ | ----------------------- | ----------------------- | -------------------- | +| **Apple M4** | 174 ms | 37 ms | 4.7× | +| **Raspberry Pi 5** (est.) | ~700 ms | ~150 ms | 4.7× | +| **Intel 2012** (unsupported) | 4.1 sec | 870 ms | 4.7× | + +**Conclusion**: + +- Supported hardware: less than 200 ms worst case ✅ +- Unsupported legacy: less than 1 sec best-effort ✅ +- Consistent 4.7× protection improvement ✅ + +--- + +## Implications: Maximum Block Size + +### Large Atoms Cost Less Than Before + +A consequence of the blended formula is that **large single atoms cost less** than under the old formula: + +| Formula | Cost for N-byte atom | Max atom at 11B limit | +| ------- | ------------------------------------------ | -------------------------------------------- | +| **Old** | `N × 12000` | ~895 KB | +| **New** | `(N+2) × 6000 + (N/64+9) × 4500` ≈ `6070N` | **~1.81 MB** | + +The new formula allows single atoms **~2× larger** for the same cost because: + +1. `SIZE_COST_PER_BYTE = 6000` (half of old 12000) +2. SHA overhead for large atoms is minimal (one invocation, blocks proportional to size) + +### Why This Happens + +Large atoms are the *safest* structure from a DoS perspective - they have the lowest work-per-cost ratio. The old formula was effectively *overcharging* for large data payloads. + +The blended formula shifts cost toward structures with high node counts (where SHA invocation overhead matters), not raw byte volume. + +### Potential Concern: Blockchain Storage Abuse + +⚠️ **This could enable cheaper on-chain storage.** + +A farmer could create a spend with a large atom in a "garbage" solution containing incompressible data: + +- Old formula: ~895 KB max per block at cost limit +- New formula: ~1.81 MB max per block at cost limit + +This roughly **doubles the potential storage per block** for someone willing to burn the cost. + +### Assessment + +This is a **known trade-off**, not an oversight: + +1. **DoS protection was the priority**: The old formula left CPU-bound attacks undercharged by 4.7×. Fixing that was more important than preventing storage abuse. +2. **Storage abuse is self-limiting**: Attackers must pay full cost (in fees) for the space. Unlike DoS attacks, storage abuse doesn't let you do more work than you pay for. +3. **Compression still helps**: Real generators with structure (not random data) still benefit from sharing. Only incompressible garbage blobs get "cheaper." +4. **Future mitigation possible**: If storage abuse becomes a problem, the `SIZE_COST_PER_BYTE` multiplier could be increased in a future fork without changing the formula structure. + +**Bottom line**: We traded slightly cheaper storage for 4.7× better DoS protection. This seems like the right trade-off since DoS attacks are a consensus/security issue, while storage abuse is an economics issue. + +--- + +## Formula Derivation and Validation + +### SHA256 Timing Benchmark + +**Tool**: `tools/benchmark_sha_cost.py` (in `canonical-generator-analysis` repo) + +1. Hash blobs of varying sizes (1 byte to 64KB) +2. Test around SHA256 block boundaries (55/56, 119/120 bytes) +3. Fit linear model: `time = ns_per_block × blocks + ns_per_invocation` +4. Extract I/S ratio + +**Result**: I/S ≈ 8 (invocation overhead is 8× block cost) + +### Cost Coefficient Fitting + +**Tools**: Analysis scripts in `canonical-generator-analysis` repository (GitHub URL: TBD) + +**Data**: + +- 509 real mainnet generators (mix of random blocks + largest blocks) +- Synthetic generators built from real mainnet spends (excluding NFT JPEGs) + +**Goal**: Find multipliers such that: + +- Total cost ≈ old cost for typical generators (backward compatible) +- ~50% from size component, ~50% from SHA component + +**Results**: + +| Generator | Blended Cost | Old Cost | Ratio | Split | +| ----------------------------------- | ------------ | -------- | ----- | ----- | +| synthetic_1M | 2,821M | 2,936M | 96% | 45/55 | +| synthetic_500K | 1,592M | 1,503M | 106% | 44/56 | + +**Coefficient Selection**: + +After testing various combinations, the final coefficients are: + +- B = 1 (per atom byte) +- A = 2 (per atom, includes ~1 byte length prefix + overhead) +- P = 2 (per pair) + +These values were validated against: + +- 509 real mainnet generators (avg ratio = 0.99, range 0.61-1.13) +- Synthetic spend-heavy generators (ratio = 0.86-1.02) + +The formula naturally rewards efficient (high-sharing) structures while maintaining backward compatibility for typical generators. + +--- + +## Implementation Overview + +### Code Structure + +This work is split across three PRs: + +| PR | Repo | Contents | +| ---------------------------------- | ---------------------------- | ------------------------------------------------------------------------------ | +| #1 Interning | clvm_rs | `intern()`, `InternedTree`, `InternedStats` — generic tree deduplication | +| #2 Cost | chia_rs | `size_cost()`, `sha_cost()`, `total_cost()` — Chia-specific cost formulas | +| #3 serde_2026 | clvm_rs | New serialization format leveraging interning (future work) | + +PR #2 depends on #1. PR #3 is independent but uses the same interning infrastructure. + +### Key Implementation Details + +**In clvm_rs:** + +- `src/serde/intern.rs`: Core interning algorithm (single-pass post-order traversal) +- `src/chia/generator.rs`: Generator processing API (will migrate to chia_rs) + +**In chia_rs:** + +- `crates/chia-consensus/src/generator_cost.rs`: Cost calculation functions +- `crates/chia-consensus/src/run_block_generator.rs`: Updated to use `run_block_generator3()` when `INTERNED_GENERATOR` flag is set +- `crates/chia-consensus/src/flags.rs`: New `INTERNED_GENERATOR` flag enabled after `hard_fork2_height` + +**Critical**: When the `INTERNED_GENERATOR` flag is set, validation must: + +1. Intern the generator to get canonical tree +2. Calculate cost from interned stats +3. Run the generator using the interned allocator (ensures atom/pair limits apply to canonical structure) + +--- + +## Farmer Changes + +Farmers need to update their block creation code to use the new generator identity and cost calculation after the hard fork. + +### Key Changes + +1. **Generator Identity**: After fork height, `generator_root` in `TransactionsInfo` must be the tree hash (not `SHA256(serialized_bytes)`) +2. **Cost Calculation**: Cost is automatically computed by Rust code using the new formula when the flag is set +3. **Tree Hash**: The tree hash must be computed from the interned generator and passed through the Python stack + +### Files Modified + +| File | Change | +| ------------------------------------- | -------------------------------------------------------------------- | +| `chia_rs/.../run_block_generator.rs` | Height check for cost formula, return tree_hash | +| `chia/full_node/mempool.py` | Pass `tree_hash` to `NewBlockGenerator` | +| `chia/types/generator_types.py` | Add `tree_hash` field | +| `chia/consensus/block_creation.py` | Use `tree_hash` as `generator_root` after fork | +| `chia/consensus/default_constants.py` | Add `HARD_FORK_TREE_GENERATOR_HEIGHT` | + +The cost is already computed in Rust by `run_block_generator2()`/`run_block_generator3()`. The Python side just uses `conds.cost`. If Rust changes the cost formula based on height → Python automatically uses the new cost. + +--- + +## Performance Considerations + +### SHA256 Performance + +The cost formula assumes hardware-accelerated SHA256 (SHA-NI on x86, crypto extensions on ARM). Current Rust consensus code may use software SHA256, but: + +1. **Future-proofing**: Once `chia-sha2` is fixed to use proper OpenSSL EVP API, hardware acceleration will be enabled +2. **Cross-platform**: Most validators run on hardware with SHA256 acceleration +3. **DoS protection**: Using I=8 protects against attacks even if some nodes use software SHA256 + +**Note**: There is a known issue where `chia-sha2`'s OpenSSL feature uses the wrong API (`openssl::sha::Sha256` instead of `openssl::hash::Hasher`), preventing hardware acceleration. A PR is needed to fix this. + +### TreeCache Optimization + +When validating a block, we need to: + +1. Compute the generator's tree hash (for identity/commitment) +2. Run the generator to get a list of spends +3. For each spend, compute the puzzle's tree hash + +**Insight**: All puzzles are subtrees of the generator. If we build a `TreeCache` while computing the generator hash, puzzle hashes become cache lookups: + +```rust +// Step 1: Hash generator, building cache +let mut cache = TreeCache::default(); +let generator_hash = tree_hash_cached(a, generator, &mut cache); + +// Step 2: Run generator to get spends +let spends = run_generator(a, generator, ...); + +// Step 3: Puzzle hashes are fast (cache hits!) +for spend in spends { + let puzzle_hash = tree_hash_cached(a, puzzle, &mut cache); // O(1) lookup + ... +} +``` + +This means: + +- Total SHA256 work = O(unique nodes in generator) +- Puzzle hash computation = O(1) per puzzle (cache lookup) +- No redundant hashing even with many spends sharing puzzles + +--- + +## Open Questions for Review + +The following design questions need reviewer input before finalizing the cost model: + +### Question 1: Unifying SHA256 Tree Hash Cost Models + +**Context**: There are two places where SHA256 tree hashing occurs with different cost models: + +1. **The new `sha256tree` CLVM instruction**: When called from within a CLVM program, this instruction computes tree hashes on-demand. Each call may hash different subtrees, and there's no caching between calls. + +2. **Generator tree hash computation**: When validating a block, we compute the generator's tree hash using an interned, cached approach. The `TreeCache` ensures each unique node is only hashed once, and puzzle hashes benefit from cache hits. + +**Question**: Should we try to unify (or at least make more similar) the cost model for these two cases? + +**Considerations**: + +- The generator version benefits from interning and caching, making it more efficient per unique node +- The CLVM instruction version has no caching and may hash the same subtree multiple times +- Different cost models could lead to inconsistencies or confusion +- However, the different characteristics (caching vs. no caching) may justify different cost models + +**Options**: + +- **A**: Use the same cost model for both (charge based on unique nodes hashed) +- **B**: Use different cost models reflecting their different characteristics +- **C**: Make them similar but account for caching benefits in the generator case + +### Question 2: Should We Charge for Generator Tree Hash at All? + +**Context**: The current cost formula includes a SHA component that charges for tree hashing the generator: + +``` +sha_component = S × sha_blocks + I × sha_invocations +``` + +This accounts for the work of computing `SHA256_tree_hash(generator)` for identity/commitment. + +**Question**: Should we charge for `sha256tree` of the generator at all, or could we remove this component entirely? + +**Considerations**: + +- **Pro-removal**: + - Tree hashing the generator may not be a DoS vector (it's a one-time computation per block) + - Removing it would simplify the cost formula significantly + - The size component already protects against memory/storage DoS + - Generator tree hash computation is relatively fast (especially with caching) +- **Pro-keeping**: + - Ensures cost reflects all work done (including identity computation) + - Protects against potential edge cases where tree hashing could be expensive + - Maintains symmetry with the SHA component's purpose (CPU/hashing DoS protection) + - The SHA component is already validated and working well + +**Options**: + +- **A**: Remove SHA component entirely, use only size component: `cost = size_component × SIZE_COST_PER_BYTE` +- **B**: Keep SHA component as-is (current proposal) +- **C**: Keep SHA component but reduce its weight (e.g., lower `SHA_COST_PER_UNIT`) + +**Impact Analysis Needed**: + +- If we remove the SHA component, we should verify: + - No new DoS vectors are introduced + - Cost still correlates well with actual work + - Backward compatibility is maintained (typical generators still cost ~96-106% of old) + +--- + +## Summary + +### What's Changing + +| Aspect | Before | After | +| ---------------------- | -------------------------- | ---------------------------- | +| **Identity** | `SHA256(serialized_bytes)` | `SHA256_tree_hash(tree)` | +| **Cost basis** | Serialized length | Interned tree structure | +| **Consensus coupling** | Tied to serialization | Independent of serialization | + +### Why It's Safe + +1. ✅ All adversarial structures cost 2x+ more than before +2. ✅ Typical generators cost 96-106% of old (backward compatible) +3. ✅ Maximum work/cost ratio is bounded across hardware +4. ✅ SHA invocation overhead properly captured (I=8) +5. ✅ Formula validated on both fast (M4) and slow (2012 Intel) hardware + +### Why It's Better + +1. **Content-addressable identity**: Same logical tree = same identity +2. **Serialization independence**: Future compression doesn't break consensus +3. **DoS protection**: 4.7× better protection against CPU-bound attacks +4. **Cleaner semantics**: Cost reflects actual work, not encoding artifact + +--- + +## Tools and Analysis + +**Note**: The tools used to generate the values for the new generator cost formula are located in the `canonical-generator-analysis` repository (GitHub URL: TBD). This includes scripts for SHA256 timing benchmarks, cost coefficient fitting, and DoS analysis. + +### Benchmark Commands + +These commands should be run from the `canonical-generator-analysis` repository: + +```bash +# SHA256 timing benchmark +uv run tools/benchmark_sha_cost.py + +# DoS test with adversarial structures +cargo run --release -p clvm-rs-test-tools --bin dos-test + +# Analyze synthetic generators +cargo run --release -p clvm-rs-test-tools --bin clvm-serde -- synthetic_1M.bin --stats --sizes + +# Batch analysis of generator directory +cargo run --release -p clvm-rs-test-tools --bin clvm-serde -- ./GENERATORS --batch --csv results.csv +``` + +--- + +## References + +- **Analysis Repository**: `canonical-generator-analysis` (GitHub URL: TBD) +- **Implementation**: See PR #1 (clvm_rs interning) and PR #2 (chia_rs cost calculation) +- **Related Work**: Future PR #3 will add `serde_2026` serialization format diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/technical-specification.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/technical-specification.md new file mode 100644 index 00000000000..e059d3fb5c9 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/generator-identity/technical-specification.md @@ -0,0 +1,624 @@ +--- +title: Generator Identity Technical Specification +slug: /chia-blockchain/resources/generator-identity/technical-specification +--- + +The original copy of this document can be found on [GitHub](https://github.com/richardkiss/generator-identity-hf-analysis/blob/main/docs/GENERATOR_IDENTITY_HARDFORK.md). + +# Generator Identity and Cost Hard Fork: Complete Summary + +This document provides a comprehensive overview of the hard fork that transitions generator identity and cost calculation from serialization-based to content-addressable (tree-structure-based) methods. + +## Executive Summary + +This hard fork makes two fundamental changes to how generators are identified and charged: + +1. **Identity**: Generator identity changes from `SHA256(serialized_bytes)` to `SHA256_tree_hash(generator)` (content-addressable) +2. **Cost**: Generator cost changes from `len(serialized_bytes) × 12000` to a blended formula based on interned tree structure + +Both changes serve the same goal: **make consensus depend on the logical content of the generator, not its serialization format**. This decouples consensus from serialization, enabling future compression improvements without hard forks. + +--- + +## The Problem: Serialization-Coupled Consensus + +### Current State + +Today, generator identity and cost are both tied to serialization: + +``` +identity = SHA256(serialized_bytes) +cost = len(serialized_bytes) × COST_PER_BYTE (12000) +``` + +This creates several problems: + +1. **Format lock-in**: Any change to serialization format changes the generator's identity, breaking consensus compatibility. +2. **Compression penalties**: Better compression → smaller bytes → different hash. A more efficient representation of the *same logical tree* would have a different identity. +3. **Cost inconsistency**: The same logical tree serialized differently would have different costs, even though the actual work to process it is identical. + +### The Solution: Content-Addressable Identity + +After the hard fork: + +``` +identity = SHA256_tree_hash(generator) // Content-addressable +cost = f(interned_tree_structure) // Structure-based +``` + +**Key insight**: Two generators with the same tree hash contain the same logical content. They should have the same identity and cost, regardless of how they were serialized. + +This means: + +- Classic serialization (no compression) +- Backref serialization (some sharing) +- 2026 serialization (full interning) +- Future formats we haven't invented yet + +...can all represent the same generator with the **same identity and same cost**. + +--- + +## Interning: The Canonical Representation + +To ensure `same content = same cost`, we must **intern** the generator before computing cost: + +``` +Any serialization → deserialize → intern → canonical tree → deterministic cost +``` + +### What is Interning? + +**Interning** deduplicates a CLVM tree based on structural equality, an equivalence relation defined recursively: + +- **Atoms** are equal if their byte contents are identical +- **Pairs** are equal if their left children are equal AND their right children are equal (recursively) + +After interning, each equivalence class is represented by exactly one node. The cost formula counts each unique atom and pair once because: + +- **Memory/storage cost**: After interning, each unique node is stored only once in memory, regardless of how many times it appeared in the original serialization. +- **SHA256 CPU cost**: When computing the tree hash with caching, each unique node is hashed only once, regardless of how many times it appears in the tree structure. + +This makes the cost deterministic and independent of serialization format or how many times a subtree appears in the original tree. + +### Relationship to Tree Hash + +Structural equality implies tree hash equality (by definition of SHA256 tree hash). The reverse is not mathematically guaranteed, but holds in practice—a counterexample would require a SHA256 collision. + +### Block Validation Requirement + +**Critical**: Validation must start from the **interned** generator. Consensus enforces limits on atoms and pairs created; different serializations of the same logical generator could otherwise evade those limits. Using the canonical interned tree guarantees the atom/pair limits and cost calculation are applied to the same logical content for every validator. + +--- + +## The New Cost Formula + +### Why Not Just Use Serialized Size? + +With content-addressable identity, we can't use serialized size for cost because: + +1. Different serializations of the same tree would have different costs +2. We want `same tree hash = same cost` + +We need a cost formula based on the **interned tree structure**. + +### The Blended Formula + +``` +size_component = B×atom_bytes + A×atom_count + P×pair_count +sha_component = S×sha_blocks + I×sha_invocations + +total_cost = size_component × SIZE_COST_PER_BYTE + + sha_component × SHA_COST_PER_UNIT +``` + +**Constants:** + +| Constant | Value | Purpose | +| --------------------------------------------------------------------------------- | ----- | ---------------------------------------------- | +| B | 1 | Per byte of atom data | +| A | 2 | Per-atom overhead | +| P | 2 | Per-pair overhead | +| S | 1 | Per SHA256 block (64 bytes) | +| I | 8 | Per SHA256 invocation | +| SIZE_COST_PER_BYTE | 6000 | Size component multiplier | +| SHA_COST_PER_UNIT | 4500 | SHA component multiplier | + +### Why Two Components? + +The formula protects against **two distinct DoS vectors**: + +**1. Memory/Storage DoS** + +- Attack: Create structures expensive to store but cheap to hash +- Protection: Size component charges for structural overhead + +**2. CPU/Hashing DoS** + +- Attack: Create structures with many small nodes (cheap in bytes, expensive to hash) +- Protection: SHA component charges for hashing work + +By splitting ~50/50, neither attack vector can exploit the other's blind spot. + +### Why SHA Invocation Cost Matters + +SHA256 has significant per-invocation overhead beyond the per-block mixing cost: + +| 硬件 | Per Block | Per Invocation | Ratio | +| ---------- | --------- | -------------- | -------------------- | +| Apple M4 | 19 ns | 151 ns | 7.9× | +| Intel 2012 | 520 ns | 3,465 ns | 6.7× | + +A tree with 1000 tiny atoms incurs 1000 invocations regardless of total bytes. Without the `I=8` coefficient, such structures would be severely undercharged. + +**Note**: The I=8 ratio is based on hardware-accelerated SHA256 (SHA-NI on x86, crypto extensions on ARM). Software SHA256 has a much lower I/S ratio (~0.07), but we use I=8 to: + +1. Future-proof for when hardware acceleration is enabled +2. Protect against cross-platform DoS attacks +3. Maintain consistency across different hardware + +--- + +## DoS Analysis and Validation + +### Adversarial Structures Tested + +| Structure | Description | DoS Vector | +| ------------------- | ------------------------------- | --------------------- | +| `million_nil_atoms` | Many zero-byte atoms | High invocation count | +| `deep_nesting` | Deeply nested pairs | High pair count | +| `single_huge_atom` | One ~100KB atom | Large data payload | +| `many_small_pairs` | Many independent pairs | High pair count | +| `hash_sized_atoms` | Many 32-byte atoms | Typical puzzle data | + +### Results: New vs Old Cost + +``` +Ratio > 1.0 means new formula charges MORE (safer) +Ratio < 1.0 means new formula charges LESS + + ⚠ single_huge_atom: 0.51x (large data - NOT a DoS vector) + ⚠ hash_sized_atoms: 0.70x (typical data - NOT a DoS vector) + ✓ balanced_tree: 1.93x + ✓ million_tiny_atoms: 2.17x + ✓ many_small_pairs: 2.25x + ✓ deep_nesting: 2.37x + ✓ million_nil_atoms: 2.37x +``` + +**Key finding**: All adversarial structures (many small nodes, deep nesting) cost **2x+ more** than before. The structures that cost less are large-data payloads, which have the *lowest* work-per-cost ratio and are not DoS vectors. + +### Cross-Hardware Validation + +| 硬件 | Per Block | Per Invocation | I/S Ratio | +| --------------------------------------------- | --------- | -------------- | -------------------- | +| **Apple M4** (2024) | 19 ns | 151 ns | 7.9× | +| **Intel 2012** (no SHA-NI) | 520 ns | 3,465 ns | 6.7× | + +The I/S ratio is consistent (6.7-7.9×) across hardware. Using `I=8` is conservative on all tested platforms. + +### Worst-Case Validation Times + +For maximum-cost adversarial generators: + +| 硬件 | Size-Only Formula | Blended Formula | Protection | +| ------------------------------------------------------------ | ----------------------- | ----------------------- | -------------------- | +| **Apple M4** | 174 ms | 37 ms | 4.7× | +| **Raspberry Pi 5** (est.) | ~700 ms | ~150 ms | 4.7× | +| **Intel 2012** (unsupported) | 4.1 sec | 870 ms | 4.7× | + +**Conclusion**: + +- Supported hardware: less than 200 ms worst case ✅ +- Unsupported legacy: less than 1 sec best-effort ✅ +- Consistent 4.7× protection improvement ✅ + +--- + +## Implications: Maximum Block Size + +### Large Atoms Cost Less Than Before + +A consequence of the blended formula is that **large single atoms cost less** than under the old formula: + +| Formula | Cost for N-byte atom | Max atom at 11B limit | +| ------- | ------------------------------------------ | -------------------------------------------- | +| **Old** | `N × 12000` | ~895 KB | +| **New** | `(N+2) × 6000 + (N/64+9) × 4500` ≈ `6070N` | **~1.81 MB** | + +The new formula allows single atoms **~2× larger** for the same cost because: + +1. `SIZE_COST_PER_BYTE = 6000` (half of old 12000) +2. SHA overhead for large atoms is minimal (one invocation, blocks proportional to size) + +### Why This Happens + +Large atoms are the *safest* structure from a DoS perspective - they have the lowest work-per-cost ratio. The old formula was effectively *overcharging* for large data payloads. + +The blended formula shifts cost toward structures with high node counts (where SHA invocation overhead matters), not raw byte volume. + +### Potential Concern: Blockchain Storage Abuse + +⚠️ **The new formula allows larger atoms for the same cost.** + +A farmer could create a spend with a large atom in a "garbage" solution containing incompressible data: + +- Old formula: ~895 KB max per block at cost limit +- New formula: ~1.81 MB max per block at cost limit + +This roughly **doubles the potential storage per block** for someone willing to burn the cost. + +**Note**: This is discussed as an open question in [Question 3: Balancing Storage vs. SHA Costs](#question-3-balancing-storage-vs-sha-costs) below. + +--- + +## Formula Derivation and Validation + +### SHA256 Timing Benchmark + +**Tool**: `benchmark-sha` (installed as entry point) + +1. Hash blobs of varying sizes (1 byte to 64KB) +2. Test around SHA256 block boundaries (55/56, 119/120 bytes) +3. Fit linear model: `time = ns_per_block × blocks + ns_per_invocation` +4. Extract I/S ratio + +**Result**: I/S ≈ 8 (invocation overhead is 8× block cost) + +### Cost Coefficient Fitting + +**Tools**: Analysis scripts are in GitHub; see [ANALYSIS_WORKFLOW.md](https://github.com/richardkiss/generator-identity-hf-analysis/blob/main/docs/ANALYSIS_WORKFLOW.md) + +**Data**: + +- 509 real mainnet generators (mix of random blocks + largest blocks) +- Synthetic generators built from real mainnet spends (excluding NFT JPEGs) + +**Goal**: Find multipliers such that: + +- Total cost ≈ old cost for typical generators (backward compatible) +- ~50% from size component, ~50% from SHA component + +**Results**: + +| Generator | Blended Cost | Old Cost | Ratio | Split | +| ----------------------------------- | ------------ | -------- | ----- | ----- | +| synthetic_1M | 2,821M | 2,936M | 96% | 45/55 | +| synthetic_500K | 1,592M | 1,503M | 106% | 44/56 | + +**Coefficient Selection**: + +After testing various combinations, the final coefficients are: + +- B = 1 (per atom byte) +- A = 2 (per atom, includes ~1 byte length prefix + overhead) +- P = 2 (per pair) + +These values were validated against: + +- 509 real mainnet generators (avg ratio = 0.99, range 0.61-1.13) +- Synthetic spend-heavy generators (ratio = 0.86-1.02) + +The formula naturally rewards efficient (high-sharing) structures while maintaining backward compatibility for typical generators. + +--- + +## Implementation Overview + +### Code Structure + +This work is split across three PRs: + +| PR | Repository | Branch | Contents | +| -------------------------------------- | ----------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------ | +| **#1 Interning** | [clvm_rs](https://github.com/Chia-Network/clvm_rs) | `generator-identity-hf` | `intern()`, `InternedTree`, `InternedStats` — generic tree deduplication | +| **#2 Cost** | [chia_rs](https://github.com/Chia-Network/chia_rs) | `generator-identity-hf` | `size_cost()`, `sha_cost()`, `total_cost()` — Chia-specific cost formulas | +| **#3 serde_2026** | [clvm_rs](https://github.com/Chia-Network/clvm_rs) | `serde_2026` | New serialization format leveraging interning (future work) | + +**Dependency order**: PR #2 depends on #1 being merged and released first. PR #3 is independent but uses the same interning infrastructure. + +### Key Implementation Details + +**In clvm_rs (PR #1):** + +- `src/serde/intern.rs`: Core interning algorithm (single-pass post-order traversal) +- Returns `InternedTree` with canonical node structure and `InternedStats` for cost calculation +- Generic infrastructure usable by any consumer (not Chia-specific) + +**In chia_rs (PR #2):** + +- `crates/chia-consensus/src/generator_cost.rs`: Cost calculation functions using `InternedStats` +- `crates/chia-consensus/src/run_block_generator.rs`: Updated to use `run_block_generator3()` when `INTERNED_GENERATOR` flag is set +- `crates/chia-consensus/src/flags.rs`: New `INTERNED_GENERATOR` flag enabled after `hard_fork2_height` + +**In clvm_rs (PR #3):** + +- `src/serde_2026/`: New serialization format with varint encoding +- Leverages interning infrastructure for optimal compression +- Independent from consensus changes (future work) + +**Critical**: When the `INTERNED_GENERATOR` flag is set, validation must: + +1. Intern the generator to get canonical tree +2. Calculate cost from interned stats +3. Run the generator using the interned allocator (ensures atom/pair limits apply to canonical structure) + +--- + +## Farmer Changes + +Farmers need to update their block creation code to use the new generator identity and cost calculation after the hard fork. + +### Key Changes + +1. **Generator Identity**: After fork height, `generator_root` in `TransactionsInfo` must be the tree hash (not `SHA256(serialized_bytes)`) +2. **Cost Calculation**: Cost is automatically computed by Rust code using the new formula when the flag is set +3. **Tree Hash**: The tree hash must be computed from the interned generator and passed through the Python stack + +### Files Modified + +| File | Change | +| ------------------------------------- | -------------------------------------------------------------------- | +| `chia_rs/.../run_block_generator.rs` | Height check for cost formula, return tree_hash | +| `chia/full_node/mempool.py` | Pass `tree_hash` to `NewBlockGenerator` | +| `chia/types/generator_types.py` | Add `tree_hash` field | +| `chia/consensus/block_creation.py` | Use `tree_hash` as `generator_root` after fork | +| `chia/consensus/default_constants.py` | Add `HARD_FORK_TREE_GENERATOR_HEIGHT` | + +The cost is already computed in Rust by `run_block_generator2()`/`run_block_generator3()`. The Python side just uses `conds.cost`. If Rust changes the cost formula based on height → Python automatically uses the new cost. + +--- + +## Performance Considerations + +### SHA256 Performance + +The cost formula assumes hardware-accelerated SHA256 (SHA-NI on x86, crypto extensions on ARM). Current Rust consensus code may use software SHA256, but: + +1. **Future-proofing**: Once `chia-sha2` is fixed to use proper OpenSSL EVP API, hardware acceleration will be enabled +2. **Cross-platform**: Most validators run on hardware with SHA256 acceleration +3. **DoS protection**: Using I=8 protects against attacks even if some nodes use software SHA256 + +**Note**: There is a known issue where `chia-sha2`'s OpenSSL feature uses the wrong API (`openssl::sha::Sha256` instead of `openssl::hash::Hasher`), preventing hardware acceleration. A PR is needed to fix this. + +### TreeCache Optimization + +When validating a block, we need to: + +1. Compute the generator's tree hash (for identity/commitment) +2. Run the generator to get a list of spends +3. For each spend, compute the puzzle's tree hash + +**Insight**: All puzzles are subtrees of the generator. If we build a `TreeCache` while computing the generator hash, puzzle hashes become cache lookups: + +```rust +// Step 1: Hash generator, building cache +let mut cache = TreeCache::default(); +let generator_hash = tree_hash_cached(a, generator, &mut cache); + +// Step 2: Run generator to get spends +let spends = run_generator(a, generator, ...); + +// Step 3: Puzzle hashes are fast (cache hits!) +for spend in spends { + let puzzle_hash = tree_hash_cached(a, puzzle, &mut cache); // O(1) lookup + ... +} +``` + +This means: + +- Total SHA256 work = O(unique nodes in generator) +- Puzzle hash computation = O(1) per puzzle (cache lookup) +- No redundant hashing even with many spends sharing puzzles + +--- + +## Open Questions for Review + +The following design questions need reviewer input before finalizing the cost model: + +> **Note**: For a more radical alternative approach, see [Generator as Witness Proposal](https://github.com/richardkiss/generator-identity-hf-analysis/blob/main/docs/GENERATOR_AS_WITNESS_PROPOSAL.md), which proposes not committing to the generator at all (treating it as pure witness). This is presented for discussion but is not part of the current implementation plan. + +### Question 1: Unifying SHA256 Tree Hash Cost Models + +**Context**: There are two places where SHA256 tree hashing occurs with different cost models: + +1. **The new `sha256tree` CLVM instruction**: When called from within a CLVM program, this instruction computes tree hashes on-demand. Each call may hash different subtrees, and there's no caching between calls. + +2. **Generator tree hash computation**: When validating a block, we compute the generator's tree hash using an interned, cached approach. The `TreeCache` ensures each unique node is only hashed once, and puzzle hashes benefit from cache hits. + +**Question**: Should we try to unify (or at least make more similar) the cost model for these two cases? + +**Considerations**: + +- The generator version benefits from interning and caching, making it more efficient per unique node +- The CLVM instruction version has no caching and may hash the same subtree multiple times +- Different cost models could lead to inconsistencies or confusion +- However, the different characteristics (caching vs. no caching) may justify different cost models + +**Options**: + +- **A**: Use the same cost model for both (charge based on unique nodes hashed) +- **B**: Use different cost models reflecting their different characteristics +- **C**: Make them similar but account for caching benefits in the generator case + +### Question 2: Should We Charge for Generator Tree Hash at All? + +**Context**: The current cost formula includes a SHA component that charges for tree hashing the generator: + +``` +sha_component = S × sha_blocks + I × sha_invocations +``` + +This accounts for the work of computing `SHA256_tree_hash(generator)` for identity/commitment. + +**Question**: Should we charge for `sha256tree` of the generator at all, or could we remove this component entirely? + +**Considerations**: + +- **Pro-removal**: + - Tree hashing the generator may not be a DoS vector (it's a one-time computation per block) + - Removing it would simplify the cost formula significantly + - The size component already protects against memory/storage DoS + - Generator tree hash computation is relatively fast (especially with caching) +- **Pro-keeping**: + - Ensures cost reflects all work done (including identity computation) + - Protects against potential edge cases where tree hashing could be expensive + - Maintains symmetry with the SHA component's purpose (CPU/hashing DoS protection) + - The SHA component is already validated and working well + +**Options**: + +- **A**: Remove SHA component entirely, use only size component: `cost = size_component × SIZE_COST_PER_BYTE` +- **B**: Keep SHA component as-is (current proposal) +- **C**: Keep SHA component but reduce its weight (e.g., lower `SHA_COST_PER_UNIT`) + +**Impact Analysis Needed**: + +- If we remove the SHA component, we should verify: + - No new DoS vectors are introduced + - Cost still correlates well with actual work + - Backward compatibility is maintained (typical generators still cost ~96-106% of old) + +### Question 3: Balancing Storage vs. SHA Costs + +**Context**: The current blended formula (50/50 split between size and SHA components) allows larger single atoms compared to the old formula: + +- Old formula: ~895 KB max atom at 11B cost limit +- New formula: ~1.81 MB max atom at 11B cost limit + +This roughly doubles the potential on-chain storage per block for someone willing to burn the cost. + +**Question**: Should we adjust the balance between storage cost and SHA cost to prevent this increase in potential storage abuse? + +**Options**: + +#### Option A: Keep Current Blended Formula (50/50 Split) + +**Pros:** + +- **Simplicity**: Maintains the balanced 50/50 split between size and SHA components +- **No increased storage abuse**: Does not make storage abuse worse than the current situation +- **DoS protection**: Maintains strong protection against CPU-bound attacks (4.7× improvement) +- **Validated**: Formula has been tested and validated against real generators + +**Cons:** + +- **Larger atoms allowed**: Permits ~2× larger single atoms compared to old formula +- **Storage economics**: Makes on-chain storage slightly cheaper for incompressible data + +#### Option B: Increase Storage Cost, Reduce SHA Cost + +Increase `SIZE_COST_PER_BYTE` and reduce (possibly to zero) `SHA_COST_PER_UNIT`: + +**Pros:** + +- **Prevents storage abuse**: Maintains or reduces maximum atom size at cost limit +- **Still protects against DoS**: If SHA cost is non-zero, maintains protection against CPU-bound attacks +- **Flexible**: Can tune the balance between storage and SHA costs + +**Cons:** + +- **Complexity**: Requires re-tuning multipliers and re-validation against real generators +- **Potential DoS risk**: If SHA cost goes to zero, loses protection against CPU-bound attacks with many small nodes +- **Less balanced**: Moves away from the validated 50/50 split that matches actual work distribution + +**Considerations**: + +- **DoS protection priority**: The old formula left CPU-bound attacks undercharged by 4.7×. Fixing that was more important than preventing storage abuse. +- **Storage abuse is self-limiting**: Attackers must pay full cost (in fees) for the space. Unlike DoS attacks, storage abuse doesn't let you do more work than you pay for. +- **Compression still helps**: Real generators with structure (not random data) still benefit from sharing. Only incompressible garbage blobs get "cheaper." +- **Future flexibility**: If storage abuse becomes a problem, Option B can be implemented in a future fork by adjusting the multipliers without changing the formula structure. + +**Current proposal**: Option A (blended formula) prioritizes DoS protection and simplicity. DoS attacks are a consensus/security issue, while storage abuse is primarily an economics issue that can be addressed later if needed. + +--- + +## Summary + +### What's Changing + +| Aspect | Before | After | +| ---------------------- | -------------------------- | ---------------------------- | +| **Identity** | `SHA256(serialized_bytes)` | `SHA256_tree_hash(tree)` | +| **Cost basis** | Serialized length | Interned tree structure | +| **Consensus coupling** | Tied to serialization | Independent of serialization | + +### Why It's Safe + +1. ✅ All adversarial structures cost 2x+ more than before +2. ✅ Typical generators cost 96-106% of old (backward compatible) +3. ✅ Maximum work/cost ratio is bounded across hardware +4. ✅ SHA invocation overhead properly captured (I=8) +5. ✅ Formula validated on both fast (M4) and slow (2012 Intel) hardware + +### Why It's Better + +1. **Content-addressable identity**: Same logical tree = same identity +2. **Serialization independence**: Future compression doesn't break consensus +3. **DoS protection**: 4.7× better protection against CPU-bound attacks +4. **Cleaner semantics**: Cost reflects actual work, not encoding artifact + +--- + +## Tools and Analysis + +**Analysis Repository**: [generator-identity-hf-analysis](https://github.com/richardkiss/generator-identity-hf-analysis) + +This repository contains all the tools, scripts, and data used to derive and validate the cost formula parameters: + +- **Python Analysis Scripts** (installed as entry points): + - `analyze-generators` - Analyze real generators from mainnet + - `benchmark-sha` - SHA256 performance benchmarking + - `dos-test` - Adversarial structure testing + - `sweep-coefficients` - Coefficient optimization + +- **Rust Analysis Tools**: + - `tools/dos-test` - Detailed DoS analysis with timing + - `tools/serialization-dos-bench` - Serialization format comparison + +- **Documentation**: + - `docs/GENERATOR_IDENTITY_HARDFORK.md` - Complete technical specification (this document) + - `docs/ANALYSIS_WORKFLOW.md` - Step-by-step analysis workflow + +### Benchmark Commands + +These commands should be run from the **[generator-identity-hf-analysis](https://github.com/richardkiss/generator-identity-hf-analysis)** repository: + +```bash +# SHA256 timing benchmark +benchmark-sha + +# DoS test with adversarial structures +dos-test -v + +# Analyze synthetic generators +analyze-generators data/synthetic_1M.bin --verbose + +# Batch analysis of generator directory +analyze-generators ./data/generators --batch --csv results.csv + +# Coefficient sweep +sweep-coefficients ./data/generators/ +``` + +For Rust-based analysis tools: + +```bash +# Detailed DoS analysis with timing +cargo run --release --bin dos-test + +# Serialization benchmark and comparison +cargo run --release --bin serialization-dos-bench -- data/synthetic_1M.bin --stats +``` + +--- + +## References + +- **Analysis Repository**: [generator-identity-hf-analysis](https://github.com/richardkiss/generator-identity-hf-analysis) - Tools and data for cost formula derivation +- **Implementation PRs**: + - PR #1 (clvm_rs): [Interning Infrastructure](https://github.com/Chia-Network/clvm_rs/pull/TBD) + - PR #2 (chia_rs): [Cost Calculation](https://github.com/Chia-Network/chia_rs/pull/TBD) + - PR #3 (clvm_rs): [serde_2026 Format](https://github.com/Chia-Network/clvm_rs/pull/TBD) (future work) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/k-sizes.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/k-sizes.md index c517c991d03..929dedaea55 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/k-sizes.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/k-sizes.md @@ -5,17 +5,17 @@ slug: /chia-blockchain/resources/k-sizes ## K值大小与压缩等级 -| 压缩等级 | 地块大小 k=32（GiB） | 地块大小 k=32（GB） | 地块大小 k=33（GiB） | 地块大小 k=34（GiB） | 地块大小 k=35（GiB） | -| -------- | -------------------- | ------------------- | -------------------- | -------------------- | -------------------- | -| 0 | 101.4 | 108.8 | 208.8 | 429.9 | 884.1 | -| 1 | 87.5 | 94.0 | 179.6 | 368.2 | 754.3 | -| 2 | 86.0 | 92.4 | 176.6 | 362.1 | 742.2 | -| 3 | 84.5 | 90.7 | 173.4 | 355.9 | 729.7 | -| 4 | 82.9 | 89.0 | 170.2 | 349.4 | 716.8 | -| 5 | 81.3 | 87.2 | 167.0 | 343.0 | 704.0 | -| 6 | 79.6 | 85.5 | 163.8 | 336.6 | 691.1 | -| 7 | 78.0 | 83.8 | 160.6 | 330.2 | 678.3 | -| 9 | 75.2 | 80.7 | 154.1 | 315.5 | 645.8 | +| 压缩等级 | 地块大小 k=32（GiB） | 地块大小 k=32（GB） | 地块大小 k=33（GiB） | 地块大小 k=34（GiB） | 地块大小 k=35（GiB） | +| ---- | --------------------- | --------------------- | --------------------- | --------------------- | --------------------- | +| 0 | 101.4 | 108.8 | 208.8 | 429.9 | 884.1 | +| 1 | 87.5 | 94.0 | 179.6 | 368.2 | 754.3 | +| 2 | 86.0 | 92.4 | 176.6 | 362.1 | 742.2 | +| 3 | 84.5 | 90.7 | 173.4 | 355.9 | 729.7 | +| 4 | 82.9 | 89.0 | 170.2 | 349.4 | 716.8 | +| 5 | 81.3 | 87.2 | 167.0 | 343.0 | 704.0 | +| 6 | 79.6 | 85.5 | 163.8 | 336.6 | 691.1 | +| 7 | 78.0 | 83.8 | 160.6 | 330.2 | 678.3 | +| 9 | 75.2 | 80.7 | 154.1 | 315.5 | 645.8 | :::info **k=32 is the minimum plot size** that will be eligible for farming. 尽管可能会看到k=25，但这仅用于测试目的。 @@ -31,25 +31,25 @@ Our documentation and code now use a closer estimation of 0.78005. The following table shows the old size estimation of C0 plots, along with the new estimations: -| k | Old est. size (GB) | New est. size (GB) | -| --: | -----------------: | -----------------: | -| 32 | 106.3648651 | 108.8844003 | -| 33 | 219.2752603 | 224.469379 | -| 34 | 451.641581 | 462.339915 | -| 35 | 929.4652826 | 951.4821439 | -| 36 | 1911.294806 | 1956.568916 | -| 37 | 3927.318095 | 4020.347087 | -| 38 | 8064.093156 | 8255.112685 | -| 39 | 16547.10024 | 16939.06239 | +| k | Old est. size (GB) | New est. size (GB) | +| -: | ----------------------------------------------------: | ----------------------------------------------------: | +| 32 | 106.3648651 | 108.8844003 | +| 33 | 219.2752603 | 224.469379 | +| 34 | 451.641581 | 462.339915 | +| 35 | 929.4652826 | 951.4821439 | +| 36 | 1911.294806 | 1956.568916 | +| 37 | 3927.318095 | 4020.347087 | +| 38 | 8064.093156 | 8255.112685 | +| 39 | 16547.10024 | 16939.06239 | ## Storage requirements for uncompressed plots -| K-size | Temp. Size | Final Size | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | -------------------- | -| New est. size (GB) | 239 GiB (256.6 GB) | 101.4 GiB (108.9 GB) | -| For a given k, the plot size is roughly ((2 \* k) + 1) \* (2 \*\* (k - 1)) \* 0.78005. In previous versions of Chia's documentation and code, the constant at the end of this equation was estimated to be 0.762. Our documentation and code now use a closer estimation of 0.78005. | 512 GiB (550 GB) | 208.8 GiB (224.2 GB) | -| Old est. size (GB) | 1041 GiB (1118 GB) | 429.8 GiB (461.5 GB) | -| K=35 | 2175 GiB (2335 GB) | 884.1 GiB (949.3 GB) | +| K-size | Temp. Size | Final Size | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------- | +| New est. size (GB) | 239 GiB (256.6 GB) | 101.4 GiB (108.9 GB) | +| For a given k, the plot size is roughly ((2 \* k) + 1) \* (2 \*\* (k - 1)) \* 0.78005. In previous versions of Chia's documentation and code, the constant at the end of this equation was estimated to be 0.762. Our documentation and code now use a closer estimation of 0.78005. | 512 GiB (550 GB) | 208.8 GiB (224.2 GB) | +| Old est. size (GB) | 1041 GiB (1118 GB) | 429.8 GiB (461.5 GB) | +| K=35 | 2175 GiB (2335 GB) | 884.1 GiB (949.3 GB) | When planning on how much plotting space is required, only calculate the temporary disk size requirement. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/faq.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/faq.md index a936f3f8d26..5e7fecae01a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/faq.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/faq.md @@ -10,28 +10,61 @@ import TabItem from '@theme/TabItem'; ### What is the Chia Signer app? -The Chia Signer app is a dedicated mobile application currently available for iOS devices designed to provide an enhanced layer of security for your Chia Wallet transactions. It allows you to securely store your private keys in your phone's Secure Enclave and approve transactions initiated from your Chia Wallet. +The Chia Signer app is a dedicated mobile application for iOS and Android that provides an enhanced layer of security for your Chia Wallet transactions. On iOS, keys are stored in the Secure Enclave. Android is currently in **beta**; on first launch the app checks for hardware-backed key storage via Android’s Keystore (including StrongBox or TEE-backed storage when the device supports it). If suitable hardware is not available, you can still use software keys; the app warns you on each software key creation that the key is not hardware-protected. ### What are the key benefits of using the Chia Signer app? -- **Secure Enclave Protection:** Your private keys are generated and stored within your device's Secure Enclave, a hardware-isolated security component. This means your keys never leave your device and are highly protected against software vulnerabilities. +- **Hardware-protected keys:** Your private keys are generated and stored in hardware-isolated security components on the device. They are not exposed to normal app memory and are highly protected against many software-level attacks. - **Secure, Device-Based Approval:** The Signer app allows you to securely approve transactions initiated from your Chia Cloud Wallet on a separate, dedicated device. - **Enhanced Security:** By separating your signing key from your main Chia Cloud Wallet interface (requiring two devices), it adds a significant layer of security against online threats and unauthorized access. ### What are the device requirements for the Chia Signer app? -To use the Chia Signer app, your iOS device must: +**iOS** -- Run **iOS 15 or later**. -- Have a **Secure Enclave** (most iPhone models starting with iPhone 6s and iPad models starting with iPad mini 4 or newer typically have this). +- See the [App Store listing](https://apps.apple.com/app/chia-signer/id6504493785) for compatible devices and the minimum iOS version. In general, you need iOS 15 or later and a Secure Enclave. + +**Android** (beta) + +- The Android app is in **beta**. Use the [Google Play listing](https://play.google.com/store/apps/details?id=net.chia.android.signer) for compatible devices, OS version, and install eligibility. Hardware-backed keys require device support for Android’s hardware-backed Keystore (e.g. StrongBox or TEE); see Google’s [Keystore documentation](https://developer.android.com/privacy-and-security/keystore). Devices without that backing use software keys with in-app notices at creation time as these keys are inherently less secure than hardware keys. ### Can I use the Chia Cloud Wallet and the Chia Signer app on the same device? -Currently, no. For security purposes, you need two separate devices: one for accessing your Chia Cloud Wallet (e.g., a computer or another phone) and a separate iOS device with the Chia Signer app installed. This functionality (using both on the same device) is planned for a future release. +Currently, no. For security purposes, you need two separate devices: one for accessing your Chia Cloud Wallet (e.g., a computer or another phone) and a separate smartphone with the Chia Signer app (iOS, or Android in beta). Using both on the same device is planned for a future release. ### How do I create a new key within the Chia Signer app? -After opening the app for the first time, you can tap the `+` button, name your key, and select "Generate Key." This will securely generate a new private key within your device's Secure Enclave. +Tap the ellipsis (the `...` button in the upper-right corner), then tap the `+ Add Key` button, name your key, optionally change the emoji, and select **Generate Key**. We recommend that you leave the `Secure your key` slider enabled. + +You also have the option to create either a `Hardware key` (a spend key) or a `Software key` (a recovery key). If you choose `Hardware key`, then the key's location will depend on your phone's hardware and OS: + +- **iOS:** The app creates a hardware-backed key in the Secure Enclave. +- **Android** (beta): On first start, the app checks for hardware-backed Keystore support. Depending on your phone's manufacturer and model, one of three options will be selected automatically: + - StrongBox + - most secure option + - uses a dedicated Hardware Security Module (HSM) + - resistant to hardware tampering + - only available on select Android devices ([list of currently supported devices](https://www.android-device-security.org/database/?sortBy=COUNT%20Lab%20Strongbox%20True;COUNT%20Lab%20Strongbox%20False&order=-1&show=Strongbox&Strongbox=True&realMeasurementsOnly=true)) + - Trusted Execution Environment (TEE) + - less secure than StrongBox + - separates secure and non-secure execution environments + - available on most Android devices + - Neither + - least secure option + - Signer app will fall back to using a software key + - Signer app will alert you each time that the new key is a software key + +:::info + +The Android Chia Signer app currently shows the same messaging for phones with a TEE and for those that only support software keys. We will update this messaging in a future release. If your phone does have a TEE, the hardware keys will be created in the TEE despite this messaging. + +::: + +### Is a TEE secure enough to be used with the Android Signer app? + +Our security best practice for the Android Signer app is to use a phone with a StrongBox. However, depending on your personal risk assessment, a phone with a TEE may also suffice. + +A key stored in a TEE is at a higher risk of compromise than one stored in a StrongBox. [This article](https://www.comviva.com/blog/safeguarding-cryptographic-keys-implementing-tee-and-strongbox-in-android-applications/) describes the differences between the environments. If you feel that a TEE is not secure enough (for example, if you plan to store large amounts of funds in a Cloud Wallet vault), then you can acquire a device with a StrongBox for the highest level of security available on an Android device. ### How do I link my Chia Signer key to a Chia Cloud Wallet vault? @@ -42,12 +75,30 @@ The linking process involves scanning a QR code displayed by your Chia Cloud Wal ### How do I sign a transaction using the Chia Signer app? -When you initiate a transaction from your linked Chia Cloud Wallet, the Chia Signer app on your iOS device will receive a request. You will review the transaction details presented on the Signer app's screen and, if correct, tap "Sign transaction." Your device may require a biometric (Face ID/Touch ID) or passcode confirmation to authorize the signing. +When you initiate a transaction from your linked Chia Cloud Wallet, the Chia Signer app on your signing device will receive a request. You will review the transaction details presented on the Signer app's screen and, if correct, tap "Sign transaction." Your device may require a biometric (Face ID, Touch ID, fingerprint) or passcode confirmation to authorize the signing. + +### Does Chia Network have access to my Signer keys, or can CNI recover my vault if I lose both keys? + +**No.** Chia Network, Inc. (CNI) does **not** have access to your **spend keys** or **recovery keys**, whether they are held in the Chia Signer app, as passkeys, or as a BLS recovery phrase you manage yourself. Signing material is generated and kept under your control; CNI does not hold copies in a form that would let us sign on your behalf. + +If you permanently lose access to **both** your spend key and your recovery key (including backups), **CNI cannot recover your keys or restore vault access for you**. ### Is an Android version of the Chia Signer app available? -Currently, the Chia Signer app is only available for iOS devices. An Android version is planned for a future release. +Yes, the android version is currently in beta: [Google Play](https://play.google.com/store/apps/details?id=net.chia.android.signer). ### Can the Chia Signer app be used as the Chia Cloud Wallet recovery key? -Currently, the Chia Signer app can only be used as the custody key for your vault but the ability to use it for the recovery key is planned for a future release. +是的。 Your vault’s recovery key remains a BLS key with an associated 24-word mnemonic seed phrase; the Chia Signer app can store and use that BLS recovery key for you. Spend keys cannot be BLS—they stay passkeys or Chia Signer hardware/software keys. + +We strongly recommend keeping the recovery key on a different device than the spend key. If both the spend key and BLS recovery material live only on the same phone and you lose access to it, you may be unable to spend or complete recovery. Chia Network cannot reset your keys or restore vault access for you. + +If recovery and spend might share one device, or you use Signer-held recovery in any other setup, back up your recovery credentials with care: + +- On Apple devices, use iCloud Keychain with Advanced Data Protection enabled. + +- On Android, use encrypted credential storage and backups tied to a strongly secured Google account: a screen lock, 2-step verification, and passkeys or hardware security keys where available. A password manager with strong 2FA is also appropriate. + +- On any platform, use a reputable password manager secured with strong 2FA—prefer passkeys or hardware security keys for the manager and your cloud accounts, not SMS-only verification. + +Treat any copy of recovery material like any other 24 word mnemonic seed phrase: anyone who obtains it may be able to attempt recovery. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/getting-started.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/getting-started.md index eb1ecd2765a..d8e4e0b4f67 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/getting-started.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/getting-started.md @@ -12,37 +12,67 @@ This guide will show you how to get started with the Chia Signer app, from setti **Prerequisites:** -- An iOS device (iPhone or iPad) running iOS 15 or later and has the Secure Enclave. +- A compatible phone or tablet for the Chia Signer app: + - **iOS:** iPhone or iPad running **iOS 15 or later** with a **Secure Enclave**. Requirements are kept up to date on the [App Store](https://apps.apple.com/app/chia-signer/id6504493785) listing. + - **Android** (beta): Phone or tablet that meets the requirements shown on the [Google Play listing](https://play.google.com/store/apps/details?id=net.chia.android.signer). For the strongest protection, use a device that supports **hardware-backed Keystore** (including **StrongBox** where available); if the device does not, the app can still run using **software keys** with clear in-app warnings when you create each key. **Key Concepts:** -- **Secure Enclave Protection:** Your private keys are generated and stored in your device's Secure Enclave, a dedicated hardware security module, ensuring they never leave your device. +- **Hardware-protected keys (recommended):** On **iOS**, keys live in the **Secure Enclave**. On **Android** (beta), keys can be stored using Android’s **hardware-backed Keystore**, which may use **StrongBox** (dedicated tamper-resistant hardware) or a **Trusted Execution Environment (TEE)** when the device supports it, see Google’s [Android Keystore overview](https://developer.android.com/privacy-and-security/keystore). If your Android device does not expose suitable hardware backing, the app falls back to **software keys** and **warns you at each key creation** that the key is software-based. - **Secure, Device-Based Approval:** The Signer app allows you to securely approve transactions initiated from your Chia Cloud Wallet on a separate, dedicated device. -- **Two-Device Requirement:** Currently, the Chia Cloud Wallet and Chia Signer app must be on separate devices (e.g., Chia Cloud Wallet on your computer/phone, Signer on your iPhone). +- **Two-Device Requirement:** Currently, the Chia Cloud Wallet and Chia Signer app must be on separate devices (for example, Chia Cloud Wallet on your computer or phone, and Signer on another smartphone). ## 1. Get the Chia Signer App -- **Download:** The Chia Signer app is available on the [iOS App Store](https://apps.apple.com/app/chia-signer/id6504493785). (Note: An Android version is planned for the future). +- **iOS:** [App Store](https://apps.apple.com/app/chia-signer/id6504493785). +- **Android** (beta): [Google Play](https://play.google.com/store/apps/details?id=net.chia.android.signer). ## 2. Create a New Key in the Chia Signer App After installing and opening the app for the first time: -1. **Add Key:** Tap the `+` button, usually located in the upper-right corner of the app's main screen. +1. **Add Key:** Tap the ellipsis (the `...` button in the upper-right corner), then tap the `+ Add Key` button. 2. **Name Your Key:** Enter a descriptive name for your key (e.g., "My Vault Key" or "Main Signer Key"). -3. **Generate Key:** Select the option to "Generate Key" (currently, the only option is to create a hardware key directly in your device's Secure Enclave). Tap `Generate Key`. (NOTE: Software key options planned for the future). - - Your device will securely generate and store a new private key within its Secure Enclave. + + + + +### Generate Key on iOS + +3. **Generate Key:** Tap **Generate Key**. The app creates a **hardware-backed key** in your device’s **Secure Enclave**. Private key material stays in that hardware and is not exposed to normal app memory. + + + + +### Hardware check on first start + +The Android app is in **beta**. When you first start the app, it checks whether your device supports **hardware-backed key storage** through Android’s [Keystore](https://developer.android.com/privacy-and-security/keystore) system. Depending on the device, that may use: + +- **StrongBox** — dedicated tamper-resistant hardware (a discrete secure module) used for Android’s hardware-backed Keystore on devices that ship StrongBox, or +- **TEE-backed Keystore** — keys handled inside a Trusted Execution Environment when StrongBox is not available but the device still offers hardware-isolated key storage. + +If the device **does not** provide the required hardware backing, the app will only offer **software keys**. + +### Generate Key on Android + +3. **Generate Key:** Tap **Generate Key** and follow the prompts. + - **Hardware available:** You can create **hardware-backed keys** (private key material remains in secure hardware). + - **No suitable hardware:** You can create **software keys** only. **Each time** you create a key, the app **alerts you** that you are creating a **software key** (not hardware-protected). + + + + 4. **View Key:** Your newly created key will now appear on the app's main screen. ## 3) Link Your Chia Signer Key to a Chia Cloud Wallet Vault -This step connects your secure key in the Signer app to a specific vault created in the Chia Cloud Wallet. +This step connects your secure key in the Signer app to a specific vault created in the Chia Cloud Wallet. Your spend key cannot be copied off the device; so when you get a new phone and still have your old phone you will want to use your spend key to instantly rekey your vault, if you do not have your old phone you will need to use your recovery phrase and timelocked recovery to rekey your vault. See the [Recovery](/cloud-wallet/recovery) guide. 1. **Initiate Linking (from Chia Cloud Wallet):** On your separate device (where you access your Chia Cloud Wallet), you will begin the process of creating or linking a vault as described [here](/cloud-wallet/getting-started). The Chia Cloud Wallet will display a **QR Code**. 2. **Link Key from Chia Signer App:** There are two primary methods to link a key, depending on whether you've already created the key in the Signer app or are linking for the first time: - - **Method A: Linking an Existing Key (Key selected in Step 2)** + - **Method A: Linking an Existing Key (after you have created and named a key above)** 1. Open the Chia Signer app and ensure your existing key is visible on the main screen. 2. Tap on the specific key you wish to link. 3. Locate and tap the "Link Key" button (this will activate your device's camera). @@ -66,7 +96,7 @@ Once linked, your Signer app becomes the gatekeeper for all transactions from th 1. **Initiate Transaction (from Chia Cloud Wallet):** When you want to send funds or perform other actions from your Chia Cloud Wallet, you will set up the transaction details in the Chia Cloud Wallet interface and click "Send" or confirm the action. 2. **Receive Signing Request (on Chia Signer App):** The Chia Signer app will automatically receive a transaction signing request. You will see a notification or the app will open, displaying the transaction details. -3. **Review Details:** **Carefully review all the transaction details** shown on your Chia Signer app screen (e.g., recipient address, amount, fee). This is your last chance to verify the transaction before it is sent. +3. **Review Details:** Carefully review all the transaction details shown on your Chia Signer app screen (e.g., recipient address, amount, fee). This is your last chance to verify the transaction before it is sent. 4. **Sign Transaction:** If the details are correct, scroll down and tap the `Sign transaction` button within the Chia Signer app. - - Your device may require a biometric (Face ID/Touch ID) or passcode confirmation to authorize the signing. + - Your device may require a biometric (Face ID, Touch ID, fingerprint) or passcode confirmation to authorize the signing. 5. **Confirmation:** Once signed, the transaction is sent to the Chia network via your Chia Cloud Wallet, and you should see a confirmation message on both the Signer app and the Chia Cloud Wallet. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/buy-xch.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/buy-xch.md new file mode 100644 index 00000000000..ce930cd32b7 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/buy-xch.md @@ -0,0 +1,84 @@ +--- +title: Buy XCH +slug: /cloud-wallet/buy-xch +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This guide will show you how to purchase XCH directly within the Chia Cloud Wallet using ACH bank transfers via Stripe. + +:::info + +Before you can buy XCH, you'll need to have a Cloud Wallet account and at least one vault. If you haven't created a vault yet, please follow the [Getting Started Guide](/cloud-wallet/getting-started) first. + +::: + +## 先决条件 + +- An active [Chia Cloud Wallet](https://vault.chia.net/) account with at least one vault +- A US bank account for ACH transfers + +## Purchase Limits + +- **Minimum purchase**: \$25 USD + +## Buying XCH + +1. Log in to your [Chia Cloud Wallet](https://vault.chia.net/) account. + +2. Navigate to the `Buy XCH` screen from the left-hand menu: + +
+ Navigate to Buy XCH screen + Navigate to Buy XCH screen +
+ +3. Enter the amount you want to purchase in USD. The minimum is within the purchase limits, then click `Next`: + +
+ Enter purchase amount + Enter purchase amount +
+ +4. Select a saved bank account, or add a new one: + - **Saved accounts**: If you have previously saved bank accounts, they will appear in a list for you to choose from + - **Add new account**: Click the "US bank account" option to add a new bank account + +
+ Select or add bank account + Select or add bank account +
+ +5. If you're adding a new bank account, follow the Stripe popup prompts to provide your bank account information and complete the setup: + +
+ Stripe popup to add bank account + Stripe popup to add bank account +
+ +6. Review the transaction details, including the amount of XCH you'll receive, the bank account to be used, and any applicable fees. Click `Next` to continue: + +
+ Review transaction details + Review transaction details +
+ +7. Review the confirmation screen and click `Next`. This completes the order. The order details will appear in the order list on the right side of the screen: + +
+ Order confirmation + Order confirmation +
+ +Once your payment is processed, the XCH will be deposited into your vault. ACH transfers are processed through Stripe and typically completes within 7 business days. + +## Troubleshooting + +If you encounter any issues while buying XCH: + +- Ensure your vault has been fully created and an address is available +- Verify your purchase amount is within the purchase limits +- Check that your bank account information is correct in Stripe +- Ensure your bank account has sufficient funds +- For additional support, use [In App Support](/cloud-wallet/in-app-support) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/faq.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/faq.md index 090ee080a46..df3888cab7a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/faq.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/faq.md @@ -14,7 +14,8 @@ The Cloud Wallet is a platform for interacting with the Chia blockchain. Assets ### Is the Chia Cloud Wallet available for mainnet? -是的。 It is in early release as of 6/25/2025 and can be accessed [here](https://vault.chia.net). +Yes, the Chia Cloud Wallet was released on 10/29/2025 and can be accessed [here](https://vault.chia.net). +The testnet version of the Chia Cloud Wallet can be accessed [here](https://vault.chiatest.net/). ### How can I obtain some TXCH for testnet11? @@ -24,6 +25,7 @@ Visit either our [official faucet site](https://testnet11-faucet.chia.net) or a For mainnet visit the [Mainnet Cloud Wallet website](https://vault.chia.net) and sign up for a free account. For testnet visit the [Testnet Cloud Wallet website](https://vault.chiatest.net) and sign up for a free account. +You can refer to our [Getting Started Guide](/cloud-wallet/getting-started) for help setting up your account. ### How is the Cloud Wallet different from other wallets? @@ -83,11 +85,11 @@ We plan to release three tiers with the Cloud Wallet: ### Where can I go for support? -Feel free to ask questions in the #support channel of [our Discord](https://discord.gg/chia). +Open your account menu and choose `Support` to create and track tickets in the Cloud Wallet. See the [In App Support](/cloud-wallet/in-app-support) guide for details. ### Where can I report a bug? -If you find any bugs, feel free to fill out a [bug report](https://docs.google.com/forms/d/e/1FAIpQLSeIAZAxSwTwZPGUVLs7_XKseoPgOmtBa0qhtWNQwBeoo9adRA/viewform). However, please keep in mind that this is early release software. We are aware of several existing bugs. +Create a ticket with the `Bug Report` type from the Support screen. See [In App Support](/cloud-wallet/in-app-support). If you discover any security issues, you can file a report on our [bug bounty site](https://hackerone.com/chia_network). Thanks for your help! @@ -97,6 +99,8 @@ Currently the only tier you can choose is the `Free` tier, which only allows you ## Recovery +For a conceptual overview of Instant Recovery and timelocked recovery, see the [Recovery](/cloud-wallet/recovery) guide. + ### What happens if I lose my spend key? You can use your recovery key to swap out the lost key for a new one. @@ -109,11 +113,31 @@ However, the current setup is not secure against wrench attacks, where the thief ### What happens if I lose my recovery key? -You can use your spend key to send your funds to a new vault. +If you still have your spend key, use [Instant Recovery](/cloud-wallet/recovery/#instant-recovery) to set a new recovery key in a single on-chain step. You confirm the change and sign with your current spend key, with no recovery clawback wait. See the [Recovery](/cloud-wallet/recovery) guide for context. If you have lost both your spend key and any usable backup of your recovery phrase, you cannot regain access to the vault. ### What happens if my recovery key is stolen? Will all of my funds be stolen? -A recovery key can only be used for recovering a vault. If this key is stolen, the thief will not immediately be able to steal your funds. However, they will likely attempt to recover your vault. In this case, the watchtower will send you an email notifying you that your vault is now in recovery mode. The recovery can only be completed after a preset timer has expired. Until this time, you can cancel the recovery and move your funds to a new vault. +A recovery key can only be used for recovering a vault. If this key is stolen, the thief will not immediately be able to steal your funds. However, they will likely attempt to recover your vault. In this case, the watchtower will send you an email notifying you that your vault is now in recovery mode. The recovery can only be completed after a preset timer has expired. Until then, you can cancel the recovery with your spend key during the clawback window. After you cancel, use [Instant Recovery](/cloud-wallet/recovery/#instant-recovery) to rotate your compromised recovery key to a new one so the stolen material no longer works. (You can still move funds to a new vault if you prefer, but Instant Recovery is the direct way to fix the keys on your existing vault.) + +### If I initiate a recovery, and wait for the clawback timer to expire, and then someone steals my recovery key, can the thief swap my keys for theirs without having to re-initiate a recovery? + +No. When you initiate the recovery, you lock in the new keys. The only way to change them is to cancel the recovery and re-initiate it. After the timer expires, the only two options are 1) complete the recovery with exactly the keys you entered, or 2) cancel the recovery and start over. If the thief only has your recovery key, then there is no option to change the keys without waiting for the recovery clawback timer to expire. + +### What is Instant Recovery? + +Instant Recovery lets you rekey your vault immediately using your current spend key: you can change your spend key, recovery key, recovery timelock, or any combination of those, in one confirmed transaction, without waiting for the recovery clawback timer. Common reasons include getting a new phone (Chia Signer keys cannot be copied off the old device), replacing a lost recovery phrase while you still can sign, or rotating a compromised recovery key after you cancel a malicious timelocked recovery. Details: [Recovery](/cloud-wallet/recovery). + +### When should I use Instant Recovery vs Timelocked Recovery? + +If you still have your spend key, use Instant Recovery. If you cannot use your spend key anymore but you do have your recovery phrase (recovery key), use Timelocked Recovery and wait for the clawback period before completing recovery. See [Recovery](/cloud-wallet/recovery). + +### Can I use Instant Recovery to change just my recovery key (or just my timelock) without changing my spend key? + +是的。 During Instant Recovery you can update any combination of spend key, recovery key, and recovery timelock. You are not required to rotate everything at once. + +### What happens if someone initiates a malicious recovery on my vault? + +You receive an email alert. If you still have your spend key and the malicious actor is using timelocked recovery, log into the Chia Cloud Wallet to cancel recovery during the clawback window using your spend key, then use [Instant Recovery](/cloud-wallet/recovery/#instant-recovery) to set a new recovery key so the attacker’s copy of the old recovery material cannot be used again. Note - if the attacker has gained access to your spend key they can use instant recovery to rekey both the spend and recovery key in which there is nothing you nor we at Chia Network, Inc. can do to recover the vault or stop the attacker. See [Recovery](/cloud-wallet/recovery). ## Watchtowers @@ -133,14 +157,16 @@ Yes! The Chia blockchain is a public ledger, so anyone can build software to mon ### What is the Chia Signer app? -The Chia Signer app turns your smartphone into a hardware wallet. The app uses your phone's Secure Enclave to create a vault spend key. This key cannot be removed from the device, so a thief would need to gain physical access to your phone in order to steal it. You can download it from the [iOS App Store](https://apps.apple.com/app/chia-signer/id6504493785). +The Chia Signer app turns your smartphone into a hardware wallet. The app uses **hardware-protected storage** on your phone (Secure Enclave on iOS; hardware-backed keystore / StrongBox on supported Android devices, the Android app is in **beta**) to create a vault spend key. This key cannot be removed from the device, so a thief would need to gain physical access to your phone in order to steal it. + +Download **iOS** from the [App Store](https://apps.apple.com/app/chia-signer/id6504493785). **Android** is in **beta** on [Google Play](https://play.google.com/store/apps/details?id=net.chia.android.signer). :::info Currently, in order to use the Chia Signer app, you will need two separate devices: 1. A computer or phone to access your vault -2. An iOS device on which the Chia Signer app is installed +2. A smartphone (iOS, or Android in beta) with the Chia Signer app installed You cannot use both the Cloud Wallet and the Chia Signer app on the same device yet. However, we do intend to enable this functionality in a future release. @@ -148,25 +174,23 @@ You cannot use both the Cloud Wallet and the Chia Signer app on the same device ### Is the Chia Signer app available for both Android and iOS? -It is currently only available for iOS. We will build an Android version in the future. +是的。 -### On which iOS devices is the Chia Signer app supported? +**iOS:** [App Store](https://apps.apple.com/app/chia-signer/id6504493785). -The app has two requirements for iOS devices: +**Android** (beta): [Google Play](https://play.google.com/store/apps/details?id=net.chia.android.signer). -1. The device must run iOS 15 or later -2. The device must have a Secure Enclave +### On which iOS devices is the Chia Signer app supported? -The following devices meet both of these requirements: +See the [App Store listing](https://apps.apple.com/app/chia-signer/id6504493785) for the current minimum OS version and device compatibility. In general, the app targets **iOS 15 or later** on devices with a **Secure Enclave**. -- iPhone models beginning with the iPhone 6 -- iPad models beginning with the iPad mini 4 +### On which Android devices is the Chia Signer app supported? -Be sure to double check that your device is running at least iOS 15 prior to installing the Chia Signer app. +The Android app is in **beta**. Supported devices and OS requirements are shown on the [Google Play listing](https://play.google.com/store/apps/details?id=net.chia.android.signer). The Play Store is the most up-to-date source for compatibility. ### Is it safe to install the Chia Signer app on a second-hand device? -Yes -- just be sure to do a factory reset of the device first. See [Apple's support site](https://support.apple.com/guide/iphone/iph7a2a9399b/ios) for instructions. +Yes -- just be sure to **factory reset** the device first so any prior owner's data and keys are wiped. For **iOS**, see [Apple's support site](https://support.apple.com/guide/iphone/iph7a2a9399b/ios). For **Android**, see [Google's guide to resetting your device](https://support.google.com/android/answer/6088915). ### Does the Chia Signer app use blind signing? @@ -176,8 +200,22 @@ No, but it doesn't use clear signing yet, either. The user is shown the details No, the Chia Signer app is only for signing transactions. You will need to use either a password or a passkey to sign into your Cloud Wallet account. +### Can I use the same phone as a signer for multiple vaults or accounts? + +是的。 The Chia Signer app is quite flexible. It supports multiple hardware keys within the app, as well as using a hardware key as a signer for multiple Cloud Wallet accounts and vaults. + +However, you should still consider your security posture before reusing a hardware key. For example, if you want to use a single key for two separate accounts, both of which you control, then this is generally safe. On the other hand, if you want to share one Chia Signer device between multiple people, then this requires a high degree of trust between all parties. + +In general, as more vaults, Cloud Wallet accounts, hardware keys, and software keys are being added to the same Chia Signer device, the security of that device decreases. Always consider the risk of your phone being lost or stolen, along with the consequences if that were to happen. + ## Security and privacy +### Does Chia Network have access to my vault keys, or can CNI recover my vault if I lose them? + +**No.** Chia Network, Inc. (CNI) does **not** have access to your vault’s **spend keys** or **recovery keys**. Those credentials stay with you—on your devices, with your passkey provider, or wherever you stored your recovery material—and are not held by CNI in a form that would let us sign transactions or recovery on your behalf. + +If you permanently lose access to **both** your spend key and your recovery key (including any usable backup of your recovery phrase), **CNI cannot recover your keys or restore access to your vault**. Self-custody means there is no master key or back door; only someone who holds the required keys can spend or complete recovery. + ### Will CNI be able to freeze and/or confiscate my assets? No. CNI won't custody any of your assets, so it won't have the ability to freeze or confiscate them. If the Cloud Wallet website were forcibly shut down, you would still have the ability to spend your assets because you would still be in control of the keys associated with your vault. However, the infrastructure to accomplish this would need to be rebuilt. @@ -204,3 +242,25 @@ In addition, in the future we plan to support vaults with multiple receive addre ### Will the Chia Signer app be open source? Yes + +## Buy XCH + +### Who can use Buy XCH? + +Buy XCH is currently available for users with US based, ACH-enabled bank accounts compatible with Stripes payment system. We are working to expand to other regions. + +### How does the Buy XCH Process work? + +Securely link your bank account and complete a purchase in the Cloud Wallet. A clawback transaction appears in your vault immediately for the purchased XCH. A day or so after the payment is initiated, the funds will leave your bank. Once your payment settles (usually within seven business days) the clawback transaction is finalized and your XCH is ready to spend. + +### Why do I see a “pending” transaction in my vault? + +XCH purchase transactions use Chia’s Clawback 2.0 feature ensuring that if your bank payment does not clear, the transaction can be safely reversed. + +### What does “Finalizing“ a Clawback Transaction mean? + +Unlike the original implementation of Clawbacks, Clawback 2.0 lets the sender finalize a transaction early, immediately releasing the funds to the recipient. This enhanced flexibility is used in Buy XCH to complete your transaction as soon as your bank payment clears. + +### What are the purchase limits for Buy XCH? + +Users currently have a minimum purchase limit of \$25. Limits help keep the system stable and secure during rollout. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/getting-started.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/getting-started.md index 5430bce8127..ac9946accd5 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/getting-started.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/getting-started.md @@ -6,7 +6,7 @@ slug: /cloud-wallet/getting-started import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -Welcome to the Chia Cloud Wallet, a new platform for interacting with the Chia blockchain. Assets are stored in vaults, in an app that is always synced with the blockchain. The Cloud Wallet is currently in beta, running on testnet11. +Welcome to the Chia Cloud Wallet, a new platform for interacting with the Chia blockchain. Assets are stored in vaults, in an app that is always synced with the blockchain. This guide will show you how to create your first Cloud Wallet vault in a few easy steps. @@ -43,7 +43,7 @@ Congratulations, you're all set to create your first vault! Currently, in order to use the Chia Signer app, you will need two separate devices: 1. A computer or phone to access your vault -2. An iOS device on which the Chia Signer app is installed +2. A smartphone (iOS, or Android in beta) with the Chia Signer app installed You cannot use both the Cloud Wallet and the Chia Signer app on the same device yet. However, we do intend to enable this functionality in a future release. @@ -57,13 +57,11 @@ You cannot use both the Cloud Wallet and the Chia Signer app on the same device 2. Give your vault a name, for example `My Signer Vault`. -3. You will need to scan the QR code using your Chia Signer app. If you don't have the app yet, you can download it from the [iOS App Store](https://apps.apple.com/app/chia-signer/id6504493785). +3. You will need to scan the QR code using your Chia Signer app. If you don't have the app yet: **iOS** — [App Store](https://apps.apple.com/app/chia-signer/id6504493785); **Android** (beta) — [Google Play](https://play.google.com/store/apps/details?id=net.chia.android.signer). -Note: The Chia Signer app currently is only built for iOS devices. We will build an Android version of the app in the future. - -
- Create vault with signer app -
+
+ Create vault with signer app +
4. From the Chia Signer app, tap the `+` button in the upper-right corner to add a new key: @@ -71,7 +69,7 @@ Note: The Chia Signer app currently is only built for iOS devices. We will build Create a new key -5. Give your new key a name, for example `My Key`. Currently, the only option is to create a hardware key directly in your device's Secure Enclave. Tap `Generate Key`: +5. Give your new key a name, for example `My Key`. Currently, the only option is to create a hardware-backed key in your device's secure hardware (Secure Enclave on iOS; hardware-backed keystore on Android, which is in beta). Tap `Generate Key`:
Generate a hardware key @@ -101,15 +99,15 @@ Note: The Chia Signer app currently is only built for iOS devices. We will build Link your key to your vault
-10. If a green check box appears over the QR code, then your signer app was successfully linked to your vault: +10. When linking succeeds, a green checkmark appears over the QR code on the Cloud Wallet page (this is a status indicator, not a checkbox you need to click):
- Signer successfully linked + Green checkmark indicating the signer was successfully linked
11. Next, copy the 24 words to a safe location. You will need to recall these words in order to recover your vault, so don't lose them. -12. You can also set a custom time for your vault's recovery clawback. This is the amount of time you will need to wait in order to recover your vault. If your 24-word recovery phrase is stolen, then you will have this long to cancel the recovery. +12. You can also set a custom time for your vault's recovery clawback. This is the amount of time you will need to wait in order to recover your vault. If your 24-word recovery phrase is stolen, then you will have this long to cancel the recovery. For how Instant Recovery and timelocked recovery work together, see the [Recovery](/cloud-wallet/recovery) guide. 13. Click the `Create` button to create your vault. A "vault faucet" will mint a new vault for you. Your vault's receive address will appear after this process is complete (typically a minute or two). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/in-app-support.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/in-app-support.md new file mode 100644 index 00000000000..e5a64a3a184 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/in-app-support.md @@ -0,0 +1,84 @@ +--- +title: In App Support +slug: /cloud-wallet/in-app-support +--- + +This guide shows how to contact Cloud Wallet support from inside the app, track your tickets, and reply until the issue is resolved. + +## Opening Support + +1. Log in to your [Chia Cloud Wallet](https://vault.chia.net/) account. + +2. Open your account menu from the profile control, then click `Support`: + +
+ Open Support from the account menu + Open Support from the account menu +
+ +3. The Support screen lists your tickets under `Your Tickets`. Use `Create Ticket` to start a new request. Toggle `Show Completed` when you want to include solved and closed tickets in the list: + +
+ Your Tickets list on the Support screen + Your Tickets list on the Support screen +
+ +If you have not created any tickets yet, the empty state invites you to create your first ticket. + +## Creating a ticket + +1. From the Support screen, click `Create Ticket`. + +2. Fill in the form: + + - `Subject` (required): a short summary of the issue (up to 150 characters) + - `Ticket Type` (required): choose the category that best matches your request (see [Ticket types](#ticket-types)) + - `Details` (required): a full description of what happened and what you expected + - `Attachments` (optional): PNG or JPEG screenshots. Total attachment size must stay under 2 MB + - `Vault` (optional): select the vault related to the issue when you have one or more vaults + +
+ Create Ticket form + Create Ticket form +
+ +3. Click `Submit Ticket`. After a successful submit, the app returns you to the Support list and shows a confirmation that includes the new ticket number when available. + +Click `Cancel` at any time to return to the Support list without submitting. + +### Ticket types + +| Ticket type | Use when | +| ------------- | ---------------------------------------------------------- | +| `Support` | General help with your account, vaults, or wallet features | +| `Bug Report` | Something in the product is not working as expected | +| `Enhancement` | You want to request a product improvement | +| `Buy XCH` | Help with purchasing XCH in the Cloud Wallet | + +## Viewing a ticket and replying + +1. On the Support screen, click a ticket card to open it. + +2. The ticket detail view shows the subject, ticket number, status, created and last updated times, ticket type when available, the message thread, and a `Reply` section at the bottom: + +
+ Support ticket detail with messages and reply + Support ticket detail with messages and reply +
+ +3. To reply, enter a message in the `Reply` section. You can attach optional PNG or JPEG files (same 2 MB total limit as when creating a ticket), then click `Send`. + +### Closing or reopening a ticket + +While a ticket is still open (not solved or closed): + +- Click `Close without Reply` to mark it solved without adding a message +- Enter a reply and click `Close with Reply` to close it with a final note + +If a ticket is `Solved`, enter a reply and click `Reopen with Reply` to open it again. + +Permanently `Closed` tickets show an alert that new replies are not accepted. Create a new ticket if you still need help. + +## Troubleshooting + +If you cannot use In App Support, visit the #support channel in [our Discord](https://discord.gg/chia). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/known-issues.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/known-issues.md index f3a754aa202..e05db010f7a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/known-issues.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/known-issues.md @@ -6,11 +6,11 @@ slug: /cloud-wallet/known-issues import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -This list was last updated on 2025-07-28. In addition to the items shown here, there are several minor UI/UX issues that we will also fix. +This list was last updated on 2025-09-30. In addition to the items shown here, there are several minor UI/UX issues that we will also fix. If you find any issues that you think are security related, please file a report at our [HackerOne site](https://hackerone.com/chia_network). -Feel free to report other issues on [our Discord server](https://discord.gg/chia). +Feel free to report other issues through [In App Support](/cloud-wallet/in-app-support). ## Cloud Wallet Known Issues @@ -19,14 +19,11 @@ Feel free to report other issues on [our Discord server](https://discord.gg/chia - If you have a brand new vault, you might not be able to create a new Offer until your vault has submitted at least one transaction. We are working on a fix for this issue. In the meantime, a workaround is to send XCH or a CAT to yourself from your own vault. After this initial transaction, the vault will not encounter the issue again. - If you are accessing the Cloud Wallet on an Android phone, you may not be able to create a passkey with a Yubikey or other hardware device. - We have experienced issues with other combinations of OS and passkey type, especially on mobile devices. These issues are typically related to the device itself, and are out of our control to fix. However, we will work on reporting these limitations more clearly when they occur. -- If you rename any tokens in your vault, and then create an Offer that involves those tokens, the old names will be displayed in the Offer. We will show the new names soon. -- The cloud wallet is currently the only wallet that supports vault based offers. This means if you create an offer in the cloud wallet the taker will need to accept the offer in their cloud wallet account. -- In some circumstances such as receiving a payout from a pool, the transaction list does not properly update and show the transactions. Generally the balance is updated properly but in rare cases it is not. We are resolving these issues to ensure the balance and transaction list is properly updated. The funds are still in the wallet even when these are not shown. ## Resolved Previously Known Issues :::note -Let us know on [our Discord server](https://discord.gg/chia) if you are still experiencing these issues: +Let us know through [In App Support](/cloud-wallet/in-app-support) if you are still experiencing these issues: ::: - The signer popups in the Cloud Wallet and Signer app for certain transaction types currently show incomplete details. This is only a display issue that we will fix soon. The signature requests themselves do work as designed. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/recovery.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/recovery.md new file mode 100644 index 00000000000..6698def2478 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/recovery.md @@ -0,0 +1,62 @@ +--- +title: Recovery +slug: /cloud-wallet/recovery +--- + +In the Cloud Wallet, recovery means rekeying your vault: you change one or more of the vault’s spend key, recovery key, and/or recovery timelock. Recovery does not move your coins to a different vault by itself; it updates which keys and recovery timelock/clawback rules control the vault you already have. + +There are two ways to recover a vault: Instant Recovery and Timelocked Recovery. They address different situations depending on whether you still have your spend key. + +## Instant Recovery + +Instant Recovery (also called Instant Rekey) lets you rotate your vault’s spend key, recovery key, and/or recovery timelock immediately, in a single transaction, with no waiting period. You prove you still control the vault by signing with your current spend key. The app asks you to confirm explicitly; nothing runs automatically. + +### When to use it + +Use Instant Recovery when you still have your spend key and you need to change keys or the timelock without going through timelocked recovery. + +Primary use cases: + +1. New device. If you use the Chia Signer app, your spend key lives in hardware-backed storage on your phone and cannot be copied to another device. When you get a new phone, you migrate by rekeying. As long as you still have the old device, you can use Instant Recovery to point the vault at keys on the new device. + +2. Emergency or compromised recovery key. If someone else gets your recovery material (for example your 24-word phrase) and starts a timelocked recovery, they must wait for the recovery clawback timer to expire. You will receive an email alert for the attempted recovery. You cancel that recovery with your spend key during the clawback window, then use Instant Recovery to set a new recovery key so the compromised recovery key is no longer valid. + +3. Lost recovery key. If you still have your spend key but never backed up your recovery phrase (or lost it), you are not stuck forever: use Instant Recovery to install a new recovery key without waiting. + +### Requirements + +You must still possess the vault’s current spend key. Instant Recovery is not available if the spend key is lost, stolen in a way you cannot use, or otherwise inaccessible. In those cases you use Timelocked Recovery with your recovery key (if you have it). + +### How it works (high level) + +You choose the new spend key, recovery key, and/or timelock values the vault should use next. You confirm the action in the app. You sign the rekey transaction with your existing spend key. After the transaction confirms on-chain, the vault is updated immediately. There is no clawback wait for this path. + +## Timelocked Recovery + +Timelocked Recovery is for when you no longer have access to your spend key, for example if your phone is lost or damaged and you cannot sign with the Signer key anymore. + +### What you need + +Your recovery key (for example your 24-word recovery phrase for a BLS recovery key). + +### What to expect + +You initiate recovery with the recovery key and propose the new keys/timelock. The vault enforces a recovery clawback period before the recovery can be completed. During that window, anyone who still has the old spend key can cancel the recovery. After the timer expires, you complete recovery with the keys you locked in when you started (you cannot silently swap to different keys mid-flight without going through the rules described in the [FAQ](/cloud-wallet/faq#recovery)). + +:::warning + +If you lose both your spend key and your recovery key (with no usable backup), no recovery path can restore the vault. Chia Network does not hold copies of your keys. + +::: + +## Which should I use? + +| Situation | Path | +| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| You still have your spend key | Instant Recovery: fast rekey, no clawback wait for the rekey itself. | +| You lost your spend key (or cannot use it) | Timelocked Recovery: use your recovery phrase and wait for the clawback period before completing recovery. | +| Your recovery key is compromised | Cancel any pending timelocked recovery with your spend key during the clawback window, then Instant Recovery to rotate to a new recovery key. | + +## Recovery clawback + +When a vault is created, you set a recovery clawback duration (a waiting period). If someone starts a timelocked recovery, that timer must elapse before the recovery can finish. The delay gives the legitimate owner, who may still have the spend key, time to see an alert (for example by email) and cancel a malicious attempt. Instant Recovery does not replace this mechanism for the timelocked path; it is the fast path when the spend key is still yours. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/tooltips.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/tooltips.md index b166945f924..a5e99d1f8c6 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/tooltips.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/tooltips.md @@ -10,7 +10,23 @@ This page contains tooltip links from the Cloud Wallet. It provides some basic i ## Recovery -This is the process of rekeying a vault. If your spend key is lost or stolen, you can swap it out for a new one. For example, if someone steals your smartphone where your Chia Signer app is installed, you can obtain a new phone, install the Chia Signer app, and create a new hardware key. You can then instruct your vault to replace the stolen key with the new one. The recovery process also allows you to change your recovery key if desired. +This is the process of rekeying a vault. It will allow you to change any combination of your vault's spend key, recovery key, and recovery timelock. There are two types of recovery, explained in the following sections: Instant and Timelocked. More information about recovery is available on the [Recovery](/cloud-wallet/recovery) guide. + +### Instant Recovery + +If you still have access to your spend key, you can recover your vault without having to wait for the clawback period to expire. There are three primary use cases for Instant Recovery (also known as Instant Rekey): + +1. **New Device** -- If you use the Chia Signer app, then your vault's spend key is stored in hardware-protected storage on your smartphone. It can never be copied or moved to another device, so when you obtain a new phone, you will need to recover your vault. As long as you still have your original phone, you can instantly rekey your vault to use your new device. + +2. **Emergency Recovery** -- If an adversary obtains a copy of your recovery key (for example, your 24-word phrase), then the adversary can attempt to recover your vault in order to drain its funds. However, they will need to wait for the recovery clawback period to expire before doing so. You will receive an email as a warning that the recovery attempt is in progress. As long as you still have your spend key (e.g. your smart phone or your passkey), you can cancel the recovery attempt, and instantly rekey your vault's recovery phrase to a new one. The adversary will no longer be able to attempt to steal your funds. + +3. **New User (Multisig)** -- It's also possible to rekey a multisig vault by using the Instant Recovery feature. For example, if one member of a 2-of-3 multisig vault is leaving the organization, you can instantly rekey that user's key in favor of a new one. + +Instant Recovery is only available when you still possess your vault's spend key. If you no longer have that key, then you will need to perform a Timelocked Recovery. + +### Timelocked Recovery + +If you no longer have access to your vault's spend key, then you can perform a Timelocked Recovery by using your vault's recovery key. For example, if you use the Chia Signer app and your phone is lost, damaged, or stolen, you can change your vault's spend key to a new device. You will need to sign the recovery transaction with your vault's recovery key. You will also need to wait for the recovery clawback to expire before you can complete the recovery. ## Spend Key @@ -22,7 +38,11 @@ This key can only be used for recovering a vault. It cannot be used for signing ## Transaction Fee -A fee for speeding up your transaction’s confirmation time if the network is busy. Testnet11 is often being dusted with small transactions, so we recommend including a fee whenever possible. Typically 0.001 TXCH is sufficient for fast confirmation on testnet11. +A fee for speeding up your transaction’s confirmation time if the network is busy. + +On mainnet, this fee is expressed in `XCH`. The recommended amount will depend on how busy the network is. + +On testnets, this fee is expressed in `TXCH`. A fee of 0.001 TXCH is often necessary -- and typically sufficient -- on these networks. ## Recovery Clawback @@ -34,11 +54,11 @@ If you use a BLS key as the recovery key, you will be given a series of 24 words ## Recovery Timer -This is the amount of time you must wait before a recovery operation can be completed. The timer is set upon the vault’s creation, and it can only be modified during a recovery. For example, when you create a vault, if you set this timer to 3 days, then after you initiate a recovery, you will need to wait for 3 days to complete it. During that time, you can cancel the recovery. The reason this timer exists is so that if someone steals your recovery key, you can cancel any recovery attempts, and send your assets to a new vault. +This is the amount of time you must wait before a recovery operation can be completed. The timer is set upon the vault’s creation, and it can only be modified during a recovery. For example, when you create a vault, if you set this timer to 3 days, then after you initiate a recovery, you will need to wait for 3 days to complete it. During that time, you can cancel the recovery. The reason this timer exists is so that if someone steals your recovery key, you can cancel recovery attempts during the window, then use Instant Recovery to rotate your recovery key while you still have your spend key. See the [Recovery](/cloud-wallet/recovery) guide. ## Signer App -A smartphone app initially available for iPhones made after 2013. The app stores a spend key in its Secure Enclave. This key cannot be copied or removed from the phone, so the only way to steal it is to gain physical access to the device. For this reason, we strongly recommend that you secure the Signer app using your phone’s biometrics. +A smartphone app for **iOS** and **Android** (Android is in **beta**). The app stores a spend key in hardware-protected storage on the device (Secure Enclave on iOS; hardware-backed keystore / StrongBox on supported Android devices). This key cannot be copied or removed from the phone, so the only way to steal it is to gain physical access to the device. For this reason, we strongly recommend that you secure the Signer app using your phone’s biometrics. **iOS:** [App Store](https://apps.apple.com/app/chia-signer/id6504493785). **Android** (beta): [Google Play](https://play.google.com/store/apps/details?id=net.chia.android.signer). ## Clawback @@ -50,3 +70,177 @@ For example, Alice sends 1 XCH to Bob, and she adds a 1-hour clawback. - Let's say Alice accidentally sent the XCH to the wrong address. During the 1-hour clawback period, she can claw the 1 XCH back to her vault. - On the other hand, maybe Bob contacts Alice to let her know that he can see the incoming XCH. In this case, Alice can finalize the transaction before the 1-hour timer has expired. - After the 1-hour timer has expired, Alice can no longer claw back the funds. The 1 XCH is now automatically counted with Bob's vault balance. + +## Key Types + +The Chia Cloud Wallet allows a number of different key types to be used as both spend keys and recovery keys. However, while the Cloud Wallet is quite flexible in this regard, not every key type is appropriate in every situation. + +Please read this section before deciding on which types of keys to use in your vault. + +### App (Hardware key) + +Create a hardware-backed key in your device's secure hardware (Secure Enclave on iOS; hardware-backed keystore on Android, currently in beta). This key can never be removed from your device. See our [Getting Started Guide](/chia-signer/getting-started/) for more info. + +#### Bottom Line + +We recommend that you use this key type as a spend key, but not as a recovery key in most situations. + +#### Usage Details + +**As a spend key** + +- **Allowed: Yes** +- **Recommended: Yes** +- The Chia Signer app turns your phone into a hardware wallet, which you can take everywhere +- If you install the app on your primary phone, be sure to leave `Login with biometrics or device pin` enabled +- For added security, we will release a version with air-gapped signing soon +- If your phone is lost, stolen, or damaged, you can recover your vault to a new phone by using one of the recommended recovery keys + +**As a recovery key** + +- **Allowed: Yes** +- **Recommended: No in most circumstances** +- The hardware key cannot be copied, which means that if you lose it, it's gone forever +- If you use a hardware key as your vault's only recovery key, then you risk not being able to recover your funds +- This key type could be used as one of several recovery keys in a multisig vault, where losing a single key would not be catastrophic + +### App (Software key) + +This key type uses a 24-word mnemonic phrase. It allows you to store a backup in your iCloud account (for iOS devices) or another cloud provider (for Android devices, coming soon). + +#### Bottom Line + +This key type may not be used as a spend key. It is our recommended recovery key type for most use cases. + +#### Usage Details + +**As a spend key** + +- **Allowed: No** +- A 24-word mnemonic phrase is not appropriate as a spend key because if someone obtains a copy of it, they can steal all of the vault's funds + +**As a recovery key** + +- **Allowed: Yes** +- **Recommended: Yes** +- Your key will be stored in your Chia Signer app +- We recommend saving a copy of this key to your iCloud keychain (enabled by default) +- We also recommend securing your iCloud account with two Yubikeys +- If you follow these recommendations, then nobody but you (not even Apple) will have access to the key +- If you lose your phone, then + - Install the Chia Signer app on a new phone + - Use the app to recover your software recovery key from your iCloud keychain + - Use your software recovery key to recover your vault to a new hardware spend key + +### Recovery phrase + +This is the same key type as `App (Software key)` but instead of storing the key in your Chia Signer app, the mnemonic phrase will be be displayed for you to copy. + +#### Bottom Line + +This key type may not be used as a spend key. We recommend using it as a recovery key if you are not using the Chia Signer app. + +#### Usage Details + +**As a spend key** + +- **Allowed: No** +- A 24-word mnemonic phrase is not appropriate as a spend key because if someone obtains a copy of it, they can steal all of the vault's funds + +**As a recovery key** + +- **Allowed: Yes** +- **Recommended: Yes** +- Carefully copy your mnemonic phrase to a safe location +- Be sure to copy the phrase correctly because we are unable to display it again later +- If you lose your spend key, then you will need to enter this phrase in order to recover your vault + +### Passkey + +A passkey is a replacement for a password. It can be stored in many different formats, such as in a password manager, in a web browser, on an OS keychain, or on a hardware device such as a Yubikey. + +#### Bottom Line + +We recommend using a passkey as a spend key if you are unable to use the Chia Signer app. We don't recommend using it as a recovery key in most situations. + +#### Usage Details + +**As a spend key** + +- **Allowed: Yes** +- **Recommended: Yes, if unable to use the Chia Signer app** +- A passkey is a less secure option than using the Chia Signer app +- Passkeys don't have screens, so you won't be able to see what you are signing with 100% certainty (you will need to rely on blind signing) +- Be sure to take appropriate security measures to ensure that your passkey cannot easily be accessed in case your device is stolen (eg ensure that your password manager automatically locks after not being used for a few minutes) +- If your passkey is lost, stolen, or damaged, you can recover your vault to a new phone by using one of the recommended recovery keys + +**As a recovery key** + +- **Allowed: Yes** +- **Recommended: No in most circumstances** +- A passkey cannot be copied, which means that if you lose it, it's gone forever +- If you use a passkey as your vault's only recovery key, then you risk not being able to recover your funds +- This key type could be used as one of several recovery keys in a multisig vault, where losing a single key would not be catastrophic + +### Vault + +Use another Cloud Wallet vault that you control as a signer. Not available with free accounts. Typically used with multisig configurations. + +#### Bottom Line + +We recommend using a vault as either a spend key or a recovery key in some situations, especially as part of a multisig setup. + +#### Usage Details + +**As a spend key** + +- **Allowed: Yes** +- **Recommended: Yes** +- Select any of your other vaults, including multisig vaults +- Modify your spend key without affecting this vault +- Maximum vault depth is 3 + +**As a recovery key** + +- **Allowed: Yes** +- **Recommended: Yes** +- Select any of your other vaults, including multisig vaults +- Modify your recovery key without affecting this vault +- Maximum vault depth is 3 + +### Recovery Provider + +Coming soon -- allow a trusted institution to initiate a recovery of your vault. + +#### Bottom Line + +Recovery providers can only be used as recovery keys. We recommend using one if you are concerned about losing access to your recovery key. + +#### Usage Details + +**As a spend key** + +- **Allowed: No** +- We don't allow this option because it would allow the provider to drain your vault's funds + +**As a recovery key** + +- **Allowed: Yes** +- **Recommended: Yes, in some situations** +- If you lose your spend key, you can ask your recovery provider to initiate a recovery +- They will need to verify your identity before initiating the recovery +- If they initiate a recovery you didn't request, you can cancel it and rekey them out of your vault +- Can also be used as a "last resort" recovery signer in a multisig setup +- Recovery providers will typically charge a fee for their services + +## Broadcast Messages + +Token issuers can send messages to holders of their tokens. These messages can be broadcast for a number of reasons, such as notifying users of an upcoming airdrop. You can subscribe to any issuer to receive their messages. + +## Topics + +Token issuers can send messages with a variety of different topics. You can subscribe to your choice of topics, for example: + +- /company/general +- /company/airdrops +- /company/meetups/miami diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md index 801b8463b30..5025234d2dd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/contribution/using-github.md @@ -108,6 +108,20 @@ Right now, you have a fork of the chia-docs repository, but you do not have the All Chia related Github repos require the signing of commits, follow the outlined process to setup automated commit signing for the Github Desktop Application. +You can sign commits with **GPG** (below) or **SSH**. GitHub documents both in [About commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). + +#### SSH commit signing + +:::info +The below information has been adapted from the [GitHub docs on SSH commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). +::: + +1. [Generate a new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) and add the public key to your GitHub account under **Settings → SSH and GPG keys**. +2. [Tell Git to sign commits with SSH](https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key): set `git config --global gpg.format ssh` and `git config --global user.signingkey` to your public key path (for example `~/.ssh/id_ed25519.pub`). +3. Enable signing: `git config --global commit.gpgsign true` (Git uses this setting for SSH signing as well when `gpg.format` is `ssh`). + +SSH-signed commits show as **Verified** on GitHub when the signing key is on your account. + #### Generating a New GPG Key :::info @@ -123,6 +137,7 @@ Note: Before generating a new GPG key, make sure you've verified your email addr 2. Open Git Bash. 3. Generate a GPG key pair. Since there are multiple versions of GPG, you may need to consult the relevant [man page](https://en.wikipedia.org/wiki/Man_page) to find the appropriate key generation command. + - If you are on version 2.1.17 or greater, paste the text below to generate a GPG key pair. ```shell diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md index c26008f3f60..4ce7a987b1f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/dev-guides-home.md @@ -29,7 +29,7 @@ import SimulatorGuide from '@site/static/img/home_pages/simulator_guide.png'; import WalletConnect from '@site/static/img/home_pages/wallet_connect.png'; import GreatChia from '@site/static/img/home_pages/chia_great.png'; -import AppDev from '@site/static/img/home_pages/chia_dev.png'; +import AppDev from '@site/static/img/home_pages/dev_on_chia.png'; import ToolsSetup from '@site/static/img/home_pages/env_setup.png'; import ProgrammingClsp from '@site/static/img/home_pages/clsp_programming.png'; import CoinLifecycle from '@site/static/img/home_pages/coin_lifecycle.png'; diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md index 36a6bcc5519..2c25a19e4b6 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat-creation-tutorial.md @@ -33,8 +33,8 @@ CAT denominations, as well as the rules behind issuance and melting, can take so - In a similar vein, Chia Network Inc. has made the design decision to map 1 CAT to 1000 mojos. This ratio will be the same for all CATs. :::caution - Theoretically, it would be possible to set the CAT:mojo ratio to something other than 1:1000 for a specific CAT, but we strongly recommend against doing this. The Chia reference wallet will not support CATs with a ratio other than 1:1000. Additionally, if you created your own wallet with support for different ratios, users of this wallet would almost certainly be confused and accidentally spend too much or too little money, by multiple orders of magnitude. Please don't attempt this. - ::: +Theoretically, it would be possible to set the CAT:mojo ratio to something other than 1:1000 for a specific CAT, but we strongly recommend against doing this. The Chia reference wallet will not support CATs with a ratio other than 1:1000. Additionally, if you created your own wallet with support for different ratios, users of this wallet would almost certainly be confused and accidentally spend too much or too little money, by multiple orders of magnitude. Please don't attempt this. +::: - The melt value of a single token is 1000 mojos. This remains true regardless of the token's face value or its circulating supply. - A token's face value and its melt value are not necessarily correlated, let alone matched. @@ -56,7 +56,7 @@ Ensure that you have Python 3.7 or later by running: - Linux/MacOS -- `python3 --version` - Windows -- `python --version` -1. Install the latest version of Chia's reference wallet. For more info, see our [installation guide](/reference-client/install-and-setup/installation). +1. Install the latest version of Chia's reference wallet. For more info, see our [installation guide](/installation). For more info, see our [installation guide](/reference-client/install-and-setup/installation). 2. Configure Chia to run on testnet11. Configure Chia to run on testnet10. For more info, see our [testnet documentation](/guides/crash-course/introduction#getting-on-testnet). @@ -145,10 +145,10 @@ pip install chia-dev-tools --no-deps Install pytest: -````bash +```bash pip install pytest ``` ./venv/bin/activate -```` +``` Install the prerequisites: @@ -226,14 +226,13 @@ pip install pytest :::note You might receive an error such as ERROR: Failed building wheel for CAT-admin-tool. This is likely safe to ignore. As long as you can run cats --help without errors, the tool has been installed properly. ::: - -```` +``` Install Chia dev tools: ```bash pip install chia-dev-tools --no-deps -```` +``` Install pytest: @@ -243,7 +242,7 @@ pip install pytest :::note You might receive an error such as ERROR: Failed building wheel for CAT-admin-tool. This is likely safe to ignore. As long as you can run cats --help without errors, the tool has been installed properly. -::: +::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md index 2e2ca98bd49..1bbab6e231d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-issuance.md @@ -61,20 +61,20 @@ python -m venv venv -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` @@ -166,7 +166,7 @@ If you are unsure whether your CAT used a single- or multi-issuance TAIL, step 1 - You can run either the light wallet or a full node. - You are recommended to have enough mojos to cover transaction fees for the reissuance. The recommended amount is five hundred thousand (500,000) mojos per coin to be reissued. - You are **required** to have a single coin that is large enough to cover the entire reissuance. Even if your XCH balance is sufficient, it may be separated into multiple small coins. The easiest way to ensure that you have a sufficiently large coin is to send a transaction to yourself of at least the total value required. - ::: +::: 3. Use the CAT Admin Tool to select a coin that will be used for issuing the CAT2 tokens. @@ -211,7 +211,7 @@ cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to xch1rh6punh4 ```bash -cats --tail ./reference_tails/delegated_tail.clsp.hex --curry 0x8a7afe10d00899b94cf0d407b85e1b9fca21868bcf158563fe9432b60e36db7136055186221fbd27ecc7fc0d5b99ef1b --send-to xch1rd7hejemt57amqtxq8azqg90hgxyhd9shwyjuppq5ez2jn4rlznscn4efy --amount 6000000000 --as-bytes --solution "(a (q 2 (i 47 (q 8) (q 2 (i (= 45 2) () (q 8)) 1)) 1) (c (q . 0x11038a7e107cb7e17a503ba201d94166018deecd777314e4697c5269d9f37fb6) 1))" --signature b75390ee21b001b7a721f719ff045e3dc2a1072ab0824a8e75c881398db0fbed8fde5c62bbdfe629dce5da3d77834559016acd6d403f9b90d3102da2e9452461457514088af0cabe0b8a8493fc9c09d1785f1322abc8958ecf7907eba0e0abcc +cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to xch1rh6punh4fy70y80ef4g89c9hqvm54dtl0fvyc4ejdccp3y6p04fqn5x8x8 --amount 1000000000000 --as-bytes --select-coin ``` @@ -365,7 +365,7 @@ You need to use the same public/private key pair to sign the CAT2 issuance as yo - You can run either the light wallet or a full node. - You are recommended to have enough mojos to cover transaction fees for the reissuance. The recommended amount is five hundred thousand (500,000) mojos per coin to be reissued. - You are **required** to have a single coin that is large enough to cover the entire reissuance. Even if your XCH balance is sufficient, it may be separated into multiple small coins. The easiest way to ensure that you have a sufficiently large coin is to send a transaction to yourself of at least the total value required. - ::: +::: 3. Use the CAT Admin Tool to select a coin that will be used for issuing the CAT2 tokens. @@ -622,10 +622,10 @@ values={[ ]}> -````powershell +```powershell cats --tail .\reference_tails\delegated_tail.clsp.hex --curry 0x8a7afe10d00899b94cf0d407b85e1b9fca21868bcf158563fe9432b60e36db7136055186221fbd27ecc7fc0d5b99ef1b --send-to xch1rd7hejemt57amqtxq8azqg90hgxyhd9shwyjuppq5ez2jn4rlznscn4efy --amount 6000000000 --as-bytes --solution "(a (q 2 (i 47 (q 8) (q 2 (i (= 45 2) () (q 8)) 1)) 1) (c (q . 0x11038a7e107cb7e17a503ba201d94166018deecd777314e4697c5269d9f37fb6) 1))" --signature b75390ee21b001b7a721f719ff045e3dc2a1072ab0824a8e75c881398db0fbed8fde5c62bbdfe629dce5da3d77834559016acd6d403f9b90d3102da2e9452461457514088af0cabe0b8a8493fc9c09d1785f1322abc8958ecf7907eba0e0abcc ``` 0x11038a7e107cb7e17a503ba201d94166018deecd777314e4697c5269d9f37fb6) 1))" --signature b75390ee21b001b7a721f719ff045e3dc2a1072ab0824a8e75c881398db0fbed8fde5c62bbdfe629dce5da3d77834559016acd6d403f9b90d3102da2e9452461457514088af0cabe0b8a8493fc9c09d1785f1322abc8958ecf7907eba0e0abcc -```` +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md index dd648a1723f..e8423a96e19 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cat2-upgrade/cat2-snapshot.md @@ -49,7 +49,7 @@ values={[ :::caution Ensure that you replace `` and `` with the actual folders -::: +::: ```powershell Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app-\resources\app.asar.unpacked\daemon\chia.exe" @@ -70,10 +70,10 @@ Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app- @@ -86,10 +86,10 @@ alias chia="/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/c 2. If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: -````bash +```bash . ./activate ``` ./activate -```` +``` @@ -115,7 +115,7 @@ alias chia="/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/c 4. `TARGET_HEIGHT` - The height of the blockchain to end the snapshot (no default - must be set). The recommended height is `2311760`, which is the last block at which CAT1 is valid. :::caution Running this process with the recommended block heights could take over 40 hours to complete. You may wish to test it first by setting the `TARGET_HEIGHT` to `1146900`. This will pull data from only 100 blocks, which should only take a few seconds. - ::: +::: In order to set these variables, you are recommended to put them into a file called `.env` at the root of the `CAT-addresses` project. The tool will automatically read the variables in this file. For example: @@ -378,7 +378,7 @@ python3 export.py --output-dir /Users/Username/CAT-addresses/results/CKC_ --tail - `` - a string to be prepended to the output file name - `` - the TAIL hash you obtained from taildatabase.com - `--coins` - an **optional** flag that will add information about individual coins to the output (which might be helpful for auditing purposes) - ::: +::: :::note This command will not create any directories, so make sure `` already exists before running it. Otherwise, you will receive a `FileNotFoundError`. ::: Otherwise, you will receive a `FileNotFoundError`. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cr-cat-tutorial.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cr-cat-tutorial.md index 331f7401ff0..e8df1b2e061 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cr-cat-tutorial.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/cat/cr-cat-tutorial.md @@ -1,5 +1,5 @@ --- -slug: /guides/cr-cat-tutorial +slug: /guides/cr-CAT-tutorial title: CR-CAT Creation Tutorial --- @@ -53,6 +53,7 @@ It is possible to brick\* funds by sending them to an address without the approp \* Technically, the funds will remain recoverable, but this process will not be easy. ::: +::: ### DID and VC Setup @@ -248,6 +249,19 @@ python3 -m pip install --upgrade pip setuptools wheel Install the CAT admin tool: +```bash +pip install . +``` ./venv/bin/activate +``` + +Install all prerequisites: + +```bash +python3 -m pip install --upgrade pip setuptools wheel +``` + +Install the CAT admin tool: + ```bash pip install . ``` @@ -289,6 +303,7 @@ Install the CAT admin tool: ```bash pip install . +``` ``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-architecture.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-architecture.md new file mode 100644 index 00000000000..b8444169e5c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-architecture.md @@ -0,0 +1,155 @@ +--- +slug: /guides/gaming-architecture +title: Architecture +--- + +This document explains the architecture and core concepts of the Chia Gaming system. Understanding these concepts is essential for developers building games or integrating with the platform. + +## System Overview + +The Chia Gaming system enables trustless two-player games using **state channels** on the Chia blockchain. Players lock funds into a shared on-chain coin, play the game entirely off-chain (fast, free, private), and settle the result back on-chain when done. + +The system consists of: + +- **Player App**: Static HTML/JS/CSS/WASM application that runs entirely in the browser. Contains the WASM game engine, game UIs, and the code that talks to a blockchain interface. +- **Tracker**: A lobby and WebSocket relay service. Provides matchmaking and ferries game messages between peers. Trackers are third-party code; anyone can run one. +- **Chia wallet (live play)**: Connected via WalletConnect. The player app reads chain state and submits transactions through the wallet (for example `chia_getCoinRecordsByNames`, `chia_pushTransactions`). A full node on the same machine is not required for players; the wallet handles chain interaction. +- **Simulator (development)**: Optional local service (`chia-gaming-sim`, ports 5800/5801) used instead of WalletConnect when testing without real XCH. Configured in `front-end/src/settings.ts`. + +## State Channels + +A state channel is a mechanism that allows two parties to transact off-chain while retaining on-chain security guarantees. The general flow is: + +1. **Open**: Both players fund a shared on-chain coin (the "channel coin") +2. **Play**: Game moves happen off-chain, with each state update signed by both parties +3. **Close**: The final state is settled on-chain, distributing funds according to the game outcome + +The key insight is that either party can unilaterally close the channel at any time by posting the latest agreed-upon state to the blockchain. This means neither player needs to trust the other; if one party disappears or misbehaves, the other can always recover their funds. + +## Coin Hierarchy + +The on-chain state is represented by a hierarchy of coins (simplified; see `OVERVIEW.md` in the chia-gaming repository for the full tree including per-player funding coins and the launcher): + +``` +Funding coins (one per player) → launcher → Channel Coin + → Unroll Coin → reward coins and/or Game Coins (referee puzzle) +``` + +- **Channel Coin**: Holds the channel funds after the handshake. Controlled by a 2-of-2 aggregate key; off-chain play updates signed unroll commitments without moving the channel coin until shutdown or dispute. +- **Unroll Coin**: Represents the latest mutually-agreed state with a sequence number. A higher sequence number preempts a lower one during dispute resolution. +- **Game coins**: Created when a game starts within the channel. Each is governed by a referee puzzle (Chialisp) for that game type; on-chain moves are validated against that puzzle if a dispute is forced. + +## The Potato Protocol + +The "potato" is a conceptual token that alternates between players, determining whose turn it is to act. The protocol ensures: + +- Only one player can propose a state update at a time +- Each state update increments a sequence number +- Both players sign each state transition +- The latest signed state is always available for on-chain settlement + +The name comes from "hot potato": you hold it when it's your turn, and pass it when you've made your move. The potato carries: + +- The current game state +- The sequence number +- Signatures from both parties on the previous state +- The proposed next state (unsigned by the receiver until they accept) + +## Referee Pattern + +Each game type implements a **referee**: a Chialisp puzzle that can validate game moves on-chain. During normal play, the referee is never invoked because both players agree on the game state. However, if a dispute arises: + +1. Either player posts the game state on-chain +2. The referee puzzle validates each subsequent move +3. After a timeout or game completion, the referee distributes funds + +The referee ensures that even if the off-chain communication breaks down, the game can always be completed fairly, on-chain (albeit more slowly and at transaction cost). + +### Game Handlers + +Each game implements a **handler**: Rust code that manages the game logic off-chain. Handlers are responsible for: + +- Validating incoming moves from the opponent +- Computing the next game state +- Generating the appropriate Chialisp evidence for on-chain validation (if needed) +- Managing game-specific state (cards, boards, scores) + +The handler architecture allows new games to be added without modifying the core channel infrastructure. + +## Connection Types + +Per the connectivity model in the chia-gaming repository (`CONNECTIVITY.md`), the **blockchain itself is not a connection**; it is the ground truth. What you connect to in the player app are three operational axes plus session state: + +| Axis | Purpose | How it is reached | +| ------- | ------------------------------------------------------ | ----------------------------------------------------------------------------- | +| Wallet | Sign spends, read balances and coin records | WalletConnect (live) or simulator (dev) | +| Tracker | Lobby UI (iframe) and message relay | WebSocket to the tracker you joined | +| Peer | Opponent game traffic | Relayed over the tracker's WebSocket | +| Session | In-progress channel obligation | Local state + on-chain coins; not a socket | + +### Session Rollover + +Session state (channel progress, pairing token, and related data) is stored in browser `localStorage`. The **tracker** connection can auto-reconnect with backoff after transient outages (`CONNECTIVITY.md`). There is no guaranteed “reconnect to the same peer” after a hard disconnect; both players may need to re-match on a tracker. Clearing browser storage loses the session. Wallet disconnect stalls signing until the wallet is reconnected; the session obligation on-chain remains. + +### Tracker Availability + +The tracker is only required for: + +- Initial matchmaking (creating/joining rooms) +- Relaying messages between peers during gameplay + +It is **not** required for on-chain settlement. If the tracker disappears permanently, players can still close the channel on-chain using their locally-stored state. + +## WalletConnect Integration + +The player app communicates with the Chia wallet via WalletConnect using the `chia` namespace. The following methods are used: + +| Method | Purpose | +| ---------------------------- | ------------------------------------------------------- | +| `chia_getWallets` | List available wallets | +| `chia_getWalletBalance` | Check available balance | +| `chia_getNextAddress` | Get a receive address | +| `chia_getHeightInfo` | Get current blockchain height | +| `chia_selectCoins` | Select coins for channel funding | +| `chia_createOfferForIds` | Create offers (used in channel open) | +| `chia_pushTransactions` | Push signed transactions to the mempool | +| `chia_createNewRemoteWallet` | Create a remote wallet for tracking channel coins | +| `chia_registerRemoteCoins` | Register channel coins for observation | +| `chia_getCoinRecordsByNames` | Look up specific coin records | +| `chia_getPuzzleAndSolution` | Get puzzle/solution for spent coins | + +### Channel open (handshake) + +Opening a channel uses **one** on-chain spend bundle, but each wallet still goes through **several** WalletConnect steps during the A–F handshake (for example `chia_selectCoins`, two `chia_createOfferForIds` calls, one per player’s funding share, and `chia_pushTransactions`). Approve each request in the Chia wallet; a missing approval can make the handshake look stuck even though only one transaction is submitted on chain. + +## Security Model + +The security of the system rests on several guarantees: + +1. **Unilateral close**: Either player can always close the channel on-chain +2. **Latest state wins**: Higher sequence numbers always supersede lower ones +3. **Timeout protection**: If one player disappears during an on-chain dispute, the other can claim funds after a timeout +4. **Tracker is a relay, not a co-signer**: The tracker ferries lobby and game messages; it does not hold channel keys or settle balances. Players still rely on signed off-chain state and on-chain puzzles for security. +5. **Wallet isolation**: The player app never has access to private keys; all signing happens in the wallet via WalletConnect + +## Frontend Architecture + +The frontend is split into two separately-deployed applications: + +### Player App + +- Fully static (HTML/JS/CSS/WASM): no server-side logic +- Contains the WASM game engine compiled from Rust +- Handles WalletConnect integration +- Manages game state in browser localStorage +- Loads the tracker's lobby UI in an iframe + +### Tracker (Lobby + Relay) + +- Express + WebSocket service +- Serves the lobby UI (room creation, matchmaking) +- Relays game messages between connected peers +- Loaded inside an iframe within the player app +- Must be on a **different origin** from the player app (security boundary) + +This separation ensures that the tracker (which is third-party code) cannot access the player app's WalletConnect session or game state. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-california-poker-rules.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-california-poker-rules.md new file mode 100644 index 00000000000..e89f7dd210d --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-california-poker-rules.md @@ -0,0 +1,67 @@ +--- +slug: /guides/gaming-california-poker-rules +title: California Poker Rules +--- + +:::note Early Alpha Release + +California Poker (CalPoker) is available in Alpha 2. On-chain Chialisp, rules, and UI may change as development continues. + +::: + +## Objective + +California Poker is a card game where players exchange cards and compete to make the best five-card poker hand. Each player receives 8 cards with all 16 cards visible to both players, selects 4 to swap with the other player, and keeps the other 4. The player who can make the best five-card poker hand from their 8 cards after swapping wins. + +## Setup + +- Each player receives 8 cards, all shown face up +- Cards are displayed sorted in rank order + +## Gameplay + +### Card Selection Phase + +1. Both players view their 8 cards simultaneously and can see their opponents cards +2. Each player selects 4 cards to keep +3. The 4 cards not selected are automatically swapped with the opponent +4. Players wait for their opponent to complete their selection + +### Hand Evaluation + +After cards swap: + +- Each player now has 8 cards (4 they kept + 4 received from opponent) +- Each player constructs the best possible five-card poker hand from their 8 cards +- Standard poker hand rankings apply (see Hand Rankings below) + +### Determining the Winner + +The player with the highest-ranking five-card poker hand wins the hand. + +## Hand Rankings + +From highest to lowest: + +1. **Royal Flush**: A, K, Q, J, 10, all of the same suit +2. **Straight Flush**: Five consecutive cards of the same suit +3. **Four of a Kind**: Four cards of the same rank +4. **Full House**: Three cards of the same rank plus two other cards of the same rank +5. **Flush**: Five cards of the same suit (not in sequence) +6. **Straight**: Five consecutive cards of different suits +7. **Three of a Kind**: Three cards of the same rank +8. **Two Pair**: Two different pairs of same rank cards +9. **One Pair**: Two cards of the same rank +10. **High Card**: When no other hand is made, the highest card wins + +## Game Flow + +1. **Cards Shown**: Both players view their 8 cards +2. **Card Selection**: Each player picks 4 cards to swap +3. **Wait for Opponent**: Wait for opponent to complete selection (may be skipped if opponent finishes first) +4. **Results Shown**: Winner is determined and results displayed +5. **Next Hand or End**: Options to start a new hand or end the session +6. **End Session**: Session may end due to: + - Playing on-chain + - Insufficient balance (yours or opponent's) + - You or opponent declined to continue diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-developers-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-developers-guide.md new file mode 100644 index 00000000000..c1ee3735fd1 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-developers-guide.md @@ -0,0 +1,288 @@ +--- +slug: /guides/gaming-developers-guide +title: Developers Guide +--- + +:::warning Alpha Release + +This is an **alpha release** of the Chia Gaming system. The codebase is subject to change, and breaking changes may occur in future versions. Use this system for development and testing purposes. + +::: + + + + + +## Intro + +This guide covers the development, testing, and deployment process for the Chia Gaming system. The system consists of two deployable artifacts: + +1. **Player App**: A fully static HTML/JS/CSS/WASM application that players run in their browser. It contains the wallet connection, WASM game engine, and all game UIs. No server-side logic, no cookies, no server-side sessions. +2. **Tracker**: A separate service that provides a lobby UI (loaded as an iframe inside the player app) and a WebSocket relay that ferries game messages between peers. Trackers are third-party code; anyone can run one. + +To follow this guide, you will need: + +- Linux or macOS operating system +- Rust (stable; pinned in the repo’s `rust-toolchain.toml`) with the `wasm32-unknown-unknown` target +- Node.js 20+ and pnpm 10.33+ +- wasm-pack 0.13.1 +- Chia wallet **2.7.1 or later** (required minimum for Alpha 2; earlier wallet versions are not supported) +- Access to the [chia-gaming repository](https://github.com/Chia-Network/chia-gaming) + +:::note Alpha 2 games + +**California Poker** and **Space Poker** are playable in Alpha 2 as early releases; on-chain Chialisp, rules, and UI may change. **Krunk** is not yet available in the player app. + +::: + +For game rules and mechanics, see: + +- [California Poker Rules](/guides/gaming-california-poker-rules) +- [Space Poker Rules](/guides/gaming-space-poker-rules) +- [Krunk Rules](/guides/gaming-krunk-rules) + +For information about becoming a gaming partner, see the [Gaming Partner RFP](/guides/gaming-partner-rfp). + +## Dependencies and Setup + +### Developer Dependencies + +- **Operating System**: Linux or macOS +- **Rust** (stable) with `wasm32-unknown-unknown` target: the [chia-gaming `rust-toolchain.toml`](https://github.com/Chia-Network/chia-gaming/blob/main/rust-toolchain.toml) pins the channel and targets when you build from a clone: + ```bash + rustup target add wasm32-unknown-unknown + ``` +- **wasm-pack** 0.13.1: + ```bash + cargo install wasm-pack --version 0.13.1 + ``` +- **Node.js 20+** and **pnpm 10.33+**: + ```bash + corepack enable + corepack prepare pnpm@10.33.0 --activate + ``` +- **macOS only**: Homebrew LLVM for WASM builds (`brew install llvm`). Build scripts automatically detect and use it. +- **Chia Wallet**: Chia **2.7.1 or later** (required minimum for Alpha 2; only needed for live WalletConnect testing, not required for simulator testing) +- **Codebase**: Access to the [chia-gaming repository](https://github.com/Chia-Network/chia-gaming) or the release artifacts + +### User Dependencies + +- **Chia wallet**: **2.7.1 or later** (required minimum for Alpha 2; light wallet is sufficient; a local full node is not required for players) +- **WalletConnect (live play)**: Each player connects their wallet via WalletConnect. The player app uses wallet RPC methods (for example `chia_getCoinRecordsByNames`, `chia_pushTransactions`) through that connection (`front-end/src/hooks/RealBlockchainInterface.ts`). +- **Simulator (development)**: For testing without real XCH, use simulator mode and the `chia-gaming-sim` binary started by `run-local-demo.sh` (HTTP port 5800, WebSocket port 5801; see `front-end/src/settings.ts`). + +:::tip Common Issues + +For common setup issues and solutions, see the [Known Issues](/guides/gaming-known-issues) document. + +::: + +## Development Workflow + +### Quick Start (Local Demo) + +The fastest way to get started is `run-local-demo.sh`, which builds everything (including `tools/build-chialisp.sh` and a `--dev` WASM build for faster iteration) and starts three services: + +```bash +git clone https://github.com/Chia-Network/chia-gaming.git +cd chia-gaming +./run-local-demo.sh +``` + +| Service | Default URL | Override env var | +| ---------- | ------------------------------------------------------------------------------------------------------- | ------------------------- | +| Player app | `http://localhost:3002` | `GAME_PORT` | +| Tracker | `http://localhost:3003` | `TRACKER_PORT` | +| Simulator | `http://localhost:5800` (HTTP), `ws://localhost:5801` (WebSocket) | `SIM_PORT`, `SIM_WS_PORT` | + +Flags: + +- `--skip-build`: skip all build steps, use existing artifacts +- `--force-build`: `cargo clean` before building + +Press Ctrl-C to stop all services. + +### Using Release Artifacts + +**Local development:** `./run-local-demo.sh` builds everything, assembles the nonce-based staging trees (`build-meta.json`, assets under `app//`), and starts the player app, tracker, and simulator. + +**Alpha 2 binaries:** Download from the [chia-gaming Releases](https://github.com/Chia-Network/chia-gaming/releases) page on the Alpha 2 release tag. Those assets are the **staged** archives from `tools/build-deploy.sh` (`.zip` and `.tgz` with the same contents): + +- `chia-gaming-YYYYMMDD-HASH.zip`: player app (`index.html`, `build-meta.json`, `app//` with JS, CSS, WASM, and `clsp/`) +- `chia-gaming-lobby-YYYYMMDD-HASH.zip`: tracker (same staging layout, plus `service.js` at the archive root) + +Build them yourself with `./tools/build-deploy.sh` from source (see [DEPLOYING.md](https://github.com/Chia-Network/chia-gaming/blob/main/DEPLOYING.md)). The staged layout matches what `run-local-demo.sh` assembles locally (file copies under `front-end/serve` and `lobby/lobby-frontend/serve`). + +To run the tracker from a release zip: + +```bash +PORT=3003 node service.js --self 'https://your-tracker.example' --dir /path/to/extracted-lobby-archive +``` + +### Building Step by Step + +For production packaging or partial rebuilds. Run commands from the repo root. The full sequence is documented in [DEPLOYING.md](https://github.com/Chia-Network/chia-gaming/blob/main/DEPLOYING.md) and mirrored in `tools/build-deploy.sh`. + +**1. Chialisp (.hex files):** + +```bash +./tools/build-chialisp.sh +``` + +This script clears stale `.hex` files, enables the Rust build script, and compiles all `.clsp` sources, the same step `run-local-demo.sh` uses. + +**2. WASM (browser target):** + +```bash +cd wasm && wasm-pack build --out-dir=../front-end/dist --release --target=web +``` + +For development, use `--dev` instead of `--release` (faster builds, larger output). + +**3. Player app (frontend JS/CSS):** + +```bash +cd front-end && pnpm install --frozen-lockfile && pnpm run build +``` + +**4. Lobby frontend:** + +```bash +cd lobby && pnpm install --frozen-lockfile +pnpm --filter chia-gaming-lobby-frontend run build +``` + +If `pnpm install` in `lobby/` warns about ignored build scripts, that is expected (see [Known Issues](/guides/gaming-known-issues)). `tools/build-deploy.sh` uses `pnpm install --frozen-lockfile --ignore-scripts` in `lobby/` for production builds. + +**5. Lobby service:** + +```bash +cd lobby && pnpm --filter chia-gaming-lobby-service run build +``` + +**6. Simulator (development only):** + +```bash +cargo build --features sim-server --bin chia-gaming-sim +``` + +### Making Code Changes + +1. **Edit Source Code**: Make your changes to the codebase. + +2. **Rebuild**: After making changes, rebuild the affected components. For quick iteration, use `--skip-build` with `run-local-demo.sh` if you only changed frontend code, or rebuild individual steps as needed. + +3. **Test Changes**: Use the simulator (recommended) or live WalletConnect to test your modifications. + +### Testing + +:::note Simulator Recommended + +For development, it is recommended to use the simulator for testing game logic without interacting with a real Chia wallet. + +::: + +**Using Simulator (Recommended for Development):** + +1. Start the local demo with `./run-local-demo.sh` +2. Navigate to the player app URL (`http://localhost:3002`) +3. Enable the simulator option in the UI +4. Create a room and copy the generated room link +5. Open a different web browser, user profile, or incognito/private window +6. Paste the room link to join as the second player using the simulator + +**Using Live WalletConnect (Advanced Testing):** + +:::important Two Separate Wallet Instances Required + +When testing with live WalletConnect (not simulator), you **must** use two different Chia wallet instances. You cannot use the same wallet or installation for both players. The easiest approach is to deploy the gaming system to a URL accessible by both computers and use two different systems with separate wallet installations. + +::: + +1. Deploy the gaming system to a URL accessible by both computers (does not need to be publicly accessible; local network, VPN, or other private network setup is sufficient) +2. Use two different computers or systems, each with its own Chia wallet installation (2.7.1 or later) +3. Each player connects their separate wallet via WalletConnect +4. Follow the standard game flow with both players using their respective wallets + +### Viewing Logs + +View service logs for debugging: + +```bash +# Logs appear in the terminal where run-local-demo.sh is running +# For more control, run services separately (see Building Step by Step) +``` + +## Verification + +After building and launching the system, verify it's working correctly: + +1. **Check Services**: Ensure all three services are accessible: + + ```bash + curl http://localhost:3002 # Player app + curl http://localhost:3003 # Tracker + curl -X POST http://localhost:5800/get_peak # Simulator + ``` + +2. **Test with Simulator**: + - Navigate to `http://localhost:3002` + - Enable simulator mode + - Create a room and test the connection + +3. **Test with Live WalletConnect**: + - Connect a Chia wallet (2.7.1 or later) via WalletConnect + - Verify the connection is established + - Test creating a room + +4. **Check WalletConnect (live play only)**: Confirm each test wallet is connected, synced, and approving pending requests in the Chia wallet UI. + +## Deploy to Production + +For detailed deployment instructions including asset layout, caching rules, and production configuration, see the [DEPLOYING.md](https://github.com/Chia-Network/chia-gaming/blob/main/DEPLOYING.md) in the chia-gaming repository. + +Key points: + +- The player app and tracker must be served from **different origins** (the lobby loads inside an iframe) +- WASM files and `.hex` chialisp files must be under the same `basePath` as `index.js` +- No simulator in production: players connect their Chia wallet via WalletConnect +- Use `tools/build-deploy.sh` to produce deployment zip archives (see [DEPLOYING.md](https://github.com/Chia-Network/chia-gaming/blob/main/DEPLOYING.md)) + +## Manual Configuration + +### Network (mainnet only) + +**Alpha 2 supports mainnet only.** The player app is wired for mainnet in source: + +- `front-end/src/constants/env.ts`: `CHAIN_ID = 'chia:mainnet'` +- `src/common/constants.rs`: `AGG_SIG_ME_ADDITIONAL_DATA` is the mainnet value + +There is no supported testnet configuration for Alpha 2. Use the **simulator** (`run-local-demo.sh`) for development without mainnet XCH. Do not change these constants for testnet unless you are doing unsupported custom experimentation. + +### WalletConnect Project Info Updates + +To configure WalletConnect settings, you'll need to obtain a WalletConnect Project ID. For registration and troubleshooting, refer to the [WalletConnect documentation](https://walletconnect.com) and your WalletConnect account dashboard. + +The repository ships a default WalletConnect **Project ID** in `front-end/src/constants/env.ts` for development. **Production or partner deployments should register their own project** at [WalletConnect Cloud](https://cloud.walletconnect.com) and replace that value before building the player app. + +Once you have your Project ID, update: + +1. **Project ID**: `front-end/src/constants/env.ts`: update `PROJECT_ID` (and `RELAY_URL` if needed) +2. **Chain and methods**: `front-end/src/constants/wallet-connect.ts`: update `REQUIRED_NAMESPACES` / `ChiaMethod` if the wallet API changes (must match what the player app calls in `RealBlockchainInterface.ts`) + +### Port Configuration + +Default ports for `run-local-demo.sh`: + +- **Port 3002**: Player app (frontend web interface) +- **Port 3003**: Tracker (lobby + relay service) +- **Port 5800**: Simulator (HTTP) +- **Port 5801**: Simulator (WebSocket) + +Override with environment variables: + +```bash +GAME_PORT=4000 TRACKER_PORT=4001 ./run-local-demo.sh +``` + +For production deployments, see the [DEPLOYING.md](https://github.com/Chia-Network/chia-gaming/blob/main/DEPLOYING.md) in the repository for port and domain configuration. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-known-issues.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-known-issues.md new file mode 100644 index 00000000000..3173ddfe570 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-known-issues.md @@ -0,0 +1,89 @@ +--- +slug: /guides/gaming-known-issues +title: Known Issues +--- + +:::warning Alpha Release + +This is an **alpha release**. Expect issues and breaking changes. The following known issues are being tracked and worked on. + +::: + +:::tip Troubleshooting + +For steps to resolve common problems, see the [Troubleshooting Guide](/guides/gaming-troubleshooting). + +::: + + + + + +## Game Availability + +**California Poker (CalPoker)** and **Space Poker** are available in Alpha 2 as early releases. On-chain Chialisp, rules, and UI for both games are still undergoing changes. + +**Krunk** is coming soon. + +## Developer Issues + +### Easy Developer Configuration Not Available + +The config-directory workflow described in older material is not available. Network, WalletConnect, and port settings are updated in the codebase. See the [Manual Configuration](/guides/gaming-developers-guide#manual-configuration) section in the Developers Guide. + +### WASM Build Failures on macOS + +**Problem**: WASM builds may fail with clang-related errors on macOS. + +**Workaround**: Install Homebrew LLVM (`brew install llvm`). Build scripts detect Homebrew LLVM paths automatically. See the [Developers Guide](/guides/gaming-developers-guide) prerequisites. + +### `ERR_PNPM_IGNORED_BUILDS` Warning + +**Problem**: During `pnpm install` you may see warnings about ignored build scripts for `@parcel/watcher` and `esbuild`. + +**Impact**: This is harmless. Those packages ship pre-built native binaries as fallbacks, so the build completes without running those scripts. + +**Resolution**: Run `pnpm approve-builds` once in `front-end/` or `lobby/` and commit the updated `.pnpm-approve-builds` file to silence the warning. The lobby build in `tools/build-deploy.sh` also uses `pnpm install --ignore-scripts` in `lobby/` for the same reason. + +## User-Facing Issues + +### "Generate Room" button contrast (fixed in Alpha 2) + +**Status:** **Fixed in Alpha 2.** Earlier builds used low-contrast styling for the Generate Room control. + +### Handshake progress feedback (fixed in Alpha 2) + +**Status:** **Fixed in Alpha 2.** The UI now shows clearer progress during the handshake and channel-confirmation phases. + +### Funds left on-chain after shutdown (fixed in Alpha 2) + +**Status:** **Fixed in Alpha 2.** Older alpha builds could leave one game stake on-chain after ending a live WalletConnect session. Current Alpha 2 builds return channel funds on shutdown. If you still see stranded coins, confirm you are on an Alpha 2 build and not an older artifact. + +- **Keep browsers open until shutdown completes**: Both players should keep the browser open until cooperative shutdown finishes. Closing early can interrupt the shutdown flow. +- **Chia Wallet does not come to the foreground for WalletConnect**: When the wallet needs approval, you may need to switch to the wallet app manually. + +### Session Persistence + +**Problem**: Game sessions are stored in browser localStorage. Refreshing the page or clearing browser data loses the session. + +**Impact**: If a session is lost mid-game, channel coins remain on-chain until timeout. Funds are not necessarily lost permanently, but coins may be locked until the timeout expires. + +**Workaround**: Do not refresh or clear browser data during active games. + +### Handshake Timing + +**Problem**: Opening a channel requires one on-chain spend bundle to confirm; both wallets must see the channel reach **Active**, which takes several minutes on mainnet (~1 minute per peak). During the handshake, each wallet must also approve **several** WalletConnect requests (`chia_selectCoins`, `chia_createOfferForIds`, and `chia_pushTransactions`), not a single tap. + +**Impact**: Player 2 may wait a long time before the lobby appears. This is expected for on-chain handshakes. If progress stalls, check both wallets for pending approvals. + +### Pending WalletConnect Requests + +**Problem**: The Chia wallet may have pending WalletConnect requests that are not immediately visible, so the handshake or gameplay can appear stuck. + +**Workaround**: Check the Chia wallet application for pending approval requests. + +### Tracker WebSocket Relay + +**Problem**: Game messages are relayed through the tracker WebSocket. If that connection drops for an extended time, play stalls. + +**Impact**: Brief outages may recover via tracker auto-reconnect; a lost peer pairing may require re-matching on the tracker (see `CONNECTIVITY.md` in the chia-gaming repository). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-krunk-rules.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-krunk-rules.md new file mode 100644 index 00000000000..08f2fd82919 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-krunk-rules.md @@ -0,0 +1,84 @@ +--- +slug: /guides/gaming-krunk-rules +title: Krunk Rules +--- + +:::warning Coming Soon + +Krunk will be available in a future release. The rules below are based on current known game mechanics and are subject to change. + +::: + +## Objective + +Krunk is a word guessing game where players try to guess each other's chosen words. Each player picks a word from the dictionary, and their opponent attempts to guess it using Wordle-style clues. The faster you guess correctly, the more you win. + +## Setup + +- Both players pick a word for their opponent to guess +- Words must be from the dictionary +- Each player has up to 5 guesses to find their opponent's word + +## Gameplay + +### Word Selection + +1. Each player secretly picks a word from the provided dictionary +2. The word must be a valid dictionary word +3. Both players select their words simultaneously + +### Guessing Phase + +1. **Make Your Guess**: Enter a five-letter word as your guess +2. **Receive Clue**: After each guess, you receive a Wordle-style clue showing: + - **🟩 Green**: Letter is correct and in the right position + - **🟧 Orange/Yellow**: Letter is correct but in the wrong position + - **⬛ Gray/Black**: Letter is not in the word +3. **Continue Guessing**: Use the clues to make your next guess +4. **Maximum Guesses**: You have up to 5 guesses to find the word + +### Example Clue + +``` +⬛⬛⬛⬛🟧RATES +🟧⬛🟧⬛⬛SPOIL +⬛🟩⬛🟩🟩MOUSY +🟩🟩🟩🟩🟩BOSSY +``` + +In this example: + +- First guess "RATES" had one letter (S) in the word but wrong position +- Second guess "SPOIL" had two letters (S and L) in wrong positions +- Third guess "MOUSY" had three letters correct (O, U, Y) in right positions +- Fourth guess "BOSSY" was correct + +## Scoring and Rewards + +The amount you win depends on how many guesses it takes you to find the word: + +- **1st or 2nd guess**: 100% of the amount posted +- **3rd guess**: 20% of the amount posted +- **4th guess**: 5% of the amount posted +- **5th guess**: 1% of the amount posted +- **6th guess or more**: Nothing (0%) + +The amount shown at the start is what you'll receive if you guess correctly on the first or second try. + +## Game Flow + +1. **Pick Word**: Choose a word for your opponent to guess (must be from the provided dictionary) +2. **Make Guesses**: Make up to 5 guesses of your opponent's word: + - Wait for opponent to pick their word + - First guess + - Second guess (or go to finish) + - Third guess (or go to finish) + - Fourth guess (or go to finish) + - Fifth guess (or go to finish) +3. **Finish**: Shows results of your guessing. Wait for opponent to finish guessing +4. **Results Shown**: Results displayed with options to start a new hand or end the session +5. **Next Hand**: Wait for opponent to start next hand (may be skipped if opponent has already started) +6. **End Session**: Session may end due to: + - Playing on-chain + - Insufficient balance (yours or opponent's) + - You or opponent declined to continue diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-partner-rfp-qa.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-partner-rfp-qa.md new file mode 100644 index 00000000000..f066a1f5ee6 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-partner-rfp-qa.md @@ -0,0 +1,140 @@ +--- +slug: /guides/gaming-partner-rfp-qa +title: Gaming RFP Q&A +--- + +# Gaming RFP Questions & Answers + +## Summary + +This page contains questions and answers regarding the Gaming Partner RFP (CHIA-GAMING-01). Questions were submitted by participants during the question submission period and responses were provided by Chia Network Inc. + +## Questions & Answers + +### What does the "Partner" get... other than that label? It looks like they're committing to timelines on maintenance and improvements. But if the code is open-source... anyone interested could do maintenance+improvements anyways? + +(I guess the potential-partner would just include payment milestones in their proposal?) + +- In addition to potential funding the Partner(s) get access to direct development and marketing support. We will supply the resources to get to a fully functioning framework to work off of. We will also provide normal reasonable support for getting vendors up to speed on what we've made available. + +### Is the partner already known and can you share some details if yes? + +- Partner(s) is/are not known, the RFP process will yield that. Goal is to have a number of submissions for the RFP, with the Partner(s) being selected in a few months. Currently we have concluded the Q&A portion of the RFP. Next step is we want potential Partner(s) to submit their proposals for how they will manage and build on top of the gaming solution. NOTE - there may be more than 1 partner selected. More information about the RFP can be found here: [Gaming RFP | Chia Documentation](/guides/gaming-partner-rfp) + +### Are CATs usable for the stake in a game out of the box or is this something that will come later? + +- No, CAT support would need to be added as one has to manage wrapped addresses for the cats within the state channel. Our initial focus is to drive XCH transactions but we are open to add CAT support eventually. + +### Will the partner retain 100% of platform revenue, or is there a revenue-share arrangement with Chia Network? + +- The Partner(s) will retain 100% of the platform revenue using their solution(s). Do take note that there could be multiple partners selected with the end goal of an interoperable and open ecosystem. + +### What revenue streams currently exist or are anticipated (e.g., transaction fees, premium features, token economics)? + +- The revenue streams are to be determined by the Partner(s) and their proposal(s). Some revenue streams we expect are premium features including potential subscription models, UI theming, direct pay from users for access, metrics, training, promotion, outside assistance detection, ads, and partnerships. + +### Are there budget parameters or cost expectations Chia Network has established for this engagement? Understanding whether proposals should optimize for cost-efficiency versus comprehensive capability would help ensure our proposal aligns with your expectations. + +- Partner(s) funding will be based on cost and time efficiency. + +### Beyond the initial evaluation criteria, what KPIs will Chia Network use to measure partner success post-handoff? (e.g., user acquisition targets, revenue milestones, uptime SLAs, feature delivery cadence). Understanding success metrics will help us propose realistic commitments and resource allocation. + +- We are interested in real increased demand for XCH as measured by N channels created in blocks, amount of funding in channels, and amount of money moving through channels. Partner(s) can (and we expect them to) define their own metrics. Note we recognize some of these metrics can be manipulated but we expect the Partner(s) traffic to be legitimate. + +### The evaluation criteria mentions 'cost and applicable web2 experience' as most heavily weighted. Can you provide approximate weighting across all evaluation criteria (e.g., cost 40%, web2 experience 30%, blockchain familiarity 20%, etc.)? This would help us prioritize our proposal accordingly. + +- There is no specific breakdown and all of the proposals will be reviewed on independent merit. + +### Given that Chia Network will deliver v1 with core blockchain and state channel logic completed, what is the anticipated frequency and complexity of Chialisp and Rust modifications the partner would need to make in the first 12 months? Are we primarily maintaining existing code, or should we expect significant new development in these languages? + +- We will supply the resources to get to a fully functioning framework to work off of. We will also provide normal reasonable support for getting Partner(s) up to speed on what we've made available. We expect that Partner(s) will be working primarily on frontend development and game logic with some chialisp development for the games themselves. + +### Will the partner have access to Chia Network engineering resources for consultation during the transition period and for complex Chialisp/state channel issues that may arise post-handoff? If so, what is the expected duration and scope of this support? + +- Yes, we will also provide normal reasonable support for getting Partner(s) up to speed on what we've made available. + +### Given that the platform involves real-value gaming outcomes, are there specific jurisdictions the partner should avoid operating in, or regulatory frameworks (e.g., gaming licenses, money transmission laws) we should anticipate needing to comply with? Has Chia Network obtained any legal opinions on the regulatory classification of the gaming platform? + +- It is the Partner(s) responsibility to ensure compliance with local regulatory environments. + +### What role will Chia Network play in marketing and user acquisition for the gaming platform post-handoff? Should the partner budget for significant marketing spend, or will Chia Network actively promote the platform through its existing channels and community? + +- We're anticipating viral and influencer marketing being the primary driver of Chia gaming marketing driven by the Partner(s). Primarily we will direct our promotions on the Chia gaming solutions themselves and secondarily we will promote the Partner(s) as part of our normal partnerships promotions. Out of necessity any promotion will drive users to particular games, game apps, and trackers for onboarding. Partner(s) are expected to use their own marks when promoting themselves with usage of Chia trademark guidelines subject to approval and the terms outlined here: https://www.chia.net/ip-trademarks/ + +### Where does Chia Network envision the gaming platform in 3–5 years? Are there specific scale targets (users, transaction volume, game types) or strategic objectives the partner should be building toward? + +- The long term vision for Chia gaming is of it being an ecosystem involving multiple, possibly many vendors interacting via open source protocols. + +The primary types of vendors are game app providers and tracker runners (still not sure what to call these things). The idea is that any game app can work with any tracker, any two game apps can talk to each other as long as they play shared games, and games can easily be added to game apps by them implementing our game handlers API. + +There likely isn't so much of a pure game writing business in there. Games should be interoperable across vendors, and when playing for money standardization on a few formats which people can directly train on is the norm. Poker is the main example. + +### Beyond the scope outlined in the RFP, are there adjacent opportunities Chia Network would value from the right partner—such as bringing an existing gaming user base, developing additional game types, or contributing to the broader Chia gaming ecosystem? We want to understand if there is appetite for a partner who can deliver beyond platform maintenance and into ecosystem growth. + +- Yes there is an appetite for a Partner(s) who can deliver beyond platform maintenance including bringing an existing gaming user base and further developing the gaming primitives. The long term vision for Chia gaming is of it being an ecosystem involving multiple, possibly many vendors interacting via open source protocols. + +There's an open question of who maintains the standard for interoperability which the whole ecosystem uses. That should be a consensus-driven process with several vendors participating including Chia Network Inc; with CNI doing some amount of direct participation and/or funding others who are contributing to it. + +### What's the existing infrastructure, where is it hosted and how is it managed? Do we have an idea of traffic one would need to support? + +- Since these are decentralized gaming primitives, there is no traditional centralized hosting infrastructure. CNI will not be hosting publicly accessible versions of the gaming solutions. The project has been designed to run as two separate docker images (tracker and game host) with the intention that these are interoperable with other implementations (i.e. trackers can identify games from other providers). This interoperability is one core reason we may select more than 1 partner during this process. The technical load on Chia gaming infrastructure is very low due to it being super-optimized for keeping the load on chain down. + +### Since most of the tasks related with the RFP are maintenance/support/refactor tasks, with the exception of UI/UX and a few features to develop, what is the scope of the Demo? What will be evaluated in this deliverable? + +- We would like to see a proof of concept of your proposed solutions (a hosted instance of the current gaming solution with your teams improvements and added features). This proof of concept need not be feature complete but progress, code quality, and functionality will all be evaluated with the intention that the potential Partner(s) need to show they can develop towards their proposed solutions. + +### What specific acceptance criteria or milestones define v1 completion? Will there be a formal sign-off process before the partner assumes responsibility? + +- We expect an ongoing collaboration between CNI and the Partner(s). We will supply the resources to get to a fully functioning framework to work off of. We will also provide normal reasonable support for getting vendors up to speed on what we've made available. Generally we will provide all of our proposed games (CalPoker, SpacePoker, and Krunk) with a functional walletConnect integration for the Chia reference client. + +The long term vision for Chia gaming is of it being an ecosystem involving multiple, possibly many vendors interacting via open source protocols. + +There's an open question of who maintains the standard for interoperability which the whole ecosystem uses. That should be a consensus-driven process with several vendors participating including Chia Network Inc; with CNI doing some amount of direct participation and/or funding others who are contributing to it. + +### After the official handoff, will the partner have full ownership of the product roadmap, or will Chia Network Inc. retain approval or veto rights over feature development, UX changes, or monetization strategies? + +- The Partner(s) are responsible for their own roadmaps. CNI will continue to support the underlying primitives and standards. The long term vision for Chia gaming is of it being an ecosystem involving multiple vendors interacting via open source protocols. Partner(s) are expected to use their own marks when promoting themselves with usage of Chia trademark guidelines subject to approval and the terms outlined here: [Intellectual Property & Trademarks](https://www.chia.net/ip-trademarks/) + +### Beyond the games currently documented (California Poker, Rock Paper Scissors, Battleship, Tic Tac Toe), are there additional game types in development or planned for v1 that the partner should anticipate supporting at handover? + +- CNI will provide all of our proposed games (CalPoker, SpacePoker, and Krunk) with a functional walletConnect integration for the Chia reference client (note that Rock Paper Scissors, Battleship, Tic Tac Toe, and Connect 4 are all community built projects with no support or development from CNI). + +### Will existing infrastructure (servers, domains, SSL certificates, CI/CD pipelines, monitoring systems) transfer to the partner, or is the partner expected to provision entirely new infrastructure? + +- CNI will not host and does not plan to host public facing instances for the gaming solution. The Partner(s) will need to setup and manage their own infrastructure to support their proposed solution. Note these are decentralized gaming primitives, there is no traditional centralized hosting infrastructure. The technical load on Chia gaming infrastructure is very low due to it being super-optimized for keeping the load on chain down. + +### Are there existing vendor contracts, third-party service agreements, or licensing arrangements the partner will need to assume, renegotiate, or replace? + +- There are no current or planned contracts, service agreements, or licensing arrangements for the Partner(s) to assume, renegotiate, or replace. Note that the code itself has the Apache 2.0 license. + +### What is the current user capacity of the platform infrastructure, and are there known scalability limitations the partner should plan to address within the first 6-12 months? + +- These are decentralized gaming primitives, there is no traditional centralized hosting infrastructure. CNI will not host and does not plan to host public facing instances for the gaming solution. The project has been designed to run as two separate docker images (tracker and game host) with the intention that these are interoperable with other implementations (i.e. trackers can identify games from other providers). The technical load on Chia gaming infrastructure is very low due to it being super-optimized for keeping the load on chain down. + +### Will the partner be permitted to rebrand the gaming platform, or is maintaining "Chia Gaming" branding a requirement? What are the guidelines for use of Chia trademarks and logos in partner marketing? + +- Partner(s) are expected to use their own marks when promoting themselves with usage of Chia trademark guidelines subject to approval and the terms outlined here: [Intellectual Property & Trademarks](https://www.chia.net/ip-trademarks/) + +### The codebase is open-source under Apache 2.0. Does the partner retain the right to develop proprietary features, games, or integrations on top of the open-source foundation, or must all partner development remain open-source? + +- We request that interoperability across game and tracker hosts be maintained but recognize that Partner(s) may create their own closed-source proprietary games, features, or integrations on top of that foundation as permitted by the Apache 2.0 license. + +### For the demo submission phase, are there specific features, capabilities, or scenarios the demo must demonstrate, or is the format and scope at the partner's discretion? + +- We would like to see a proof of concept of your proposed solutions. This proof of concept need not be feature complete but progress, code quality, and functionality will all be evaluated with the intention that the potential Partner(s) need to show they can develop towards their proposed solutions. + +### Will Chia Network Inc. consider existing operational tools and infrastructure built for the Chia Gaming ecosystem (such as game room trackers or monitoring systems) as evidence of capability and commitment? + +- Yes these are evidence of capability and commitment and will be weighted accordingly during the demo review process. While we expect some demos to show game hosts demos could also be focused on infrastructure components. + +### The RFP notes this project validates state channel primitives for payment channels. Will the partner have input into or early access to future Chia protocol developments that could enhance gaming functionality? + +- Yes, the long term vision for Chia gaming is of it being an ecosystem involving multiple vendors interacting via open source protocols. + +There's an open question of who maintains the standard for interoperability which the whole ecosystem uses. That should be a consensus-driven process with several vendors participating including Chia Network Inc; with CNI doing some amount of direct participation and/or funding others who are contributing to it. + +### Is there an expectation that the partner will contribute improvements to the core state channel or Chialisp logic back to Chia Network Inc., or will the partner's technical development be fully independent after handover? + +- Yes we do expect the Partner(s) to contribute to the long term vision for Chia gaming. The vision being an ecosystem involving multiple vendors interacting via open source protocols. + +There's an open question of who maintains the standard for interoperability which the whole ecosystem uses. That should be a consensus-driven process with several vendors participating including Chia Network Inc; with CNI doing some amount of direct participation and/or funding others who are contributing to it. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-partner-rfp.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-partner-rfp.md new file mode 100644 index 00000000000..d16bce3cba4 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-partner-rfp.md @@ -0,0 +1,100 @@ +--- +slug: /guides/gaming-partner-rfp +title: Gaming RFP +--- + +# Gaming Partner RFP + +## Request for Proposal: Chia Network Gaming Partner + +**RFP Reference #:** CHIA-GAMING-01 + +### Timeline + +| Phase | Description | Date | +| :------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------- | +| 1. RFP Issuance | RFP is published publicly | December 10, 2025 | +| 2. Question Submission Deadline | Participants can submit questions regarding the RFP, deliverables, timelines, or the codebase in regards to this partner selection process. | December 22, 2025 | +| 3. Question Response Announcement | Chia Network Inc will respond to questions regarding this partner selection process and make questions and answers publicly available. | January 7, 2026 | +| 4. Proposal Submission Deadline | Participants must submit their proposals prior to the end of this date. | January 14, 2026 | +| 5. Proposal Decision Announcement | Chia Network Inc will decide the top three proposals. Winners will be required to submit a demo of their proposed solution. | January 28, 2026 | +| 6. Demo Submission Deadline | Top three participants must submit a demo of their proposed solution prior to the end of this date. | February 25, 2026 | +| 7. Partner Decision Announcement | Chia Network Inc will announce the official gaming partner. | March 11, 2026 | + +## 1. Company Background + +**Chia Network Inc.** is a software company founded in 2017 by Bram Cohen, the creator of BitTorrent. Our mission is to build a global, public, and open-source platform that enables secure and transparent financial transactions. As a leader in the blockchain space, Chia is developing a new, more sustainable, and powerful blockchain technology. This gaming project is a critical proof of concept to validate state channel primitives, which will directly inform the development of payment channels and other financial applications for the Chia ecosystem. + +## 2. Project Overview and Partner's Role + +Chia Network Inc is seeking a partner to take over the development, product management, and hosting of its gaming solution. The goal is to transition the project from a proof of concept to a fully managed, revenue-generating product for the partner. The partner's responsibilities will be to manage the platform as a complete product, including operations, ongoing development, and business strategy to grow the user base and generate revenue long-term. + +## 3. Scope of Work (SOW) + +The partner will assume full responsibility for the project following the completion of the v1 build. The initial scope of work will be to: + +- **Platform Maintenance:** Provide continuous bug fixes, game support, and ongoing maintenance for the platform. + +- **Product Development:** Revamp the existing UI/UX and build out new gamification features. A minimum requirement is to include player profiles, leaderboards, and a basic achievement system. + +- **Infrastructure Management:** Manage all backend and hosting infrastructure, ensuring platform stability, performance, and security. + +- **Blockchain Integration:** Maintain the existing wallet integrations including the logic for state channel setup, winnings, and error handling. + +- **Security:** Conduct ongoing API security scanning and vulnerability management. + +## 4. Technical Details & Dependencies + +The project is an open-source platform built on a modern technical stack. Partners should have expertise with the following: + +- **Languages:** Rust (primary backend), TypeScript (frontend), and Chialisp (on-chain logic). +- **Web Technologies:** Frontend development with an emphasis on modern web UI/UX. +- **Blockchain:** Familiarity with blockchain concepts and, ideally, experience with the Chia ecosystem. +- **Security:** Experience with security tools like OWASP ZAP and handling JWT authentication. + +:::note Key Expectation + +Chia Network's internal team will deliver a fully functional v1 with all core blockchain and state channel logic completed. The partner's role is to build upon and manage this foundation. + +::: + +The codebase is publicly available at [https://github.com/Chia-Network/chia-gaming](https://github.com/Chia-Network/chia-gaming). + +## 5. Partner Timeline and Deliverables + +- **Demo Submission:** The top three proposal submissions must submit a demo of their proposed solution by the Demo Submission Deadline. + +- **Partner Takeover:** The partner will officially take over the project upon the successful completion of the v1 build. A reasonable estimate for this handover is end of Q1 2026. + +- **First 6-12 Months:** The final proposal should include a phased plan outlining deliverables for the initial period, including a schedule for the UI revamp and the release of new gamification features. + +## 6. Proposal Submission and Evaluation + +### Submission & Contact + +- All questions regarding this RFP must be submitted in writing to proposals@chia.net by the Questions Submission Deadline. Responses will be published publicly for all vendors to access by the Questions Response Announcement. + +- Proposals must be submitted digitally in PDF format to the same email address by the Proposal Submission Deadline. + +- Top three proposals will be determined by Chia Network, Inc for which the submitters will be required to submit a demo of their proposed solutions by the Demo Submission Deadline. + +### Evaluation Criteria + +Proposals will be evaluated on a combination of factors, with cost and applicable web2 experience (hosting, UI, gamification) being the most heavily weighted. We are looking for a partner with a proven track record of managing and growing a web-based product. + +The top three proposals will be chosen for the next phase which requires potential partners to create and submit demos by the Demo Submission Deadline. The final partner decision will be made by the Partner Decision Announcement. + +## 7. Documentation and References + +For detailed technical documentation on the Chia Gaming system, see: + +- [Developers Guide](/guides/gaming-developers-guide) - Complete guide for development, testing, and deployment +- [Users Guide](/guides/gaming-users-guide) - Guide for testing gaming implementations +- [Troubleshooting Guide](/guides/gaming-troubleshooting) - Common issues and solutions +- [Known Issues](/guides/gaming-known-issues) - Documented known issues and workarounds +- [Game Rules](/guides/gaming-california-poker-rules) - Detailed game rules and mechanics + +For additional information about the Chia blockchain and ecosystem: + +- [Chia Documentation](https://docs.chia.net) - Main Chia documentation portal +- [Chia GitHub](https://github.com/Chia-Network) - Official Chia repositories diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-space-poker-rules.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-space-poker-rules.md new file mode 100644 index 00000000000..4006b7ba8e4 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-space-poker-rules.md @@ -0,0 +1,142 @@ +--- +slug: /guides/gaming-space-poker-rules +title: Space Poker Rules +--- + +:::warning Early Alpha Release + +Space Poker is included in Alpha 2 as an early release. On-chain Chialisp, rules, and UI may change before general availability. The rules below match the current implementation in the [chia-gaming](https://github.com/Chia-Network/chia-gaming) repository (`clsp/games/spacepoker/`). + +::: + +## Objective + +Space Poker is a **two-player, suitless Hold'em-style** game on a **single shared board**. Each player gets two hole cards; five community cards are dealt (flop, turn, river). Players bet over four streets, then the best five-card hand wins the pot. Each player also has a **boost** flag (+ or −) that can break ties within the same hand class. + +There is **one hand per game** in the channel, not two parallel boards. + +## Setup + +### Stakes + +When starting Space Poker in the player app, you set: + +- **Unit size**: mojos per betting unit (`bet_unit` on-chain). +- **Stack size**: number of units each player brings (default **10** in the UI). + +Total locked stake for the hand is `2 × unit size × stack size` mojos (`AMOUNT` in the on-chain validators). The minimum increment used in the protocol is **`bet_unit = total per-player stake ÷ 10`**. The UI slider raises in whole units; the chain accepts any valid non-negative raise in mojos up to each player's remaining stack. + +### Cards and boost + +- Hole cards and community cards are ranks **2–A** only (T=10, J=11, Q=12, K=13, A=14). **There are no suits.** +- Each player receives **two hole cards**, drawn deterministically from commit entropy (see `derive_all_cards` in chia-gaming). +- Each player gets **one boost** for the hand: **+** with probability **⅓**, otherwise **−** (derived from hashed commit material, not from individual cards). +- Community cards are **shared**: flop (3), then turn (1), then river (1), revealed in that order as streets complete. + +### Opening the hand + +1. Both players post hash-chain commits (`commitA`, `commitB`). +2. **`commitB` posts the first unit** into the pot (`half_pot` starts at one `bet_unit`). +3. Betting begins at **pre-flop** (`N = 4` in the validator state). + +## Hand Rankings + +From lowest to highest: + +1. **High Card**: No pair or better +2. **Pair**: Two cards of the same rank +3. **Two Pair**: Two different pairs +4. **Set (Three of a Kind)**: Three cards of the same rank +5. **Full House**: Three of a kind plus a pair +6. **Straight**: Five consecutive ranks (high card of the straight breaks ties within the class) +7. **Four of a Kind**: Four cards of the same rank +8. **Five of a Kind**: Five cards of the same rank + +**Important differences from traditional poker:** + +- **No flushes**: ranks only; suits do not exist. +- **Five of a kind** is the highest hand. +- **No ace-low wheel**: A-2-3-4-5 is **not** a straight (only five consecutive ranks where the top card is exactly four above the bottom, e.g. 6-7-8-9-10). +- **Straight beats full house**: in this suitless deck, straights are rarer than full houses (see `space_hand_eval.clinc`). + +## Tiebreakers + +Hands are compared as structured values `(hand counts… boost rank kickers…)` using lexicographic ordering (`deep_compare` in Chialisp): + +1. **Hand class**: e.g. full house beats set; straight beats full house. +2. **Boost**: with the **same** class, **+** beats **−** (boost does **not** upgrade you to a higher class; a boosted set still loses to an unboosted full house). +3. **Kickers**: remaining rank fields in the hand tuple, highest first. + +At showdown each side automatically selects the **best five cards** from their seven (two hole + five board) via `space_hand_calc`; players do not manually pick cards in normal play. + +## Gameplay + +### Streets + +Four betting rounds map to standard street names: + +| Validator `N` | Street | Board state | +| ------------- | -------- | ----------------------------------- | +| 4 | Pre-flop | Hole cards only | +| 3 | Flop | Three community cards | +| 2 | Turn | Fourth community card | +| 1 | River | Fifth community card; then showdown | + +### Pre-flop coin toss + +On the first street only (`N = 4`), a **coin toss** (from compared hash-chain images) decides who **opens** betting: + +- **Opener**: sends an **open** move: optional raise amount (0 = **check**). +- **Non-opener**: may **pong** (defer opening; roles swap, toss flips) once, then the other player opens. + +This is enforced on-chain in `begin_round.clsp` so the opener cannot ignore an unfavorable toss by checking. + +### Turn Structure + +Players **alternate** on each street. The **opener** acts first with **check** or **raise**; the other player responds with **call** or **raise** in `mid_round`. A **call** ends the street (or goes to showdown on the river). See **Pre-flop coin toss** above when `N = 4`. + +### Actions per street + +| Phase | Your turn options (UI) | On-chain meaning | +| ------------- | ----------------------------------------- | --------------------------------------------- | +| `begin_round` | **Check** or **Raise** | Open with 0 or more mojos added to `half_pot` | +| `mid_round` | **Call** or **Raise** | Match the current raise, or raise again | +| `end` | (automatic reveal) | Best-five selection and payout | + +- **Check**: only when you are the opener on a street (`begin_round`). +- **Call**: matches the last raise and ends the street (or proceeds to showdown on the river). +- **Raise**: increases the wager; opponent must call or re-raise in `mid_round`. +- **Fold** (UI only): forfeits the current hand through the protocol **timeout** path (`acceptTimeout` in the player app). This is **not** a separate on-chain fold opcode and is **not** a network or connection timeout. Use only when you intend to abandon the hand outside normal call/raise flow. + +After a call on streets 4–2, the next street deals the next community card(s). After a call on the river (`N = 1`), play moves to **showdown**. + +### Showdown + +- Both players' best five-card hands are computed from seven cards (hole + board). +- The mover reveals with a preimage and five-card **bitfield**; the waiter must match with their own best five (`end.clsp`). +- The UI shows win/loss/split, pot result, evaluated hand names, and hole cards when the protocol exposes them in readables (`"call"` on the river or `"end"`). +- There is no “must show only if you lose” rule in the validators; display follows what the handlers emit. + +### All-In + +Stack limits are enforced by validator state: total committed chips per player cannot exceed half of `AMOUNT`. When a player cannot raise further, they call or check with what remains; there is no separate “all-in” opcode; the UI tracks **stack** and **pot** from `half_pot` and raise amounts. + +## Game Flow + +1. **Proposal**: Agree on unit size and stack size; both fund the game coin. +2. **Commits**: Hash-chain commits; hole cards and boost are fixed from entropy. +3. **Pre-flop**: Coin toss (if needed), then check/raise and call/raise until the street closes. +4. **Flop → Turn → River**: Each street: opener check/raises, opponent calls or raises, then the next board cards appear. +5. **Showdown**: River call or final reveal; pot split by hand comparison. +6. **Next hand or session end**: Start another hand from the lobby if balances allow, or shut down the channel (clean shutdown returns funds in Alpha 2 builds). + +## Session end + +A session may end because: + +- Players finish and choose not to continue +- Insufficient balance for the next stake +- Clean shutdown or channel close on-chain +- A player uses **Fold** (protocol timeout via `acceptTimeout`) in the UI to abandon the current hand + +For installation, WalletConnect, and testing steps, see the [Users Guide](/guides/gaming-users-guide) and [Developers Guide](/guides/gaming-developers-guide). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-troubleshooting.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-troubleshooting.md new file mode 100644 index 00000000000..3b8ca952c01 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-troubleshooting.md @@ -0,0 +1,197 @@ +--- +slug: /guides/gaming-troubleshooting +title: Troubleshooting +--- + + + + + +## Developer Troubleshooting + +## Build Issues + +### Rust / WASM + +**`wasm-pack` not found or wrong version:** + +```bash +cargo install wasm-pack --version 0.13.1 +``` + +**WASM build fails with clang errors (macOS):** + +```bash +brew install llvm +# Build scripts auto-detect Homebrew LLVM paths +``` + +**`wasm32-unknown-unknown` target not installed:** + +```bash +rustup target add wasm32-unknown-unknown +``` + +### Node.js / pnpm + +**`pnpm` not found or wrong version:** + +```bash +corepack enable +corepack prepare pnpm@10.33.0 --activate +``` + +**`ERR_PNPM_IGNORED_BUILDS` warnings:** + +This is harmless. Silence with: + +```bash +cd front-end && pnpm approve-builds +cd lobby && pnpm approve-builds +``` + +**Node version too old:** + +The project requires Node.js 20+. Check your version with `node --version`. + +### Chialisp / Hex Files + +**Missing `.hex` files:** + +```bash +./tools/build-chialisp.sh +``` + +This recompiles all `.clsp` sources to `.hex` (same script used by `run-local-demo.sh` and `tools/build-deploy.sh`). + +## Runtime Issues + +### Simulator + +**Simulator not responding on port 5800:** + +```bash +# Build and run the simulator +cargo build --features sim-server --bin chia-gaming-sim +./target/debug/chia-gaming-sim +``` + +The simulator uses hardcoded ports: 5800 (HTTP) and 5801 (WebSocket). Ensure nothing else is using these ports. + +**Port conflicts with tracker:** + +The tracker defaults to port 5801 if `PORT` is not set, which conflicts with the simulator WebSocket port. Always set `PORT` explicitly: + +From a **source checkout** (local demo): + +```bash +PORT=3003 node lobby/lobby-service/dist/index-rollup.cjs --self 'http://localhost:3003' --dir ./lobby/lobby-frontend/serve +``` + +From an **Alpha 2 release zip** (`service.js` at the archive root): + +```bash +PORT=3003 node service.js --self 'http://localhost:3003' --dir /path/to/extracted-lobby-archive +``` + +### Player App + +**Blank page or JS errors:** + +- Verify WASM files exist in `front-end/dist/` (`chia_gaming_wasm.js`, `chia_gaming_wasm_bg.wasm`) +- Verify `.hex` files exist in `clsp/` directories +- Check browser console for 404 errors on assets + +**`build-meta.json` errors:** + +The player app reads `build-meta.json` from the server root to determine the asset base path. If this file is missing or malformed, assets will fail to load. The `run-local-demo.sh` script generates this automatically. + +### Tracker + +**Tracker iframe not loading:** + +- Verify the tracker is running on a **different origin** from the player app +- Check the browser console for CSP (Content Security Policy) errors +- Verify the `--self` flag matches the public URL of the tracker + +**WebSocket connection failures:** + +- Verify the tracker's `--self` URL is accessible from both players' browsers +- Check for firewall or proxy rules blocking WebSocket upgrades +- Ensure the tracker process is still running + +## WalletConnect Issues + +### Connection + +**WalletConnect pairing fails:** + +- Ensure the Chia wallet is **2.7.1 or later** (minimum) +- Check that the wallet's WalletConnect feature is enabled +- Try regenerating the pairing URI by refreshing the player app + +**"No matching key" or namespace errors:** + +The gaming system requires specific WalletConnect methods. Ensure your wallet supports the `chia` namespace with the required methods. See `front-end/src/constants/wallet-connect.ts` in the repository for the full list. + +### During Gameplay + +**Handshake hangs:** + +1. Check your Chia wallet for pending approval requests +2. Confirm each wallet is connected, synced, and has no pending WalletConnect approvals +3. Check the browser console for WebSocket errors +4. Ensure both players are connected to the same tracker + +**Transaction not confirming:** + +- Each transaction block takes approximately 1 minute +- Channel opening uses one on-chain spend bundle; confirmation can take several minutes (about 1 minute per peak) +- If a transaction is stuck, check the mempool via your wallet + +**Wallet disconnects mid-game:** + +- Reconnect the wallet via WalletConnect; stalled operations resume when the wallet is back (`CONNECTIVITY.md`) +- Session data may remain in browser localStorage, but do not refresh the page during an active game +- If the session is abandoned, channel coins follow on-chain timeout rules (see [Known Issues](/guides/gaming-known-issues)) + +## User Troubleshooting + +For documented limitations and workarounds, see [Known Issues](/guides/gaming-known-issues). + +### Connection Issues + +**Shutdown hangs or incomplete:** + +- Both players should keep the browser open until shutdown completes +- Check each wallet for pending WalletConnect approvals + +### Session Management Issues + +**Lost session after refresh:** + +- Sessions are not restored from the server; refreshing clears in-progress UI state +- Channel coins may remain on-chain until timeout if you abandon mid-game + +### Firewall / Proxy + +**WebSocket connections blocked:** + +- Ensure your network allows WebSocket connections (HTTP Upgrade) +- If behind a corporate proxy, WebSocket traffic may be blocked +- The tracker uses standard HTTP ports; configure your proxy to allow WebSocket upgrades on the tracker's port + +## Getting Additional Help + +If you continue to experience issues after trying these troubleshooting steps: + +1. **Check Known Issues**: Review the [Known Issues](/guides/gaming-known-issues) document for documented problems and workarounds. + +2. **Review Documentation**: + - [Developers Guide](/guides/gaming-developers-guide) + - [Users Guide](/guides/gaming-users-guide) + - [Architecture](/guides/gaming-architecture) + +3. **Check Repository**: Review the [chia-gaming repository](https://github.com/Chia-Network/chia-gaming) for additional information and issue reports. + +4. **Support**: For additional support, visit the [Gaming channel](https://discord.com/channels/1034523881404370984/1275119503273103381) in the official Chia Discord server. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-users-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-users-guide.md new file mode 100644 index 00000000000..f273af80d48 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/chia-gaming/gaming-users-guide.md @@ -0,0 +1,94 @@ +--- +slug: /guides/gaming-users-guide +title: Users Guide +--- + +:::important For Developers + +This user guide is intended to help developers test their gaming implementations. **Chia Network Inc will not host a version of this for users to play.** Before following this guide, developers must install and set up the gaming system. See the [Developers Guide](/guides/gaming-developers-guide) for installation and setup instructions. + +::: + +:::warning Session Persistence + +**Game sessions are not saved.** If you refresh your browser or clear browser storage (localStorage, cache, etc.), your game session will be lost and you will need to create a new session. Do not refresh your browser or clear browser data while a game is in progress. + +::: + +:::note Funds on shutdown (Alpha 2) + +**Fixed in Alpha 2:** Earlier alpha builds could leave one stake worth of funds on-chain after a live WalletConnect session shut down. Alpha 2 returns channel funds on shutdown. If you test an older build, use the simulator for development until you are on Alpha 2. + +::: + +## Intro + +This guide walks through testing a Chia Gaming implementation with two players (Alice and Bob). For live testing, each player connects a Chia wallet (**2.7.1 or later**; required minimum for Alpha 2) via WalletConnect. The player app reads chain state and submits transactions through the wallet connection (see `front-end/src/hooks/RealBlockchainInterface.ts` in the chia-gaming repository). A tracker service relays lobby and game messages between the two browsers. + +:::warning Mainnet only (Alpha 2) + +Live WalletConnect play requires a **mainnet** Chia wallet. Alpha 2 does not support testnet. Use **Simulator** mode in the player app for development without mainnet XCH. + +::: + +:::important Two players, two wallets + +Live WalletConnect testing requires **two separate wallet installations** (for example two computers, or two user profiles each with its own wallet). You cannot run both players from the same wallet on one machine. See the [Developers Guide](/guides/gaming-developers-guide) testing section for details. + +::: + +:::note Handshaking Timing + +Each peak (block) on mainnet takes approximately 1 minute. Opening a channel uses **one** on-chain spend bundle (both players co-sign the combined funding transaction during the A–F handshake; see `OVERVIEW.md` in the chia-gaming repository). Each wallet must still approve **several** WalletConnect requests during the handshake (coin selection, funding offers, and pushing the transaction), not just one prompt. Each wallet must see that transaction confirm and the channel reach **Active** before play begins, so expect several minutes of waiting. The UI shows handshake progress during this period. + +::: + +## Player 1: Alice + +1. **Visit the player app**: Navigate to the player app URL (e.g. `http://localhost:3002` for local development). + +2. **Connect with WalletConnect**: Use WalletConnect to connect a Chia wallet (2.7.1 or later) to the game. For live WalletConnect testing, do not select "Simulator". + +3. **Check Your Light Wallet**: You should see a "getWalletBalance" request in your Chia Light Wallet. Choose "remember this decision" and confirm the request. + +4. **Start a New Room**: Create a new game room and copy the invitation URL. + +5. **Send the Invitation URL to Bob**: Share the room invitation URL with the second player (Bob). + +## Player 2: Bob + +1. **Paste URL**: Paste the invitation URL into a browser that does not share session state with Alice (e.g., another computer, or an incognito/private window). + +2. **Connect Wallet**: Connect your separate Chia wallet (2.7.1 or later) via WalletConnect. + +3. **Wait for Handshake**: Wait until the handshake is complete. The handshake status will be displayed on-screen. + + Once complete, the screen will automatically change to the game lobby screen. + +:::warning Handshaking Time + +Handshaking on-chain takes a long time. Before the game starts, the channel-creation transaction must confirm and both wallets must see the channel become **Active**. Each peak takes approximately 1 minute, so expect several minutes of waiting. The lobby may take several minutes to appear for Bob. + +::: + +:::warning Pending WalletConnect Requests + +If the handshake seems to hang, check your Chia wallet for any pending WalletConnect requests. The wallet may have a request waiting for approval that needs to be confirmed before the handshake can proceed. + +::: + +## Gameplay + +Once both players are connected and the handshake is complete, choose a game in the lobby. Alpha 2 includes **[California Poker](/guides/gaming-california-poker-rules)** (CalPoker) and **[Space Poker](/guides/gaming-space-poker-rules)** as early releases; on-chain Chialisp, rules, and UI for both may still change. **[Krunk](/guides/gaming-krunk-rules)** is coming soon. + +## Game Completion + +After a game completes, you'll see the results screen with options to start a new hand or end the session. + +## Troubleshooting + +For troubleshooting assistance, see the [Troubleshooting Guide](/guides/gaming-troubleshooting) which includes both developer and user-facing troubleshooting information. + +## Known Issues + +For a complete list of known issues, see the [Known Issues](/guides/gaming-known-issues) document. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md index e2cba187413..9925e120ea1 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-primitive-guide.md @@ -102,20 +102,20 @@ python -m venv venv -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md index 169ae98dc6a..58d334d56fd 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/clawback/clawback-user-guide.md @@ -229,7 +229,7 @@ The receiver's wallet will show a pending transaction, including the value, the - While the transaction is in this state, it does not show up in any of the `Balance` fields in the receiver's wallet. This is because the sender can still claw it back. The receiver should therefore not assume the amount will eventually be claimed. This is because the sender can still claw it back. The receiver should therefore not assume the amount will eventually be claimed. - The timer showing how long until the transaction can be claimed does not begin counting down until the original transaction is confirmed on the blockchain. -::: +:::
@@ -53,7 +52,7 @@ pip install . ``` ./venv/bin/activate python -m pip install --upgrade pip setuptools wheel pip install . -```` +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp.md index 96f1d979d8a..8553e7b26ee 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/chialisp.md @@ -122,7 +122,7 @@ Which should produce the following output: 42 ``` -So Chialisp can calculate the [meaning of life]()! +So Chialisp can calculate the [meaning of life](https://en.wikipedia.org/wiki/42_(number)#The_Hitchhiker's_Guide_to_the_Galaxy)! --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/intro-to-chialisp.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/intro-to-chialisp.md index f3852f40424..c8796dea15e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/intro-to-chialisp.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/crash-course/intro-to-chialisp.md @@ -132,7 +132,7 @@ Which should produce the following output: 42 ``` -So Chialisp can calculate the [meaning of life]()! +So Chialisp can calculate the [meaning of life](https://en.wikipedia.org/wiki/42_(number)#The_Hitchhiker's_Guide_to_the_Galaxy)! --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-description.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-description.md index bd576f909fa..fde8188e32a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-description.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-description.md @@ -42,7 +42,7 @@ The singleton comes in two layers -- one permanent and one non-permanent. ### Permanent layer | Setting | Prefarm Value | Description | -| :------ | :------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +|:------- |:------------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `wt` | 30 days | Withdrawal Timelock -- When attempting to begin a withdrawal, this is the minimum number of seconds that must have elapsed since the last withdrawal, rekey or clawback. | | `pc` | 90 days | Payment Clawback -- The minimum number of seconds that must elapse after initiating a withdrawal before the withdrawal can be completed. Clawbacks are possible during this window. | | `rt` | 15 days | Rekey Timelock -- When attempting to begin a standard rekey, this is the minimum number of seconds that must have elapsed since the last withdrawal, rekey or clawback. For a slow rekey, this amount gets added for each key less than `m` (in addition to the amount of time that would have been required in a standard rekey). | @@ -52,10 +52,10 @@ The singleton comes in two layers -- one permanent and one non-permanent. ### Non-permanent layer | Setting | Initial
Value | Description | -| :------ | :---------------- | :-------------------------------------------------------------------------- | -| `m` | 3 | The initial number of pubkeys required to do a withdrawal or standard rekey | -| `n` | 5 | The maximum number of pubkeys required to do a withdrawal or standard rekey | -| `pks` | | A comma separated list of pubkey files that will control this money | +|:------- |:----------------------- |:--------------------------------------------------------------------------- | +| `m` | 3 | The initial number of pubkeys required to do a withdrawal or standard rekey | +| `n` | 5 | The maximum number of pubkeys required to do a withdrawal or standard rekey | +| `pks` | | A comma separated list of pubkey files that will control this money | ## Allowed Actions @@ -123,10 +123,10 @@ The amount of time before the rekey can begin depends on the number of keys used The following table illustrates a few examples of initiation timelock lengths, for various values of `m` and `k`. For this table, `rt` is set to 15 days and `sp` is set to 45 days (these are both denominated in seconds). The table assumes that `n` (5) and the minimum `k` (1) have not been modified from their default values: | `m` | `k` | Days | Comment | -| :-: | :-: | :--: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +|:---:|:---:|:----:|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 3 | 3 | 15 | Standard rekey, no penalty | -| 3 | 2 | 75 | Slow rekey, `sp` day penalty + 2 \* standard `rt` days | -| 3 | 1 | 90 | Slow rekey, `sp` day penalty + 3 \* `rt` days | +| 3 | 2 | 75 | Slow rekey, `sp` day penalty + 2 \* standard `rt` days | +| 3 | 1 | 90 | Slow rekey, `sp` day penalty + 3 \* `rt` days | | 1 | 1 | 15 | This is a case where, after a prior rekey, `m` was reduced to 1. There is no penalty, even with a single key | | 5 | 3 | 90 | In this case, a lock level increase has been performed, so 5 of 5 keys are required to avoid a penalty | | 5 | 1 | 120 | This is the longest possible initiation timelock duration when `n` is 5 and the minimum `k` is 1. In this case, `m` has been increased to 5, and 1 key is being used for the rekey | @@ -190,11 +190,11 @@ The following table lists the action/consequence, given the current value of `m`
-| `m` | Keys Sniffed | Keys Stolen | Keys Lost | -| :-- | :------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------- | :------------------------------------------------------- | -| 3 | 0-2: normal rekey
3: lock level increase to 4, normal rekey
4: lock level increase to 5, normal rekey
5: deadlocked | 0-2: normal rekey
3-5: drained | 0-2: normal rekey
3-4: slow rekey
5: bricked | -| 4 | 0-3: normal rekey
4: lock level increase to 5, normal rekey
5: deadlocked | 0-1: normal rekey
2: slow rekey
3-5: drained | 0-1: normal rekey
2-4: slow rekey
5: bricked | -| 5 | 0-4: normal rekey
5: deadlocked | 0: normal rekey
1-2: slow rekey
3-5: drained | 0: normal rekey
1-4: slow rekey
5: bricked | +| `m` | Keys Sniffed | Keys Stolen | Keys Lost | +|:--- |:------------------------------------------------------------------------------------------------------------------------------------------------------- |:-------------------------------------------------------------------- |:-------------------------------------------------------------------- | +| 3 | 0-2: normal rekey
3: lock level increase to 4, normal rekey
4: lock level increase to 5, normal rekey
5: deadlocked | 0-2: normal rekey
3-5: drained | 0-2: normal rekey
3-4: slow rekey
5: bricked | +| 4 | 0-3: normal rekey
4: lock level increase to 5, normal rekey
5: deadlocked | 0-1: normal rekey
2: slow rekey
3-5: drained | 0-1: normal rekey
2-4: slow rekey
5: bricked | +| 5 | 0-4: normal rekey
5: deadlocked | 0: normal rekey
1-2: slow rekey
3-5: drained | 0: normal rekey
1-4: slow rekey
5: bricked | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md index 432d218331e..e29aef6351b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/custody-tool-user-guide.md @@ -77,20 +77,20 @@ python -m venv venv -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` @@ -248,13 +248,13 @@ The `cic init` command will initialize the permanent layer of the singleton. **N For this guide, we'll create an example singleton that uses the values listed in the table below. As a reminder, these settings correspond to those used in the [flow chart](https://docs.chia.net/files/chia-custody-tool.png). | Flag  | Example
Value | Description | -| :--------- | :---------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-d` | keys_and_sb | The directory where the keys and spend bundles will be stored. | -| `-wt` | 600 seconds | Withdrawal Timelock -- the minimum number of seconds that must have elapsed since the last withdrawal, rekey or clawback before a withdrawal can be initiated. | -| `-pc` | 1200 seconds | Payment Claw back -- the minimum number of seconds that must elapse after initiating a withdrawal before the withdrawal can be completed. Clawbacks are possible during this window. | -| `-rt` | 300 seconds | Rekey Timelock -- when attempting to begin a standard rekey, this is the minimum number of seconds that must have elapsed since the last withdrawal, rekey or claw back. For a slow rekey, this amount gets added for each key less than `m`. | -| `-rc` | 600 seconds | Rekey Claw back -- the minimum number of seconds that must elapse after initiating a rekey before the rekey can be completed. Claw backs are possible during this window. | -| `-sp` | 900 seconds | Slow rekey Penalty -- this amount gets added to the Rekey Timelock when a slow rekey is being performed. | +|:---------- |:----------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `-d` | keys_and_sb | The directory where the keys and spend bundles will be stored. | +| `-wt` | 600 seconds | Withdrawal Timelock -- the minimum number of seconds that must have elapsed since the last withdrawal, rekey or clawback before a withdrawal can be initiated. | +| `-pc` | 1200 seconds | Payment Claw back -- the minimum number of seconds that must elapse after initiating a withdrawal before the withdrawal can be completed. Clawbacks are possible during this window. | +| `-rt` | 300 seconds | Rekey Timelock -- when attempting to begin a standard rekey, this is the minimum number of seconds that must have elapsed since the last withdrawal, rekey or claw back. For a slow rekey, this amount gets added for each key less than `m`. | +| `-rc` | 600 seconds | Rekey Claw back -- the minimum number of seconds that must elapse after initiating a rekey before the rekey can be completed. Claw backs are possible during this window. | +| `-sp` | 900 seconds | Slow rekey Penalty -- this amount gets added to the Rekey Timelock when a slow rekey is being performed. | :::info notes regarding the above table diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md index f51e31670ef..122aaee3bd3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/custody/prefarm-audit.md @@ -91,7 +91,7 @@ NOTE: A high level of technical proficiency is needed to understand the details 4. `BASE_REKEY_TIMELOCK` = integer of the rekey timelock. 5. `SLOW_REKEY_PENALTY` = integer of the slow rekey penalty. 3. Curry the necessary parameters into singleton_top_layer_v1_1.clsp `(SINGLETON_STRUCT INNER_PUZZLE)`: - 1. `SINGLETON_STRUCT` = a tree with the following elements in order `(MOD_HASH . (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH))`: + 1. `SINGLETON_STRUCT` = a tree with the following elements in order `(MOD_HASH . (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH))`: (LAUNCHER_ID . LAUNCHER_PUZZLE_HASH)): 1. `MOD_HASH` = singleton_top_layer puzzle sha256 tree hash without its curried arguments. 2. `LAUNCHER_ID` = the ID of the singleton we are committed to paying. 3. `LAUNCHER_PUZZLE_HASH` = the puzzle hash of the launcher. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md index 9771897eda3..b8128c96f61 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/dao/dao-known-issues.md @@ -16,7 +16,7 @@ Under normal circumstances, an attacker can create a malicious proposal to drain However, prior to creating this proposal, the attacker can use proposal spam to improve the chances of the attack's success. -The DAO wallet subscribes to `PROPOSAL` coins by hinting the `TREASURY_ID` in the `memos` field upon the coin's creation. To release the coins, launch the wallet from `main`, and then run the [release_coins](/reference-client/cli-reference/dao-cli#release_coins) command. +The DAO wallet subscribes to `PROPOSAL` coins by hinting the `TREASURY_ID` in the `memos` field upon the coin's creation. To release the coins, launch the wallet from `main`, and then run the [release_coins](/dao-cli#release_coins) command. - There is a limit on the number of items a `full_node` will return to a wallet based on a subscribed puzzle_hash (including hinted coins): \* `trusted_max_subscribe_response_items`: 500000 \* `max_subscribe_response_items`: 100000 - Mitigation: This issue only exists in the 2.1.2 release. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-permissions.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-permissions.md index 0df34fdcdc2..6e10cab91d0 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-permissions.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-permissions.md @@ -16,7 +16,7 @@ DataLayer Permissions give owners of data stores a method to gate participation, This guide will show you how to get started with DataLayer Permissions. Additional resources include: -- [DataLayer user guide](/guides/datalayer-user-guide) -- You should already be familiar with using DataLayer before working with permissions. This guide will help you to get started +- [DataLayer user guide](/guides/datalayer-user-guide) -- You should already be familiar with using DataLayer before working with permissions. This guide will help you to get started. Follow its full-node guidance (trusted node, synced to chain tip) for production. If the full node runs on another machine you operate, use [trusted peers](/chia-blockchain/resources/faq#what-are-trusted-peers-and-how-do-i-add-them)—never third-party or community nodes marked as trusted. - [S3 plugin](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/data_layer/s3_plugin_service.py) -- This is the reference plugin for Amazon S3 integration. It is [discussed](#the-chia-s3-plugin) later in this guide - [Source API calls](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/data_layer/data_layer.py) -- In case you want to dig into the source code - [CLI documentation](/reference-client/cli-reference/datalayer-cli) for DataLayer @@ -85,7 +85,7 @@ Functionality: Configure a store for uploading Request Parameters: | Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :-------------------------- | +|:--------- |:------ |:-------- |:--------------------------- | | store_id | STRING | True | The store ID, in hex format | Response: `{"handle_upload": [true|false]}` @@ -99,7 +99,7 @@ Functionality: Configure a store for downloading from a mirror Request Parameters: | Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :------------------------------------- | +|:--------- |:------ |:-------- |:-------------------------------------- | | store_id | STRING | True | The store ID, in hex format | | url | STRING | True | The URL of the mirror to download from | @@ -117,11 +117,11 @@ Functionality: Upload data to a store Request Parameters: -| Parameter | Type | Required | Description | -| :----------------- | :----- | :------- | :-------------------------- | -| store_id | STRING | True | The store ID, in hex format | +| Parameter | Type | Required | Description | +|:-------------------- |:------ |:-------- |:--------------------------- | +| store_id | STRING | True | The store ID, in hex format | | full_tree_filename | STRING | True | Name of full tree dat file | -| diff_filename | STRING | True | Name of delta dat file | +| diff_filename | STRING | True | Name of delta dat file | Response: `{"uploaded": [true|false]}` @@ -138,7 +138,7 @@ Functionality: Download a data file from a URI Request Parameters: | Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :------------------------------------------------- | +|:--------- |:------ |:-------- |:-------------------------------------------------- | | url | STRING | True | The URI for the download, eg `"server_info.url"` | | filename | STRING | True | The name of the file to download, eg `"file1.dat"` | @@ -157,7 +157,7 @@ Functionality: Add missing files to a store Request Parameters: | Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------------------------------------------------- | +|:--------- |:------ |:-------- |:------------------------------------------------------------------------ | | store_id | STRING | True | The store ID, in hex format | | files | LIST | True | The list of files to be added, for example: `["file1.dat", "file2.dat"]` | @@ -232,10 +232,10 @@ Functionality: Add a new store Request Parameters: | Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :---------------------------------------------------------------------------------------------------------- | +|:--------- |:------ |:-------- |:----------------------------------------------------------------------------------------------------------- | | store_id | STRING | True | The store ID, in hex format | -| bucket | STRING | True\* | The name of the S3 bucket [* Either `bucket` or `urls` or both is required] | -| urls | LIST | True\* | A list of s3 URLs, for example `["s3://one", "s3://two"]` [* Either `bucket` or `urls` or both is required] | +| bucket | STRING | True\* | The name of the S3 bucket [* Either `bucket` or `urls` or both is required] | +| urls | LIST | True\* | A list of s3 URLs, for example `["s3://one", "s3://two"]` [* Either `bucket` or `urls` or both is required] | Success Response: `{"success": true, "id": store id}` @@ -254,7 +254,7 @@ Functionality: Remove a store Request Parameters: | Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :-------------------------- | +|:--------- |:------ |:-------- |:--------------------------- | | store_id | STRING | True | The store ID, in hex format | Response: `{"success": [true|false], "store_id":store id in hex if successful}` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md index 5f1f4db3ba9..4fae4ef2b07 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/datalayer/datalayer-user-guide.md @@ -126,7 +126,19 @@ If you ever need to display your address, run `chia keys show`. This command wil ### Configure Chia to run DataLayer -At this point, you should have installed and started Chia. You should also have a synced wallet with some XCH (0.01 XCH is sufficient to get started). You do _not_ need a synced full node. +At this point, you should have installed and started Chia. You should also have a synced wallet with some XCH (0.01 XCH is sufficient to get started). **Chia strongly recommends** using DataLayer with a **trusted full node that is fully synced** to chain tip. That keeps on-chain state, confirmations, and mempool behavior accurate and under your control. Relying on Wallet Mode only, or on a full node that is still catching up, is **not recommended** for production or security-sensitive use. + +:::info Full node on a different machine + +When you **cannot** run a full node on the same system as DataLayer, point this client at a **synced full node you own and operate** elsewhere (for example another server or workstation in your environment). Configure it using [What are trusted peers and how do I add them?](/chia-blockchain/resources/faq#what-are-trusted-peers-and-how-do-i-add-them). **Add trusted peers only for infrastructure you control.** Anyone who operates the node you mark as trusted can influence the chain tip, blocks, and related state your wallet trusts—so community nodes, hosted strangers' nodes, and other third parties must **not** be added as trusted peers for DataLayer or production wallets. + +::: + +:::tip Faster full-node sync + +Syncing from genesis can take a long time. Download an official [database checkpoint](https://www.chia.net/downloads/#database-checkpoint) and follow [Using the Official Database Snapshot Torrent](/reference-client/troubleshooting/node-syncing#using-the-official-database-snapshot-torrent) for step-by-step setup—usually much faster than syncing from scratch. + +::: :::info @@ -268,20 +280,21 @@ As shown in the above image: Finally, you need to restart Chia. Close the GUI and run steps 3 and 6 above. When Chia starts, it will automatically enable both of the DataLayer services. -5. If the dot to the left of `WALLET` is green (indicating that your wallet is synced), then you may proceed. If it is still orange, then you need to wait for it turn green before continuing. +5. Before you continue, confirm the following in the Chia GUI: + - The dot to the left of `WALLET` is green (wallet synced). If it is orange, wait until it turns green. + - If `FULL NODE` appears in the sidebar, the dot to the left of `FULL NODE` must be green (local full node synced to chain tip). If it is orange, wait until it turns green. + - If `FULL NODE` does **not** appear (Wallet Mode) because your full node runs on another machine, complete [trusted peer setup](/chia-blockchain/resources/faq#what-are-trusted-peers-and-how-do-i-add-them) first: only your own synced full node(s), `connect_to_unknown_peers: false`, and verify with `chia wallet show` that the wallet lists `-Trusted: True` as in the FAQ. Do not proceed while the wallet is syncing from default untrusted peers. -:::info +:::info Full node status -Regardless of the status of `FULL NODE`, you may safely proceed with this tutorial: +- Orange dot = full node is still syncing; wait before relying on DataLayer for important work. +- Green dot = full node is synced to chain tip (recommended before continuing this guide). +- Missing `FULL NODE` usually means Wallet Mode. Default behavior (syncing from many **untrusted** peers) is **not** acceptable for production DataLayer. Either run a **local** full node (checkpoint download above can speed that up) or use Wallet Mode **only** with a remote full node **you operate**, configured strictly as [trusted peers](/chia-blockchain/resources/faq#what-are-trusted-peers-and-how-do-i-add-them)—never community or third-party nodes you do not control. -- Orange dot = full node is syncing -- Green dot = full node is synced -- `FULL NODE` is missing = you are running in `Wallet Mode` - -::: +:::
- Synced wallet + Wallet and full node both synced (green)

diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-bulk-mint.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-bulk-mint.md index d9bec7dc4c5..074b5b8b67d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-bulk-mint.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-bulk-mint.md @@ -102,20 +102,20 @@ python -m venv venv -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` -````bash +```bash python3 -m venv venv . ./venv/bin/activate ``` ./venv/bin/activate -```` +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md index 531d4b66cfa..a55420edd0d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-intro.md @@ -63,7 +63,7 @@ The cost for minting and modifying NFTs is significantly higher. The following c If the mempool is not full, then a 1-mojo fee will be sufficient for any of these spends to be included in the next transaction block. To view the current status of the mempool, see the [Mempool Cost](https://dashboard.chia.net/d/46EAA05E/mempool-transactions-and-fees?orgId=1&viewPanel=40) table on our dashboard site. (If the green line representing the current mempool cost is close to the red line representing the maximum cost, then the mempool is full, and the following table should be used.) | Operation | Cost (approx) | Min fee (mojos) | Cost in USD at $30/XCH | -| :------------------------------ | ------------: | :-------------- | :--------------------- | +|:------------------------------- | -------------:|:--------------- |:---------------------- | | Minting NFT without DID | 53 million | 265 million | $0.00795 | | Minting NFT with DID | 123 million | 615 million | $0.01845 | | Adding a URI to NFT without DID | 41 million | 205 million | $0.00615 | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md index 8cd03655ac3..af590197ce5 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/verifiable-credentials-guide.md @@ -344,7 +344,7 @@ Proofs: ## RPC Guide -This section will show you how to mint, transfer, and revoke a VC using Chia's [wallet RPC](/reference-client/rpc-reference/vc-rpc). The RPC commands will generally give more detailed responses than their CLI equivalents, but the functionality will be mostly the same. +This section will show you how to mint, transfer, and revoke a VC using Chia's [wallet RPC](/reference-client/rpc-reference/vc-rpc). This section will show you how to mint, transfer, and revoke a VC using Chia's [wallet RPC](/vc-rpc). The RPC commands will generally give more detailed responses than their CLI equivalents, but the functionality will be mostly the same.
Note about Windows command escaping diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-developer-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-developer-guide.md index 4260b2f78fc..e603faf0328 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-developer-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-developer-guide.md @@ -24,50 +24,50 @@ For more info, see our WalletConnect [command documentation](/reference-client/w The following table shows each RPC for Chia WalletConnect dApps, along with a description of what each RPC does, and a link to the equivalent Chia RPC: -| WalletConnect RPC | Chia Wallet RPC | Description | -| :-------------------- | :---------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------ | -| addCATtoken | [create_new_wallet](/reference-client/rpc-reference/wallet-rpc#create_new_wallet) | Create a new wallet for CATs | -| addVCProofs | [vc_add_proofs](/reference-client/rpc-reference/vc-rpc/#vc_add_proofs) | Add a set of proofs to the DB that can be used when spending a VC | -| cancelOffer | [cancel_offer](/reference-client/rpc-reference/wallet-rpc#cancel_offer) | Cancel an offer | -| checkOfferValidity | [check_offer_validity](/reference-client/rpc-reference/wallet-rpc#check_offer_validity) | Check if an offer is valid | -| createNewDIDWallet | [create_new_wallet](/reference-client/rpc-reference/did-rpc/#create_new_wallet) | Create a new DID wallet | -| createOfferForIDs | [create_offer_for_ids](/reference-client/rpc-reference/wallet-rpc#create_offer_for_ids) | Create a new offer | -| getAllOffers | [get_all_offers](/reference-client/rpc-reference/wallet-rpc#get_all_offers) | Show the details of all offers for this wallet | -| getCATAssetId | [cat_get_asset_id](/reference-client/rpc-reference/wallet-rpc#cat_get_asset_id) | Retrieve a the asset ID from a CAT wallet | -| getCATWalletInfo | [get_wallets](/reference-client/rpc-reference/wallet-rpc/#get_wallets) | Get CAT Wallet Info | +| WalletConnect RPC | Chia Wallet RPC | Description | +|:--------------------- |:--------------------------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------------- | +| addCATtoken | [create_new_wallet](/reference-client/rpc-reference/wallet-rpc#create_new_wallet) | Create a new wallet for CATs | +| addVCProofs | [vc_add_proofs](/reference-client/rpc-reference/vc-rpc/#vc_add_proofs) | Add a set of proofs to the DB that can be used when spending a VC | +| cancelOffer | [cancel_offer](/reference-client/rpc-reference/wallet-rpc#cancel_offer) | Cancel an offer | +| checkOfferValidity | [check_offer_validity](/reference-client/rpc-reference/wallet-rpc#check_offer_validity) | Check if an offer is valid | +| createNewDIDWallet | [create_new_wallet](/reference-client/rpc-reference/did-rpc/#create_new_wallet) | Create a new DID wallet | +| createOfferForIDs | [create_offer_for_ids](/reference-client/rpc-reference/wallet-rpc#create_offer_for_ids) | Create a new offer | +| getAllOffers | [get_all_offers](/reference-client/rpc-reference/wallet-rpc#get_all_offers) | Show the details of all offers for this wallet | +| getCATAssetId | [cat_get_asset_id](/reference-client/rpc-reference/wallet-rpc#cat_get_asset_id) | Retrieve a the asset ID from a CAT wallet | +| getCATWalletInfo | [get_wallets](/reference-client/rpc-reference/wallet-rpc/#get_wallets) | Get CAT Wallet Info | | getCurrentAddress | [get_next_address](/reference-client/rpc-reference/wallet-rpc#get_next_address)\* | Set `new_address` to `false` to use the current address | | getNextAddress | [get_next_address](/reference-client/rpc-reference/wallet-rpc#get_next_address)\* | Set `new_address` to `true` to create a new address | -| getNFTsCount | [nft_count_nfts](/reference-client/rpc-reference/nft-rpc/#nft_count_nfts) | Count the number of NFTs in a wallet | -| getNFTInfo | [nft_get_info](/reference-client/rpc-reference/nft-rpc/#nft_get_info) | Get info about an NFT | -| getNFTs | [nft_get_nfts](/reference-client/rpc-reference/nft-rpc/#nft_get_nfts) | Show all NFTs in a given wallet | +| getNFTsCount | [nft_count_nfts](/reference-client/rpc-reference/nft-rpc/#nft_count_nfts) | Count the number of NFTs in a wallet | +| getNFTInfo | [nft_get_info](/reference-client/rpc-reference/nft-rpc/#nft_get_info) | Get info about an NFT | +| getNFTs | [nft_get_nfts](/reference-client/rpc-reference/nft-rpc/#nft_get_nfts) | Show all NFTs in a given wallet | | getNFTWalletsWithDIDs | [nft_get_wallets_with_dids](/reference-client/rpc-reference/nft-rpc/#nft_get_wallets_with_dids) | Show all NFT wallets that are associated with DIDs | -| getOfferData | [get_offer](/reference-client/rpc-reference/wallet-rpc#get_offer) | Show the details of one offer | -| getOfferRecord | [get_all_offers](/reference-client/rpc-reference/wallet-rpc#get_all_offers) | Show the details of all offers for this wallet | -| getOffersCount | [get_offers_count](/reference-client/rpc-reference/wallet-rpc#get_offers_count) | Obtain the number of offers from the current wallet | -| getOfferSummary | [get_offer_summary](/reference-client/rpc-reference/wallet-rpc#get_offer_summary) | Show a summary of an offer | +| getOfferData | [get_offer](/reference-client/rpc-reference/wallet-rpc#get_offer) | Show the details of one offer | +| getOfferRecord | [get_all_offers](/reference-client/rpc-reference/wallet-rpc#get_all_offers) | Show the details of all offers for this wallet | +| getOffersCount | [get_offers_count](/reference-client/rpc-reference/wallet-rpc#get_offers_count) | Obtain the number of offers from the current wallet | +| getOfferSummary | [get_offer_summary](/reference-client/rpc-reference/wallet-rpc#get_offer_summary) | Show a summary of an offer | | getProofsForRoot | [vc_get_proofs_for_root](/reference-client/rpc-reference/vc-rpc/#vc_get_proofs_for_root) | Given a specified VC root, get any proofs associated with that root | -| getPublicKey | [get_public_key](/reference-client/rpc-reference/daemon-rpc#get_public_key) | Request the user to provide their master public key | -| getSyncStatus | [get_sync_status](/reference-client/rpc-reference/wallet-rpc#get_sync_status) | Show whether the current wallet is syncing or synced | -| getTransaction | [get_transaction](/reference-client/rpc-reference/wallet-rpc#get_transaction) | Get a transaction's details from its ID | -| getVC | [vc_get](/reference-client/rpc-reference/vc-rpc/#vc_get) | Given a launcher ID, get the Verifiable Credential | -| getVCList | [vc_get_list](/reference-client/rpc-reference/vc-rpc/#vc_get_list) | Get a list of Verifiable Credentials | -| getWalletAddresses | [get_wallet_addresses](/reference-client/rpc-reference/daemon-rpc/#get_wallet_addresses) | Get wallet addresses for one or more wallet keys | -| getWalletBalance | [get_wallet_balance](/reference-client/rpc-reference/wallet-rpc#get_wallet_balance) | Obtain the balance (and related info) from a wallet | -| getWalletBalances | [get_wallet_balances](/reference-client/rpc-reference/wallet-rpc/#get_wallet_balances) | Request the asset balances for specific wallets associated with the current wallet key | -| getWallets | [get_wallets](/reference-client/rpc-reference/wallet-rpc#get_wallets) | Show all wallets associated with the current fingerprint, including (by default) coin information | -| logIn | [log_in](/reference-client/rpc-reference/wallet-rpc#log_in) | Log into the wallet with the specified key | -| mintNFT | [nft_mint_nft](/reference-client/rpc-reference/nft-rpc/#nft_mint_nft) | Mint an NFT | -| revokeVC | [vc_revoke](/reference-client/rpc-reference/vc-rpc/#vc_revoke) | Revoke an on chain VC provided the correct DID is available | -| sendTransaction | [send_transaction](/reference-client/rpc-reference/wallet-rpc#send_transaction) | Send a transaction | -| setDIDName | [did_set_wallet_name](/reference-client/rpc-reference/did-rpc/#did_set_wallet_name) | Set the name of a DID wallet | -| setNFTDID | [nft_set_nft_did](/reference-client/rpc-reference/nft-rpc/#nft_set_nft_did) | Set the DID for an NFT | -| showNotification | [get_notifications](/reference-client/rpc-reference/wallet-rpc/#get_notifications) | Show notification with offer or general announcement | -| signMessageByAddress | [sign_message_by_address](/reference-client/rpc-reference/wallet-rpc#sign_message_by_address) | Sign a message using an XCH address without incurring an on-chain transaction | -| signMessageById | [sign_message_by_id](/reference-client/rpc-reference/wallet-rpc#sign_message_by_id) | Sign a message using a DID or NFT ID without incurring an on-chain transaction | -| spendCAT | [cat_spend](/reference-client/rpc-reference/wallet-rpc#cat_spend) | Send CAT funds to another wallet | -| spendClawbackCoins | [spend_clawback_coins](/reference-client/rpc-reference/wallet-rpc/#spend_clawback_coins) | Claw back or claim claw back transaction | -| takeOffer | [take_offer](/reference-client/rpc-reference/wallet-rpc#take_offer) | Take an offer | -| transferNFT | [nft_transfer_nft](/reference-client/rpc-reference/nft-rpc#nft_transfer_nft) | Transfer an NFT to a new wallet address | -| spendVC | [vc_spend](/reference-client/rpc-reference/vc-rpc/#vc_spend) | Add Proofs To Verifiable Credential | -| verifySignature | [verify_signature](/reference-client/rpc-reference/wallet-rpc#verify_signature) | Given a public key, message and signature, verify if it is valid | -| waitForConfirmation | | | +| getPublicKey | [get_public_key](/reference-client/rpc-reference/daemon-rpc#get_public_key) | Request the user to provide their master public key | +| getSyncStatus | [get_sync_status](/reference-client/rpc-reference/wallet-rpc#get_sync_status) | Show whether the current wallet is syncing or synced | +| getTransaction | [get_transaction](/reference-client/rpc-reference/wallet-rpc#get_transaction) | Get a transaction's details from its ID | +| getVC | [vc_get](/reference-client/rpc-reference/vc-rpc/#vc_get) | Given a launcher ID, get the Verifiable Credential | +| getVCList | [vc_get_list](/reference-client/rpc-reference/vc-rpc/#vc_get_list) | Get a list of Verifiable Credentials | +| getWalletAddresses | [get_wallet_addresses](/reference-client/rpc-reference/daemon-rpc/#get_wallet_addresses) | Get wallet addresses for one or more wallet keys | +| getWalletBalance | [get_wallet_balance](/reference-client/rpc-reference/wallet-rpc#get_wallet_balance) | Obtain the balance (and related info) from a wallet | +| getWalletBalances | [get_wallet_balances](/reference-client/rpc-reference/wallet-rpc/#get_wallet_balances) | Request the asset balances for specific wallets associated with the current wallet key | +| getWallets | [get_wallets](/reference-client/rpc-reference/wallet-rpc#get_wallets) | Show all wallets associated with the current fingerprint, including (by default) coin information | +| logIn | [log_in](/reference-client/rpc-reference/wallet-rpc#log_in) | Log into the wallet with the specified key | +| mintNFT | [nft_mint_nft](/reference-client/rpc-reference/nft-rpc/#nft_mint_nft) | Mint an NFT | +| revokeVC | [vc_revoke](/reference-client/rpc-reference/vc-rpc/#vc_revoke) | Revoke an on chain VC provided the correct DID is available | +| sendTransaction | [send_transaction](/reference-client/rpc-reference/wallet-rpc#send_transaction) | Send a transaction | +| setDIDName | [did_set_wallet_name](/reference-client/rpc-reference/did-rpc/#did_set_wallet_name) | Set the name of a DID wallet | +| setNFTDID | [nft_set_nft_did](/reference-client/rpc-reference/nft-rpc/#nft_set_nft_did) | Set the DID for an NFT | +| showNotification | [get_notifications](/reference-client/rpc-reference/wallet-rpc/#get_notifications) | Show notification with offer or general announcement | +| signMessageByAddress | [sign_message_by_address](/reference-client/rpc-reference/wallet-rpc#sign_message_by_address) | Sign a message using an XCH address without incurring an on-chain transaction | +| signMessageById | [sign_message_by_id](/reference-client/rpc-reference/wallet-rpc#sign_message_by_id) | Sign a message using a DID or NFT ID without incurring an on-chain transaction | +| spendCAT | [cat_spend](/reference-client/rpc-reference/wallet-rpc#cat_spend) | Send CAT funds to another wallet | +| spendClawbackCoins | [spend_clawback_coins](/reference-client/rpc-reference/wallet-rpc/#spend_clawback_coins) | Claw back or claim claw back transaction | +| takeOffer | [take_offer](/reference-client/rpc-reference/wallet-rpc#take_offer) | Take an offer | +| transferNFT | [nft_transfer_nft](/reference-client/rpc-reference/nft-rpc#nft_transfer_nft) | Transfer an NFT to a new wallet address | +| spendVC | [vc_spend](/reference-client/rpc-reference/vc-rpc/#vc_spend) | Add Proofs To Verifiable Credential | +| verifySignature | [verify_signature](/reference-client/rpc-reference/wallet-rpc#verify_signature) | Given a public key, message and signature, verify if it is valid | +| waitForConfirmation | | | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/asic-hwvdf-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/asic-hwvdf-cli.md index 129e3a0f0d1..31851481be2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/asic-hwvdf-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/asic-hwvdf-cli.md @@ -17,20 +17,19 @@ Usage: hw_vdf_client [OPTIONS] PORT [N_VDFS] Options: -| Long Command | Type | Required | Description | -| :----------------- | :------ | :------- | :---------------------------------------------------- | -| --freq | INTEGER | False | set ASIC frequency [%d, 200 - 2200] | -| --voltage | INTEGER | False | set board voltage [.88, 0.7 - 1.0] | -| --ip | TEXT | False | timelord IP address [localhost] | -| --vdfs-mask | TEXT | False | mask for enabling VDF engines [7, 1 - 7] | -| --vdf-threads | TEXT | False | number of software threads per VDF engine [4, 2 - 64] | -| --proof-threads | TEXT | False | number of proof threads per VDF engine [3, 1 - 63] | -| --auto-freq-period | TEXT | False | auto-adjust frequency every N seconds [0, 10 - inf] | -| --list | TEXT | False | list available devices and exit | -| --help | None | False | Show a help message and exit | - -
-Example 1 - Run the ASIC software with defaults +| Long Command | Type | Required | Description | +| :----------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------- | +| --freq | INTEGER | False | set ASIC frequency [%d, 200 - 2200] | +| --voltage | INTEGER | False | set board voltage [.88, 0.7 - 1.0] | +| --ip | TEXT | False | timelord IP address [localhost] | +| --vdfs-mask | TEXT | False | mask for enabling VDF engines [7, 1 - 7] | +| --vdf-threads | TEXT | False | number of software threads per VDF engine [4, 2 - 64] | +| --proof-threads | TEXT | False | number of proof threads per VDF engine [3, 1 - 63] | +| --auto-freq-period | TEXT | False | auto-adjust frequency every N seconds [0, 10 - inf] | +| --list | TEXT | False | list available devices and exit | +| --help | None | False | Show a help message and exit | + +
Example 1 - Run the ASIC software with defaults ```bash hw_vdf_client 8000 3 @@ -52,8 +51,7 @@ Response:
-
-Example 2 - Run the ASIC software with auto-frequency, initial frequency, and defined ip +
Example 2 - Run the ASIC software with auto-frequency, initial frequency, and defined ip ```bash hw_vdf_client --freq 1500 --auto-freq-period 60 --ip 192.168.0.122 8000 3 @@ -75,8 +73,7 @@ Response:
-
-Example 3 - Run the ASIC software with defined ip and only 1 vdf (i.e. defaults for cluster) +
Example 3 - Run the ASIC software with defined ip and only 1 vdf (i.e. defaults for cluster) ```bash hw_vdf_client --ip 192.168.0.122 8000 1 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cat-admin-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cat-admin-cli.md index 6c8b057d788..25ba839027f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cat-admin-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cat-admin-cli.md @@ -23,30 +23,29 @@ Usage: cats [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| -l | --tail | TEXT | True | The TAIL program to launch this CAT with | -| -c | --curry | TEXT | False | An argument to curry into the TAIL | -| -s | --solution | TEXT | False | The solution to the TAIL program [default: ()] | -| -t | --send-to | TEXT | True | The address these CATs will appear at once they are issued | -| -a | --amount | INTEGER | True | The amount to issue in mojos (regular XCH will be used to fund this) | -| -m | --fee | INTEGER | False | The fees for the transaction, in mojos [default: 0] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -l | --tail | TEXT | True | The TAIL program to launch this CAT with | +| -c | --curry | TEXT | False | An argument to curry into the TAIL | +| -s | --solution | TEXT | False | The solution to the TAIL program [default: ()] | +| -t | --send-to | TEXT | True | The address these CATs will appear at once they are issued | +| -a | --amount | INTEGER | True | The amount to issue in mojos (regular XCH will be used to fund this) | +| -m | --fee | INTEGER | False | The fees for the transaction, in mojos [default: 0] | | -d | --authorized-provider | TEXT | False | A trusted DID that can issue VCs that are allowed to trade the CAT. Specifying this option will make the CAT a CR (credential restricted) CAT. Requires specifying either --proofs-checker or --cr-flag Specifying this option will make the CAT a CR (credential restricted) CAT. Requires specifying either `--proofs-checker` or `--cr-flag` | -| -r | --proofs-checker | TEXT | False | The program that checks the proofs of a VC for a CR-CAT. Specifying this option requires a value for --authorized-providers Specifying this option requires a value for `--authorized-providers` | -| -v | --cr-flag | TEXT | False | Specify a list of flags to check a VC for in order to authorize this CR-CAT. Specifying this option requires a value for --authorized-providers. Cannot be used if a custom --proofs-checker is specified. Specifying this option requires a value for `--authorized-providers`. Cannot be used if a custom `--proofs-checker` is specified. | -| -f | --fingerprint | INTEGER | False | The wallet fingerprint to use as funds | -| -sig | --signature | TEXT | False | A signature to aggregate with the transaction | -| -as | --spend | TEXT | False | An additional spend to aggregate with the transaction | -| -b | --as-bytes | None | False | Output the spend bundle as a sequence of bytes instead of JSON | -| -sc | --select-coin | None | False | Stop the process once a coin from the wallet has been selected and return the coin | -| -q | --quiet | None | False | Quiet mode will not ask to push transaction to the network | -| -p | --push | None | False | Automatically push transaction to the network in quiet mode | -| | --root-path | PATH | False | The root folder where the config lies [default: ~/.chia/mainnet] | -| | --wallet-rpc-port | INTEGER | False | The RPC port the wallet service is running on | -| | --help | None | False | Show a help message and exit | - -
-Example 1 - select a coin from the wallet with a value of at least 1 XCH (1 trillion mojos) +| -r | --proofs-checker | TEXT | False | The program that checks the proofs of a VC for a CR-CAT. Specifying this option requires a value for --authorized-providers Specifying this option requires a value for `--authorized-providers` | +| -v | --cr-flag | TEXT | False | Specify a list of flags to check a VC for in order to authorize this CR-CAT. Specifying this option requires a value for --authorized-providers. Cannot be used if a custom --proofs-checker is specified. Specifying this option requires a value for `--authorized-providers`. Cannot be used if a custom `--proofs-checker` is specified. | +| -f | --fingerprint | INTEGER | False | The wallet fingerprint to use as funds | +| -sig | --signature | TEXT | False | A signature to aggregate with the transaction | +| -as | --spend | TEXT | False | An additional spend to aggregate with the transaction | +| -b | --as-bytes | None | False | Output the spend bundle as a sequence of bytes instead of JSON | +| -sc | --select-coin | None | False | Stop the process once a coin from the wallet has been selected and return the coin | +| -q | --quiet | None | False | Quiet mode will not ask to push transaction to the network | +| -p | --push | None | False | Automatically push transaction to the network in quiet mode | +| | --root-path | PATH | False | The root folder where the config lies [default: ~/.chia/mainnet] | +| | --wallet-rpc-port | INTEGER | False | The RPC port the wallet service is running on | +| | --help | None | False | Show a help message and exit | + +
Example 1 - select a coin from the wallet with a value of at least 1 XCH (1 trillion mojos) Request: @@ -69,8 +68,7 @@ The "parent_coin_info", "puzzle_hash", and "amount" values are hashed together t
-
-Example 2 - Push a transaction to the network, currying an inner puzzle hash into the TAIL +
Example 2 - Push a transaction to the network, currying an inner puzzle hash into the TAIL Request: @@ -91,8 +89,7 @@ After pushing the transaction, the new ID and Eve Coin (singleton parent coin) w
-
-Example 3 - Mint a new CR-CAT +
Example 3 - Mint a new CR-CAT First, select a coin to use for the minting. Flags included in this example (CR-specific flags are in **bold**): @@ -185,17 +182,16 @@ Usage: secure_the_bag [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -c | --curry | TEXT | False | An argument to curry into the TAIL | -| -a | --amount | INTEGER | True | The amount to issue in mojos (regular XCH will be used to fund this) | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -c | --curry | TEXT | False | An argument to curry into the TAIL | +| -a | --amount | INTEGER | True | The amount to issue in mojos (regular XCH will be used to fund this) | | -stbtp | --secure-the-bag-targets-path | TEXT | True | Path to CSV file containing targets of secure the bag (inner puzzle hash + amount). The total value of the coins in this file must match the value of the `amount` flag. If they don't match, an error will be thrown. | -| -lw | --leaf-width | INTEGER | True | Secure the bag leaf width [default: 100] | -| -pr | --prefix | TEXT | True | Address prefix [default: xch] | -| | --help | NONE | False | Show a help message and exit | +| -lw | --leaf-width | INTEGER | True | Secure the bag leaf width [default: 100] | +| -pr | --prefix | TEXT | True | Address prefix [default: xch] | +| | --help | NONE | False | Show a help message and exit | -
-Create a coin tree from a CSV file, currying a coin ID that was obtained from the cats command +
Create a coin tree from a CSV file, currying a coin ID that was obtained from the cats command ```bash secure_the_bag --tail .\reference_tails\genesis_by_coin_id.clsp.hex --amount 1000000000000 --secure-the-bag-targets-path C:\Users\User\Downloads\spacebucks.csv --prefix txch --curry 0x8f4dbff8df3f6aa9303eb47625cf8f09d885f1ad6a2d440582cb6bd45f53d2e8 @@ -221,20 +217,19 @@ Usage: secure_the_bag [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------- | -| -ecid | --eve-coin-id | TEXT | True | ID of coin that was spent to create secured bag | -| -th | --tail-hash | TEXT | True | TAIL hash / Asset ID of CAT to unwind from secured bag of CATs | -| -stbtp | --secure-the-bag-targets-path | TEXT | True | Path to CSV file containing targets of secure the bag (inner puzzle hash + amount) | -| -utph, | --unwind-target-puzzle-hash | TEXT | False | Puzzle hash of target to unwind from secured bag. This is a useful option for testing a single unwind | -| -wi | --wallet-id | INTEGER | False | The wallet id to use (typically `1`) | -| -f | --fingerprint | INTEGER | False | The wallet fingerprint to use as funds | -| -uf | --unwind-fee | INTEGER | True | Fee paid for each unwind spend. Enough mojos must be available to cover all spends [default: 500000] | -| -lw | --leaf-width | INTEGER | True | Secure the bag leaf width (number of tokens to unwind in one block) [default: 100] | -| | --help | NONE | False | Show a help message and exit | - -
-Unwind a bag that has been secured with the above example, using a puzzle hash +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -ecid | --eve-coin-id | TEXT | True | ID of coin that was spent to create secured bag | +| -th | --tail-hash | TEXT | True | TAIL hash / Asset ID of CAT to unwind from secured bag of CATs | +| -stbtp | --secure-the-bag-targets-path | TEXT | True | Path to CSV file containing targets of secure the bag (inner puzzle hash + amount) | +| -utph, | --unwind-target-puzzle-hash | TEXT | False | Puzzle hash of target to unwind from secured bag. This is a useful option for testing a single unwind | +| -wi | --wallet-id | INTEGER | False | The wallet id to use (typically `1`) | +| -f | --fingerprint | INTEGER | False | The wallet fingerprint to use as funds | +| -uf | --unwind-fee | INTEGER | True | Fee paid for each unwind spend. Enough mojos must be available to cover all spends [default: 500000] | +| -lw | --leaf-width | INTEGER | True | Secure the bag leaf width (number of tokens to unwind in one block) [default: 100] | +| | --help | NONE | False | Show a help message and exit | + +
Unwind a bag that has been secured with the above example, using a puzzle hash ```bash unwind_the_bag --eve-coin-id 9fe3e95308949cb9c49333f829922dc7118cd3e2fdf365cde669b47852ce3a7b --tail-hash 9c39398afb1d7ffa03a589f60e5e39f2ae4572ff7048e689fe3128c339581b2d --secure-the-bag-targets-path C:\Users\User\Downloads\spacebucks.csv --unwind-fee 500000 --wallet-id 1 --unwind-target-puzzle-hash af85d83ff01ec4b6f37d85d038e68736adc6cc9bb2c48c9d0973605448f73f3f diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/clawback-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/clawback-cli.md index 05bee82cacb..ebf02384665 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/clawback-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/clawback-cli.md @@ -59,17 +59,17 @@ Usage: `clawback claim [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -c | --coin-id | TEXT | True | The coin ID you want to claim | -| -m | --fee | FLOAT | False | The fee in XCH for this transaction | -| -w | --wallet-id | INTEGER | False | The wallet id for fees. If no target address given the clawback will go to this wallet id | -| -t | --target-address | TEXT | False | The address you want to send the coin to | -| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -c | --coin-id | TEXT | True | The coin ID you want to claim | +| -m | --fee | FLOAT | False | The fee in XCH for this transaction | +| -w | --wallet-id | INTEGER | False | The wallet id for fees. If no target address given the clawback will go to this wallet id | +| -t | --target-address | TEXT | False | The address you want to send the coin to | +| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -db | --db-path | TEXT | False | Set the path for the database | -| -h | --help | None | False | Show a help message and exit | +| -db | --db-path | TEXT | False | Set the path for the database | +| -h | --help | None | False | Show a help message and exit | :::info @@ -85,8 +85,7 @@ In this case, the Recipient needs to wait for one more block to be farmed before ::: -
-Example +
Example First, the Sender creates a new clawback coin with a 60-second timelock: @@ -244,20 +243,19 @@ Usage: `clawback claw [OPTIONS]` Options: Clawback an unclaimed coin -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -c | --coin-id | TEXT | True | The coin ID for the clawback coin to inspect | -| -m | --fee | FLOAT | False | The fee in XCH for this transaction | -| -w | --wallet-id | INTEGER | False | The wallet id for fees. If no target address given the clawback will go to this wallet id | -| -t | --target-address | TEXT | False | The address you want to sent the clawed back coin to | -| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -c | --coin-id | TEXT | True | The coin ID for the clawback coin to inspect | +| -m | --fee | FLOAT | False | The fee in XCH for this transaction | +| -w | --wallet-id | INTEGER | False | The wallet id for fees. If no target address given the clawback will go to this wallet id | +| -t | --target-address | TEXT | False | The address you want to sent the clawed back coin to | +| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -db | --db-path | TEXT | False | Set the path for the database | -| -h | --help | None | False | Show a help message and exit | +| -db | --db-path | TEXT | False | Set the path for the database | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Let's say the following clawback coin exists: @@ -316,21 +314,20 @@ Usage: `clawback create [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -t | --to | TEXT | True | The recipient's address | -| -l | --timelock | INTEGER | False | The timelock to use for the clawback coin you're creating, in seconds. Default is two weeks | -| -a | --amount | INTEGER | True | The amount to fund (in XCH) | -| -w | --wallet-id | INTEGER | False | The wallet id to send from | -| -m | --fee | FLOAT | False | The fee in XCH for the funding transaction | -| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -t | --to | TEXT | True | The recipient's address | +| -l | --timelock | INTEGER | False | The timelock to use for the clawback coin you're creating, in seconds. Default is two weeks | +| -a | --amount | INTEGER | True | The amount to fund (in XCH) | +| -w | --wallet-id | INTEGER | False | The wallet id to send from | +| -m | --fee | FLOAT | False | The fee in XCH for the funding transaction | +| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -db | --db-path | TEXT | False | Set the path for the database | -| -h | --help | None | False | Show a help message and exit | +| -db | --db-path | TEXT | False | Set the path for the database | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example For this example, we will use two wallets: a Sender and a Recipient. The Sender has a balance of 10 TXCH and the Recipient has 0 TXCH. @@ -409,17 +406,16 @@ Usage: `clawback show [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -c | --coin-id | TEXT | False | The coin ID for the clawback coin to inspect | -| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -c | --coin-id | TEXT | False | The coin ID for the clawback coin to inspect | +| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -db | --db-path | TEXT | False | Set the path for the database | -| -h | --help | None | False | Show a help message and exit | +| -db | --db-path | TEXT | False | Set the path for the database | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 The Sender can show a Clawback coin without passing in the Coin ID: @@ -442,8 +438,7 @@ Time left: 518 seconds
-
-Example 2 +
Example 2 Anyone other than the sender needs to pass in the Coin ID in order to show a Clawback coin: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cli.md index 2aa71aba180..4ee66e49f74 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cli.md @@ -25,6 +25,20 @@ Some examples: As with the rest of this project, this doc is a work-in-progress. Feel free to browse the [source code](https://github.com/Chia-Network/chia-blockchain/tree/main/chia/cmds) or the [Chia Proof of Space Construction Document](https://www.chia.net/assets/Chia_Proof_of_Space_Construction_v1.1.pdf) for more insight in the meantime. +## Related CLI references + +This page is an overview. Deeper command documentation lives in topic pages, for example: + +- [Wallet CLI](/reference-client/cli-reference/wallet-cli) +- [Offers](/reference-client/cli-reference/offer-cli) +- [Verifiable Credentials (VC)](/reference-client/cli-reference/vc-cli) +- [Clawback](/reference-client/cli-reference/clawback-cli) +- [Simulator](/reference-client/cli-reference/simulator-cli) +- [Plotters](/reference-client/cli-reference/plotter-cli) +- [DID](/reference-client/cli-reference/did-cli) and [NFT](/reference-client/cli-reference/nft-cli) +- [DAO CLI](/reference-client/cli-reference/dao-cli) (historical: the DAO wallet was [removed in Chia 2.5.3](https://github.com/Chia-Network/chia-blockchain/blob/main/CHANGELOG.md#253-chia-blockchain-2025-03-25)) +- HTTP RPC (for `chia rpc …`): [Wallet RPC](/reference-client/rpc-reference/wallet-rpc) and the other service pages under [RPC reference](/reference-client/rpc-reference/rpc) + # Locate the `chia` binary executable ## Mac @@ -49,19 +63,19 @@ Then, running the `chia -h` command should work. There is more than one `chia.exe` binary; the GUI is `Chia.exe` (two of these!) and the CLI is `chia.exe`. They are found in different places. Note the big C versus the little c. -The CLI one is the one referred to in this document, and for version 2.1.0 installed for the user it can be found at +The CLI is the one this document refers to. A typical per-user install layout (paths can vary by Chia version and install options) is: ```bash ~\AppData\Local\Programs\Chia\resources\app.asar.unpacked\daemon\chia.exe ``` -If installed for all users it can be found at +If installed for all users, a common location is: ```bash C:\Program Files\Chia\resources\app.asar.unpacked\daemon\chia.exe ``` -# [init](https://github.com/Chia-Network/chia-blockchain/blob/master/src/cmds/init.py) +# [init](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/init.py) Command: `chia init` @@ -81,36 +95,44 @@ If no old version exists, `init`: # start -Command: `chia start {service}` +Command: `chia start [OPTIONS] GROUP [GROUP ...]` -- Service `node` will start only the full node. -- Service `farmer` will start the farmer, harvester, a full node, and the wallet. -- positional arguments: - \{all,node,harvester,farmer,farmer-no-wallet,farmer-only,timelord,timelord-only,timelord-launcher-only,wallet,wallet-only,introducer,simulator} +Pass one or more **service group** names. The exact mapping is defined in the reference client as [`SERVICES_FOR_GROUP`](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/util/service_groups.py) in `chia/util/service_groups.py` (if this table and your install disagree, treat the source file and `chia start -h` as canonical). **Flags** `-r, --restart`: Restart of running processes -| | Full Node | Wallet | Farmer | Harvester | Timelord | Timelord Launcher | Timelord-Only | Introducer | Full Node Simulator | -| ----------------- | --------- | ------ | ------ | --------- | -------- | ----------------- | ------------- | ---------- | ------------------- | -| all | X | X | X | X | X | X | | | | -| node | X | | | | | | | | | -| harvester | | | | X | | | | | | -| farmer | X | X | X | X | | | | | | -| farmer-no-wallet | X | | X | X | | | | | | -| farmer-only | | | X | | | | | | | -| timelord | X | | | | X | X | | | | -| timelord-only | | | | | X | | X | | | -| timelord-launcher | | | | | | X | | | | -| wallet | X | X | | | | | | | | -| wallet-only | | X | | | | | | | | -| introducer | | | | | | | | X | | -| simulator | | | | | | | | | X | +**Service groups** (internal service names in parentheses where helpful): + +:::warning +`chia start all` literally starts every service group, including timelord and timelord launcher. Only use `all` if this machine is intentionally configured to run timelord components. +::: + +| Group | What gets started | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | +| `all` | Full node, wallet, farmer, harvester, timelord, timelord launcher, DataLayer (`chia_data_layer`, `chia_data_layer_http`) | +| `daemon` | (no processes; reserved) | +| `data` | Wallet, DataLayer (`chia_data_layer`) | +| `data_layer_http` | DataLayer HTTP service only | +| `node` | Full node only | +| `harvester` | Harvester only | +| `farmer` | Full node, wallet, farmer, harvester | +| `farmer-no-wallet` | Full node, farmer, harvester (no wallet) | +| `farmer-only` | Farmer service only | +| `timelord` | Full node, timelord, timelord launcher | +| `timelord-only` | Timelord only | +| `timelord-launcher-only` | Timelord launcher only | +| `wallet` | Wallet only | +| `introducer` | Introducer | +| `simulator` | Full node (simulator) | +| `crawler` | Crawler | +| `seeder` | Crawler and seeder | +| `seeder-only` | Seeder only | # plotters -In 2.1.0 the option to use different plotters including compressed plotter was introduced. Each plotter has slightly different hardware requirements and may need slightly different options specified. +The reference client supports several plotters (including third-party and compressed-plot options). Each plotter has slightly different hardware requirements and may need slightly different options specified. The cli reference for all plotters can be found in the [Plotters CLI Page](/reference-client/cli-reference/plotter-cli). Learn more about the alternative plotters in the [Alternative Plotters page](/reference-client/plotting/plotting-software). ## plotnft @@ -140,7 +162,7 @@ To create a Plot NFT, use `chia plotnft create -u https://poolnamehere.com`, ent To switch pools, you can use `chia plotnft join`, and to leave a pool (switch to self farming), use `chia plotnft leave`. The `show` command can be used to check your current points balance. CLI plotting with `create_plots` is the same as before, but the `-p` is replaced with `-c`, and the pool contract address from `chia plotnft show` should be used here. -## [Plots check](https://github.com/Chia-Network/chia-blockchain/blob/master/src/plotting/check_plots.py) +## [Plots check](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/plotting/check_plots.py) Command: `chia plots check -n [num checks] -l -g [substring]` @@ -173,7 +195,7 @@ Running the command with `-n 10` or `-n 20` is good for a very minor check, but Consider using `-n 30` to get a statistically better idea. -For more detail, you can read about the DiskProver commands in [chiapos](https://github.com/Chia-Network/chiapos/blob/master/src/prover_disk.hpp) +For more detail, you can read about the DiskProver commands in [chiapos](https://github.com/Chia-Network/chiapos/blob/main/src/prover_disk.hpp) **What does the ratio of full proofs vs expected proofs mean?** @@ -243,7 +265,7 @@ Command: `chia db validate [add flags and parameters]` # keys -## [derive](https://github.com/Chia-Network/chia-blockchain/blob/2f2593661c842b70a0e848752f12777f2df3ed18/chia/cmds/keys.py#L139) +## [derive](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/keys.py) Command: `chia keys derive [OPTIONS] COMMAND [ARGS]` @@ -260,7 +282,7 @@ Command: `chia keys derive [OPTIONS] COMMAND [ARGS]` - The valid values for `COMMAND` are `child-key`, `search`, and `wallet-address`. - See below for details and example commands. -### [child-key](https://github.com/Chia-Network/chia-blockchain/blob/2f2593661c842b70a0e848752f12777f2df3ed18/chia/cmds/keys.py#L271) +### [child-key](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/keys.py) Command: `chia keys derive child-key [OPTIONS]` @@ -289,7 +311,7 @@ Example HD path: m/12381n/8444n/2/ - Generate a mnemonic seed and show the farmer pubkeys 10-14 derived from that seed: `chia keys derive --mnemonic-seed-filename <(chia keys generate_and_print | sed -n 2p) child-key -i 10 -n 5 -t farmer` -### [search](https://github.com/Chia-Network/chia-blockchain/blob/2f2593661c842b70a0e848752f12777f2df3ed18/chia/cmds/keys.py#L162) +### [search](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/keys.py) Command: `chia keys derive search [OPTIONS] [SEARCH_TERMS]...` @@ -309,7 +331,7 @@ Command: `chia keys derive search [OPTIONS] [SEARCH_TERMS]...` - Search for a wallet address: `chia keys derive search -t address -l 100 ` -### [wallet-address](https://github.com/Chia-Network/chia-blockchain/blob/2f2593661c842b70a0e848752f12777f2df3ed18/chia/cmds/keys.py#L234) +### [wallet-address](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/keys.py) Command: `chia keys derive wallet-address [OPTIONS]` @@ -403,7 +425,21 @@ chia dev mempool benchmark -n 1000 --- -# Other commands (not all are fully documented) +## data (DataLayer) + +The `chia data` command group is the CLI for the Chia DataLayer. For the full subcommand list and examples, see the [DataLayer CLI reference](/reference-client/cli-reference/datalayer-cli). + +--- + +## solver + +The `chia solver` command group talks to the standalone Solver service (partial proofs → full proofs for V2 plots / PoS2-era farming). Run `chia solver -h`; current releases provide **`get_state`**. For connecting the farmer to a Solver over HTTP RPC, see [`connect_to_solver`](/reference-client/rpc-reference/farmer-rpc#connect_to_solver) on the Farmer RPC page. + +--- + +## Other commands (not all are fully documented) + +The following sample output is aligned with the top-level Click groups registered in [`chia/cmds/chia.py`](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/chia.py) (`version` and `run_daemon` are registered on the root CLI in the same file). **Your local `chia -h` may list commands in a different order.** The **`beta`** command exists in the client but is **hidden** from help unless your build exposes it. ```sh $ chia @@ -418,28 +454,28 @@ Options: -h, --help Show this message and exit. Commands: - completion Generate shell completion - configure Modify configuration - dao Create, manage or show state of DAOs - data Manage your data - db Manage the blockchain database - dev Developer commands and tools - farm Manage your farm - init Create or migrate the configuration - keys Manage your keys - netspace Estimate total farmed space on the network - passphrase Manage your keyring passphrase - peer Show, or modify peering connections - plotnft Manage your plot NFTs - plots Manage your plots - plotters Advanced plotting options - rpc RPC Client - run_daemon Runs chia daemon - show Show node information - start Start service groups - stop Stop services - version Show chia version - wallet Manage your wallet + completion Generate shell completion + configure Modify configuration + data Manage your data (DataLayer) + db Manage the blockchain database + dev Developer commands and tools + farm Manage your farm + init Create or migrate the configuration + keys Manage your keys + netspace Estimate total farmed space on the network + passphrase Manage your keyring passphrase + peer Show, or modify peering connections + plotnft Manage your plot NFTs + plots Manage your plots + plotters Advanced plotting options + rpc RPC Client + run_daemon Runs chia daemon + show Show node information + solver Manage your solver + start Start service groups + stop Stop services + version Show chia version + wallet Manage your wallet ``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/custody-tool-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/custody-tool-cli.md index 5393a75443e..984e172061e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/custody-tool-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/custody-tool-cli.md @@ -25,15 +25,14 @@ Usage: `cic audit [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -f | --filepath | TEXT | False | The file path the dump the audit log | -| -d | --diff | TEXT | False | A previous audit log to diff against this one | -| -h | --help | None | False | Show a help message and exit | +| -f | --filepath | TEXT | False | The file path the dump the audit log | +| -d | --diff | TEXT | False | A previous audit log to diff against this one | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -102,15 +101,14 @@ Usage: `cic clawback [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | -| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | -| -h | --help | None | False | Show a help message and exit | +| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | +| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -134,14 +132,13 @@ Usage: `cic complete [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | -| -h | --help | None | False | Show a help message and exit | +| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | +| -h | --help | None | False | Show a help message and exit | -
-Example -- complete a withdrawal +
Example -- complete a withdrawal Request: @@ -171,19 +168,18 @@ Usage: `cic derive_root [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | -c | --configuration | TEXT | False | The configuration file with which to derive the root (or the filepath to create it at if using --db-path) [default: ./Configuration (needs derivation).txt] | -| -db | --db-path | TEXT | False | Optionally specify a DB path to find the configuration from | -| -pks | --pubkeys | TEXT | True | A comma separated list of pubkey files that will control this money | -| -m | --initial-lock-level | TEXT | True | The initial number of pubkeys required to do a withdrawal or standard rekey | -| -n | --maximum-lock-level | TEXT | False | The maximum number of pubkeys required to do a withdrawal or standard rekey | -| -min | --minimum-pks | INTEGER | False | The minimum number of pubkeys required to initiate a slow rekey [default: 1] | -| -va | --validate-against | TEXT | False | Specify a configuration file to check whether it matches the specified parameters | -| -h | --help | None | False | Show a help message and exit | +| -db | --db-path | TEXT | False | Optionally specify a DB path to find the configuration from | +| -pks | --pubkeys | TEXT | True | A comma separated list of pubkey files that will control this money | +| -m | --initial-lock-level | TEXT | True | The initial number of pubkeys required to do a withdrawal or standard rekey | +| -n | --maximum-lock-level | TEXT | False | The maximum number of pubkeys required to do a withdrawal or standard rekey | +| -min | --minimum-pks | INTEGER | False | The minimum number of pubkeys required to initiate a slow rekey [default: 1] | +| -va | --validate-against | TEXT | False | Specify a configuration file to check whether it matches the specified parameters | +| -h | --help | None | False | Show a help message and exit | -
-Example -- set up a 2-of-3 root config +
Example -- set up a 2-of-3 root config Request: @@ -209,16 +205,15 @@ Usage: `cic examine_spend [OPTIONS] SPEND_FILE` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------------- | :------ | :------- | :--------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------- | | | --qr-density | INTEGER | False | The amount of bytes to pack into a single QR code [default: 250] | -| -va | --validate-against | TEXT | False | A new configuration file to check against requests for rekeys | -| -h | --help | None | False | Show a help message and exit | +| -va | --validate-against | TEXT | False | A new configuration file to check against requests for rekeys | +| -h | --help | None | False | Show a help message and exit | `SPEND_FILE` is an unsigned spend bundle. This command will convert the spend bundle into a QR code and open it into a web browser for printing. You can then scan this QR code, for example using an HSM's QR scanner, for easier signing. -
-Example -- examine a rekey spend bundle +
Example -- examine a rekey spend bundle Request: @@ -249,15 +244,14 @@ Usage: `cic export_config [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :-------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | -f | --filename | TEXT | False | The file path to export the config to (default: ./Configuration Export (\*\*\*\*\*\*).sqlite) | | -db | --db-path | TEXT | True | The file path to initialize/find the sync database at (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -p | --public | None | False | Enable to export the public information only (default: disabled) | -| -h | --help | None | False | Show a help message and exit | +| -p | --public | None | False | Enable to export the public information only (default: disabled) | +| -h | --help | None | False | Show a help message and exit | -
-Example -- export the config to export.bin +
Example -- export the config to export.bin Request: @@ -283,15 +277,14 @@ Usage: `cic increase_security_level [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | -| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | -| -h | --help | None | False | Show a help message and exit | +| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | +| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | +| -h | --help | None | False | Show a help message and exit | -
-Example -- move to a 4-of-5 config +
Example -- move to a 4-of-5 config Request: @@ -317,18 +310,17 @@ Usage: `cic init [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------------- | :--- | :------- | :-------------------------------------------------------------------------------------------------- | -| -d | --directory | TEXT | False | The directory in which to create the configuration file [default: .] | -| -wt | --withdrawal-timelock | TEXT | True | The amount of time where nothing has happened before a withdrawal can be made (in seconds) | -| -pc | --payment-clawback | TEXT | True | The amount of time to clawback a payment before it's completed (in seconds) | -| -rc | --rekey-cancel | TEXT | True | The amount of time to cancel a rekey before it's completed (in seconds) | -| -rt | --rekey-timelock | TEXT | True | The amount of time where nothing has happened before a standard rekey can be initiated (in seconds) | -| -sp | --slow-penalty | TEXT | True | The time penalty for performing a slow rekey (in seconds) | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------------- | :--- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -d | --directory | TEXT | False | The directory in which to create the configuration file [default: .] | +| -wt | --withdrawal-timelock | TEXT | True | The amount of time where nothing has happened before a withdrawal can be made (in seconds) | +| -pc | --payment-clawback | TEXT | True | The amount of time to clawback a payment before it's completed (in seconds) | +| -rc | --rekey-cancel | TEXT | True | The amount of time to cancel a rekey before it's completed (in seconds) | +| -rt | --rekey-timelock | TEXT | True | The amount of time where nothing has happened before a standard rekey can be initiated (in seconds) | +| -sp | --slow-penalty | TEXT | True | The time penalty for performing a slow rekey (in seconds) | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -354,18 +346,17 @@ Usage: `cic launch_singleton [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------- | -| -c | --configuration | TEXT | True | The configuration file with which to launch the singleton | -| -db | --db-path | TEXT | True | The file path to initialize the sync database at | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -c | --configuration | TEXT | True | The configuration file with which to launch the singleton | +| -db | --db-path | TEXT | True | The file path to initialize the sync database at | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | | -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface. See the rpc_port under full_node in config.yaml | -| | --fee | INTEGER | False | Fee to use for the launch transaction (in mojos) [default: 0] | -| -h | --help | None | False | Show a help message and exit | +| | --fee | INTEGER | False | Fee to use for the launch transaction (in mojos) [default: 0] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -391,14 +382,13 @@ Usage: `cic p2_address [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -p | --prefix | TEXT | False | The prefix to use when encoding the address (default: xch) | -| -h | --help | None | False | Show a help message and exit | +| -p | --prefix | TEXT | False | The prefix to use when encoding the address (default: xch) | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -422,20 +412,19 @@ Usage: `cic payment [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------- | -| -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | -| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | -| -a | --amount | INTEGER | False | The outgoing amount (in mojos) to pay [default: 0] | -| -t | --recipient-address | TEXT | True | The address that can claim the money after the clawback period is over (must be supplied if amount is > 0) | -| -ap | --absorb-available-payments | None | False | Look for any outstanding payments to the singleton and claim them while doing this spend (adds tx cost) [default: false] | -| -mc | --maximum-extra-cost | INTEGER | False | The maximum extra tx cost to be taken on while absorbing payments (as an estimated percentage) [default: 50] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | +| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | +| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | +| -a | --amount | INTEGER | False | The outgoing amount (in mojos) to pay [default: 0] | +| -t | --recipient-address | TEXT | True | The address that can claim the money after the clawback period is over (must be supplied if amount is > 0) | +| -ap | --absorb-available-payments | None | False | Look for any outstanding payments to the singleton and claim them while doing this spend (adds tx cost) [default: false] | +| -mc | --maximum-extra-cost | INTEGER | False | The maximum extra tx cost to be taken on while absorbing payments (as an estimated percentage) [default: 50] | | -at | --amount-threshold | INTEGER | False | The minimum amount required of a payment in order for it to be absorbed [default: 1000000000000 or 1 XCH][0 means "absorb everything"] | -| -h | --help | None | False | Show a help message and exit | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -463,17 +452,16 @@ Usage: `cic push_tx [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------- | -| -b | --spend-bundle | TEXT | True | The signed spend bundle | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -b | --spend-bundle | TEXT | True | The signed spend bundle | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | | -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface. See the rpc_port under full_node in config.yaml | -| -m | --fee | INTEGER | False | The fee to attach to this spend (in mojos) | -| -h | --help | None | False | Show a help message and exit | +| -m | --fee | INTEGER | False | The fee to attach to this spend (in mojos) | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -499,15 +487,14 @@ Usage: `cic show [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------------------ | -| -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (**\*\***).sqlite) [required] | -| -c | --config | None | False | Enable to display the details of the public config (default: disabled) | -| -d | --derivation | None | False | Enable to display the private details of the private config (default: disabled) | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (**\*\***).sqlite) [required] | +| -c | --config | None | False | Enable to display the details of the public config (default: disabled) | +| -d | --derivation | None | False | Enable to display the private details of the private config (default: disabled) | +| -h | --help | None | False | Show a help message and exit | -
-Example -- show the configuration and derivation +
Example -- show the configuration and derivation Request: @@ -561,16 +548,15 @@ Usage: `cic start_rekey [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------ | :--- | :------- | :------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------ | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | -db | --db-path | TEXT | True | The file path to the sync DB (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | -| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | -| -new | --new-configuration | TEXT | True | The configuration you would like to rekey the singleton to | -| -h | --help | None | False | Show a help message and exit | +| -f | --filename | TEXT | False | The filepath to dump the spend bundle into | +| -pks | --pubkeys | TEXT | True | A comma separated list of pubkeys that will be signing this spend | +| -new | --new-configuration | TEXT | True | The configuration you would like to rekey the singleton to | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Request: @@ -596,16 +582,15 @@ Usage: `cic sync [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------ | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | -c | --configuration | TEXT | False | The configuration file with which to initialize a sync database (default: ./Configuration (\*\*\*\*\*\*).txt) | | -db | --db-path | TEXT | True | The file path to initialize/find the sync database at (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface. See the rpc_port under full_node in config.yaml | -| -s | --show | None | False | Enable to show a summary of the singleton after sync is complete (default: disabled) | -| -h | --help | None | False | Show a help message and exit | +| -np | --node-rpc-port | INTEGER | False | Set the port where the Node is hosting the RPC interface. See the rpc_port under full_node in config.yaml | +| -s | --show | None | False | Enable to show a summary of the singleton after sync is complete (default: disabled) | +| -h | --help | None | False | Show a help message and exit | -
-Example -- sync and show the config +
Example -- sync and show the config Request: @@ -642,14 +627,13 @@ Usage: `cic update_config [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :--- | :------- | :------------------------------------------------------------------------------------------------------------ | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :--- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | -c | --configuration | TEXT | False | The configuration file with which to initialize a sync database (default: ./Configuration (\*\*\*\*\*\*).txt) | | -db | --db-path | TEXT | True | The file path to initialize/find the sync database at (default: ./sync (\*\*\*\*\*\*).sqlite) | -| -h | --help | None | False | Show a help message and exit | +| -h | --help | None | False | Show a help message and exit | -
-Example -- update config after rekey +
Example -- update config after rekey Request: @@ -700,8 +684,7 @@ Usage: `hsmgen` There are no options with this command. It will simply generate and display a single secret exponent. -
-Example 1 -- display key +
Example 1 -- display key The basic command displays a new secret exponent. @@ -718,8 +701,7 @@ se12celrk5asn0f3w49dxpxe5hg6sg88ezdvp89hpgdqspwj6e03yfq9e6yw4 ```
-
-Example 2 -- save a key to a file +
Example 2 -- save a key to a file Request: @@ -743,8 +725,7 @@ Usage: `hsmgen ` A secret exponent (required) is the only argument allowed. -
-Example 1 +
Example 1 Derive and display a public key from a file containing a secret exponent: @@ -760,8 +741,7 @@ bls123813eh73c2cttvqytzjfnjdhnme7ah8mzsc9yzsf2y40mvhfa9rt5nha20jw50ld8h98w9u2wc0
-
-Example 2 +
Example 2 Calculate a public key from a file containing a secret exponent and save it to another file: @@ -789,21 +769,20 @@ Positional arguments: Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------- | :--- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------- | -| -y | --yes | None | False | Enable to skip confirmations (default: disabled) | -| | --qr | None | False | Enable to show signature as QR code (default: disabled) | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------- | :--- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -y | --yes | None | False | Enable to skip confirmations (default: disabled) | +| | --qr | None | False | Enable to show signature as QR code (default: disabled) | | | --nochunks | None | False | Enable to read the spend in its entirety rather than as chunks (testing only) argument to pass to gpg (besides -d). (default: disabled) | -| -c | --create-private-key | TEXT | False | Create keys for non-existent files | -| -g | --gpg-argument | TEXT | False | Argument to pass to gpg (besides -d) | -| -h | --help | None | False | Show a help message and exit | +| -c | --create-private-key | TEXT | False | Create keys for non-existent files | +| -g | --gpg-argument | TEXT | False | Argument to pass to gpg (besides -d) | +| -h | --help | None | False | Show a help message and exit | This command is normally run from an HSM with a QR scanner attached. On Linux, this command will display a QR code to the screen to be scanned. On Windows, the QR display isn't working. -
-Example 1 +
Example 1 This example will block until the scan is complete. @@ -821,8 +800,7 @@ waiting for qrint-encoded signing requests
-
-Example 2 +
Example 2 This example will not block. @@ -860,8 +838,7 @@ Optional arguments: Note that `hex-encoded-signature` is a list. To add more signatures, append more arguments. -
-Example +
Example Create a signed spend bundle from two signatures and output to a text file: @@ -891,8 +868,7 @@ Optional arguments: -h, --help show a help message and exit -
-Example +
Example Request: @@ -922,8 +898,7 @@ Optional arguments: -h, --help show a help message and exit -
-Example +
Example Request: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/dao-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/dao-cli.md index 9c765546ee0..d801c69d516 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/dao-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/dao-cli.md @@ -7,17 +7,25 @@ slug: /reference-client/cli-reference/dao-cli import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -This document contains a comprehensive reference of Chia DAO CLI commands and options. +This page previously documented the `chia dao` command group for the proof-of-concept DAO wallet in older Chia clients. + +:::info Removed from the reference client in Chia 2.5.3 + +The proof-of-concept DAO wallet and the **`chia dao`** CLI were removed in [Chia blockchain 2.5.3](https://github.com/Chia-Network/chia-blockchain/blob/main/CHANGELOG.md#253-chia-blockchain-2025-03-25) (March 2025). Current releases do not ship a `dao` subcommand on `chia -h`. The command reference below is **historical only** and does not apply to supported releases. + +For the same context on HTTP RPC, see [DAO RPC](/reference-client/rpc-reference/dao-rpc). + +::: :::warning -Chia DAOs are currently an _alpha_ primitive. This means that DAOs are not yet ready for production use, but you can still test them on either a simulator or a testnet. **We recommend against creating DAOs with this primitive on mainnet!** +The content below described an _alpha_ DAO primitive when it still existed. **Do not rely on it for current installs.** -Prior to using the DAO alpha primitive, be sure to read the [list of known issues](/dao-known-issues). +Prior discussion of known issues: [list of known issues](/dao-known-issues). ::: -## Reference +## Historical reference (pre–DAO wallet removal) ## `add` @@ -27,16 +35,16 @@ Usage: chia dao add \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -n | --name | TEXT | False | Set the DAO wallet name | -| -t | --treasury-id | TEXT | True | The Treasury ID of the DAO you want to track | -| -a | --filter-amount | INTEGER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -n | --name | TEXT | False | Set the DAO wallet name | +| -t | --treasury-id | TEXT | True | The Treasury ID of the DAO you want to track | +| -a | --filter-amount | INTEGER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | +| -h | --help | None | False | Show a help message and exit | -:::details Example +
Example Start with a wallet with some XCH or TXCH: @@ -123,7 +131,7 @@ CAT 07e809aa0324acaf...: From here, you can add funds, create proposals, vote on proposals, etc. -::: +
--- @@ -135,24 +143,23 @@ Usage: chia dao add_funds \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the DAO Treasury Wallet | -| -w | --funding-wallet-id | INTEGER | True | The ID of the wallet to send funds from (must be of type `STANDARD_WALLET`) | -| -a | --amount | TEXT | True | The amount of funds to send, in XCH or CATs | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | - -
- Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the DAO Treasury Wallet | +| -w | --funding-wallet-id | INTEGER | True | The ID of the wallet to send funds from (must be of type `STANDARD_WALLET`) | +| -a | --amount | TEXT | True | The amount of funds to send, in XCH or CATs | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | + +
Example Start by showing the current wallet status: @@ -250,15 +257,14 @@ Usage: chia dao balance \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -h | --help | None | False | Show a help message and exit | -
- Example +
Example ```bash chia dao balance -i 2 @@ -282,24 +288,23 @@ Usage: chia dao close_proposal \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------ | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -p | --proposal-id | TEXT | True | The ID of the proposal you are voting on | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -p | --proposal-id | TEXT | True | The ID of the proposal you are voting on | | -d | --self-destruct | None | False | If this flag is set, it will self-destruct a broken proposal, thus forcing to force it to close \[default: not set] | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | | | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | | | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | -
- Example +
Example First, show the status of a proposal: @@ -409,29 +414,29 @@ Usage: chia dao create \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -n | --name | TEXT | False | Set the DAO wallet name | -| | --proposal-timelock | INTEGER | False | The minimum number of blocks before a proposal can close \[default: 1000] | -| | --soft-close | INTEGER | False | The number of blocks a proposal must remain unspent before closing \[default: 20] | -| | --attendance-required | INTEGER | True | The minimum number of votes a proposal must receive to be accepted | -| | --pass-percentage | INTEGER | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 \[default: 5000] | -| | --self-destruct | INTEGER | False | The number of blocks required before a proposal can be automatically removed \[default: 10000] | -| | --oracle-delay | INTEGER | False | The number of blocks required between oracle spends of the treasury \[default: 50] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -n | --name | TEXT | False | Set the DAO wallet name | +| | --proposal-timelock | INTEGER | False | The minimum number of blocks before a proposal can close \[default: 1000] | +| | --soft-close | INTEGER | False | The number of blocks a proposal must remain unspent before closing \[default: 20] | +| | --attendance-required | INTEGER | True | The minimum number of votes a proposal must receive to be accepted | +| | --pass-percentage | INTEGER | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 \[default: 5000] | +| | --self-destruct | INTEGER | False | The number of blocks required before a proposal can be automatically removed \[default: 10000] | +| | --oracle-delay | INTEGER | False | The number of blocks required between oracle spends of the treasury \[default: 50] | | | --proposal-minimum | INTEGER | False | The minimum amount (in xch) that a proposal must use to be created (this is a spam-prevention measure; it will be donated to the treasury when the proposal is closed) \[default: 0.000000000001] | -| | --filter-amount | INTEGER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | -| | --cat-amount | INTEGER | True | The number of DAO CATs (in mojos) to create when initializing the DAO | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --fee-for-cat | TEXT | False | Set the fees for the CAT creation transaction, in XCH \[default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | +| | --filter-amount | INTEGER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | +| | --cat-amount | INTEGER | True | The number of DAO CATs (in mojos) to create when initializing the DAO | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --fee-for-cat | TEXT | False | Set the fees for the CAT creation transaction, in XCH \[default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | :::info @@ -453,8 +458,7 @@ You can split one coin into multiple coins by running the [chia wallet coins spl ::: -
- Example +
Example This example will create a DAO with the following options: @@ -562,22 +566,22 @@ Usage: chia dao create_proposal \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the DAO wallet to use | -| -a | --amount | INTEGER | True | The amount of new cats the proposal will mint (in mojos) | -| -t | --to-address | TEXT | True | The address new cats will be minted to | -| -v | --vote-amount | INTEGER | True | The number of votes to add | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the DAO wallet to use | +| -a | --amount | INTEGER | True | The amount of new cats the proposal will mint (in mojos) | +| -t | --to-address | TEXT | True | The address new cats will be minted to | +| -v | --vote-amount | INTEGER | True | The number of votes to add | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | :::warning @@ -585,8 +589,7 @@ The votes need to be minted from the treasury's funds, so your DAO will need to ::: -
- Example +
Example This example will show how to create a proposal to mint 100 DAO CATs and deliver them to another wallet. @@ -681,27 +684,26 @@ Usage: chia dao create_proposal \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -t | --to-address | TEXT | False | The address the proposal will send funds to | -| -a | --amount | FLOAT | False | The amount of funds the proposal will send (in mojos) | -| -v | --vote-amount | INTEGER | True | The number of votes to add | -| | --asset-id | TEXT | False | The asset id of the funds the proposal will send. Leave blank for xch | -| -j | --from-json | TEXT | False | Path to a json file containing a list of additions, for use in proposals with multiple spends | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | - -
- Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -t | --to-address | TEXT | False | The address the proposal will send funds to | +| -a | --amount | FLOAT | False | The amount of funds the proposal will send (in mojos) | +| -v | --vote-amount | INTEGER | True | The number of votes to add | +| | --asset-id | TEXT | False | The asset id of the funds the proposal will send. Leave blank for xch | +| -j | --from-json | TEXT | False | Path to a json file containing a list of additions, for use in proposals with multiple spends | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | + +
Example Be sure to have some CATs locked up for voting. To view the number of CATs that have been locked, run `chia wallet show`: @@ -817,29 +819,28 @@ Usage: chia dao create_proposal \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -v | --vote-amount | INTEGER | True | The number of votes to add | -| | --proposal-timelock | INTEGER | False | The new minimum number of blocks before a proposal can close | -| | --soft-close | INTEGER | False | The number of blocks a proposal must remain unspent before closing | -| | --attendance-required | INTEGER | False | The minimum number of votes a proposal must receive to be accepted | -| | --pass-percentage | INTEGER | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 | -| | --self-destruct | INTEGER | False | The number of blocks required before a proposal can be automatically removed | -| | --oracle-delay | INTEGER | False | The number of blocks required between oracle spends of the treasury | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | - -
- Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -v | --vote-amount | INTEGER | True | The number of votes to add | +| | --proposal-timelock | INTEGER | False | The new minimum number of blocks before a proposal can close | +| | --soft-close | INTEGER | False | The number of blocks a proposal must remain unspent before closing | +| | --attendance-required | INTEGER | False | The minimum number of votes a proposal must receive to be accepted | +| | --pass-percentage | INTEGER | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 | +| | --self-destruct | INTEGER | False | The number of blocks required before a proposal can be automatically removed | +| | --oracle-delay | INTEGER | False | The number of blocks required between oracle spends of the treasury | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | + +
Example Let's say a DAO has the following rules: @@ -907,24 +908,23 @@ Usage: chia dao exit_lockup \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the DAO wallet from which to exit the lockup | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the DAO wallet from which to exit the lockup | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | This command will unlock tokens that have been locked for voting, provided that there are no active proposals that these CATs have voted on. This command will automatically determine which CATs are available to be unlocked. -
- Example +
Example First, obtain the current state of the DAO tokens: @@ -1004,15 +1004,14 @@ Usage: chia dao get_id \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the DAO wallet which will receive the funds | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the DAO wallet which will receive the funds | +| -h | --help | None | False | Show a help message and exit | -
- Example +
Example Get the ID of an existing treasury: @@ -1038,20 +1037,19 @@ Usage: chia dao list_proposals \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -c | --include-closed | None | False | Set to include previously closed proposals \[Default: not set] | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -c | --include-closed | None | False | Set to include previously closed proposals \[Default: not set] | +| -h | --help | None | False | Show a help message and exit | This command will list all open proposals by default. If the `-c` flag is included, then all open _and_ closed proposals will be listed. To show the details of a specific proposal, use the [show_proposal](#show_proposal) command. -
- Example +
Example ```bash chia dao list_proposals -i 2 @@ -1082,25 +1080,24 @@ Usage: chia dao lockup_coins \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the DAO wallet to use | -| -a | --amount | TEXT | True | The amount of CATs (not mojos) to lock in voting mode | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the DAO wallet to use | +| -a | --amount | TEXT | True | The amount of CATs (not mojos) to lock in voting mode | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | This command will lock the specified number of tokens, thereby making them available for voting. -
- Example +
Example Before locking the tokens, show the current status of the DAO's wallets: @@ -1214,22 +1211,21 @@ Usage: chia dao release_coins \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | - -
- Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | + +
Example Let's say this is the state of the wallet: @@ -1307,15 +1303,14 @@ Usage: chia dao rules \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -h | --help | None | False | Show a help message and exit | -
- Example +
Example ```bash chia dao rules -i 2 @@ -1345,16 +1340,15 @@ Usage: chia dao show_proposal \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -p | --proposal_id | TEXT | True | The ID of the proposal to fetch, obtainable by running the [list_proposals](#list_proposals) command | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -p | --proposal_id | TEXT | True | The ID of the proposal to fetch, obtainable by running the [list_proposals](#list_proposals) command | +| -h | --help | None | False | Show a help message and exit | -
- Example +
Example ```bash chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d @@ -1390,25 +1384,24 @@ Usage: chia dao vote \[OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -i | --wallet-id | INTEGER | True | ID of the wallet to use | -| -p | --proposal-id | TEXT | True | The ID of the proposal you are voting on | -| -a | --vote-amount | INTEGER | True | The number of votes you want to cast | -| -n | --vote-no | None | False | Use this option to vote against a proposal. If not present then the vote is for the proposal | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | -| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | -| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | -| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | -| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | -| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | -| -h | --help | None | False | Show a help message and exit | - -
- Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -i | --wallet-id | INTEGER | True | ID of the wallet to use | +| -p | --proposal-id | TEXT | True | The ID of the proposal you are voting on | +| -a | --vote-amount | INTEGER | True | The number of votes you want to cast | +| -n | --vote-no | None | False | Use this option to vote against a proposal. If not present then the vote is for the proposal | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --reuse, --reuse-puzhash | None | False | Set either of these flags to reuse the existing address for the change \[default: not set] | +| | --new-address, --generate-new-puzhash | None | False | Set either of these flags to generate a new puzzle hash / address for the change \[default: not set] | +| -ma | --min-coin-amount, --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units | +| -l | --max-coin-amount, --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units | +| | --exclude-coin | TEXT | False | Exclude the coin with this ID from being spent | +| | --exclude-amount | TEXT | False | Exclude any coins with this XCH or CAT amount from being included | +| -h | --help | None | False | Show a help message and exit | + +
Example Start by showing the status of a proposal: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/datalayer-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/datalayer-cli.md index f1365ac771f..427e156ccb2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/datalayer-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/datalayer-cli.md @@ -11,6 +11,8 @@ This page includes a comprehensive list of Chia's Command Line Interface command We also have documented the [RPC API](/reference-client/rpc-reference/datalayer-rpc) for interacting with the DataLayer. +Chia **strongly recommends** using DataLayer with a **trusted full node fully synced** to chain tip for production and security-sensitive workloads. To reach a synced state faster than syncing from genesis, use an official [database checkpoint](https://www.chia.net/downloads/#database-checkpoint) and follow [Using the Official Database Snapshot Torrent](/reference-client/troubleshooting/node-syncing#using-the-official-database-snapshot-torrent). If the full node cannot run on the same machine as DataLayer, point this client at a synced full node **you own and operate** elsewhere and configure [trusted peers](/chia-blockchain/resources/faq#what-are-trusted-peers-and-how-do-i-add-them); **only** add nodes you control—never mark community or third-party hosts as trusted. + The relevant DataLayer commands can be found by running `chia data`: ```bash @@ -39,18 +41,17 @@ Usage: `chia data add_mirror [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------- | -| -i | --id | TEXT | True | The hexadecimal ID of the store to mirror | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -i | --id | TEXT | True | The hexadecimal ID of the store to mirror | | -a | --amount | INTEGER | True | The amount (in mojos) to spend to create the mirror. In theory, mirrors with a higher `amount` will be prioritized. Minimum `amount` is 0 | -| -u | --url | TEXT | False | A URL where the mirror will reside. Can be repeated to add multiple URLs in the same command | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Fingerprint of the wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -u | --url | TEXT | False | A URL where the mirror will reside. Can be repeated to add multiple URLs in the same command | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Fingerprint of the wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Create one mirror with multiple URLs: @@ -76,18 +77,17 @@ Usage: `chia data add_missing_files [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------- | -| -i | --ids | TEXT | True | The hexadecimal store id(s) | -| -o | --override | None | False | If set, will overwrite files that already exist (default: not set) | -| -n | --no-override | None | False | If set, will not overwrite files that already exist (default: set) | -| -d | --directory | TEXT | False | If specified, use a non-default directory to write the files (default: `~/.chia/mainnet/data_layer/db/server_files_location_`) | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Fingerprint of the wallet to use | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -i | --ids | TEXT | True | The hexadecimal store id(s) | +| -o | --override | None | False | If set, will overwrite files that already exist (default: not set) | +| -n | --no-override | None | False | If set, will not overwrite files that already exist (default: set) | +| -d | --directory | TEXT | False | If specified, use a non-default directory to write the files (default: `~/.chia/mainnet/data_layer/db/server_files_location_`) | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -f | --fingerprint | INTEGER | False | Fingerprint of the wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example For this example, there is one local store: @@ -158,16 +158,15 @@ Usage: `chia data clear_pending_roots [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -i | --id | TEXT | True | The ID of the store from which to clear the pending roots | -| | --yes | None | False | Set to confirm the action without prompting [Default: not set / prompt to confirm] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -i | --id | TEXT | True | The ID of the store from which to clear the pending roots | +| | --yes | None | False | Set to confirm the action without prompting [Default: not set / prompt to confirm] | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example To clear all pending roots, you need to enter the store ID. An example of this which also disables prompting: An example of this which also disables prompting: @@ -201,16 +200,15 @@ Usage: `chia data create_data_store [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------: | :---------------------------------------------------------------------------------------------------------- | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | -| | --verbose | None | False | Set to enable verbose output | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | +| | --verbose | None | False | Set to enable verbose output | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Create a new data store: @@ -352,16 +350,15 @@ Usage: `chia data delete_mirror [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -c | --coin_id | TEXT | True | The coin_id of the mirror to delete (obtainable from the [get_mirrors](#get_mirrors) command) | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -c | --coin_id | TEXT | True | The coin_id of the mirror to delete (obtainable from the [get_mirrors](#get_mirrors) command) | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data delete_mirror -c b5756487c17fe3a2628e45a9d3d42e89231af718bb1735e6c8441e07ec005f9d -m 0.000001 @@ -385,15 +382,15 @@ Usage: `chia data get_keys [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store id | -| -r | --root_hash | TEXT | False | The hexadecimal root hash | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | -| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | +| -r | --root_hash | TEXT | False | The hexadecimal root hash | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | +| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | +| -h | --help | None | False | Show a help message and exit | :::info @@ -403,8 +400,7 @@ If an item is larger than `max-page-size`, an error will be thrown. ::: -
-Example +
Example ```bash chia data get_keys --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f @@ -434,15 +430,15 @@ Usage: `chia data get_keys_values [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store id | -| -r | --root_hash | TEXT | False | The hexadecimal root hash | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | -| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | +| -r | --root_hash | TEXT | False | The hexadecimal root hash | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | +| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | +| -h | --help | None | False | Show a help message and exit | :::info @@ -452,8 +448,7 @@ If an item is larger than `max-page-size`, an error will be thrown. ::: -
-Example +
Example ```bash chia data get_keys_values --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f @@ -493,16 +488,16 @@ Usage: `chia data get_kv_diff [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store ID | -| -hash_1 | --hash_1 | TEXT | True | The first hash to compare | -| -hash_2 | --hash_2 | TEXT | True | The second hash to compare | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | -| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :--------------------------- | :---------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store ID | +| -hash_1 | --hash_1 | TEXT | True | The first hash to compare | +| -hash_2 | --hash_2 | TEXT | True | The second hash to compare | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -p | --page | INTEGER | False | Enables pagination of the output and requests a specific page | +| | --max-page-size | INTEGER | False | Set how many bytes to be included in a page, if pagination is enabled [Default: 40 MB] | +| -h | --help | None | False | Show a help message and exit | :::info @@ -512,8 +507,7 @@ If an item is larger than `max-page-size`, an error will be thrown. ::: -
-Example +
Example ```bash chia data get_kv_diff --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -hash_1 0x26e60dd9b493eee1f6781fc13dd025e0bfafcde5a103c95dd087d91bd848d406 -hash_2 0xc2dc94c2a85d7db4cfdd1d907bcc441c8fce595db2e2075b973fb8171e2f19a2 @@ -551,15 +545,14 @@ Usage: `chia data get_mirrors [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -i | --id | TEXT | True | The hexadecimal ID of the store for which to get mirrors | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -i | --id | TEXT | True | The hexadecimal ID of the store for which to get mirrors | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data get_mirrors -i 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f @@ -597,14 +590,13 @@ Usage: `chia data get_owned_stores [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data get_owned_stores @@ -636,20 +628,19 @@ Usage: `chia data get_proof [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -store | --id | TEXT | True | The hexadecimal store id | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -store | --id | TEXT | True | The hexadecimal store id | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -k | --key | TEXT | True | The hexadecimal key | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -k | --key | TEXT | True | The hexadecimal key | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | The proof is a proof of inclusion that a given key, value pair is in the specified datalayer store by chaining the Merkle hashes up to the published on-chain root hash. A user can generate a proof for multiple k,v pairs in the same datastore. -
-Example +
Example ```bash chia data get_proof --id 7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e -k 0x0003 @@ -690,15 +681,14 @@ Usage: `chia data get_root [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store id | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data get_root --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f @@ -727,15 +717,14 @@ Usage: `chia data get_root_history [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store id | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data get_root_history --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f @@ -788,14 +777,13 @@ Usage: `chia data get_subscriptions [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data get_subscriptions @@ -830,17 +818,16 @@ Usage: `chia data get_sync_status [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store id | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | If the `root_hash` matches the `target_root_hash`, then the store is synced. -
-Example +
Example ```bash chia data get_sync_status -store 39114b28a3674b6c2c0ed65d3518842fd17f9df46794f49cd223f9f3a463f09d @@ -872,17 +859,16 @@ Usage: `chia data get_value [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -store | --id | TEXT | True | The hexadecimal store id | -| -k | --key | TEXT | True | The hexadecimal key | -| -r | --root_hash | TEXT | False | The hexadecimal root hash | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal store id | +| -k | --key | TEXT | True | The hexadecimal key | +| -r | --root_hash | TEXT | False | The hexadecimal root hash | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under data_layer in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data get_value --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f --key 0004 @@ -917,8 +903,7 @@ Options: Note that currently `check` is the only sub-command under the `plugins` command. This command is shown in the example. -
-Example +
Example ```bash chia data plugins check @@ -948,16 +933,15 @@ Usage: `chia data remove_subscription [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -store | --id | TEXT | True | The hexadecimal ID of the store to which you would like to subscribe | -| -u | --url | TEXT | False | A URL where the data store resides. This argument can be used multiple times in the same command | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -store | --id | TEXT | True | The hexadecimal ID of the store to which you would like to subscribe | +| -u | --url | TEXT | False | A URL where the data store resides. This argument can be used multiple times in the same command | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia data remove_subscription -store 8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d -u http://www.example.com:8575 @@ -981,16 +965,15 @@ Usage: `chia data subscribe [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -store | --id | TEXT | True | The hexadecimal ID of the store to which you would like to subscribe | -| -u | --url | TEXT | False | A URL where the data store resides. This argument can be used multiple times in the same command | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -store | --id | TEXT | True | The hexadecimal ID of the store to which you would like to subscribe | +| -u | --url | TEXT | False | A URL where the data store resides. This argument can be used multiple times in the same command | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Subscribe to a data store without specifying any URLs: @@ -1024,8 +1007,7 @@ Response:
-
-Example 2 +
Example 2 Subscribe to a data store using multiple URLs where that store resides: @@ -1069,13 +1051,13 @@ Usage: `chia data unsubscribe [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -store | --id | TEXT | True | The hexadecimal ID of the store to which you would like to unsubscribe | -| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| | --retain | None | False | Retain local .dat files [Default: false (don't retain data)] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -store | --id | TEXT | True | The hexadecimal ID of the store to which you would like to unsubscribe | +| -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| | --retain | None | False | Retain local .dat files [Default: false (don't retain data)] | +| -h | --help | None | False | Show a help message and exit | :::info @@ -1089,8 +1071,7 @@ The `unsubscribe` command may or may not delete any data, depending on which ver Example: -
-Example +
Example ```bash chia data unsubscribe -store 8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d @@ -1114,16 +1095,16 @@ Usage: `chia data update_data_store [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -store | --id | TEXT | True | The hexadecimal store ID | -| -d | --changelist | TEXT | True | A JSON object representing the changelist | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -store | --id | TEXT | True | The hexadecimal store ID | +| -d | --changelist | TEXT | True | A JSON object representing the changelist | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| | --submit | None | False | Set to submit the result on chain [Default: don't submit] | -| | --no-submit | None | False | Set to explicitly specify not to submit the result on chain [Default: don't submit] | -| -h | --help | None | False | Show a help message and exit | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| | --submit | None | False | Set to submit the result on chain [Default: don't submit] | +| | --no-submit | None | False | Set to explicitly specify not to submit the result on chain [Default: don't submit] | +| -h | --help | None | False | Show a help message and exit | A few notes on the `-d` / `--changelist` option: @@ -1139,8 +1120,7 @@ A few notes on the `-d` / `--changelist` option: The following examples will show the basic functionality of this command. -
-Example 1 -- Insert a single key/value pair +
Example 1 -- Insert a single key/value pair ```bash chia data update_data_store --id=1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -d '[{"action":"insert", "key":"0003", "value":"abc123"}]' @@ -1157,8 +1137,7 @@ Response:
-
-Example 2 -- Delete a single key +
Example 2 -- Delete a single key ```bash chia data update_data_store --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f --changelist '[{"action":"delete", "key":"0003"}]' @@ -1175,8 +1154,7 @@ Response:
-
-Example 3 -- Insert two keys +
Example 3 -- Insert two keys ```bash chia data update_data_store --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f --changelist '[{"action":"insert", "key":"0x0004", "value":"123abc"},{"action":"insert", "key":"0005", "value":"0xbeadfeed"}]' @@ -1221,8 +1199,7 @@ Response:
-
-Example 4 -- Show that you may not overwrite an existing key +
Example 4 -- Show that you may not overwrite an existing key ```bash chia data update_data_store --id=1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -d '[{"action":"insert", "key":"0004", "value":"0123456789abcdef"}]' @@ -1236,8 +1213,7 @@ Exception from 'data': {'error': 'Key already present: 0004', 'success': False}
-
-Example 5 -- Delete and add the same key in the same command +
Example 5 -- Delete and add the same key in the same command ```bash chia data update_data_store --id=1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -d '[{"action":"delete", "key":"0004"}, {"action":"insert", "key":"0004", "value":"0123456789abcdef"}]' @@ -1266,8 +1242,7 @@ Response:
-
-Example 6 -- Show a key/value pair that was inserted into the Climate Warehouse +
Example 6 -- Show a key/value pair that was inserted into the Climate Warehouse ```bash [{"action":"insert","key":"70726f6a6563747c37353339656336392d636238652d343464362d383832332d653062313135303162643433","value":"7b2263757272656e745265676973747279223a2243756c7469766f222c2272656769737472794f664f726967696e223a2243756c7469766f222c226f726967696e50726f6a6563744964223a224d6163546573743135222c2270726f6772616d223a224d6163546573743135222c2270726f6a6563744964223a224d6163546573743135222c2270726f6a6563744e616d65223a224d6163546573743135222c2270726f6a6563744c696e6b223a224d6163546573743135222c2270726f6a656374446576656c6f706572223a224d6163546573743135222c22736563746f72223a22456e6572677920646973747269627574696f6e222c2270726f6a65637454797065223a224f7a6f6e65204465706c6574696e67205375627374616e636573222c22636f766572656442794e4443223a224f757473696465204e4443222c226e6463496e666f726d6174696f6e223a224d6163546573743135222c2270726f6a656374537461747573223a22436f6d706c65746564222c22756e69744d6574726963223a2274434f3265222c226d6574686f646f6c6f6779223a22426173656c696e65204d6574686f646f6c6f677920666f72206465636f6d706f736974696f6e206f66204e324f2066726f6d206578697374696e672061646970696320616369642070726f64756374696f6e20706c616e7473202d2d2d2056657273696f6e20332e30222c2270726f6a65637454616773223a224d6163546573743135222c2276616c69646174696f6e426f6479223a22436172626f6e20436865636b2028496e646961292050726976617465204c74642e222c2270726f6a65637453746174757344617465223a22323032302d30332d32385430303a30303a30302e3030305a222c2276616c69646174696f6e44617465223a22323032322d30332d30315430303a30303a30302e3030305a222c2277617265686f75736550726f6a6563744964223a2237353339656336392d636238652d343464362d383832332d653062313135303162643433222c2274696d65537461676564223a313634363639343630322c226f7267556964223a2230623039643861653437626665323731366263323532383231333463653661613931616333646364663933363335616338656436626362333031626234636238227d"}] @@ -1315,12 +1290,12 @@ Usage: `chia data verify_proof [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | -| -p | --proof | TEXT | True | Proof to validate in JSON format | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -p | --proof | TEXT | True | Proof to validate in JSON format | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | Notes about this command: @@ -1345,8 +1320,7 @@ The proof to validate requires several fields: Each of these fields is output with the [get_proof](#get_proof) command. For more examples, see chia-blockchain [PR #16845](https://github.com/Chia-Network/chia-blockchain/pull/16845). -
-Example +
Example ```bash chia data verify_proof -p '{"coin_id": "0x774e5f9ba7a8afbfa7fd2050347b4a2d400d3cd530637a18b61b094bb5a0f756", "inner_puzzle_hash": "0x875cc80014bc72f2028c27500d5b44bf6906cd13ad16d7b5f4a5da77a06c8c2f", "store_proofs": {"proofs": [{"key_clvm_hash": "0xa143e7ffd81147f136f921fef88760c46c7a05f15b81995f9c5cfed2a737a3f1","layers": [], "node_hash": "0xe488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb", "value_clvm_hash": "0xed052604ee4ff3996c15ef9b2cb0925233a2e78b6168bb6e67d133e074109b42"}], "store_id": "0x7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e"}}' @@ -1382,10 +1356,10 @@ Usage: `chia data wallet_log_in [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :-------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------ | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :-------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | | -dp | --data-rpc-port | INTEGER | False | Set the port where the DataLayer is hosting the RPC interface. See rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | True | Fingerprint of the wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | True | Fingerprint of the wallet to use | +| -h | --help | None | False | Show a help message and exit | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/did-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/did-cli.md index d18f3551a37..8f137c1cf65 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/did-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/did-cli.md @@ -19,17 +19,16 @@ Usage: `chia wallet did create [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -n | --name | TEXT | False | Set the DID wallet name [default: None] | -| -a | --amount | INTEGER | False | Set the DID amount in mojos. Value must be an odd number. [default: 1] | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | -| -h | --help | None | False | Show a help message and exit. | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -n | --name | TEXT | False | Set the DID wallet name [default: None] | +| -a | --amount | INTEGER | False | Set the DID amount in mojos. Value must be an odd number. [default: 1] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | +| -h | --help | None | False | Show a help message and exit. | -
-Example +
Example Create a new DID: @@ -85,18 +84,17 @@ Usage: `chia wallet did find_lost [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -id | --coin_id | TEXT | True | The DID ID, launcher ID, or latest coin ID of the DID you want to recover. The most time-efficient of these is the latest coin ID | -| -m | --metadata | TEXT | False | The new whole metadata in json format | -| -r | --recovery_list_hash | TEXT | False | Override the recovery list hash of the DID. Only set this if your last DID spend updated the recovery list | -| -n | --num_verification | INTEGER | False | Override the required verification number of the DID. Only set this if your last DID spend updated the required verification number | -| -h | --help | None | False | Show a help message and exit. | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -id | --coin_id | TEXT | True | The DID ID, launcher ID, or latest coin ID of the DID you want to recover. The most time-efficient of these is the latest coin ID | +| -m | --metadata | TEXT | False | The new whole metadata in json format | +| -r | --recovery_list_hash | TEXT | False | Override the recovery list hash of the DID. Only set this if your last DID spend updated the recovery list | +| -n | --num_verification | INTEGER | False | Override the required verification number of the DID. Only set this if your last DID spend updated the required verification number | +| -h | --help | None | False | Show a help message and exit. | -
-Example +
Example Locate a DID owned by the local wallet: @@ -122,18 +120,17 @@ Usage: `chia wallet did get_details [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -id | --coin_id | TEXT | True | The DID ID, launcher ID, or latest coin ID of the DID you want to recover. The most time-efficient of these is the latest coin ID | -| -l | --latest | None | False | If the `coin_id` is not the latest coin ID of this DID, set this flag to receive the latest DID information (not allowed if the `coin_id` is the DID ID) | -| -h | --help | None | False | Show a help message and exit. | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -id | --coin_id | TEXT | True | The DID ID, launcher ID, or latest coin ID of the DID you want to recover. The most time-efficient of these is the latest coin ID | +| -l | --latest | None | False | If the `coin_id` is not the latest coin ID of this DID, set this flag to receive the latest DID information (not allowed if the `coin_id` is the DID ID) | +| -h | --help | None | False | Show a help message and exit. | Note that `coin_id` could pertain to any DID, not just those owned by this wallet. -
-Example +
Example Get the latest details of a DID from a coin ID: @@ -169,15 +166,14 @@ Usage: `chia wallet did get_did [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | ID of the wallet to use | -| -h | --help | None | False | Show a help message and exit. | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | ID of the wallet to use | +| -h | --help | None | False | Show a help message and exit. | -
-Example +
Example Get info for DID with ID 2: @@ -204,17 +200,16 @@ Usage: `chia wallet did message_spend [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | ID of the wallet to use | -| -pa | --puzzle_announcements | TEXT | False | The list of puzzle announcement hex strings, split by commas (`,`) | -| -ca | --coin_announcements | TEXT | False | The list of coin announcement hex strings, split by commas (`,`) | -| -h | --help | None | False | Show a help message and exit. | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | ID of the wallet to use | +| -pa | --puzzle_announcements | TEXT | False | The list of puzzle announcement hex strings, split by commas (`,`) | +| -ca | --coin_announcements | TEXT | False | The list of coin announcement hex strings, split by commas (`,`) | +| -h | --help | None | False | Show a help message and exit. | -
-Example +
Example Create a default message spend bundle from a DID wallet: @@ -253,16 +248,15 @@ Usage: `chia wallet did get_did [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | ID of the wallet to use | -| -n | --name | TEXT | True | Set the DID wallet name | -| -h | --help | None | False | Show a help message and exit. | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | ID of the wallet to use | +| -n | --name | TEXT | True | Set the DID wallet name | +| -h | --help | None | False | Show a help message and exit. | -
-Example +
Example Set the name for Wallet ID 2 to `New Name`: @@ -322,16 +316,15 @@ Usage: `chia wallet did sign_message [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --did_id | TEXT | True | DID ID you want to use for signing | -| -m | --hex_message | TEXT | True | The message you want to sign | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --did_id | TEXT | True | DID ID you want to use for signing | +| -m | --hex_message | TEXT | True | The message you want to sign | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet did sign_message -f 590161281 -i did:chia:1cxw5dqug4gavvgylx88zfkmqv235ryr6j9tvyjwwuga0pa52wjvqavdyar --hex_message "This is a test message." @@ -357,19 +350,18 @@ Usage: `chia wallet did transfer [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | ID of the DID wallet to transfer | -| -ta | --target-address | TEXT | True | Target recipient wallet address | -| -r | --reset_recovery | None | False | Set this flag if you want to reset the recovery DID settings (they will not be transferred with the DID) | -| -m | --fee | TEXT | False | An optional transaction fee, in XCH | -| | --reuse | None | False | Reuse existing address for the change | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | ID of the DID wallet to transfer | +| -ta | --target-address | TEXT | True | Target recipient wallet address | +| -r | --reset_recovery | None | False | Set this flag if you want to reset the recovery DID settings (they will not be transferred with the DID) | +| -m | --fee | TEXT | False | An optional transaction fee, in XCH | +| | --reuse | None | False | Reuse existing address for the change | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet did transfer -i 4 -ta xch1gdhch02gp6352plffxqy7ppaar2dvtnek6p2cc79nc5apqzae37sktag6l @@ -434,13 +426,13 @@ Usage: `chia wallet did update_metadata [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | ID of the DID wallet to use | -| -m | --metadata | TEXT | True | The new whole metadata in json format | -| | --reuse | None | False | Set this flag to reuse existing address for the change | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | ID of the DID wallet to use | +| -m | --metadata | TEXT | True | The new whole metadata in json format | +| | --reuse | None | False | Set this flag to reuse existing address for the change | +| -h | --help | None | False | Show a help message and exit | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/nft-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/nft-cli.md index 32dd7b166d3..0d9b44cbbc6 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/nft-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/nft-cli.md @@ -17,15 +17,15 @@ Usage: chia wallet nft create [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -di | --did-id | TEXT | False | DID Id to use | -| -n | --name | TEXT | False | Set the NFT wallet name | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -di | --did-id | TEXT | False | DID Id to use | +| -n | --name | TEXT | False | Set the NFT wallet name | +| -h | --help | None | False | Show a help message and exit | -:::details Example 1 - Create an NFT wallet that is not linked to a DID +
Example 1 - Create an NFT wallet that is not linked to a DID Create an NFT Wallet: @@ -39,9 +39,9 @@ Response: Successfully created an NFT wallet with id 3 on key 4288332900 ``` -::: +
-:::details Example 2 - Create an NFT wallet that is linked to a DID, specifying the fingerprint and name +
Example 2 - Create an NFT wallet that is linked to a DID, specifying the fingerprint and name ```bash chia wallet nft create -f 4288332900 -di did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 -n "DID-linked NFT Wallet" @@ -53,10 +53,8 @@ Response: Successfully created an NFT wallet with id 4 on key 4288332900 ``` -::: - -
-Show both of these NFT wallets +
+
Show both of these NFT wallets ```bash chia wallet show @@ -112,28 +110,27 @@ Usage: chia wallet nft mint [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | Id of the NFT wallet to use | -| -u | --uris | TEXT | True | Comma separated list of content URIs | -| -nh | --hash | TEXT | True | NFT content hash | -| -mu | --metadata-uris | TEXT | False | Comma separated list of metadata URIs | -| -mh | --metadata-hash | TEXT | False | NFT metadata hash | -| -lu | --license-uris | TEXT | False | Comma separated list of license URIs | -| -lh | --license-hash | TEXT | False | NFT license hash | -| -ra | --royalty-address | TEXT | False | Royalty address | -| -rp | --royalty-percentage-fraction | INTEGER | False | NFT royalty percentage fraction in basis points. Example: 175 would represent 1.75% [default: 0] | -| -ta | --target-address | TEXT | False | Target address | -| -en | --edition-number | INTEGER | False | NFT edition number [default: 1] | -| -et | --edition-total | INTEGER | False | NFT edition total number [default: 1] | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| | --no-did-ownership | None | False | Disable DID ownership support. If this flag is not set, then DID ownership is supported by default | -| -h | --help | None | False | Show a help message and exit | - -
-Example 1 - Mint an NFT that is not associated with a DID +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | Id of the NFT wallet to use | +| -u | --uris | TEXT | True | Comma separated list of content URIs | +| -nh | --hash | TEXT | True | NFT content hash | +| -mu | --metadata-uris | TEXT | False | Comma separated list of metadata URIs | +| -mh | --metadata-hash | TEXT | False | NFT metadata hash | +| -lu | --license-uris | TEXT | False | Comma separated list of license URIs | +| -lh | --license-hash | TEXT | False | NFT license hash | +| -ra | --royalty-address | TEXT | False | Royalty address | +| -rp | --royalty-percentage-fraction | INTEGER | False | NFT royalty percentage fraction in basis points. Example: 175 would represent 1.75% [default: 0] | +| -ta | --target-address | TEXT | False | Target address | +| -en | --edition-number | INTEGER | False | NFT edition number [default: 1] | +| -et | --edition-total | INTEGER | False | NFT edition total number [default: 1] | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| | --no-did-ownership | None | False | Disable DID ownership support. If this flag is not set, then DID ownership is supported by default | +| -h | --help | None | False | Show a help message and exit | + +
Example 1 - Mint an NFT that is not associated with a DID ```bash chia wallet nft mint -i 3 -u https://images.pexels.com/photos/11053072/pexels-photo-11053072.jpeg -nh 14836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0 @@ -175,8 +172,7 @@ NFT minted Successfully with spend bundle:
-
-Example 2 - Mint an NFT that is associated with a DID. Specify all URLs and hashes, along with a royalty of 3% +
Example 2 - Mint an NFT that is associated with a DID. Specify all URLs and hashes, along with a royalty of 3% ```bash chia wallet nft mint -f 2522319413 -i 2 -ra txch1r2hc8zaxmqetkwuqz99nspwa7dlhnyx6uuxlt8srrsd2n7pscwfqgjhy7h -ta txch1z456h8t2wyzhrpzz8mf844zd6jc6tf7stlwggdf57hm3f3mh6cmqf2kzv2 -u https://images.pexels.com/photos/12051365/pexels-photo-12051365.jpeg -nh fca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533f -mu https://metadata_example.com -mh 868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e -lu https://license_example.com -lh 358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82 -et 1337 -en 42 -rp 300 @@ -255,8 +251,7 @@ License URIs:
-
-Example 3 - Mint a video NFT that is associated with a DID +
Example 3 - Mint a video NFT that is associated with a DID Here we'll use a direct link to a .webp file: @@ -308,18 +303,17 @@ Usage: chia wallet nft set_did [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | Id of the NFT wallet to use | -| -di | --did-id | TEXT | True | DID ID to set on the NFT | -| -ni | --nft-coin-id | TEXT | True | Coin ID of the NFT coin to set the DID on | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | Id of the NFT wallet to use | +| -di | --did-id | TEXT | True | DID ID to set on the NFT | +| -ni | --nft-coin-id | TEXT | True | Coin ID of the NFT coin to set the DID on | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH [default: 0] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Set the DID on an NFT in wallet `2` and include a 1-mojo fee: @@ -345,16 +339,15 @@ Usage: chia wallet nft sign_message [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --nft_id | TEXT | True | NFT ID you want to use for signing | -| -m | --hex_message | TEXT | True | The message you want to sign | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --nft_id | TEXT | True | NFT ID you want to use for signing | +| -m | --hex_message | TEXT | True | The message you want to sign | +| -h | --help | None | False | Show a help message and exit | -
-Example 1: Basic signing +
Example 1: Basic signing ```bash chia wallet nft sign_message -f 590161281 -i nft12dfld077vn3ywp4vdx9ljg96k89kpr6jlqwkm7lgaf3g8jwn2l4q6eytqs -m "This is a test message." @@ -370,8 +363,7 @@ Signature: 88eb8bacdc6b19614aa7744c3b3809e3c0ff76ba398fe6eebb7eaeb2fcb35452243ed
-
-Example 2: Obtain and validate a signature +
Example 2: Obtain and validate a signature This example was created on the testnet. For applying these instructions to mainnet, the only material difference is in the prefix of the address (txch/xch). @@ -478,17 +470,16 @@ Usage: chia wallet nft list [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | Id of the NFT wallet to use | -| | --num | INTEGER | False | Number of NFTs to return | -| | --start-index | INTEGER | False | Which starting index to start listing NFTs from | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | Id of the NFT wallet to use | +| | --num | INTEGER | False | Number of NFTs to return | +| | --start-index | INTEGER | False | Which starting index to start listing NFTs from | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 - Show NFTs from a wallet that is not associated with a DID +
Example 1 - Show NFTs from a wallet that is not associated with a DID ```bash chia wallet nft list -i 2 @@ -527,8 +518,7 @@ License URIs:
-
-Example 2 - Show NFTs from a wallet that is associated with a DID +
Example 2 - Show NFTs from a wallet that is associated with a DID ```bash chia wallet nft list -i 4 @@ -577,15 +567,14 @@ Usage: chia wallet nft get_info [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin for which to show info | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin for which to show info | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Get coin info by NFT Coin ID: @@ -634,18 +623,17 @@ Usage: chia wallet nft transfer [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | Id of the NFT wallet to use | -| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin to transfer | -| -ta | --target-address | TEXT | True | Target recipient wallet address | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | Id of the NFT wallet to use | +| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin to transfer | +| -ta | --target-address | TEXT | True | Target recipient wallet address | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 - Send an NFT from a wallet not associated with a DID +
Example 1 - Send an NFT from a wallet not associated with a DID This recipient in this example will be a common burn address (an address for which nobody has the private key): @@ -673,8 +661,7 @@ NFT transferred successfully with spend bundle:
-
-Example 2 - Send an NFT from a wallet associated with a DID +
Example 2 - Send an NFT from a wallet associated with a DID This recipient in this example will be a common burn address (an address for which nobody has the private key): @@ -712,20 +699,19 @@ Usage: chia wallet nft add_uri [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :-------------- | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | Id of the NFT wallet to use | -| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin to update | -| -u | --uri | TEXT | True (see INFO) | Data URI to add to the NFT | -| -mu | --metadata-uri | TEXT | True (see INFO) | Metadata URI to add to the NFT | -| -lu | --license-uri | TEXT | True (see INFO) | License URI to add to the NFT | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | -| -h | --help | None | False | Show a help message and exit | - -
-Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :--------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | Id of the NFT wallet to use | +| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin to update | +| -u | --uri | TEXT | True (see INFO) | Data URI to add to the NFT | +| -mu | --metadata-uri | TEXT | True (see INFO) | Metadata URI to add to the NFT | +| -lu | --license-uri | TEXT | True (see INFO) | License URI to add to the NFT | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | +| -h | --help | None | False | Show a help message and exit | + +
Example Add a URI to an NFT by NFT coin ID: @@ -779,18 +765,17 @@ Usage: chia wallet nft set_did [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | True | Id of the NFT wallet to use | -| -di | --did-id | TEXT | True | DID Id to set on the NFT | -| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin on which to set the DID | -| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | -| -h | --help | None | False | Show a help message and exit | - -
-Example +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | True | Id of the NFT wallet to use | +| -di | --did-id | TEXT | True | DID Id to set on the NFT | +| -ni | --nft-coin-id | TEXT | True | Id of the NFT coin on which to set the DID | +| -m | --fee | TEXT | False | Set the fees per transaction, in XCH. [default: 0] | +| -h | --help | None | False | Show a help message and exit | + +
Example ```bash chia wallet nft set_did -i 2 -di did:chia:16kgxghw80cjlytl7x7zxuuux32v308fnmcgkfrh652rtcdqexm4q7gsarr -ni 6052a11829c20e9fb9c8fd66b38565e1fcfdedae3d3b410dfb6caef363fb22d8 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/offer-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/offer-cli.md index bb5fe600ed2..f4a3e0bbbe3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/offer-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/offer-cli.md @@ -7,8 +7,7 @@ slug: /reference-client/cli-reference/offer-cli import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -36,19 +35,19 @@ Usage: `chia wallet make_offer [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :-----------: | :---------------: | :-----: | :------: | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -o | --offer | TEXT | True | A wallet id to offer and the amount to offer (formatted like wallet_id:amount) | -| -r | --request | TEXT | True | A wallet id of an asset to receive and the amount you wish to receive (formatted like wallet_id:amount) | -| -p | --filepath | TEXT | True | The path to write the generated offer file to | -| -m | --fee | TEXT | False | A fee to add to the offer when it gets taken | -| | --reuse | None | False | Set this flag to reuse an existing address for the offer [Default: generate a new address] | -| | --override | None | False | Creates offer without checking for unusual values | -| | --valid-at | INTEGER | False | UNIX timestamp at which the associated transactions become valid | -| | --expires-at | INTEGER | False | UNIX timestamp at which the associated transactions expire | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :-----------: | :---------------: | :-----: | :------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -o | --offer | TEXT | True | A wallet id to offer and the amount to offer (formatted like wallet_id:amount) | +| -r | --request | TEXT | True | A wallet id of an asset to receive and the amount you wish to receive (formatted like wallet_id:amount) | +| -p | --filepath | TEXT | True | The path to write the generated offer file to | +| -m | --fee | TEXT | False | A fee to add to the offer when it gets taken | +| | --reuse | None | False | Set this flag to reuse an existing address for the offer [Default: generate a new address] | +| | --override | None | False | Creates offer without checking for unusual values | +| | --valid-at | INTEGER | False | UNIX timestamp at which the associated transactions become valid | +| | --expires-at | INTEGER | False | UNIX timestamp at which the associated transactions expire | +| -h | --help | None | False | Show a help message and exit | --- @@ -60,14 +59,14 @@ Usage: `chia wallet take_offer [OPTIONS] PATH_OR_HEX` Options: -| Short Command | Long Command | Type | Required | Description | -| :-----------: | :---------------: | :-----: | :------: | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -e | --examine-only | None | False | Print the summary of the offer file but do not take it | -| -m | --fee | TEXT | False | The fee to use when pushing the completed offer | -| | --reuse | None | False | Set this flag to reuse an existing address for the offer [Default: generate a new address] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :-----------: | :---------------: | :-----: | :------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -e | --examine-only | None | False | Print the summary of the offer file but do not take it | +| -m | --fee | TEXT | False | The fee to use when pushing the completed offer | +| | --reuse | None | False | Set this flag to reuse an existing address for the offer [Default: generate a new address] | +| -h | --help | None | False | Show a help message and exit | --- @@ -79,14 +78,14 @@ Usage: `chia wallet cancel_offer [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :-----------: | :---------------: | :-----: | :------: | :----------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -id | --id | TEXT | True | The offer ID that you wish to cancel | -| | --insecure | None | False | Set this flag to disable making an on-chain transaction and simply mark the offer as canceled [Default: cancel on-chain] | -| -m | --fee | TEXT | False | The fee to use when canceling the offer securely | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :-----------: | :---------------: | :-----: | :------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -id | --id | TEXT | True | The offer ID that you wish to cancel | +| | --insecure | None | False | Set this flag to disable making an on-chain transaction and simply mark the offer as canceled [Default: cancel on-chain] | +| -m | --fee | TEXT | False | The fee to use when canceling the offer securely | +| -h | --help | None | False | Show a help message and exit | --- @@ -98,15 +97,15 @@ Usage: `chia wallet get_offers [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :-----------: | :--------------------: | :-----: | :------: | :------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -id | --id | TEXT | False | The ID of the offer that you wish to examine | -| -p | --filepath | TEXT | False | The path to rewrite the offer file to (must be used in conjunction with --id) | -| -em | --exclude-my-offers | None | False | Exclude your own offers from the output | -| -et | --exclude-taken-offers | None | False | Exclude offers that you've accepted from the output | -| -ic | --include-completed | None | False | Include offers that have already been confirmed/canceled or failed | -| -s | --summaries | None | False | Show the assets being offered and requested for each offer | -| -r | --reverse | None | False | Reverse the order of the output | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :-----------: | :--------------------: | :-----: | :------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -id | --id | TEXT | False | The ID of the offer that you wish to examine | +| -p | --filepath | TEXT | False | The path to rewrite the offer file to (must be used in conjunction with --id) | +| -em | --exclude-my-offers | None | False | Exclude your own offers from the output | +| -et | --exclude-taken-offers | None | False | Exclude offers that you've accepted from the output | +| -ic | --include-completed | None | False | Include offers that have already been confirmed/canceled or failed | +| -s | --summaries | None | False | Show the assets being offered and requested for each offer | +| -r | --reverse | None | False | Reverse the order of the output | +| -h | --help | None | False | Show a help message and exit | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/plotter-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/plotter-cli.md index a8d80f08736..079aa62078b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/plotter-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/plotter-cli.md @@ -19,28 +19,28 @@ Usage: chia plotters chiapos [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------ | :------ | :------- | :---------------------------------------------------------------------------------------- | -| -t | --tmp_dir | TEXT | True | Temporary directory 1 (where most of the plots temp data will be stored) | -| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | -| -k | --size | INTEGER | False | K value [Default: 32] | -| -m | --memo | TEXT | False | Memo variable | -| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | -| -b | --buffer | INTEGER | False | Size of the buffer, in MB [Default: 4608] | -| -u | --buckets | INTEGER | False | Number of buckets [Default: 64] | -| -s | --stripes | INTEGER | False | Stripe size [Default: 65536] | -| -r | --threads | INTEGER | False | Num threads [Default: 2] | -| -e | --nobitfield | None | False | Disable bitfield [Default: bitfield is enabled] | -| | --override-k | None | False | Force size smaller than 32 (only needed where `-k` is less than 32 [Default: disabled] | -| -a | --alt_fingerprint | INTEGER | False | Enter the alternative fingerprint of the key you want to use | -| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | -| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | -| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | -| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------------------------------ | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -t | --tmp_dir | TEXT | True | Temporary directory 1 (where most of the plots temp data will be stored) | +| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | +| -k | --size | INTEGER | False | K value [Default: 32] | +| -m | --memo | TEXT | False | Memo variable | +| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | +| -b | --buffer | INTEGER | False | Size of the buffer, in MB [Default: 4608] | +| -u | --buckets | INTEGER | False | Number of buckets [Default: 64] | +| -s | --stripes | INTEGER | False | Stripe size [Default: 65536] | +| -r | --threads | INTEGER | False | Num threads [Default: 2] | +| -e | --nobitfield | None | False | Disable bitfield [Default: bitfield is enabled] | +| | --override-k | None | False | Force size smaller than 32 (only needed where `-k` is less than 32 [Default: disabled] | +| -a | --alt_fingerprint | INTEGER | False | Enter the alternative fingerprint of the key you want to use | +| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | +| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | +| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | +| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | | -x | --exclude_final_dir | None | False | Skips adding [final dir] to harvester for farming [Default: copy to final dir is enabled] | -| -d | --final_dir | TEXT | True | Final directory after plot has been created | -| | --compress | INTEGER | False | Compression level [Default: 0 (not compressed)] | -| -h | --help | None | False | Show a help message and exit | +| -d | --final_dir | TEXT | True | Final directory after plot has been created | +| | --compress | INTEGER | False | Compression level [Default: 0 (not compressed)] | +| -h | --help | None | False | Show a help message and exit | ### `madmax` @@ -50,23 +50,23 @@ Usage: chia plotters madmax [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------ | :------ | :------- | :--------------------------------------------------------------------------------------- | -| -k | --size | INTEGER | False | K value [Default: 32] | -| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | -| -r | --threads | INTEGER | False | Num threads [Default: 4] | -| -u | --buckets | INTEGER | False | Number of buckets [Default: 256] | -| -v | --buckets3 | INTEGER | False | Number of buckets for phases 3 and 4 [Default: 256] | -| -t | --tmp_dir | TEXT | True | Temporary directory 1 (where most of the plots temp data will be stored) | -| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | -| -w | --waitforcopy | None | False | Wait for the plot to finish copying before starting the next plot [Default: don't wait] | -| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | -| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | -| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | -| -G | --tmptoggle | None | False | Alternate tmpdir/tmpdir2 [Default: disabled] | -| -K | --rmulti2 | INTEGER | False | Thread multiplier for P2 [Default: 1] | -| -d | --final_dir | TEXT | True | Final directory after plot has been created | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -k | --size | INTEGER | False | K value [Default: 32] | +| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | +| -r | --threads | INTEGER | False | Num threads [Default: 4] | +| -u | --buckets | INTEGER | False | Number of buckets [Default: 256] | +| -v | --buckets3 | INTEGER | False | Number of buckets for phases 3 and 4 [Default: 256] | +| -t | --tmp_dir | TEXT | True | Temporary directory 1 (where most of the plots temp data will be stored) | +| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | +| -w | --waitforcopy | None | False | Wait for the plot to finish copying before starting the next plot [Default: don't wait] | +| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | +| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | +| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | +| -G | --tmptoggle | None | False | Alternate tmpdir/tmpdir2 [Default: disabled] | +| -K | --rmulti2 | INTEGER | False | Thread multiplier for P2 [Default: 1] | +| -d | --final_dir | TEXT | True | Final directory after plot has been created | +| -h | --help | None | False | Show a help message and exit | --- @@ -84,26 +84,26 @@ Usage: chia plotters bladebit cudaplot [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------- | -| -r | --threads | INTEGER | False | Num threads [Default: 12] | -| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | -| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | -| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | -| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | -| -t | --tmp_dir | TEXT | False | Temporary directory 1 (where most of the plot's temp data will be stored) [Default: in memory] | -| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | -| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | -| -w | --warmstart | None | False | Set to enable warm start [Default: disabled] | -| | --nonuma | None | False | Set to disable numa [Default: enabled] | -| | --no-cpu-affinity | None | False | Set to disable assigning automatic thread affinity [Default: enabled] | -| -v | --verbose | None | False | Set to enable verbose output [Default: disabled] | -| -d | --final_dir | TEXT | True | Final directory after plot has been created | -| | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | -| | --device | INTEGER | False | The CUDA device index (typically 0 or 1), set if more than one GPU is installed [Default: 0] | -| | --disk-128 | None | False | Enable hybrid disk plotting, requires 128 GB of system RAM [Default: disabled] | -| | --disk-16\* | None | False | Enable hybrid disk plotting, requires at least 16 GB of system RAM [Default: disabled] **\*SEE WARNING BELOW** | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -r | --threads | INTEGER | False | Num threads [Default: 12] | +| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | +| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | +| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | +| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | +| -t | --tmp_dir | TEXT | False | Temporary directory 1 (where most of the plot's temp data will be stored) [Default: in memory] | +| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | +| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | +| -w | --warmstart | None | False | Set to enable warm start [Default: disabled] | +| | --nonuma | None | False | Set to disable numa [Default: enabled] | +| | --no-cpu-affinity | None | False | Set to disable assigning automatic thread affinity [Default: enabled] | +| -v | --verbose | None | False | Set to enable verbose output [Default: disabled] | +| -d | --final_dir | TEXT | True | Final directory after plot has been created | +| | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | +| | --device | INTEGER | False | The CUDA device index (typically 0 or 1), set if more than one GPU is installed [Default: 0] | +| | --disk-128 | None | False | Enable hybrid disk plotting, requires 128 GB of system RAM [Default: disabled] | +| | --disk-16\* | None | False | Enable hybrid disk plotting, requires at least 16 GB of system RAM [Default: disabled] **\*SEE WARNING BELOW** | +| -h | --help | None | False | Show a help message and exit | :::warning warning @@ -140,21 +140,21 @@ Usage: chia plotters bladebit ramplot [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :--------------------------------------------------------------------------------------- | -| -r | --threads | INTEGER | False | Num threads [Default: 12] | -| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | -| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | -| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | -| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | -| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | -| -w | --warmstart | None | False | Set to enable warm start [Default: disabled] | -| | --nonuma | None | False | Set to disable numa [Default: enabled] | -| | --no-cpu-affinity | None | False | Set to disable assigning automatic thread affinity [Default: enabled] | -| -v | --verbose | None | False | Set to enable verbose output [Default: disabled] | -| -d | --final_dir | TEXT | True | Final directory after plot has been created | -| | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -r | --threads | INTEGER | False | Num threads [Default: 12] | +| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | +| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | +| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | +| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | +| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | +| -w | --warmstart | None | False | Set to enable warm start [Default: disabled] | +| | --nonuma | None | False | Set to disable numa [Default: enabled] | +| | --no-cpu-affinity | None | False | Set to disable assigning automatic thread affinity [Default: enabled] | +| -v | --verbose | None | False | Set to enable verbose output [Default: disabled] | +| -d | --final_dir | TEXT | True | Final directory after plot has been created | +| | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | +| -h | --help | None | False | Show a help message and exit | ### `diskplot` @@ -164,34 +164,34 @@ Usage: chia plotters bladebit diskplot [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------- | -| -r | --threads | INTEGER | False | Num threads [Default: 12] | -| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | -| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | -| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | -| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | -| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | -| -w | --warmstart | None | False | Set to enable warm start [Default: disabled] | -| | --nonuma | None | False | Set to disable numa [Default: enabled] | -| -v | --verbose | None | False | Set to enable verbose output [Default: disabled] | -| -d | --final_dir | TEXT | True | Final directory after plot has been created | -| | --no-cpu-affinity | None | False | Set to disable assigning automatic thread affinity [Default: enabled] | -| | --cache | INTEGER | False | Size of cache to reserve for I/O | -| | --f1-threads | INTEGER | False | Override the default thread count (12) for F1 generation | -| | --fp-threads | INTEGER | False | Override the default thread count (12) for forward propagation | -| | --c-threads | INTEGER | False | Override the default thread count (12) for C table processing | -| | --p2-threads | INTEGER | False | Override the default thread count (12) for Phase 2 | -| | --p3-threads | INTEGER | False | Override the default thread count (12) for Phase 3 | -| | --alternate | None | False | Set to halve the temp2 cache size requirements by alternating bucket writing methods between tables | -| -t | --tmp_dir | TEXT | True | Temporary directory 1 (where most of the plot's temp data will be stored) | -| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | -| -u | --buckets | INTEGER | False | Number of buckets [Default: 256] | -| -m | --memo | TEXT | False | Memo variable | -| | --no-t1-direct | None | False | Set to disable direct I/O on the temp 1 directory | -| | --no-t2-direct | None | False | Set to disable direct I/O on the temp 2 directory | -| | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -r | --threads | INTEGER | False | Num threads [Default: 12] | +| -n | --count | INTEGER | False | Number of plots to create [Default: 1] | +| -f | --farmerkey | TEXT | False | Farmer Public Key (48 bytes) [Default: use the key from the current wallet] | +| -p | --pool-key | TEXT | False | Pool Public Key (48 bytes) [Default: use the key from the current wallet (self-pooling)] | +| -c | --contract | TEXT | False | Pool Contract Address (64 chars) [Default: none] | +| -i | --id | TEXT | False | Plot ID [Default: generate a random ID] | +| -w | --warmstart | None | False | Set to enable warm start [Default: disabled] | +| | --nonuma | None | False | Set to disable numa [Default: enabled] | +| -v | --verbose | None | False | Set to enable verbose output [Default: disabled] | +| -d | --final_dir | TEXT | True | Final directory after plot has been created | +| | --no-cpu-affinity | None | False | Set to disable assigning automatic thread affinity [Default: enabled] | +| | --cache | INTEGER | False | Size of cache to reserve for I/O | +| | --f1-threads | INTEGER | False | Override the default thread count (12) for F1 generation | +| | --fp-threads | INTEGER | False | Override the default thread count (12) for forward propagation | +| | --c-threads | INTEGER | False | Override the default thread count (12) for C table processing | +| | --p2-threads | INTEGER | False | Override the default thread count (12) for Phase 2 | +| | --p3-threads | INTEGER | False | Override the default thread count (12) for Phase 3 | +| | --alternate | None | False | Set to halve the temp2 cache size requirements by alternating bucket writing methods between tables | +| -t | --tmp_dir | TEXT | True | Temporary directory 1 (where most of the plot's temp data will be stored) | +| -2 | --tmp_dir2 | TEXT | False | Temporary directory 2 [Default: same as `tmp_dir`] | +| -u | --buckets | INTEGER | False | Number of buckets [Default: 256] | +| -m | --memo | TEXT | False | Memo variable | +| | --no-t1-direct | None | False | Set to disable direct I/O on the temp 1 directory | +| | --no-t2-direct | None | False | Set to disable direct I/O on the temp 2 directory | +| | --compress | INTEGER | False | Compression level, 0-9 are accepted [Default: 1] | +| -h | --help | None | False | Show a help message and exit | ### `simulate` @@ -201,19 +201,19 @@ Usage: bladebit simulate [OPTIONS] \ Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------- | -| -n | --iterations | INTEGER | False | The number of iterations to run [Default: 100] | -| -p | --parallel | INTEGER | False | The number of instances to run in parallel [Default: 1] | -| -l | --lookup | FLOAT | False | Maximum allowed time per proof lookup, in seconds [Default: 8.00] | -| -f | --filter | INTEGER | False | Plot filter bit count [Default: 512] | -| | --partials | INTEGER | False | Partials per-day simulation [Default: 300] | -| | --power | INTEGER | False | Time in seconds to run power simulation. -n is set automatically in this mode. -n is set automatically in this mode. | -| -s | --size | INTEGER | False | Size of farm. Only used when `--power` is set. | -| | --seed | HEX STRING | False | 64 char hex string to use as a random seed for challenges | -| | --no-cuda | None | False | If set, don't use CUDA for decompression. [Default: not set] [Default: not set] | -| -d | --device | INTEGER | False | Cuda device index, to be used when more than one device exists [Default: 0] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -n | --iterations | INTEGER | False | The number of iterations to run [Default: 100] | +| -p | --parallel | INTEGER | False | The number of instances to run in parallel [Default: 1] | +| -l | --lookup | FLOAT | False | Maximum allowed time per proof lookup, in seconds [Default: 8.00] | +| -f | --filter | INTEGER | False | Plot filter bit count [Default: 512] | +| | --partials | INTEGER | False | Partials per-day simulation [Default: 300] | +| | --power | INTEGER | False | Time in seconds to run power simulation. -n is set automatically in this mode. -n is set automatically in this mode. | +| -s | --size | INTEGER | False | Size of farm. Only used when `--power` is set. | +| | --seed | HEX STRING | False | 64 char hex string to use as a random seed for challenges | +| | --no-cuda | None | False | If set, don't use CUDA for decompression. [Default: not set] [Default: not set] | +| -d | --device | INTEGER | False | Cuda device index, to be used when more than one device exists [Default: 0] | +| -h | --help | None | False | Show a help message and exit | --- @@ -231,17 +231,17 @@ Usage: drplotter plot [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------ | -| -h | --help | None | False | Show a help message and exit | -| -f | --farmerkey | TEXT | True | Farmer Public Key (48 bytes, hex encoded) | -| -c | --contractkey | TEXT | True | Pool Contract Address (64 chars, hex encoded) | -| -d | --outputDirectory | TEXT | True | Final directory after plot has been created | -| | --compression | TEXT | False | Set compression mode. Choose between eco3x (68 bits per proof), or pro4x (49 bits per proof) [Default: eco3x] | -| -i | --gpu_id | INTEGER | False | GPU ID to use [Default: 0] | -| -n | --n_to_plot | INTEGER | False | Number of plots to create [Default: 0, fills directory] | -| -L | --gpu_memory_limit | INTEGER | False | GPU memory limit in MB [Default: 0 (disabled)] | -| | --min_gpu_ram | None | False | Use min gpu ram | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------------------------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -f | --farmerkey | TEXT | True | Farmer Public Key (48 bytes, hex encoded) | +| -c | --contractkey | TEXT | True | Pool Contract Address (64 chars, hex encoded) | +| -d | --outputDirectory | TEXT | True | Final directory after plot has been created | +| | --compression | TEXT | False | Set compression mode. Choose between eco3x (68 bits per proof), or pro4x (49 bits per proof) [Default: eco3x] | +| -i | --gpu_id | INTEGER | False | GPU ID to use [Default: 0] | +| -n | --n_to_plot | INTEGER | False | Number of plots to create [Default: 0, fills directory] | +| -L | --gpu_memory_limit | INTEGER | False | GPU memory limit in MB [Default: 0 (disabled)] | +| | --min_gpu_ram | None | False | Use min gpu ram | ### `verify` @@ -267,15 +267,15 @@ Usage: drsolver [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------- | :------ | :------- | :--------------------------------------------------- | -| -h | --help | None | False | Show a help message and exit | -| -g | --gpu | INTEGER | True | GPU ID to use for solving | -| -v | --verbose | None | False | Verbose output | -| -t | --token | TEXT | True | Client token to use for registration | -| | --generate-token | None | False | Generate a client token | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -g | --gpu | INTEGER | True | GPU ID to use for solving | +| -v | --verbose | None | False | Verbose output | +| -t | --token | TEXT | True | Client token to use for registration | +| | --generate-token | None | False | Generate a client token | | | --drserver-ip | TEXT | True | Your own DrServer, at IP:PORT, e.g. 192.168.0.1:8080 | -| | --ssl | BOOLEAN | False | Use SSL for your solver server [Default: false] | +| | --ssl | BOOLEAN | False | Use SSL for your solver server [Default: false] | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/simulator-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/simulator-cli.md index db13cb8365e..3c82db69528 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/simulator-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/simulator-cli.md @@ -30,17 +30,16 @@ Usage: `chia dev sim create [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------- | :------ | :------- | :---------------------------------------------------------------------------- | -| -f | --fingerprint | INTEGER | False | Use your fingerprint to skip the key prompt | -| -r | --reward_address | TEXT | False | Use this address instead of the default farming address | -| -p | --plot-directory | TEXT | False | Set the directory in which to create/store plots (Default: 'simulator/plots') | -| -m | --mnemonic | TEXT | False | Add a new key to the keychain using the specified mnemonic | -| -a | --auto-farm | BOOLEAN | False | Enable or Disable auto farming (Default: True) | -| -h | --help | None | False | Show a help message and exit | - -
-Example 1 +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :--------------------------------------------------------------------------------------------------------------- | +| -f | --fingerprint | INTEGER | False | Use your fingerprint to skip the key prompt | +| -r | --reward_address | TEXT | False | Use this address instead of the default farming address | +| -p | --plot-directory | TEXT | False | Set the directory in which to create/store plots (Default: 'simulator/plots') | +| -m | --mnemonic | TEXT | False | Add a new key to the keychain using the specified mnemonic | +| -a | --auto-farm | BOOLEAN | False | Enable or Disable auto farming (Default: True) | +| -h | --help | None | False | Show a help message and exit | + +
Example 1 Use all default values, with no keys present on the local machine. @@ -169,8 +168,7 @@ Genesis block generated, exiting.
-
-Example 2 +
Example 2 Use all default values, with a key and plots already generated: @@ -207,8 +205,7 @@ Genesis block already exists, exiting.
-
-Example 3 +
Example 3 Add a mnemonic seed for a key that does not yet exist on this machine. @@ -310,8 +307,7 @@ Options: Auto farming is enabled by default. The examples will show you how to disable/enable it. -
-Example 1 +
Example 1 Disable auto farming: @@ -327,8 +323,7 @@ Auto farming is now off
-
-Example 2 +
Example 2 Enable auto farming: @@ -354,15 +349,14 @@ Usage: `chia dev sim farm [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------- | -| -b | --blocks | INTEGER | False | Number of blocks to create (Default: 1) | -| -n | --non-transaction | None | False | Enable to allow non-transaction blocks (Default: disabled) | -| -a | --target-address | TEXT | False | Block reward address. If not specified, the default address will be used | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :-------------------------------------------------------------------------------------------- | +| -b | --blocks | INTEGER | False | Number of blocks to create (Default: 1) | +| -n | --non-transaction | None | False | Enable to allow non-transaction blocks (Default: disabled) | +| -a | --target-address | TEXT | False | Block reward address. If not specified, the default address will be used | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Farm one transaction block using the default values: @@ -379,8 +373,7 @@ Block Height is now: 2
-
-Example 2 +
Example 2 Farm multiple transaction blocks: @@ -397,8 +390,7 @@ Block Height is now: 5
-
-Example 3 +
Example 3 Farm multiple blocks (transaction or non-transaction): @@ -415,8 +407,7 @@ Block Height is now: 8
-
-Example 4 +
Example 4 Farm a transaction block and send the reward to a different address. @@ -490,17 +481,16 @@ Usage: `chia dev sim revert [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -b | --blocks | INTEGER | False | Number of blocks to go back (Default: 1) | -| -n | --new_blocks | INTEGER | False | Number of new blocks to add during a reorg (Default: 1) | -| -r | --reset | None | False | Enable to revert all transactions to the genesis block (Default: disabled) | -| -f | --force | None | False | Enable to forcefully delete blocks, this is not a reorg but might be needed in very special circumstances. Note: Use with caution, this will break all wallets (Default: disabled) | -| -d | --disable_prompt | None | False | Disable confirmation prompt when force reverting, only works in conjunction with `-f` (Default: prompt is enabled) | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------ | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -b | --blocks | INTEGER | False | Number of blocks to go back (Default: 1) | +| -n | --new_blocks | INTEGER | False | Number of new blocks to add during a reorg (Default: 1) | +| -r | --reset | None | False | Enable to revert all transactions to the genesis block (Default: disabled) | +| -f | --force | None | False | Enable to forcefully delete blocks, this is not a reorg but might be needed in very special circumstances. Note: Use with caution, this will break all wallets (Default: disabled) | +| -d | --disable_prompt | None | False | Disable confirmation prompt when force reverting, only works in conjunction with `-f` (Default: prompt is enabled) | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Revert the transactions from one block and advance the chain by one block: @@ -517,8 +507,7 @@ Block Height is now: 11
-
-Example 2 +
Example 2 Revert transactions from three blocks and advance the chain by five blocks: @@ -535,8 +524,7 @@ Block Height is now: 17
-
-Example 3 +
Example 3 Revert all transactions in the blockchain (note that this could take several minutes): @@ -563,14 +551,13 @@ Usage: `chia dev sim start [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :----------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :---------------------------------------------------------------------------------------- | | -r | --restart | None | False | Enable to restart running services (Default: disabled) | | -w | --wallet | None | False | Enable to start wallet (Default: disabled) | -| -h | --help | None | False | Show a help message and exit | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Use the default values. This will start the daemon and the simulator, but not the wallet: @@ -588,8 +575,7 @@ chia_full_node_simulator: started
-
-Example 2 +
Example 2 Status before this example: Simulator is running and wallet is not running. @@ -619,17 +605,16 @@ Usage: `chia dev sim status [OPTIONS]` Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------- | -| -f | --fingerprint | INTEGER | False | Get detailed information on this fingerprint. | -| -k | --show_key | None | False | Enable to show detailed key information, including seed phrase (Default: disabled) | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -f | --fingerprint | INTEGER | False | Get detailed information on this fingerprint. | +| -k | --show_key | None | False | Enable to show detailed key information, including seed phrase (Default: disabled) | | -c | --show_coins | None | False | Enable to show all unspent coins (Default: disabled). When enabled, this does not show reward coins unless used in conjunction with `-i` | | -i | --include_rewards | None | False | Enable to show rewards coins (Default: disabled). This option must be used in conjunction with `-c` | -| -a | --show_addresses | None | False | Enable to show the balances of all addresses (Default: disabled) | -| -h | --help | None | False | Show a help message and exit | +| -a | --show_addresses | None | False | Enable to show the balances of all addresses (Default: disabled) | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Show the status using the default values: @@ -670,8 +655,7 @@ Current Farming address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4ua
-
-Example 2 +
Example 2 Include key info with the status (CAUTION: this includes the key's seed phrase): @@ -724,8 +708,7 @@ Current Farming address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4ua
-
-Example 3 +
Example 3 Show all coins, including reward coins: @@ -785,8 +768,7 @@ Created at: 2022-09-27 23:50:07
-
-Example 4 +
Example 4 Show the balance of each address: @@ -841,14 +823,13 @@ Usage: `chia dev sim stop [OPTIONS]` Options: Stop running services -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :-------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------------------- | | -d | --daemon | None | False | Enable to stop the daemon (Default: disabled) | | -w | --wallet | None | False | Enable to stop the wallet (Default: disabled) | -| -h | --help | None | False | Show a help message and exit | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Stop the simulator with the default values: @@ -877,8 +858,7 @@ The response shows that the daemon and wallet are still running:
-
-Example 2 +
Example 2 Stop the simulator, daemon, and wallet: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/vc-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/vc-cli.md index 62b5b75e235..d081b71ca27 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/vc-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/vc-cli.md @@ -19,16 +19,15 @@ Usage: chia wallet vcs add_proof_reveal [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -p | --proof | TEXT | True\* | A flag to add as a proof | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -p | --proof | TEXT | True\* | A flag to add as a proof | | -r | --root-only | None | False | If this flag is set, do not add the proofs to the DB, just output the root from the specified proofs [Default: not set] | -| -h | --help | None | False | Show a help message and exit | +| -h | --help | None | False | Show a help message and exit | -
-Example 1 +
Example 1 Add two proofs: @@ -44,8 +43,7 @@ Proofs added to DB successfully!
-
-Example 2 +
Example 2 Get the root hash of the tree created from adding two proofs: @@ -71,16 +69,15 @@ Usage: chia wallet vcs get [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -s | --start | INTEGER | False | The index to start the list at [default: 0] | -| -c | --count | INTEGER | False | How many results to return [default: 50] | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -s | --start | INTEGER | False | The index to start the list at [default: 0] | +| -c | --count | INTEGER | False | How many results to return [default: 50] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet vcs get -f 2108245669 @@ -108,17 +105,16 @@ Usage: chia wallet vcs get_proofs_for_root [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -r | --proof-hash | TEXT | True | The root to search for | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -r | --proof-hash | TEXT | True | The root to search for | +| -h | --help | None | False | Show a help message and exit | Note that if the root is not currently stored in the VC, the command will fail. -
-Example +
Example Search for a hash currently stored in the VC: @@ -146,20 +142,19 @@ Usage: chia wallet vcs mint [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use as the issuing wallet | -| -d | --did | TEXT | True | The DID of the VC's proof provider. Must be owned by the issuing wallet Must be owned by the issuing wallet | -| -t | --target-address | TEXT | False | The address to send the VC to once it's minted [Default: send to minting wallet] | -| -m | --fee | TEXT | False | Blockchain fee for mint transaction, in XCH | -| | --push | None | False | Push the transaction to the network [Default: True] | -| | --no-push | None | False | Do not push the transaction to the network [Default: False] | -| | --transaction-file | TEXT | False | A file to write relevant transactions to | -| -h | --help | None | False | Show a help message and exit | - -
-Example +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use as the issuing wallet | +| -d | --did | TEXT | True | The DID of the VC's proof provider. Must be owned by the issuing wallet Must be owned by the issuing wallet | +| -t | --target-address | TEXT | False | The address to send the VC to once it's minted [Default: send to minting wallet] | +| -m | --fee | TEXT | False | Blockchain fee for mint transaction, in XCH | +| | --push | None | False | Push the transaction to the network [Default: True] | +| | --no-push | None | False | Do not push the transaction to the network [Default: False] | +| | --transaction-file | TEXT | False | A file to write relevant transactions to | +| -h | --help | None | False | Show a help message and exit | + +
Example A DID is required in order to mint a new VC. If the proof provider does not already have a DID, use the `did create` command to create one. For example: @@ -225,22 +220,21 @@ Usage: chia wallet vcs revoke [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -p | --parent-coin-id | TEXT | True\* | The ID of the parent coin of the VC (\*optional if VC ID is used) | -| -l | --vc-id TEXT | TEXT | True\* | The launcher ID of the VC to revoke (must be tracked by wallet) (\*optional if Parent ID is used) | -| -m | --fee | TEXT | False | Blockchain fee for revocation transaction, in XCH | -| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -p | --parent-coin-id | TEXT | True\* | The ID of the parent coin of the VC (\*optional if VC ID is used) | +| -l | --vc-id TEXT | TEXT | True\* | The launcher ID of the VC to revoke (must be tracked by wallet) (\*optional if Parent ID is used) | +| -m | --fee | TEXT | False | Blockchain fee for revocation transaction, in XCH | +| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | | | --generate-new-puzhash | None | False | If this flag is set, then send the VC to a new puzzle hash. This is the default behavior, and setting this flag will override the --reuse-puzhash flag if it is also set This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set | -| | --push | None | False | Push the transaction to the network [Default: True] | -| | --no-push | None | False | Do not push the transaction to the network [Default: False] | -| | --transaction-file | TEXT | False | A file to write relevant transactions to | -| -h | --help | None | False | Show a help message and exit | +| | --push | None | False | Push the transaction to the network [Default: True] | +| | --no-push | None | False | Do not push the transaction to the network [Default: False] | +| | --transaction-file | TEXT | False | A file to write relevant transactions to | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Revoke the proofs from a VC. A few notes: A few notes: @@ -293,23 +287,22 @@ Usage: chia wallet vcs update_proofs [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :--------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | -| -l | --vc-id | TEXT | True | The launcher ID of the VC whose proofs should be updated | -| -t | --new-puzhash | TEXT | False | The puzzle hash to which to send the VC after the proofs have been updated | -| -p | --new-proof-hash | TEXT | True | The new proof hash to update the VC to | -| -m | --fee | TEXT | False | Blockchain fee for update transaction, in XCH | -| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the rpc_port under wallet in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which key to use | +| -l | --vc-id | TEXT | True | The launcher ID of the VC whose proofs should be updated | +| -t | --new-puzhash | TEXT | False | The puzzle hash to which to send the VC after the proofs have been updated | +| -p | --new-proof-hash | TEXT | True | The new proof hash to update the VC to | +| -m | --fee | TEXT | False | Blockchain fee for update transaction, in XCH | +| | --reuse-puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from (ignored if `--generate-new-puzhash` is also specified) [Default: generate new puzzle hash] | | | --generate-new-puzhash | None | False | If this flag is set, then send the VC to a new puzzle hash. This is the default behavior, and setting this flag will override the --reuse-puzhash flag if it is also set This is the default behavior, and setting this flag will override the `--reuse-puzhash` flag if it is also set | -| | --push | None | False | Push the transaction to the network [Default: True] | -| | --no-push | None | False | Do not push the transaction to the network [Default: False] | -| | --transaction-file | TEXT | False | A file to write relevant transactions to | -| -h | --help | None | False | Show a help message and exit | +| | --push | None | False | Push the transaction to the network [Default: True] | +| | --no-push | None | False | Do not push the transaction to the network [Default: False] | +| | --transaction-file | TEXT | False | A file to write relevant transactions to | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Update the proofs. A few notes: A few notes: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/wallet-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/wallet-cli.md index 3f346724124..f97848b7f5e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/wallet-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/wallet-cli.md @@ -23,16 +23,15 @@ Usage: chia wallet add_token [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -id | --asset-id | TEXT | True | The Asset ID of the coin you wish to add/rename (the treehash of the TAIL program) | -| -n | --token-name | TEXT | False | The name you wish to designate to the token | -| -f | --fingerprint | INTEGER | False | The wallet fingerprint you wish to add the token to | -| -h | --help | None | False | Show a help message and exit | +| -id | --asset-id | TEXT | True | The Asset ID of the coin you wish to add/rename (the treehash of the TAIL program) | +| -n | --token-name | TEXT | False | The name you wish to designate to the token | +| -f | --fingerprint | INTEGER | False | The wallet fingerprint you wish to add the token to | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Add the Spacebucks token: @@ -62,19 +61,19 @@ Usage: chia wallet coins list [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------- | -| -p | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | False | Id of the wallet to use [default: 1] | -| -u | --show-unconfirmed | BOOLEAN | False | Separately display unconfirmed coins [default: false] | -| | --min-amount | TEXT | False | Ignore coins worth less then this much (XCH or CAT units) | -| | --max-amount | TEXT | False | Ignore coins worth more then this much (XCH or CAT units) | -| | --exclude-coin | TEXT | False | Prevent this coin from being included (can be reused to exclude multiple coins) | -| | --exclude-amount | TEXT | False | Exclude any coins with this amount from being included (can be reused to exclude multiple amounts) | -| | --paginate | None | False | Prompt for each page of data. Defaults to enabled for interactive consoles, otherwise defaults to disabled | -| | --no-paginate | None | False | Do not prompt for each page of data. Defaults to disabled for interactive consoles, otherwise defaults to enabled | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | +| -p | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | False | Id of the wallet to use [default: 1] | +| -u | --show-unconfirmed | BOOLEAN | False | Separately display unconfirmed coins [default: false] | +| | --min-amount | TEXT | False | Ignore coins worth less then this much (XCH or CAT units) | +| | --max-amount | TEXT | False | Ignore coins worth more then this much (XCH or CAT units) | +| | --exclude-coin | TEXT | False | Prevent this coin from being included (can be reused to exclude multiple coins) | +| | --exclude-amount | TEXT | False | Exclude any coins with this amount from being included (can be reused to exclude multiple amounts) | +| | --paginate | None | False | Prompt for each page of data. Defaults to enabled for interactive consoles, otherwise defaults to disabled | +| | --no-paginate | None | False | Do not prompt for each page of data. Defaults to disabled for interactive consoles, otherwise defaults to enabled | +| -h | --help | None | False | Show a help message and exit | :::info @@ -87,8 +86,7 @@ You can disable the dust filter by editing `~/.chia/mainnet/config/config.yaml` Example 1 will give a baseline: -
-Example 1 +
Example 1 List all coins for a given fingerprint: @@ -132,8 +130,7 @@ Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb The following examples all use the same coin state that was obtained in Example 1: -
-Example 2: exclude small coins +
Example 2: exclude small coins Exclude coins smaller than 0.1 XCH: @@ -161,8 +158,7 @@ Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb
-
-Example 3: exclude large coins +
Example 3: exclude large coins Exclude coins larger than 0.00001 XCH. Note that there is one coin of exactly that value. It is included: @@ -193,8 +189,7 @@ Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc
-
-Example 4: exclude specific coins +
Example 4: exclude specific coins Use the `--exclude-coin` flag multiple times to exclude individual coins: @@ -228,8 +223,7 @@ Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb
-
-Example 5: exclude specific amounts +
Example 5: exclude specific amounts Use the `--exclude-amount` flag multiple times to exclude specific amounts. Note that if multiple coins have the same amount, they will all be excluded: @@ -260,8 +254,7 @@ Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb
-
-Example 6: disable pagination +
Example 6: disable pagination The `--no-paginate` flag will cause _all_ coins to be listed with no additional input from the user: @@ -301,8 +294,7 @@ Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb
-
-Example 7: list a CAT +
Example 7: list a CAT First, list all assets in the wallet: @@ -380,24 +372,23 @@ Usage: chia wallet coins combine [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | -| -p | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -p | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | | -a | --target-amount | TEXT | False | Select coins until this amount (in XCH or CAT) is reached. Combine all selected coins into one coin, which will have a value of at least target-amount | -| | --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units [default: disabled] | -| | --exclude-amount | TEXT | False | Exclude any coins with this amount from being included (can be reused | -| -n | --number-of-coins | INTEGER | False | The number of coins we are combining [default: 500] | -| | --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units [default: disabled] | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | -| | --input-coin | TEXT | False | Only combine coins with these ids (can be reused) | -| | --largest-first | None | False | Sort coins from largest to smallest [default: smallest-first] | -| | --smallest-first | None | False | Sort coins from smallest to largest (this is the default behavior) | -| -h | --help | None | False | Show a help message and exit | - -
-Example 1: specific coins +| | --min-amount | TEXT | False | Ignore coins worth less then this much XCH or CAT units [default: disabled] | +| | --exclude-amount | TEXT | False | Exclude any coins with this amount from being included (can be reused | +| -n | --number-of-coins | INTEGER | False | The number of coins we are combining [default: 500] | +| | --max-amount | TEXT | False | Ignore coins worth more then this much XCH or CAT units [default: disabled] | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | +| | --input-coin | TEXT | False | Only combine coins with these ids (can be reused) | +| | --largest-first | None | False | Sort coins from largest to smallest [default: smallest-first] | +| | --smallest-first | None | False | Sort coins from smallest to largest (this is the default behavior) | +| -h | --help | None | False | Show a help message and exit | + +
Example 1: specific coins First, list all coins, without pagination: @@ -501,8 +492,7 @@ Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a
-
-Example 2: enable min/max thresholds +
Example 2: enable min/max thresholds Start by listing all coins, with pagination disabled: @@ -600,8 +590,7 @@ Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a
-
-Example 3: combine the two smallest coins +
Example 3: combine the two smallest coins Start by listing all coins, with pagination disabled: @@ -694,8 +683,7 @@ Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a
-
-Example 4: largest first / target amount +
Example 4: largest first / target amount Start by listing all coins, with pagination disabled: @@ -763,8 +751,7 @@ Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a
-
-Example 5: error case +
Example 5: error case Start by listing all coins of at least 0.9 XCH: @@ -800,8 +787,7 @@ This shows that you cannot combine a single coin. Lowering (or removing) the `--
-
-Example 6: default settings +
Example 6: default settings Start by listing all coins, with pagination disabled: @@ -872,16 +858,16 @@ Usage: chia wallet coins split [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -p | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -n | --number-of-coins | INTEGER | True | The number of new coins to create, excluding the remainder coin (minimum 1, maximum 500) | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | -| -a | --amount-per-coin | TEXT | True | The amount of each newly created coin, in XCH | -| -t | --target-coin-id | TEXT | True | The coin id of the coin we are splitting | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -n | --number-of-coins | INTEGER | True | The number of new coins to create, excluding the remainder coin (minimum 1, maximum 500) | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | +| -a | --amount-per-coin | TEXT | True | The amount of each newly created coin, in XCH | +| -t | --target-coin-id | TEXT | True | The coin id of the coin we are splitting | +| -h | --help | None | False | Show a help message and exit | This command requires a single coin to be specified for splitting. The maximum number of new coins is 500. These coins will be of equal value, and the original coin must contain sufficient funds for the splitting to occur. @@ -896,8 +882,7 @@ Therefore, if you split a coin into more than 200 coins worth less than one mill The minimum number of new coins is 1. "Splitting" one coin into one new coin could be useful because a second new coin will be created with the remaining value. -
-Example 1 +
Example 1 First, list the coins available: @@ -981,8 +966,7 @@ Coin ID: 0x27049c58aad594bdb83a0f191098f438218cbd7066700342034709afb2470c0d
-
-Example 2: split a CAT +
Example 2: split a CAT Start by listing the CATs in `Wallet ID: 4`: @@ -1062,19 +1046,18 @@ Usage: chia wallet delete_unconfirmed_transactions [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -ids | --tx_ids | TEXT | True | IDs of the Clawback transactions you want to revert or claim. Separate multiple IDs by comma (,) Separate multiple IDs by comma (,) | -| -m | --fee | TEXT | False | A fee to add to the offer when it gets taken, in XCH [default: 0] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -ids | --tx_ids | TEXT | True | IDs of the Clawback transactions you want to revert or claim. Separate multiple IDs by comma (,) Separate multiple IDs by comma (,) | +| -m | --fee | TEXT | False | A fee to add to the offer when it gets taken, in XCH [default: 0] | +| -h | --help | None | False | Show a help message and exit | Note that wallet will automatically detect whether the transactions should be reverted (clawed back) or claimed. -
-Example 1: clawback +
Example 1: clawback First, create the clawback. This is a normal `send` command, with an extra `--clawback` timer: @@ -1135,8 +1118,7 @@ Created at: 2023-06-14 13:17:33
-
-Example 2: claim +
Example 2: claim Set up a clawback send transaction with a 60-second clawback window: @@ -1209,15 +1191,14 @@ Usage: chia wallet delete_unconfirmed_transactions [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet delete_unconfirmed_transactions --fingerprint 2121994410 @@ -1241,17 +1222,16 @@ Usage: chia wallet get_address [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -n | --new-address | None | False | Create a new wallet receive address [default: disabled] | -| -l | --latest-address | None | False | Show the most recently created wallet receive address [default: enabled] | -| -h | --help | None | False | Show a help message and exit | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -n | --new-address | None | False | Create a new wallet receive address [default: disabled] | +| -l | --latest-address | None | False | Show the most recently created wallet receive address [default: enabled] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Get a new address: @@ -1277,14 +1257,13 @@ Usage: chia wallet get_derivation_index [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet get_derivation_index --fingerprint 2121994410 @@ -1308,17 +1287,16 @@ Usage: chia wallet get_transaction [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i, | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -tx | --tx_id | TEXT | True | Transaction id to search for | -| -v | --verbose | None | False | Show verbose output [default: disabled] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i, | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -tx | --tx_id | TEXT | True | Transaction id to search for | +| -v | --verbose | None | False | Show verbose output [default: disabled] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet get_transaction --fingerprint 2121994410 --tx_id 1b32a7f42c88b70924e3ec70d2a377b2b5c5f28de14736a3e2b5d411dec98c06 @@ -1346,24 +1324,23 @@ Usage: chia wallet get_transactions [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :------------------ | :------ | :------- | :---------------------------------------------------------------------------------------------------------------- | --------- | -------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -o | --offset | INTEGER | False | Skip transactions from the beginning of the list [default: 0] | -| -l | --limit | INTEGER | False | Max number of transactions to return [default: 4294967295] | -| -v | --verbose | None | False | Show verbose output [default: disabled] | -| | --paginate | None | False | Prompt for each page of data. Defaults to enabled for interactive consoles, otherwise defaults to disabled | -| | --no-paginate | None | False | Do not prompt for each page of data. Defaults to disabled for interactive consoles, otherwise defaults to enabled | -| | --sort-by-height | None | False | Sort transactions by height [default: disabled] | -| | --sort-by-relevance | None | False | Sort transactions by \{confirmed \\ | height \\ | time\} [default: disabled] | -| | --reverse | None | False | Reverse the transaction ordering [default: disabled] | -| | --clawback | None | False | Only show clawback transactions [default: disabled] | -| -h | --help | None | False | Show a help message and exit | - -
-Example 1: Show a single XCH transaction +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -o | --offset | INTEGER | False | Skip transactions from the beginning of the list [default: 0] | +| -l | --limit | INTEGER | False | Max number of transactions to return [default: 4294967295] | +| -v | --verbose | None | False | Show verbose output [default: disabled] | +| | --paginate | None | False | Prompt for each page of data. Defaults to enabled for interactive consoles, otherwise defaults to disabled | +| | --no-paginate | None | False | Do not prompt for each page of data. Defaults to disabled for interactive consoles, otherwise defaults to enabled | +| | --sort-by-height | None | False | Sort transactions by height [default: disabled] | +| | --sort-by-relevance | None | False | Sort transactions by \{confirmed \\| height \\| time\} [default: disabled] | +| | --reverse | None | False | Reverse the transaction ordering [default: disabled] | +| | --clawback | None | False | Only show clawback transactions [default: disabled] | +| -h | --help | None | False | Show a help message and exit | + +
Example 1: Show a single XCH transaction Start by showing all wallets associated with the current fingerprint: @@ -1412,8 +1389,7 @@ Created at: 2023-08-01 19:55:51
-
-Example 2: Show all transactions from a CAT +
Example 2: Show all transactions from a CAT Start by showing all wallets associated with the current fingerprint: @@ -1521,16 +1497,15 @@ Usage: chia wallet notifications delete [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | TEXT | False | A specific notification ID to delete | -| | --all | None | False | All notifications can be deleted (they will be recovered during resync) [default: disabled] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | TEXT | False | A specific notification ID to delete | +| | --all | None | False | All notifications can be deleted (they will be recovered during resync) [default: disabled] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Delete all notifications: @@ -1556,14 +1531,14 @@ Usage: chia wallet notifications get [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | TEXT | False | The specific notification ID to show | -| -s | --start | INTEGER | False | The number of notifications to skip | -| -e | --end | INTEGER | False | The number of notifications to stop at | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | TEXT | False | The specific notification ID to show | +| -s | --start | INTEGER | False | The number of notifications to skip | +| -e | --end | INTEGER | False | The number of notifications to stop at | +| -h | --help | None | False | Show a help message and exit | :::info @@ -1571,8 +1546,7 @@ To set up your wallet to receive notifications, follow [these instructions](/chi ::: -
-Example +
Example ```bash chia wallet notifications get --fingerprint 2121994410 @@ -1598,18 +1572,17 @@ Usage: chia wallet notifications send [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -t | --to-address | TEXT | True | The address to send the notification to | -| -a | --amount | TEXT | False | The amount (in XCH) to send to get the notification past the recipient's spam filter [default: 0.00001] | -| -n | --message | TEXT | True | The message of the notification | -| -m | --fee | TEXT | False | The fee for the transaction | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -t | --to-address | TEXT | True | The address to send the notification to | +| -a | --amount | TEXT | False | The amount (in XCH) to send to get the notification past the recipient's spam filter [default: 0.00001] | +| -n | --message | TEXT | True | The message of the notification | +| -m | --fee | TEXT | False | The fee for the transaction | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example Send a test notification: @@ -1635,25 +1608,24 @@ Usage: chia wallet send [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | -| -a | --amount | TEXT | True | How much chia to send, in XCH or CAT units | -| -e | --memo | TEXT | False | Additional memo for the transaction | -| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | -| -t | --address | TEXT | True | Address to send the XCH | -| -o | --override | None | False | Submits transaction without checking for unusual values [default: disabled] | -| -ma | --min-coin-amount | TEXT | False | Ignore coins worth less then this much (XCH or CAT units) | -| -l | --max-coin-amount | TEXT | False | Ignore coins worth more then this much (XCH or CAT units) | -| | --exclude-coin | TEXT | False | Exclude this coin from being spent | -| | --reuse | None | False | Set this flag to reuse an existing address for the change [default: not set] | -| | --clawback_time | INTEGER | False | The seconds that the recipient needs to wait to claim the fund. A positive number will enable this feature A positive number will enable this feature | -| -h | --help | None | False | Show a help message and exit | - -
-Example 1: send with memo +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --id | INTEGER | False | ID of the wallet to use [default: 1] | +| -a | --amount | TEXT | True | How much chia to send, in XCH or CAT units | +| -e | --memo | TEXT | False | Additional memo for the transaction | +| -m | --fee | TEXT | False | Set the fees for the transaction, in XCH [default: 0] | +| -t | --address | TEXT | True | Address to send the XCH | +| -o | --override | None | False | Submits transaction without checking for unusual values [default: disabled] | +| -ma | --min-coin-amount | TEXT | False | Ignore coins worth less then this much (XCH or CAT units) | +| -l | --max-coin-amount | TEXT | False | Ignore coins worth more then this much (XCH or CAT units) | +| | --exclude-coin | TEXT | False | Exclude this coin from being spent | +| | --reuse | None | False | Set this flag to reuse an existing address for the change [default: not set] | +| | --clawback_time | INTEGER | False | The seconds that the recipient needs to wait to claim the fund. A positive number will enable this feature A positive number will enable this feature | +| -h | --help | None | False | Show a help message and exit | + +
Example 1: send with memo Send 1000 mojos with a test memo: @@ -1671,8 +1643,7 @@ Run 'chia wallet get_transaction -f 3792481086 -tx 0x6fbac9409dbdef3cfa8a8fd82be
-
-Example 2: clawback +
Example 2: clawback Send 1 TXCH and include a 3600-second (1 hour) clawback: @@ -1736,15 +1707,14 @@ Usage: chia wallet show [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -------------- | ------------------- | ------------ | ---------- | ------ | -------------- | ------------------- | ----------------- | ------ | ------------- | ----------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -w | --wallet_type | TEXT | False | Choose a specific wallet type to return, choose from the following: [standard_wallet \\ | atomic_swap \\ | authorized_payee \\ | multi_sig \\ | custody \\ | cat \\ | recoverable \\ | decentralized_id \\ | pooling_wallet \\ | nft \\ | data_layer \\ | data_layer_offer] | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -w | --wallet_type | TEXT | False | Choose a specific wallet type to return, choose from the following: [standard_wallet \\| atomic_swap \\| authorized_payee \\| multi_sig \\| custody \\| cat \\| recoverable \\| decentralized_id \\| pooling_wallet \\| nft \\| data_layer \\| data_layer_offer] | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet show --fingerprint 2121994410 @@ -1799,16 +1769,15 @@ Usage: chia wallet sign_message [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | -| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -a | --address | TEXT | True | The address you want to use for signing | -| -m | --hex_message | TEXT | True | The hex message you want sign | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :--------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | +| -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -a | --address | TEXT | True | The address you want to use for signing | +| -m | --hex_message | TEXT | True | The hex message you want sign | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet sign_message --fingerprint 2121994410 --address xch1jp5thqu3dhwkvvh5p77lvlackddrd9q2zpt58zs6yqr2c4yvregs69ayqr --hex_message 0xdeadbeef @@ -1834,15 +1803,14 @@ Usage: chia wallet update_derivation_index [OPTIONS] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :---------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------- | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :---------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | -wp | --wallet-rpc-port | INTEGER | False | Set the port where the Wallet is hosting the RPC interface. See the `rpc_port` under `wallet` in config.yaml | -| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | -| -i | --index | INTEGER | True | Index to set. Must be greater than the current derivation index | -| -h | --help | None | False | Show a help message and exit | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -i | --index | INTEGER | True | Index to set. Must be greater than the current derivation index | +| -h | --help | None | False | Show a help message and exit | -
-Example +
Example ```bash chia wallet update_derivation_index --fingerprint 2121994410 --index 475 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/dual-farming-testnet-mainnet.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/dual-farming-testnet-mainnet.md index 72be365922a..1d9adce86f8 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/dual-farming-testnet-mainnet.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/dual-farming-testnet-mainnet.md @@ -24,7 +24,7 @@ For the mainnet installation, we will stick with the default ports and `CHIA_ROO ## 设置测试网络安装 1. (Optional) Install [yq](https://github.com/mikefarah/yq#install) to make editing the yaml files easier - - Alternatively, you can manually edit the ports in `config.yaml` + 1. Alternatively, you can manually edit the ports in `config.yaml` 2. 运行以下命令： ```bash diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-basics.md index 0e5a59b4903..37371f2214a 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-basics.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-basics.md @@ -35,8 +35,8 @@ Every three years, there is a scheduled halving of the block reward. Every three 以下是完整的区块奖励计划： -| 年份 | 区块奖励 | XCH / 10 mins | -| ----- | --------- | ------------- | +| 年份 | 区块奖励 | XCH / 10 mins | +| ----- | ------------------------- | ------------- | | 1-3 | 2.0 XCH | 64 | | 4-6 | 1.0 XCH | 32 | | 7-9 | 0.5 XCH | 16 | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-compressed-plots.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-compressed-plots.md index 1920b4a00f7..81023ad4494 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-compressed-plots.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-compressed-plots.md @@ -31,13 +31,14 @@ In the future, we plan to enable decompression at the farmer level. In the futur 3. Slide the `Enable compressed plot support` slider to the right, as shown in the above image. 4. For `Parallel Decompressor Count`, the default value of `1` will be fine for most users. Here are some details: - - This number _only_ affects the amount of memory used for decompression. - - The amount memory required will vary according to the level of compression. For example, if `Parallel Decompressor Count` is set to `1`, around 600-700 MB of memory will be consumed while decompressing a single C7 plot. - - The amount of memory required will scale linearly, so setting it to `2` will double the required memory. -If your harvester has sufficient memory, as well as a high CPU core count, you can increase this number. For example, 2 might be optimal for a 16-core CPU, or 4 for dual 32-core CPUs. For example, `2` might be optimal for a 16-core CPU, or `4` for dual 32-core CPUs. + - This number _only_ affects the amount of memory used for decompression. + - The amount memory required will vary according to the level of compression. For example, if `Parallel Decompressor Count` is set to `1`, around 600-700 MB of memory will be consumed while decompressing a single C7 plot. + - The amount of memory required will scale linearly, so setting it to `2` will double the required memory. -However, the generation and speed of your CPU will also have a large impact on the optimal setting. If you do increase `Parallel Decompressor Count`, be sure to monitor your harvester's performance as there is no one-size-fits-all solution. + If your harvester has sufficient memory, as well as a high CPU core count, you can increase this number. For example, 2 might be optimal for a 16-core CPU, or 4 for dual 32-core CPUs. For example, `2` might be optimal for a 16-core CPU, or `4` for dual 32-core CPUs. + + However, the generation and speed of your CPU will also have a large impact on the optimal setting. If you do increase `Parallel Decompressor Count`, be sure to monitor your harvester's performance as there is no one-size-fits-all solution. 5. The default value for `Decompressor Thread Count` is `0`. This is the number of threads that will participate in decompressing plots. This number, multiplied by `Parallel Decompressor Count`, needs to less than or equal to the total number of harvester cores. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-many-machines.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-many-machines.md index f6bb7359901..fd05109b7e2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-many-machines.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-many-machines.md @@ -47,6 +47,7 @@ If you are more of a visual learner, JM made a video outlining the steps from th ``` Options to make this directory accessible include: + - Share the directory on a network drive - Copy it using a USB key - Do a network copy to each harvester @@ -174,7 +175,7 @@ In other words, _only use the keys specific to your machine's purpose_. #### 在多台机器上生成地块 -As stated [above](/reference-client/farming/farming-many-machines#先决条件), run the following command when creating plots: +As stated [above](/reference-client/farming/farming-many-machines#prerequisites), run the following command when creating plots: ```bash chia plots create -f -p @@ -184,7 +185,7 @@ When you use the `-f` and `-p` parameters, you do not need to copy the keys to t #### 在多台机器上进行收割 -Rather than maintaining a copy of your farmer's certificates on each harvester, follow the [above](/reference-client/farming/farming-many-machines#先决条件) steps to keep them in one place while farming. +Rather than maintaining a copy of your farmer's certificates on each harvester, follow the [above](/reference-client/farming/farming-many-machines#prerequisites) steps to keep them in one place while farming. ### 钱包保持独立(Separate) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/pool-farming.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/pool-farming.md index dd6a68237c8..60ac58ecda7 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/pool-farming.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/pool-farming.md @@ -48,14 +48,14 @@ For more info, see our [blog post](https://www.chia.net/2023/03/19/introducing-c 主要有两个选项： 1. 独自耕种：这个联合耕种农田不会连接到任何联合耕种服务器，1.75 XCH将直接进入你的钱包。 这与旧的（原始）地块（OG）不同，因为旧地块永远锁定在独自耕种状态。 - 使用命令行： + 使用命令行： ```bash chia plotnft create -s local ``` 2. 连接联合耕种：加入一个联合耕种池，并在生成地块后立即开始耕种。 - 使用命令行： + 使用命令行： ```bash chia plotnft create -s pool -u https://bar.examplepool.org @@ -108,7 +108,7 @@ You can now start creating plots for this Plot NFT, which means these plots will Detailed instructions can be found in the "How to Plot" page: - Plotting from the [CLI](/reference-client/plotting/plotting-how-to#cli-plotting) -- Plotting from the [GUI](/reference-client/plotting/plotting-how-to#图形用户界面gui生成地块) +- Plotting from the [GUI](/reference-client/plotting/plotting-how-to#gui-plotting) ### 第五步：管理联合耕种农田。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/farming-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/farming-guide.md index 4d6d4a164ee..95e13fbb510 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/farming-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/farming-guide.md @@ -6,9 +6,6 @@ slug: /reference-client/getting-started/farming-guide import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -import WalletKeyDetails from '@site/static/img/troubleshooting/wallet_key_details.png'; -import WalletKeysPublic from '@site/static/img/faq/wallet_keys_public_key.png'; -import WalletLogout from '@site/static/img/troubleshooting/wallet_logout.png'; So you want to be a Chia farmer? You've come to the right place! @@ -299,7 +296,7 @@ Pools typically require you to wait for 30 minutes before leaving. This is to pr :::info -Chia's pooling protocol has several significant advantages over pools on other blockchains. Read more about these advantages, as well as the technical details of how the protocol works, in our [pooling section](/chia-blockchain/introduction#矿池pooling). +Chia's pooling protocol has several significant advantages over pools on other blockchains. Read more about these advantages, as well as the technical details of how the protocol works, in our [pooling section](/docs/chia-blockchain/introduction.md#pooling). ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/wallet-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/wallet-guide.md index 045ac07a4a3..60c7517b020 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/wallet-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/wallet-guide.md @@ -89,7 +89,7 @@ Chia Asset Tokens (CATs) are fungible assets on Chia's blockchain. In Chia parla

2. The Chia reference wallet comes with a few included CATs, but most will need to be entered manually. If you want to add one of the included CATs, click the slider next to the CAT you would like to add. - Otherwise, click the `+` button: + Otherwise, click the `+` button:
add token diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/installation.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/installation.md index 07fee362e83..01da970b893 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/installation.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/installation.md @@ -20,7 +20,7 @@ There are various ways to install Chia, with the best method depending on what y - If you intend to do [Chialisp](https://chialisp.com) development or build projects that leverage Chia, you have the options of either using an installer (the recommended pattern), or installing from source. -- Lastly, if you plan on making contributions to the source code, then installing Chia [from source](/reference-client/install-and-setup/installation#from-source) would be your path. +- Lastly, if you plan on making contributions to the source code, then installing Chia [from source](/docs/reference-client/install-and-setup/installation.md#from-source) would be your path. **_In summary, unless you already knew before reading this page that you should be installing from source, chances are your best path will be to install from our [official downloads page](https://www.chia.net/downloads) or a Linux package, depending on your OS._** @@ -382,7 +382,7 @@ Install Ubuntu 20.04 LTS from the Microsoft Store and run it and complete its in #### Install from source - WSL2 -See [install from source](/reference-client/install-and-setup/installation#from-source) for detailed instruction. +See [install from source](/docs/reference-client/install-and-setup/installation.md#from-source) for detailed instruction. Running a standalone Windows wallet gui is deprecated but may return in later versions. You can run the Windows version and share keys. You can also plot in WSL2 and migrate the plots to a Windows farmed plot directory. @@ -417,7 +417,7 @@ For maximum speed, `-t` and `-2` should be inside the WSL2 filesystem. Something #### Install from source - Amazon Linux 2 -See [install from source](/reference-client/install-and-setup/installation#from-source) for detailed instruction. +See [install from source](/docs/reference-client/install-and-setup/installation.md#from-source) for detailed instruction. #### Install from binary package @@ -434,382 +434,157 @@ pip install --extra-index-url https://pypi.chia.net/simple chia-blockchain miniu -_**These instructions were tested with Chia 1.1.4 on FreeBSD 11.3- and 11.4-RELEASE, newer versions may exist**_ + ---- - -#### Upgrading Existing Chia Installs - -If you're upgrading from a previously built chia installation, exit from your previous venv environment (`deactivate`), create a new directory in which to place the latest Chia (e.g. `mkdir ~/chia-1.0.5 && cd ~/chia-1.0.5`), clone the latest repo (`git clone https://github.com/Chia-Network/chia-blockchain.git -b latest`), enter it and create a new Python virtual environment within it (`python3 -m venv venv`). Now, activate the newest environment (`. venv/bin/activate`), upgrade pip (`pip install --upgrade pip`). Now you may skip down to the [clvm_rs install section](#clvm_rs) and begin there. - ---- - -#### Why This Manual Installation? - -Currently the only way to ensure Chia builds on FreeBSD is to do it from the source. By following these instructions to the letter, you should have no problem building the latest Chia from source on a FreeBSD 11.3 or 11.4. This should also work on FreeBSD 12, possibly with some modifications - e.g. if the ports py-cryptography version is newer than 3.3.2, simply edit as needed - or if your preferred Python version is 3.8+ it should all still work considering you modify the package names as necessary. - -#### Notes on FreeNAS (TrueNAS) - -If you had been using NFS or Samba sharing to expose your plots to a harvester on another OS, such as Linux, you can instead build Chia within a jail (see the FreeNAS manual for 'jails'), expose your plot directories to it and run the harvester within. In my experience, it provides lower-latency and more reliable access to the plots since the disks are direct-attached and not being provided through an extra few layers of network protocols. - -If you are using a fresh jail created by the FreeNAS web GUI you may need to install openssh and setup a ssh key to login as root because by default it appears PAM password logins do not work. The jail shell CLI provided by the FreeNAS GUI allows copy and pasting so you can easily paste your public-key into /root/.ssh/authorized_keys && chmod -R 700 /root/.ssh. - -These instructions would be applicable to 11.3 and 11.4 jails created within FreeNAS 11 only. Version 12 (FreeBSD 12) ✔ + -#### Other Notes - -These instructions will have you building both chia-blockchain and clvm_rs from github source, and python-cryptography from FreeBSD's ports. - -The result of this build will be the "chia version" showing the current release branch ahead by 1 and in "dev0"; for instance building 1.0.1 results in "chia version" returning "1.0.2.dev0". If someone knows why this is and how to fix it, please, edit and correct this! It does not happen on Linux. - -_**These instructions assume a fresh FreeBSD 11 installation!**_ - -#### Discouraged? - -Following the instructions in this document will result in a working Chia CLI build on FreeBSD 11 if you follow step-by-step starting from a vanilla FreeBSD installation. Is something broken? Compare the commands you typed, accessible in your **bash** shell history, and match them with each command in this document. If you feel you've messed something up, do the following: - -``` -# if you have (venv) in your shell prompt, type deactivate -deactivate -# remove the chia-blockchain directory which will contain clvm_rs and the Python venv -rm -rf chia-blockchain -# ... now start again! You don't need to do all the setup steps but instead may start at the upgrade notes above if you had finished up to the py-cryptography ports build. -``` - -#### Pre-requisite package installation +:::warning Community-Supported +FreeBSD is not officially supported by the Chia team. These instructions are community-contributed and may lag behind the latest release. If you encounter issues, please report them in [chia-blockchain discussions](https://github.com/Chia-Network/chia-blockchain/discussions/8763). +::: -_If starting the build again after a failure and you have not re-installed FreeBSD, don't just skip this package installation section! You may have missed one or more software packages critical to the build._ +These instructions are for building Chia from source on **FreeBSD 13 or 14**. Chia requires **Python 3.10 or newer** (see [`install.sh`](https://github.com/Chia-Network/chia-blockchain/blob/main/install.sh)). The build script uses Poetry to resolve all Python dependencies (including `chia_rs`, `clvm_tools`, and `cryptography`) — no manual Rust wheel builds are needed. -The 'pkg', 'portsnap' and port build are to be run as root. Everything else can be run from a normal non-root user. +#### 先决条件 -As root, update pkg and ports, and then install all packages as instructed below. +Install required system packages as root: -``` -# Update your packages and ports; if ports are already installed as part of your fresh install run portsnap update instead of fetch/extract. +```bash pkg update -portsnap fetch && portsnap extract - -# Install bash if you have not; the default csh will not suffice for the build scripts. -pkg install bash -# change your shell to bash -chsh -s /usr/local/bin/bash -# run bash -/usr/local/bin/bash -``` - -Make sure you change the shell for your non-root chia-blockchain user. If you're opting to run Chia as root, you can skip this. If you are root, run this as it appears below; otherwise, you can omit the username because you are already that user. - -``` -chsh -s /usr/local/bin/bash NONROOT_USERNAME -``` - -Now proceed with installing the mandatory development tools. - -``` -pkg install lang/gcc9 gcc gmake cmake - +pkg install bash git cmake gmake gmp rust python311 py311-sqlite3 ``` -#### gcc notes +Adjust the Python version number (`python311`, `py311-sqlite3`) if your ports tree provides a different minor version (3.11, 3.12, etc.) as long as it is 3.10 or above. -After installing gcc version 9.0, this message appears: +Optional but recommended for remote sessions: -``` -To ensure binaries built with this toolchain find appropriate versions -of the necessary run-time libraries, you may want to link using - - -Wl,-rpath=/usr/local/lib/gcc9 -``` - -It's probably possible to build the libraries in a way that doesn't require `export LD_LIBRARY_PATH=/usr/local/lib/gcc9`. If you know how click "edit" and dish. - -#### Install rust, Python, and everything else. - -``` -pkg install lang/rust -pkg install lang/python37 py37-pip py37-setuptools py37-wheel py37-sqlite3 py37-cffi py37-virtualenv py37-maturin python -pkg install node npm git openssl -``` - -If you are ssh'ing into the machine you might want to use 'screen' so that processes will continue even if you logout. For more information: https://www.freebsd.org/cgi/man.cgi?query=screen. 'tmux' is also a great alternative especially if you use iTerm2 on macOS as it supports native tabs and windows with the '-CC' CLI option. - -``` -# optional packages +```bash pkg install screen tmux ``` -#### Repo Cloning and Virtual Environment (venv) Activation +#### Build -**From this point on, with the exception of the security/py-cryptography port build process (and any other exceptions noted), you may proceed as a normal user.** +Clone the repository and run the install script: -``` -# Clone the latest chia-blockchain repository, via HTTP: +```bash git clone https://github.com/Chia-Network/chia-blockchain.git -b latest -# or with SSH: -git clone git@github.com:Chia-Network/chia-blockchain.git -b latest -# Note: you can specify the branch by adding "--branch " like: git clone http://github.com/Chia-Network/chia-blockchain.git --branch 1.0.1 - -``` - -Create a virtual environment directory 'venv' from _within_ the 'chia-blockchain' directory and activate it before proceeding - -``` cd chia-blockchain -python3 -m venv venv -source venv/bin/activate -``` - -You are now in the virtual environment that Python (and so chia) will use. You should have a "(venv)" prefix to your terminal prompt to confirm the venv is working. - -Upgrade pip: - -``` -pip install --upgrade pip -``` - -To exit the virtual environment: - -``` -deactivate -``` - -#### Building py-cryptography from ports - -_**You'll need to switch to root for this part. If you're already using root remember to leave the virtual environment for this step.**_ - -``` -cd /usr/ports/security/py-cryptography - -# Instruct 'make' that the SSL library is openssl. -# Also force the Python version in case the port tries for a higher one -echo "DEFAULT_VERSIONS+=ssl=openssl python=3.7 python3=3.7" >> /etc/make.conf - -make -``` - -You'll probably see a bunch of warnings and notices; these are not errors and it will build. - -Do NOT run make install. We will do our own py-cryptography install because 'make install' does not copy to our virtual environment. (If you know how to change this, please edit). - -If you are running inside a jail and make fails with an error about the OSVERSION not matching UNAME, you will need to set the UNAME_r environment variable to match your jails OSVERSION: - -``` -# Adjust the value to match your jails OSVERSION -export UNAME_r=11.4-RELEASE -``` - -A full version list can be found [here](https://docs.freebsd.org/en/books/porters-handbook/book.html#versions). - -Once complete switch back to your non-root user if you so optioned. You must now be in your venv once again. - -#### clvm_rs - -Build and install the current version of [clvm_rs](https://github.com/Chia-Network/clvm_rs). -These instructions were created for version 0.1.7 but a newer version may exist. - -``` -git clone http://github.com/Chia-Network/clvm_rs.git --branch 0.1.7 -cd clvm_rs -maturin develop --release -pip install git+https://github.com/Chia-Network/clvm@use_clvm_rs -``` - -clvm_rs 0.1.7 is now installed in your virtual environment. - -#### Install py-cryptography to the venv -Copy py-cryptography and its meta-data from the staging directory to your virtual environment: - -``` -cp -R /usr/ports/security/py-cryptography/work-py37/stage/usr/local/lib/python3.7/site-packages/cryptography ${VIRTUAL_ENV}/lib/python3.7/site-packages/cryptography -cp -R /usr/ports/security/py-cryptography/work-py37/stage/usr/local/lib/python3.7/site-packages/cryptography-3.3.2-py3.7.egg-info ${VIRTUAL_ENV}/lib/python3.7/site-packages/cryptography-3.3.2-py3.7.egg-info -``` - -Clear any Python byte-code cache files that may contain the old path. These should be re-built by the interpreter but we like a clean environment. - -``` -find ${VIRTUAL_ENV}/lib/python3.7/site-packages/cryptography -name __pycache__ | xargs -I{} rm -rf "{}" -``` - -#### Chia modifications and Building Chia Itself - -Switch to your chia-blockchain clone directory. You will need to edit two files. - -Using your favorite text editor, modify setup.py to edit the cryptography package version to 3.3.2. - -``` -"cryptography==3.4.6" --> to --> "cryptography==3.3.2" +sh install.sh ``` -Now you must modify chia/util/keychain.py to provide a static key when using the Python keyring. This is mandatory otherwise every time the keyring is accessed your passphrase will need to be entered on the command line, and for the CLI daemon this will not do. +`install.sh` detects FreeBSD via `uname`, sets `MAKE=gmake` and `BUILD_VDF_CLIENT=N`, creates a Python virtual environment, installs Poetry, and resolves all dependencies from `pyproject.toml`. -On line 25 of chia/util/keychain.py, change: +:::note miniupnpc build failure +On some FreeBSD versions, Poetry may fail to build `miniupnpc` from source. If `install.sh` exits with errors related to `miniupnpc`, install it into the virtual environment manually and then re-run: -``` -elif platform=="linux": +```bash +. ./.venv/bin/activate +pip install miniupnpc +deactivate +sh install.sh ``` -to: - -``` -elif platform=="linux" or platform.startswith("freebsd"): -``` +::: -On line 27 of the same file, change the passphrase from "your keyring password" to whatever you wish your passphrase to be. This is intended to be fixed in future versions but, for the time being, Linux and FreeBSD must have the keyphrase provided statically. +After installation completes, activate the environment and initialize Chia: -``` -keyring.keyring_key = "your keyring password" # type: ignore +```bash +. ./activate +chia init ``` -can be changed like so: - -``` -keyring.keyring_key = "Too Many Secrets" -``` +#### Upgrading -Now, you will build Chia! +To upgrade to a newer Chia release, pull the latest tag and re-run the install: -``` +```bash +cd chia-blockchain +. ./activate +deactivate +git fetch --all --tags +git checkout latest sh install.sh -``` - -Once done, run: - -``` +. ./activate chia init ``` -NOTE: if you need to disable UPnP - a protocol which automatically sets up port-forwarding on routers using NAT which is a typical setup at any residence with broadband - set "enable_upnp: False" in config.yaml. You can use the one-liner below or do it yourself. +#### Notes on TrueNAS -``` -sed -i .bak 's/enable_upnp: True/enable_upnp: False' ~/.chia/mainnet/config/config.yaml -``` +If you run TrueNAS (formerly FreeNAS) and previously used NFS or Samba to expose plots to a harvester on another OS, you can instead build Chia inside a jail and mount plot directories directly. This provides lower-latency access to plots. -While you don't absolutely need port 8444 forwarded to your Chia node, it is advised that you do so that other peers may connect to you instead of you solely connecting to them. For the average at-home farmer it is advised you do not disable UPnP unless you absolutely know what you're doing or have another node on your local network already using the port and are planning to [Farm on Many Machines](https://docs.chia.net/reference-client/farming/farming-many-machines/). +To access a jail created by the TrueNAS web GUI, run `iocage console JAIL_NAME` from the TrueNAS host. Alternatively, install `openssh` in the jail and set up SSH key access. ---- +#### Known limitations -#### Installed and Ready to Farm! +- **VDF client:** `install.sh` sets `BUILD_VDF_CLIENT=N` on FreeBSD. This means the timelord cannot run on FreeBSD; farming (full node, farmer, harvester) is unaffected. +- **Compressed plots:** Community testing has reported `RuntimeError: Harvester does not support compressed plots` on FreeBSD. This issue is not fully resolved. If you encounter it, verify your `config.yaml` harvester settings and that the Chia version you are running supports the compression level of your plots. +- **GUI:** The Electron-based GUI is not supported on FreeBSD. Use the CLI. +- **UPnP:** If you need to disable UPnP (for example, if another node on your LAN already uses port 8444), run: -That's it! Provided the instructions were followed to the T, and the build is a fresh FreeBSD 11.3 or 11.4, either hardware or FreeNAS jailed, you should be good to go! Now go to town with `chia start node` or whatever floats your boat. - -More details can be found in the [Chia Introduction](https://docs.chia.net/chia-blockchain/introduction). +```bash +chia configure --enable-upnp false +``` -_**These instructions were tested with Chia 1.1.4 on OpenBSD/amd64 6.8, newer versions may exist**_ - -```sh -# install required packages -doas pkg_add git python-3.8.6 rust cmake gmake gmpxx - -# create a new user with the login class "daemon" so that it can use all -# available memory for plotting, then switch to that user -doas useradd -m -Ldaemon chia -doas -u chia ksh -l -cd - -# clone repos -git clone https://github.com/Chia-Network/chia-blockchain.git --branch latest -git clone https://github.com/Chia-Network/clvm_rs.git --branch 0.1.7 -git clone https://github.com/PyO3/maturin.git --branch v0.10.3 -git clone https://github.com/timkuijsten/chiavdf.git --branch openbsd # chiavdf/pull/71 - -export BUILD_VDF_CLIENT=N - -# create python virtual environment for Chia -cd chia-blockchain/ -python3 -m venv venv -. ./venv/bin/activate -pip install --upgrade pip - -cd ../chiavdf/ -pip install . - -cd ../maturin/ -# don't pass static compiler flags to the rust linker because that would cause -# a core dump, possibly because of resource limits -sed -i 's|cargo_args.extend(\["--", "-C", "link-arg=-s"\])|#cargo_args.extend(\["--", "-C", "link-arg=-s"\])|' setup.py -pip install . - -cd ../clvm_rs/ -maturin develop --release + -# XXX should be a more elegant way... -cp target/release/libclvm_rs.so ../chia-blockchain/clvm_rs.so + -cd ../chia-blockchain/ -# use our previous compile results -sed -i 's|"chiavdf==1.0.1"|"chiavdf==1.0.2.dev1"|' setup.py - -# use a hardcoded random secret so the software can run headless and without -# user intervention -sed -i 's|elif platform == "linux":|elif platform == "linux" or platform.startswith("openbsd"):|' chia/util/keychain.py -_keyring=$(dd status=none if=/dev/random bs=8 count=1 | od -H | tr -d ' ' | head -1 | cut -b8-25) -sed -i 's|keyring.keyring_key = "your keyring password"|keyring.keyring_key = "'"$_keyring"'"|' chia/util/keychain.py -unset _keyring - -sh install.sh +:::warning Community-Supported +OpenBSD is not officially supported by the Chia team. These instructions are community-contributed and may lag behind the latest release. +::: -# DONE, Chia is installed now, start using it by creating a config and keys +These instructions are for building Chia from source on **OpenBSD 7.x** (amd64). Chia requires **Python 3.10 or newer**. -chia init -chia keys generate +#### 先决条件 -# if you are going to setup port forwarding, disable upnp -chia configure --enable-upnp false +Install required system packages as root (or with `doas`): -chia start node wallet farmer harvester +```bash +doas pkg_add bash git python-3.11.10 rust cmake gmake gmp ``` -#### GUI Build / Usage +Adjust the Python version as appropriate for your OpenBSD release, as long as it is 3.10 or above. -_WARNING: the following has only been tested with Chia 1.0beta7 on OpenBSD/amd64 6.7_ - -The build instructions in the previous sections above must be completed successfully before attempting to build the GUI using the procedure below. - -_WARNING: Although the following steps have been used successfully, the resulting GUI will be run with an older version of electron than is recommended by the Chia Network team. This may result in unexpected problems._ - -#### Prerequisite package installation +#### Build -As root (or using doas / sudo), first install some additional OpenBSD packages required for GUI usage: +Create a dedicated user (optional but recommended) and switch to it: ```bash -pkg_add -i electron +doas useradd -m -Ldaemon chia +doas -u chia bash -l +cd ``` -#### Build +Clone the repository and run the install script: ```bash +git clone https://github.com/Chia-Network/chia-blockchain.git -b latest cd chia-blockchain -. ./activate -cd chia-blockchain-gui +sh install.sh +``` -# build / set up GUI -npm run build +`install.sh` detects OpenBSD via `uname`, sets `MAKE=gmake` and `BUILD_VDF_CLIENT=N`, creates a Python virtual environment, installs Poetry, and resolves all dependencies from `pyproject.toml`. -# Remove failed electron 8.2.5 install and fall back to the OpenBSD -# ports tree 8.2.0 electron, which currently (as of 6/10/2020) works. -# -# This may not continue to work in the future. A full solution to -# this requires official OpenBSD electron builds, provided by the -# electron project itself. +After installation completes: -rm -rf node_modules/electron +```bash +. ./activate +chia init +chia keys generate ``` -#### Launch GUI +#### Known limitations -The GUI can now be launched using the following commands: +- **VDF client:** `install.sh` sets `BUILD_VDF_CLIENT=N` on OpenBSD. The timelord cannot run on OpenBSD; farming is unaffected. +- **GUI:** The Electron-based GUI is not supported on OpenBSD. Use the CLI. +- **UPnP:** Disable if needed: ```bash -cd chia-blockchain -. ./activate - -cd chia-blockchain-gui -npm run electron +chia configure --enable-upnp false ``` @@ -1030,7 +805,7 @@ Note that the `chia-timelord` service runs the timelord coordinator service, but Sometimes stray daemons left over from previously running processes will cause strange bugs/errors when upgrading to a new version. Make sure all daemons and chia processes are killed before installing or upgrading. Make sure all daemons and chia processes are killed before installing or upgrading. -This is normally done by executing `chia stop -d all` from the upgrade example above.\ +This is normally done by executing `chia stop -d all` from the upgrade example above. But it doesn't hurt to double check using `ps -Af | grep chia` to make sure there are no chia processes left running. You may have to manually kill the chia daemon if an install and chia start was performed without first running `chia stop -d all` If all else fails, rebooting the machine and restarting the chia daemon/processes usually does the trick. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/testnets.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/testnets.md index bfea44262c5..c61964d08cb 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/testnets.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/testnets.md @@ -9,8 +9,8 @@ slug: /reference-client/install-and-setup/testnets Testnet 7 may remain active, but is no longer officially supported by Chia Network Inc. Testnets can be used to test the chia software with coins that have no real world value.\ -If you want to run the Chia blockchain mainnet, use the [mainnet installation](/reference-client/install-and-setup/installation) instructions. -If you want to run the Chia blockchain mainnet, use the [mainnet installation](/reference-client/install-and-setup/installation) instructions. +If you want to run the Chia blockchain mainnet, use the [mainnet installation](/installation) instructions. +If you want to run the Chia blockchain mainnet, use the [mainnet installation](/docs/reference-client/install-and-setup/installation.md) instructions. ::: @@ -20,7 +20,7 @@ If you want to run the Chia blockchain mainnet, use the [mainnet installation](/ ### 先决条件 -- Minimum Chia version is 2.1.0 [installed](/reference-client/install-and-setup/installation). +- Minimum Chia version is 2.1.0 [installed](/docs/reference-client/install-and-setup/installation.md). - All chia processes have been stopped with `chia stop all-d`. ### Configure Chia for testnet @@ -38,8 +38,6 @@ chia configure --testnet true ### (Opt) Download the official testnet db -This step is optional, but it will speed up syncing with the testnet - The process for using the official database snapshot torrent can be found here: https://docs.chia.net/reference-client/troubleshooting/node-syncing/#using-the-official-database-snapshot-torrent @@ -49,9 +47,6 @@ https://docs.chia.net/reference-client/troubleshooting/node-syncing/#using-the-o # Start your node chia start farmer -# Once the node has started, connect to the testnet introducer -chia peer full_node -a testnet10-node.chia.net:58444 - # Check sync status chia show -s` @@ -92,7 +87,7 @@ For the mainnet installation, we will stick with the default ports and CHIA_ROOT :::note (Optional) Install `yq` to make editing the yaml files easier [https://github.com/mikefarah/yq#install](https://github.com/mikefarah/yq#install).\ -Alternatively, you can manually edit the ports in `config.yaml`.\ +Alternatively, you can manually edit the ports in `config.yaml`. Alternatively, you can manually edit the ports in `config.yaml`. ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/timelord-install.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/timelord-install.md index 76ef17ea51b..221c1308601 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/timelord-install.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/timelord-install.md @@ -10,7 +10,7 @@ import TabItem from '@theme/TabItem'; **DO NOT** overclock ASICs, overclocking diminishes the life of the ASIC! ::: -Timelord architecture information can be found [here](/chia-blockchain/architecture/timelords).\ +Timelord architecture information can be found [here](/chia-blockchain/architecture/timelords). The hw_vdf_client parameter information can be found [here](/reference-client/cli-reference/asic-hwvdf-cli). --- @@ -18,7 +18,7 @@ The hw_vdf_client parameter information can be found [here](/reference-client/cl ## Timelord Requirements and Dependencies :::info -Due to restrictions on how [MSVC](https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B) handles 128 bit numbers and how Python relies upon MSVC, it is not possible to build and run Timelords of all types on Windows.\ +Due to restrictions on how [MSVC](https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B) handles 128 bit numbers and how Python relies upon MSVC, it is not possible to build and run Timelords of all types on Windows. Running a timelord on a farming machine will reduce the efficiency of the farmer and the timelord, for this reason it is recommended to have a dedicated machine for running timelords. ::: @@ -27,10 +27,8 @@ Requirements: 1. Software Timelord - With the release of ASIC timelords, software timelords will have a near impossible time competing. It is recommended to only run a software timelord for experimentation and learning purposes. - Dedicated host machine that is a modern gaming PC with minimum 6 fast cores and 8GB of RAM. - 2. Bluebox Timelord - Dedicated host machine that is a modern gaming PC with minimum 6 fast cores and 8GB of RAM. - 3. ASIC Timelord - The ASIC hardware - Dedicated host machine that is a modern gaming PC with minimum 6 fast cores and 8GB of RAM. @@ -90,7 +88,7 @@ The bluebox timelord must be installed from scratch following the instructions [ :::warning -**DO NOT** overclock ASICs, overclocking diminishes the life of the ASIC!\ +**DO NOT** overclock ASICs, overclocking diminishes the life of the ASIC! Detailed information about the hw_vdf_client parameters can be found [here](/reference-client/cli-reference/asic-hwvdf-cli). ::: @@ -105,9 +103,39 @@ Main Machine (ASIC 1) -------------------------- (chia node, timelord-only, and ASIC software) \_____ ASIC 3 (ASIC software only, IP set to main machine) ``` -For an ASIC cluster you will need to follow the below install steps on the main machine to include the chia node, timelord-only, and ASIC software processes are all being run on the main machine.\ +For an ASIC cluster you will need to follow the below install steps on the main machine to include the chia node, timelord-only, and ASIC software processes are all being run on the main machine. The additional ASIC hosts will only need the ASIC software installed (noted in the below install instructions). +When the timelord and ASIC software run on different machines (not localhost-only), update `~/.chia/mainnet/config/config.yaml` on the **timelord host** before starting services: + +- Set `timelord.vdf_server.host` to `0.0.0.0` so the timelord listens for remote `hw_vdf_client` TCP connections (default port `8000`). +- Add each ASIC machine's LAN IP to `timelord.vdf_clients.ip`. The timelord accepts only VDF clients whose source IP appears in this list. +- On each ASIC host, point `hw_vdf_client` at the timelord with `--ip ` (see [ASIC HW VDF CLI](/reference-client/cli-reference/asic-hwvdf-cli)). +- When using hardware VDF clients only, set `timelord_launcher.process_count` to `0` so the timelord launcher does not spawn local software `vdf_client` processes. + +Example `timelord` section (adjust IPs for your cluster): + +```yaml +timelord: + vdf_server: + host: 0.0.0.0 + port: 8000 + vdf_clients: + ip: + - 127.0.0.1 + - +``` + +Replace `` with the source IP of each ASIC machine. Add one entry per remote ASIC host. + +On each remote ASIC host: + +```bash +hw_vdf_client --ip 8000 1 +``` + +Use `1` for `N_VDFS` on cluster nodes that run a single engine; see the install steps below for localhost examples. + ```bash # Install packages sudo apt-get update @@ -138,7 +166,7 @@ chia start node timelord-only ### Installing a Timelord from Source :::info -On MacOS x86_64 and all Linux distributions, building a Timelord is as easy as running `chia start timelord &` in the virtual environment. You can also run `./vdf_bench square_asm 400000` once you've built Timelord to give you a sense of your optimal and unloaded ips. Each run of `vdf_bench` can be surprisingly variable and, in production, the actual ips you will obtain will usually be about 20% lower due to load of creating proofs. The default configuration for Timelords is good enough to just let you start it up. Set your log level to INFO and then grep for "Estimated IPS:" to get a sense of what actual ips your Timelord is achieving.\ +On MacOS x86_64 and all Linux distributions, building a Timelord is as easy as running `chia start timelord &` in the virtual environment. You can also run `./vdf_bench square_asm 400000` once you've built Timelord to give you a sense of your optimal and unloaded ips. Each run of `vdf_bench` can be surprisingly variable and, in production, the actual ips you will obtain will usually be about 20% lower due to load of creating proofs. The default configuration for Timelords is good enough to just let you start it up. Set your log level to INFO and then grep for "Estimated IPS:" to get a sense of what actual ips your Timelord is achieving. Detailed information about the hw_vdf_client parameters can be found [here](/reference-client/cli-reference/asic-hwvdf-cli). ::: @@ -209,7 +237,7 @@ chia start node timelord-only ## ASIC Timelord Systemd Setup -Below is an example of a systemd service file to run the ASIC hw vdf processes.\ +Below is an example of a systemd service file to run the ASIC hw vdf processes. NOTE - make sure to replace `USERNAME` with your system's username. ```bash diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-compression.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-compression.md index 6559db40710..1651b683545 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-compression.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-compression.md @@ -23,17 +23,17 @@ The next sections list three methods to determine the compression level that wil You can use the following table as a basic guide for choosing a compression level. You can use the following table as a basic guide for choosing a compression level. It assumes BladeBit CUDA was used to create K32 plots: -|
Level | Size
(GiB) | Relative
Size | Reward
Increase | Min Spec
Harvester | -| :---------- | :--------------- | :------------------ | :-------------------- | :------------------------ | -| C0 | 101.4 | 100% | 0% | Pi 4 | -| C1 | 87.5 | 86.3% | 15.9% | Pi 4 | -| C2 | 86.0 | 84.8% | 17.9% | Pi 4 | -| C3 | 84.5 | 83.3% | 20.0% | Pi 4 | -| C4 | 82.9 | 81.8% | 22.3% | Desktop CPU | -| C5 | 81.3 | 80.2% | 24.7% | Fast CPU | -| C6 | 79.6 | 78.5% | 27.4% | Fast CPU | -| C7 | 78.0 | 76.9% | 29.8% | GPU | -| C9 | 75.2 | 74.2% | 34.8% | GPU | +|
Level | Size
(GiB) | Relative
Size | Reward
Increase | Min Spec
Harvester | +| :---------- | :---------------------------------- | :-------------------- | :-------------------- | :------------------------ | +| C0 | 101.4 | 100% | 0% | Pi 4 | +| C1 | 87.5 | 86.3% | 15.9% | Pi 4 | +| C2 | 86.0 | 84.8% | 17.9% | Pi 4 | +| C3 | 84.5 | 83.3% | 20.0% | Pi 4 | +| C4 | 82.9 | 81.8% | 22.3% | Desktop CPU | +| C5 | 81.3 | 80.2% | 24.7% | Fast CPU | +| C6 | 79.6 | 78.5% | 27.4% | Fast CPU | +| C7 | 78.0 | 76.9% | 29.8% | GPU | +| C9 | 75.2 | 74.2% | 34.8% | GPU | The right column (Min Spec Harvester) shows the minimum type of computer required for harvesting at each compression level, where: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-hardware.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-hardware.md index 39a98c2216f..100e66d432d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-hardware.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-hardware.md @@ -67,13 +67,13 @@ The **BladeBit CUDA** plotter requires an NVIDIA GPU with CUDA capability 5.2 an The following table lists the general plotter types, along with their requirements, for creating k32 plots: -| Processor +
Storage | Plotter
Name(s) | Chia
Version | Comp.
Plots | Compute | Temp
Disk
(GB) | RAM
(GB) | Plot
Times
(min.) | -| :---------------------- | :--------------------------------------- | :----------------- | :-------------- | :------ | :--------------------- | :----------- | :------------------------ | -| **GPU +
RAM** | BladeBit CUDA | 2.0 | Yes | GPU | None | 256 | 1-3 | -| **GPU +
SSD** | BladeBit CUDA | 2.1 | Yes | GPU | 180 | 128 | 3-5 | -| **CPU +
RAM** | BladeBit RAM | 2.0 | Yes | CPU | None | 416 | 2-5 | -| **CPU +
SSD** | Bladebit Disk
madMAx
ChiaPoS | 2.0 | No | CPU | 512 | 4 | 15-60 | -| **CPU +
HDD** | Bladebit Disk
madMAx
ChiaPoS | 2.0 | No | CPU | 512 | 4 | > 60 | +| Processor +
Storage | Plotter
Name(s) | Chia
Version | Comp.
Plots | Compute | Temp
Disk
(GB) | RAM
(GB) | Plot
Times
(min.) | +| :---------------------- | :--------------------------------------- | :------------------ | :------------------------------ | :------ | :---------------------------------------- | :------------------------------ | :----------------------------------------------------------- | +| **GPU +
RAM** | BladeBit CUDA | 2.0 | Yes | GPU | None | 256 | 1-3 | +| **GPU +
SSD** | BladeBit CUDA | 2.1 | Yes | GPU | 180 | 128 | 3-5 | +| **CPU +
RAM** | BladeBit RAM | 2.0 | Yes | CPU | None | 416 | 2-5 | +| **CPU +
SSD** | Bladebit Disk
madMAx
ChiaPoS | 2.0 | No | CPU | 512 | 4 | 15-60 | +| **CPU +
HDD** | Bladebit Disk
madMAx
ChiaPoS | 2.0 | No | CPU | 512 | 4 | > 60 | :::note @@ -127,17 +127,25 @@ Unfortunately, we may not be able to offer support if your machine does not fall Operating Systems -- Ubuntu 20.04.6 LTS -- Ubuntu 22.04.02 LTS -- Ubuntu 23.04 -- RHEL 7.4 -- RHEL 8.7 -- RHEL 9.1 -- Windows 10 version 22H2 -- Windows 11 version 21H2 -- Windows 11 version 22H2 -- Windows Server 2022 -- Windows Server 2019 (version 1809) +[Ubuntu](https://ubuntu.com/about/release-cycle) + +- Ubuntu 22.04 LTS (until May 2027) +- Ubuntu 24.04 LTS (until May 2029) +- Ubuntu 26.04 LTS (until May 2031) + +[Red Hat Enterprise Linux](https://access.redhat.com/support/policy/updates/errata_legacy#Planning_Guides) + +- RHEL 8.10 (until 3Q 2029) +- RHEL 9.10 (until 2Q 2032) +- RHEL 10.3 - 10.9 (until 2027-30) +- RHEL 10.10 (until 2Q 2035) + +[Windows](https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions) + +- Windows 11 version 25H2 (until 12 Oct 2027) +- Windows 11 version 26H1 (until 14 Mar 2028) +- Windows Server 2022 (until 14 Oct 2031) +- Windows Server 2025 (Until 14 Nov 2034) Systems diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-how-to.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-how-to.md index 195b3d70106..dac88d90829 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-how-to.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-how-to.md @@ -15,7 +15,7 @@ To create plots, you must have: This page will give a basic overview of how to obtain these values. For a detailed description, see the [Beginner's Guide to Farming](/reference-client/getting-started/farming-guide). -If you already have a wallet with a plot NFT, feel free to skip to the section for [CLI Plotting](#cli-plotting) or [GUI Plotting](#图形用户界面gui生成地块). +If you already have a wallet with a plot NFT, feel free to skip to the section for [CLI Plotting](#cli-plotting) or [GUI Plotting](#gui-plotting). ## Public Keys diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-setup.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-setup.md index cc4aeabee0f..799b0eadae2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-setup.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-setup.md @@ -33,14 +33,14 @@ One thing to keep in mind is that a farming computer only cares about the comple With that in mind, the following table will give you an idea of what compression level to use, given your farming computer. This assumes you will use the Bladbit plotter that comes prepackaged with Chia installations: This assumes you will use the Bladbit plotter that comes prepackaged with Chia installations: -|
Level | Size
(GiB) | Relative
Size | Reward
Increase | Farm
With | -| :---------- | :--------------- | :------------------ | :-------------------- | :--------------- | -| C0 | 101.4 | 100% | 0% | Pi 4 | -| C1 | 87.5 | 86.3% | 15.9% | Pi 4 | -| C2 | 86.0 | 84.8% | 17.9% | Pi 4 | -| C3 | 84.5 | 83.3% | 20.0% | Pi 4 | -| C4 | 82.9 | 81.8% | 22.3% | Pi 4 | -| C5 | 81.3 | 80.2% | 24.7% | Fast CPU | -| C6 | 79.6 | 78.5% | 27.4% | Fast CPU | -| C7 | 78.0 | 76.9% | 29.8% | GPU | -| C9 | 75.2 | 74.2% | 34.8% | GPU | +|
Level | Size
(GiB) | Relative
Size | Reward
Increase | Farm
With | +| :---------- | :---------------------------------- | :-------------------- | :-------------------- | :--------------- | +| C0 | 101.4 | 100% | 0% | Pi 4 | +| C1 | 87.5 | 86.3% | 15.9% | Pi 4 | +| C2 | 86.0 | 84.8% | 17.9% | Pi 4 | +| C3 | 84.5 | 83.3% | 20.0% | Pi 4 | +| C4 | 82.9 | 81.8% | 22.3% | Pi 4 | +| C5 | 81.3 | 80.2% | 24.7% | Fast CPU | +| C6 | 79.6 | 78.5% | 27.4% | Fast CPU | +| C7 | 78.0 | 76.9% | 29.8% | GPU | +| C9 | 75.2 | 74.2% | 34.8% | GPU | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/ssd-endurance.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/ssd-endurance.md index 6dc38ed226c..554cbd4f73b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/ssd-endurance.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/ssd-endurance.md @@ -15,14 +15,14 @@ The fastest plot creation is done completely in memory, but requires a server wi 衡量SSD耐久性的度量标准是以一定的工作负载为基础的写入总量，即TBW。 一般来说，工作负载是根据JEDEC组织的JESD219工作负载来定义的。 An SSD can still plot well beyond meeting its rated TBW limit, because UBER can be measured (when seeing host errors) and retention is not required (Chia plotting requires temporary or ephemeral storage). -| 地块生成程序 | 缓存/内存磁盘 | K=32的写入次数 | -| ------------------- | ------------- | -------------- | -| Chiapos beta (2020) | 0 | 1.8 TBW | -| Chiapos 2021 | 0 | 1.4 TBW | -| madMAx Chia_plot | 0 | 1.43 TBW | -| madMAx Chia_plot | 110G | 0.396 TBW | -| Bladebit Disk | 0 | 1.225 TBW | -| Bladebit Disk | \>99G | 0.381 TBW | +| 地块生成程序 | 缓存/内存磁盘 | K=32的写入次数 | +| -------------------------------------- | ------- | ------------------------- | +| Chiapos beta (2020) | 0 | 1.8 TBW | +| Chiapos 2021 | 0 | 1.4 TBW | +| madMAx Chia_plot | 0 | 1.43 TBW | +| madMAx Chia_plot | 110G | 0.396 TBW | +| Bladebit Disk | 0 | 1.225 TBW | +| Bladebit Disk | \>99G | 0.381 TBW | Consumer NVMe SSDs are generally not recommended due to their lower endurance, and they often employ caching algorithms to faster media (SLC, or single level cell) for great bursty performance. They do not perform well under heavy workload sustained I/O. 虽然有一些高性能的消费级NVMe SSD可以提供出色的生成地块性能，但较低的TBW将导致更快的磨损。 They do not perform well under heavy workload sustained I/O. 虽然有一些高性能的消费级NVMe SSD可以提供出色的生成地块性能，但较低的TBW将导致更快的磨损。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/daemon-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/daemon-rpc.md index 6adbfe84b37..42b3654bda2 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/daemon-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/daemon-rpc.md @@ -7,10 +7,9 @@ slug: /reference-client/rpc-reference/daemon-rpc import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -This document provides a comprehensive reference to Chia's Daemon RPC API. +This document provides a comprehensive reference to Chia's Daemon RPC API over HTTPS/WebSockets (`chia/daemon/server.py`). Command names come from the daemon's command mapping (see `get_routes`). `chia rpc daemon` wraps these for local CLI use. -
- Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -51,12 +50,11 @@ values={[ Be sure to replace `username` with your actual username for both the `.crt` and `.key` file.```powershell wscat -n --cert C:\Users\ - -```` +``` ```powershell wscat -n --cert C:\Users\\.chia\mainnet\config\ssl\daemon\private_daemon.crt --key C:\Users\\.chia\mainnet\config\ssl\daemon\private_daemon.key -c wss://0.0.0.0:55400 -```` +``` @@ -141,8 +139,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon exit @@ -168,7 +165,7 @@ Response: ### `get_routes` -Functionality: List all available Daemon RPC routes +Functionality: List all websocket command names exposed by the daemon (same set as `get_command_mapping()` in the daemon server). Usage: chia rpc daemon [OPTIONS] get_routes [REQUEST] @@ -181,8 +178,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon get_routes @@ -193,26 +189,27 @@ Response: ```json { "routes": [ - "start_service", - "start_plotting", - "stop_plotting", - "stop_service", - "is_running", - "running_services", - "is_keyring_locked", - "keyring_status", - "unlock_keyring", - "validate_keyring_passphrase", - "set_keyring_passphrase", - "remove_keyring_passphrase", "exit", - "register_service", - "get_status", - "get_version", + "get_keys_for_plotting", + "get_network_info", "get_plotters", "get_routes", + "get_status", + "get_version", "get_wallet_addresses", - "get_keys_for_plotting" + "is_keyring_locked", + "is_running", + "keyring_status", + "register_service", + "remove_keyring_passphrase", + "running_services", + "set_keyring_passphrase", + "start_plotting", + "start_service", + "stop_plotting", + "stop_service", + "unlock_keyring", + "validate_keyring_passphrase" ], "success": true } @@ -237,8 +234,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon get_status @@ -272,8 +268,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon get_version @@ -307,15 +302,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------------------- | :------ | :------- | :------------------------------------------------------------------------------------------ | -| fingerprints | NUMBER | False | List the keys for the specified fingerprints only [Default: list keys for all fingerprints] | -| index | NUMBER | False | Starting index for addresses to list [Default: 0] | -| count | NUMBER | False | Number of addresses to list [Default: 1] | +| Flag | Type | Required | Description | +| :---------------------------------------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| fingerprints | NUMBER | False | List the keys for the specified fingerprints only [Default: list keys for all fingerprints] | +| index | NUMBER | False | Starting index for addresses to list [Default: 0] | +| count | NUMBER | False | Number of addresses to list [Default: 1] | | non_observer_derivation | BOOLEAN | False | Set to `True` to use non-observer derivation [Default: `False`] | -
-Example 1: default +
Example 1: default The default behavior is to show the first address for all fingerprints. @@ -347,8 +341,7 @@ Response:
-
-Example 2: custom +
Example 2: custom Show two addresses from one fingerprint, starting at index 100: @@ -395,8 +388,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon is_keyring_locked @@ -430,12 +422,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------ | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------ | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | service | STRING | TRUE | The service to query; valid examples include, but are not limited to, "chia_data_layer", "chia_data_layer_http", "chia_wallet", "chia_full_node", "chia_harvester", "chia_farmer", "chia_introducer", "chia_timelord", "chia_timelord_launcher", "chia_full_node_simulator", "chia_seeder", "chia_crawler", "wallet_ui" | -
-Example +
Example Query whether the Chia wallet service is running: @@ -472,8 +463,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon keyring_status @@ -519,8 +509,7 @@ Request Parameters: | :------ | :----- | :------- | :---------------------------------- | | service | STRING | TRUE | The name of the service to register | -
-Example +
Example ```json chia rpc daemon register_service '{"service": "chia_wallet"}' @@ -553,12 +542,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------------- | :----- | :------- | :-------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :-------------------------------------- | :----- | :------- | :-------------------------------------------------------------------------------- | | current_passphrase | STRING | True | The current passphrase; if entered correctly, it will be removed from the keyring | -
-Example 1 +
Example 1 Remove the real passphrase: @@ -577,8 +565,7 @@ Response:
-
-Example 2 +
Example 2 Attempt to remove a fake passphrase: @@ -614,8 +601,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon running_services @@ -655,15 +641,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| current_passphrase | STRING | True | The current passphrase (if none, use an empty string) | -| new_passphrase | STRING | True | The new passphrase, by default must be at least 8 characters long | -| passphrase_hint | STRING | False | The new passphrase hint, if one is desired | +| Flag | Type | Required | Description | +| :-------------------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| current_passphrase | STRING | True | The current passphrase (if none, use an empty string) | +| new_passphrase | STRING | True | The new passphrase, by default must be at least 8 characters long | +| passphrase_hint | STRING | False | The new passphrase hint, if one is desired | | save_passphrase | BOOLEAN | False | Whether to save the new passphrase to your system's secure credential store, thus allowing Chia to access your keys without prompting for your passphrase. [Default: False] [Default: False] | -
-Example +
Example ```json chia rpc daemon set_keyring_passphrase '{"current_passphrase": "", "new_passphrase": "12345678", "passphrase_hint": "It has eight characters"}' @@ -697,13 +682,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------ | :------ | :------- | :------------------------------------------------------------ | -| service | STRING | True | The service to start | +| Flag | Type | Required | Description | +| :------ | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | +| service | STRING | True | The service to start | | testing | Boolean | False | If `true`, then test the start_service RPC [Default: `false`] | -
-Example +
Example Start the wallet service: @@ -744,8 +728,7 @@ Request Parameters: | :------ | :----- | :------- | :------------------ | | service | STRING | True | The service to stop | -
-Example +
Example Stop the wallet service: @@ -781,12 +764,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--- | :----- | :------- | :-------------------------------- | +| Flag | Type | Required | Description | +| :--- | :----- | :------- | :---------------------------------------------------------------------------------------------------- | | key | STRING | False | The key to unlock [Default: None] | -
-Example +
Example ```json chia rpc daemon unlock_keyring '{"key": "12345678"}' @@ -824,8 +806,7 @@ Request Parameters: | :--- | :----- | :------- | :--------------- | | key | STRING | True | The key to check | -
-Example +
Example ```json chia rpc daemon validate_keyring_passphrase '{"key": "12345678"}' @@ -861,12 +842,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | :----- | :------- | :------------------------------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :----------- | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | | fingerprints | NUMBER | False | List the keys for the specified fingerprints only [Default: list keys for all fingerprints] | -
-Example +
Example Show the keys for one specific fingerprint: @@ -907,8 +887,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon get_plotters @@ -960,23 +939,23 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :------ | :------- | :--------------------------------------------------------------------- | -| service | STRING | True | The plotting service to use | -| plotter | STRING | False | The plotter to use [Default: "chiapos"] | -| delay | INTEGER | False | The number of seconds to delay before starting to plot [Default: 0] | -| parallel | BOOLEAN | False | Set to create multiple plots in parallel [Default: false] | -| k | INTEGER | True | The k-size of the plot to create | -| overrideK | BOOLEAN | True | Set to `true` to create a plot smaller than k-32 | -| r | INTEGER | True | The number of threads to use for creating the plot(s) | -| b | INTEGER | True | Size of the buffer, in MB | -| u | INTEGER | True | Number of buckets | -| e | BOOLEAN | True | Set to `true` to disable bitfield | -| t | STRING | True | The temporary directory where the plot will be created | -| d | STRING | True | The destination where the plot will be moved after it has been created | -| x | BOOLEAN | True | Set to `true` to skip moving the plot after it has been created | -| n | INTEGER | False | The number of plots to create [Default: 1] | -| queue | STRING | False | The type of plotting queue [Default: "default"] | +| Flag | Type | Required | Description | +| :-------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------- | +| service | STRING | True | The plotting service to use | +| plotter | STRING | False | The plotter to use [Default: "chiapos"] | +| delay | INTEGER | False | The number of seconds to delay before starting to plot [Default: 0] | +| parallel | BOOLEAN | False | Set to create multiple plots in parallel [Default: false] | +| k | INTEGER | True | The k-size of the plot to create | +| overrideK | BOOLEAN | True | Set to `true` to create a plot smaller than k-32 | +| r | INTEGER | True | The number of threads to use for creating the plot(s) | +| b | INTEGER | True | Size of the buffer, in MB | +| u | INTEGER | True | Number of buckets | +| e | BOOLEAN | True | Set to `true` to disable bitfield | +| t | STRING | True | The temporary directory where the plot will be created | +| d | STRING | True | The destination where the plot will be moved after it has been created | +| x | BOOLEAN | True | Set to `true` to skip moving the plot after it has been created | +| n | INTEGER | False | The number of plots to create [Default: 1] | +| queue | STRING | False | The type of plotting queue [Default: "default"] | --- @@ -999,8 +978,7 @@ Request Parameters: | :--- | :----- | :------- | :---------------------------------- | | id | STRING | True | The ID of the plot to stop creating | -
-Example +
Example ```json chia rpc daemon stop_plotting '{"id": "68607640-4dfc-4946-9a0d-186beec3b8f8"}' @@ -1035,9 +1013,9 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :----- | :------- | :----------------------------------------------- | -| mnemonic | STRING | True | The mnemonic word list (see below for details) | +| Flag | Type | Required | Description | +| :------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------- | +| mnemonic | STRING | True | The mnemonic word list (see below for details) | | label | STRING | False | The label to assign for this key [Default: None] | Requirements for the mnemonic word list: @@ -1049,8 +1027,7 @@ Requirements for the mnemonic word list: - Each word must be in the [BIP-39 word list](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt) - The mnemonic must form a valid private key -
-Example 1: success +
Example 1: success The following example adheres to each of the above rules: @@ -1069,8 +1046,7 @@ Response:
-
-Example 2: invalid length +
Example 2: invalid length The mnemonic must be either 12 or 24 words. Else, an error will be returned. For example: Else, an error will be returned. For example: @@ -1089,8 +1065,7 @@ Response:
-
-Example 3: invalid word +
Example 3: invalid word Each word must be in the BIP-39 word list. Else, an error will be returned. For example: Else, an error will be returned. For example: @@ -1109,8 +1084,7 @@ Response:
-
-Example 4: Invalid word order +
Example 4: Invalid word order If the mnemonic is 12 or 24 words, and each word is in the BIP-39 word list, the final check is that the words form a valid mnemonic phrase. For example: For example: @@ -1146,8 +1120,8 @@ Options: Request Parameters: -| Flag | Type | Required | -| :-------- | :----- | :------- | +| Flag | Type | Required | +| :----------------------------- | :----- | :------- | | root_path | STRING | True | --- @@ -1198,8 +1172,7 @@ Request Parameters: Note that this command will fail if the OS key ring is locked. -
-Example +
Example ```json chia rpc daemon delete_key_by_fingerprint '{"fingerprint": 1542304282}' @@ -1252,8 +1225,7 @@ Request Parameters: None Note that this command will fail if the OS key ring is locked. -
-Example +
Example ```json chia rpc daemon get_all_private_keys @@ -1298,8 +1270,7 @@ Request Parameters: None Note that this command will fail if the OS key ring is locked. -
-Example +
Example ```json chia rpc daemon get_first_private_key @@ -1334,12 +1305,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :------ | :------- | :------------------------------------------------------ | +| Flag | Type | Required | Description | +| :---------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------- | | fingerprint | INTEGER | False | The fingerprint to look up [Default: get the first key] | -
-Example +
Example ```json chia rpc daemon get_key_for_fingerprint '{"fingerprint": 1542304282}' @@ -1374,13 +1344,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :------------------------------------------------------------------ | -| fingerprint | INTEGER | True | The fingerprint whose key you want to look up | +| Flag | Type | Required | Description | +| :----------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------- | +| fingerprint | INTEGER | True | The fingerprint whose key you want to look up | | include_secrets | BOOLEAN | False | Set to `true` to include secrets in the response [Default: `false`] | -
-Example +
Example ```json chia rpc daemon get_key '{"fingerprint": 1542304282}' @@ -1419,12 +1388,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :----------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------- | | include_secrets | BOOLEAN | False | Set to `true` to include secrets in the response [Default: `false`] | -
-Example +
Example ```json chia rpc daemon get_keys @@ -1469,8 +1437,7 @@ Request Parameters: | :---------- | :------ | :------- | :-------------------------------------------- | | fingerprint | INTEGER | True | The fingerprint whose key you want to look up | -
-Example +
Example ```json chia rpc daemon get_public_key '{"fingerprint": 1542304282}' @@ -1508,8 +1475,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc daemon get_public_keys @@ -1554,8 +1520,7 @@ Request Parameters: | fingerprint | INTEGER | True | The fingerprint whose label you want to set | | label | STRING | True | The new label | -
-Example +
Example ```json chia rpc daemon set_label '{"fingerprint": 1542304282, "label": "New Label"}' @@ -1611,8 +1576,7 @@ Request Parameters: | :---------- | :------ | :------- | :--------------------------------------------- | | fingerprint | INTEGER | True | The fingerprint whose label you want to delete | -
-Example +
Example ```json chia rpc daemon delete_label '{"fingerprint": 1542304282}' diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/dao-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/dao-rpc.md index 7062cc9f228..043fdb2ad79 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/dao-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/dao-rpc.md @@ -15,14 +15,19 @@ Prior to using the DAO alpha primitive, be sure to read the [list of known issue ::: +:::info Removed from the reference client in Chia 2.5.3 + +The proof-of-concept DAO wallet and all `dao_*` wallet RPCs were removed in [Chia blockchain 2.5.3](https://github.com/Chia-Network/chia-blockchain/blob/main/CHANGELOG.md#253-chia-blockchain-2025-03-25) (March 2025). Current releases do not register these commands on `chia rpc wallet get_routes`. The reference below is historical only. + +::: + :::note -The RPC to create a new DAO is a **wallet RPC** called [create_new_wallet](/reference-client/rpc-reference/wallet-rpc/#create_new_wallet), therefore it is not documented here. See Example 7 for details of how this command's options can be used. +Creating a DAO wallet historically used the [create_new_wallet](/reference-client/rpc-reference/wallet-rpc/#create_new_wallet) wallet RPC (see Example 7). That flow applied to clients that still shipped the DAO wallet; it is not available on supported releases after the removal above. ::: -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -40,7 +45,38 @@ chia rpc wallet dao_get_treasury_balance '{\"wallet_id\": 2}'
-## Reference +The sections below document **wallet** RPCs (`chia rpc wallet`) from when the DAO wallet still existed. On current releases, start from [Wallet RPC](/reference-client/rpc-reference/wallet-rpc); `chia rpc wallet get_routes` does not expose `dao_*` commands after the removal noted above. + +### `get_routes` + +Functionality: List every path on the wallet RPC server (`WalletRpcApi` plus shared `RpcServer` routes). + +Usage: chia rpc wallet [OPTIONS] get_routes [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_routes +``` + +Response: + +The canonical sorted list is on [Wallet RPC — get_routes](/reference-client/rpc-reference/wallet-rpc#get_routes). + +
+ +--- + +## Historical reference (pre–DAO wallet removal) ### `dao_add_funds_to_treasury` @@ -57,15 +93,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------------- | ------ | :------- | :------------------------------------------------------------------------------------ | -| wallet_id | NUMBER | True | The DAO wallet to which to add funds. Must be of type `DAOWallet` | -| funding_wallet_id | NUMBER | True | The wallet from which the funds will come. Must be of type `STANDARD_WALLET` or `CAT` | -| amount | NUMBER | True | The amount of funds to add, in mojos | -| fee | NUMBER | False | An optional blockchain fee, in mojos \[Default: 0] | +| Flag | Type | Required | Description | +| :---------------------------------------------------------- | ------ | :------- | :---------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The DAO wallet to which to add funds. Must be of type `DAOWallet` | +| funding_wallet_id | NUMBER | True | The wallet from which the funds will come. Must be of type `STANDARD_WALLET` or `CAT` | +| amount | NUMBER | True | The amount of funds to add, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos \[Default: 0] | -
-Example +
Example Start by showing the treasury's current balance: @@ -200,10 +235,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | ------ | :------- | :-------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :-------------------------------- | ------ | :------- | :------------------------------------------------------------------------------------------------------------ | | wallet_id | NUMBER | True | The ID of the wallet whose filter level you would like to adjust. Must be of type `DAOWallet` | -| filter_level | NUMBER | True | The new filter level. Propos with fewer votes than this will not be shown. | +| filter_level | NUMBER | True | The new filter level. Propos with fewer votes than this will not be shown. | --- @@ -222,11 +257,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | ------ | :------- | :------------------------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :------------------------------- | ------ | :------- | :---------------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the wallet that contains the proposal to close. Must be of type `DAOWallet` | -| proposal_id | STRING | True | The ID of the proposal to close | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| proposal_id | STRING | True | The ID of the proposal to close | +| fee | NUMBER | False | An optional blockchain fee, in mojos | --- @@ -245,12 +280,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | ------ | :------- | :--------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------------- | ------ | :------- | :------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The DAO wallet to use for creating the proposal. Must be of type `DAOWallet` | -| proposal_type | STRING | True | Must be either `spend`, `update`, or `mint` | -| vote_amount | NUMBER | False | The number of votes to add | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| proposal_type | STRING | True | Must be either `spend`, `update`, or `mint` | +| vote_amount | NUMBER | False | The number of votes to add | +| fee | NUMBER | False | An optional blockchain fee, in mojos | Proposal Types: @@ -264,38 +299,38 @@ If the proposal is of type `spend`, then `additions` may optionally be included `additions` is a list with the following elements: -| Element | Required | Description | -| :---------- | :------- | :-------------------------------------------------- | +| Element | Required | Description | +| :------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | | asset_id | False | The asset_id of the funds to spend \[Default: None] | -| puzzle_hash | True | The puzzle_hash of the funds to spend | -| amount | True | The amount, in mojos, to spend | +| puzzle_hash | True | The puzzle_hash of the funds to spend | +| amount | True | The amount, in mojos, to spend | If the proposal is of type `spend`, and `additions` is not included, then the following **request parameters** will be used instead: -| Parameter | Required | Description | -| :------------ | :------- | :-------------------------------------------------- | +| Parameter | Required | Description | +| :--------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | | asset_id | False | The asset_id of the funds to spend \[Default: None] | -| inner_address | True | The inner address of the funds to spend | -| amount | True | The amount, in mojos, to spend | +| inner_address | True | The inner address of the funds to spend | +| amount | True | The amount, in mojos, to spend | If the proposal is of type `update`, then the **request parameter** `new_dao_rules` is required. `new_dao_rules` is a list of optional rules to update. If a rule is missing from this list, it will not be updated: -| Rule | Required | Description | -| :------------------- | :------- | :------------------------------------------------------------------------------------------------- | -| proposal_timelock | False | The new minimum number of blocks before a proposal can close | -| soft_close_length | False | The number of blocks a proposal must remain unspent before closing | -| attendance_required | False | The minimum number of votes a proposal must receive to be accepted | -| pass_percentage | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 | -| self_destruct_length | False | The number of blocks required before a proposal can be automatically removed | -| oracle_spend_delay | False | The number of blocks required between oracle spends of the treasury | +| Rule | Required | Description | +| :------------------------------------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------- | +| proposal_timelock | False | The new minimum number of blocks before a proposal can close | +| soft_close_length | False | The number of blocks a proposal must remain unspent before closing | +| attendance_required | False | The minimum number of votes a proposal must receive to be accepted | +| pass_percentage | False | The percentage of 'yes' votes in basis points a proposal must receive to be accepted. 100% = 10000 | +| self_destruct_length | False | The number of blocks required before a proposal can be automatically removed | +| oracle_spend_delay | False | The number of blocks required between oracle spends of the treasury | If the proposal is of type `mint`, then the following **request parameters** are required: -| Parameter | Required | Description | -| :----------------- | :------- | :------------------------------------------- | -| amount | True | The number of DAO CATs to mint | +| Parameter | Required | Description | +| :----------------------------------------------------------- | :------- | :------------------------------------------- | +| amount | True | The number of DAO CATs to mint | | cat_target_address | True | The xch address that will receive the tokens | --- @@ -315,11 +350,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :----------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :--------------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the wallet from which to release the DAO CATs. Must be of type `DAOWallet` | -| coins | STRING | False | A list of coin IDs to release | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| coins | STRING | False | A list of coin IDs to release | +| fee | NUMBER | False | An optional blockchain fee, in mojos | --- @@ -338,10 +373,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :----------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :--------------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the wallet from which to release the DAO CATs. Must be of type `DAOWallet` | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | --- @@ -360,12 +395,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :------------------------------------------------------------------- | | wallet_id | NUMBER | True | The wallet from which to list proposals; must be of type `DAOWallet` | -
-Example +
Example Request: @@ -424,13 +458,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | ------ | :------- | :---------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | ------ | :------- | :-------------------------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the DAO wallet from which to look up a proposal's status. Must be of type `DAOWallet` | -| proposal_id | STRING | True | The ID of the proposal whose status you would like to show | +| proposal_id | STRING | True | The ID of the proposal whose status you would like to show | -
-Example +
Example First, get all proposals, which will show their IDs: @@ -499,12 +532,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :----------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :--------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The DAO wallet from which to show the rules. Must be of type `DAOWallet` | -
-Example +
Example Request: @@ -548,12 +580,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :--------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :------------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The DAO whose treasury balance you would like to show. Must be of type `DAOWallet` | -
-Example +
Example Request: @@ -591,12 +622,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :------------------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :---------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The DAO wallet whose ID you would like to retrieve. Must be of type `DAOWallet` | -
-Example +
Example Request: @@ -627,13 +657,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | ------ | :------- | :------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | ------ | :------- | :----------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The DAO wallet where the proposal lives. Must be of type `DAOWallet` | -| proposal_id | STRING | True | The ID of the proposal whose details you would like to show | +| proposal_id | STRING | True | The ID of the proposal whose details you would like to show | -
-Example +
Example ```bash chia rpc wallet dao_parse_proposal '{"wallet_id": 2, "proposal_id": "0x7b10351e130317fc3f7b6d5e50aeb3b8d63db7545ef5e80836913f5741cdbb22"}' @@ -685,10 +714,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | ------ | :------- | :---------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | ------ | :------- | :-------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the wallet from which to lock DAO CATs. Must be of type `DAOWallet` | -| amount | NUMBEr | True | The amount of CATs to lock for voting | +| amount | NUMBEr | True | The amount of CATs to lock for voting | --- @@ -707,12 +736,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | ------- | :------- | :------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The ID of the wallet where the proposal lives. Must be of type `DAOWallet` | -| proposal_id | STRING | True | The ID of the proposal on which you would like to vote | -| vote_amount | NUMBER | False | The number of DAO CATs to use for this vote \[Default: None] | -| is_yes_vote | BOOLEAN | True | A boolean indicating whether this vote is "yes" (`true`) or "no" (`false`) | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| Flag | Type | Required | Description | +| :---------------------------------------------------- | ------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The ID of the wallet where the proposal lives. Must be of type `DAOWallet` | +| proposal_id | STRING | True | The ID of the proposal on which you would like to vote | +| vote_amount | NUMBER | False | The number of DAO CATs to use for this vote \[Default: None] | +| is_yes_vote | BOOLEAN | True | A boolean indicating whether this vote is "yes" (`true`) or "no" (`false`) | +| fee | NUMBER | False | An optional blockchain fee, in mojos | --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/datalayer-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/datalayer-rpc.md index 94c21b92c73..c5508b209c8 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/datalayer-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/datalayer-rpc.md @@ -7,8 +7,7 @@ slug: /reference-client/rpc-reference/datalayer-rpc import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -28,10 +27,12 @@ chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}' ## Intro -This page includes a comprehensive list of Chia's DataLayer RPC API. +This page includes a comprehensive list of Chia's DataLayer RPC API. Routes implemented on `DataLayerRpcApi` are merged with the shared HTTP routes from `RpcServer` (connections, network info, version, logging, health checks, and graceful shutdown). We also have documented the [DataLayer CLI](/reference-client/cli-reference/datalayer-cli) commands for interacting with the DataLayer. +Chia **strongly recommends** using DataLayer with a **trusted full node fully synced** to chain tip for production and security-sensitive workloads. To reach a synced state faster than syncing from genesis, use an official [database checkpoint](https://www.chia.net/downloads/#database-checkpoint) and follow [Using the Official Database Snapshot Torrent](/reference-client/troubleshooting/node-syncing#using-the-official-database-snapshot-torrent). If the full node cannot run on the same machine as DataLayer, point this client at a synced full node **you own and operate** elsewhere and configure [trusted peers](/chia-blockchain/resources/faq#what-are-trusted-peers-and-how-do-i-add-them); **only** add nodes you control—never mark community or third-party hosts as trusted. + By default, the DataLayer RPC API is exposed on port 8562. This is configured in `~/.chia/mainnet/config/config.yaml` under `data_layer:rpc_port`. This port must not be exposed publicly for security concerns. Commands that modify the blockchain include an optional fee. This fee can be specified in two ways: @@ -61,15 +62,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------- | -| id | TEXT | True | The hexadecimal ID of the store to mirror | -| urls | TEXT | True | A list of URLs where the mirror will reside | +| Flag | Type | Required | Description | +| :----- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------- | +| id | TEXT | True | The hexadecimal ID of the store to mirror | +| urls | TEXT | True | A list of URLs where the mirror will reside | | amount | INTEGER | True | The number of mojos to spend to create the mirror. In theory, mirrors with a higher `amount` will be prioritized | -| fee | TEXT | False | Set the fee for the transaction, in mojos | +| fee | TEXT | False | Set the fee for the transaction, in mojos | -
-Example +
Example Create one mirror with multiple URLs: @@ -106,14 +106,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ids | TEXT | False | A list of hexadecimal store IDs to restore (default: all subscribed stores) | | override | BOOLEAN | False | If `True`, will overwrite files that already exist (default: `False`) | | foldername | TEXT | False | The name of the folder where the files to be restored are located (default: `~/.chia/mainnet/data_layer/db/server_files_location_`) | -
-Example +
Example For this example, there is one owned store: @@ -181,12 +180,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | -| id | TEXT | True | The hexadecimal store ID | -| changelist | TEXT | True | A string representing the changelist | +| Flag | Type | Required | Description | +| :-------------------------------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| id | TEXT | True | The hexadecimal store ID | +| changelist | TEXT | True | A string representing the changelist | | submit_on_chain | BOOLEAN | False | Specify whether to submit the update to the blockchain (`True`), or to store it locally (`False`). Default: `True` (See info box for details) | -| fee | TEXT | False | Set the fee for the transaction, in mojos | +| fee | TEXT | False | Set the fee for the transaction, in mojos | :::info @@ -207,8 +206,7 @@ A few notes on the `changelist` option: The following examples will show the basic functionality of this command. -
-Example 1 -- Insert a single key/value pair +
Example 1 -- Insert a single key/value pair ```json chia rpc data_layer batch_update '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "changelist":[{"action":"insert", "key":"0003", "value":"abc123"}]}' @@ -225,8 +223,7 @@ Response:
-
-Example 2 -- Delete a single key +
Example 2 -- Delete a single key ```json chia rpc data_layer batch_update '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "changelist":[{"action":"delete", "key":"0003"}]}' @@ -243,8 +240,7 @@ Response:
-
-Example 3 -- Insert two keys +
Example 3 -- Insert two keys ```json chia rpc data_layer batch_update '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "changelist":[{"action":"insert", "key":"0x0004", "value":"123abc"},{"action":"insert", "key":"0005", "value":"0xbeadfeed"}]}' @@ -289,8 +285,7 @@ Response:
-
-Example 4 -- Show that you may not overwrite an existing key +
Example 4 -- Show that you may not overwrite an existing key ```json chia rpc data_layer batch_update '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "changelist":[{"action":"insert", "key":"0002", "value":"0123456789abcdef"}]}' @@ -304,8 +299,7 @@ Request failed: {'error': 'Key already present: 0002', 'success': False}
-
-Example 5 -- Delete and add the same key in the same command +
Example 5 -- Delete and add the same key in the same command ```json chia rpc data_layer batch_update '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "changelist":[{"action":"delete", "key":"0002"},{"action":"insert", "key":"0002", "value":"0123456789abcdef"}]}' @@ -337,8 +331,7 @@ Response:
-
-Example 6 -- Show a key/value pair that was inserted into the Climate Warehouse +
Example 6 -- Show a key/value pair that was inserted into the Climate Warehouse ```json [ @@ -399,14 +392,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| trade_id | TEXT | True | The `trade_id` of the offer. This is displayed with the response of the [make_offer](#make_offer) RPC | -| secure | BOOLEAN | True | If `true`, the offer will be canceled on the blockchain, making it impossible to be accepted later. If `false`, the offer will only be canceled locally. We recommend that you set this to `true` unless you are certain that the offer file has not left your computer | -| fee | TEXT | False | If `secure` is `true`, this will set the fee for the transaction, in mojos. If `secure` is `false`, the fee will be ignored | +| Flag | Type | Required | Description | +| :---------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| trade_id | TEXT | True | The `trade_id` of the offer. This is displayed with the response of the [make_offer](#make_offer) RPC | +| secure | BOOLEAN | True | If `true`, the offer will be canceled on the blockchain, making it impossible to be accepted later. If `false`, the offer will only be canceled locally. We recommend that you set this to `true` unless you are certain that the offer file has not left your computer | +| fee | TEXT | False | If `secure` is `true`, this will set the fee for the transaction, in mojos. If `secure` is `false`, the fee will be ignored | -
-Example +
Example Cancel an offer on-chain, using "secure":"true": @@ -441,8 +433,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc data_layer check_plugins @@ -479,12 +470,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :--- | :------- | :----------------------- | +| Flag | Type | Required | Description | +| :---------------------------- | :--- | :------- | :----------------------- | | store_id | TEXT | True | The hexadecimal store ID | -
-Example +
Example ```json chia rpc data_layer clear_pending_roots '{"store_id":"2772c8108e19f9fa98ff7bc7d4bafd821319bc90af6b610d086b85f4c21fa816"}' @@ -527,8 +517,7 @@ Request Parameters: | :--- | :--- | :------- | :---------------------------------------- | | fee | TEXT | False | Set the fee for the transaction, in mojos | -
-Example +
Example ```json chia rpc data_layer create_data_store '{"fee":"1000"}' @@ -702,8 +691,7 @@ Request Parameters: Example: -
-Example +
Example ```json chia rpc data_layer delete_key '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "key":"0001", "fee":"100000"}' @@ -737,13 +725,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--- | :--- | :------- | :--------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--- | :--- | :------- | :------------------------------------------------------------------------------------------------------------ | | id | TEXT | True | The `coin_id` of the mirror to delete, obtainable by running [get_mirrors](#get_mirrors) | -| fee | TEXT | False | Set the fee for the transaction, in mojos | +| fee | TEXT | False | Set the fee for the transaction, in mojos | -
-Example 1 +
Example 1 ```json chia rpc data_layer delete_mirror '{"id":"0x9a2132858b81907875a65123e592b7aea80b23724202ac21bba0aedf583f7427"}' @@ -759,8 +746,7 @@ Response:
-
-Example 2 +
Example 2 If you attempt to delete a mirror you did not create, this will fail: @@ -798,8 +784,7 @@ Request Parameters: | id | TEXT | True | The hexadecimal store ID | | hash | TEXT | True | The hash from which to display ancestors | -
-Example +
Example First get the root hash of a data store: @@ -852,11 +837,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :----- | :------- | :------------------------------------------------------------------------------------------------ | -| id | TEXT | True | The hexadecimal store ID | -| root_hash | TEXT | False | The root hash from which to obtain data | -| page | NUMBER | False | Enables pagination of the output and requests a specific page | +| Flag | Type | Required | Description | +| :------------------------------------------------------ | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------- | +| id | TEXT | True | The hexadecimal store ID | +| root_hash | TEXT | False | The root hash from which to obtain data | +| page | NUMBER | False | Enables pagination of the output and requests a specific page | | max_page_size | NUMBER | False | Set how many bytes to be included in a page. Only used if pagination is enabled. Default is 40 MB | :::info @@ -876,8 +861,7 @@ If an item is larger than `max_page_size`, an error will be thrown. ::: -
-Example +
Example ```json chia rpc data_layer get_keys '{"id":"0x8f9601eba73a276d5b9e12fbec52b113217e89a55831ae1d80bca48462fbaea7", "root_hash": "0x9527cc5e43bf93062423221e9bec761cbc3f24a0811cb0738da2419dfe7649f7"}' @@ -911,12 +895,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-----------: | :----: | :------: | :------------------------------------------------------------------------------------------------ | -| id | TEXT | True | The hexadecimal store ID | -| root_hash | TEXT | False | The root hash from which to obtain data | -| page | NUMBER | False | Enables pagination of the output and requests a specific page | -| max_page_size | NUMBER | False | Set how many bytes to be included in a page. Only used if pagination is enabled. Default is 40 MB | +| Flag | Type | Required | Description | +| :-----------------------------------------------------: | :----: | :------: | :-------------------------------------------------------------------------------------------------------------------------------- | +| id | TEXT | True | The hexadecimal store ID | +| root_hash | TEXT | False | The root hash from which to obtain data | +| page | NUMBER | False | Enables pagination of the output and requests a specific page | +| max_page_size | NUMBER | False | Set how many bytes to be included in a page. Only used if pagination is enabled. Default is 40 MB | :::info @@ -935,8 +919,7 @@ If an item is larger than `max_page_size`, an error will be thrown. ::: -
-Example +
Example First, we'll show show an example that does not specify the root hash. This will result in stale data being displayed, per the above message. @@ -1040,12 +1023,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :----- | :------- | :------------------------------------------------------------------------------------------------ | -| id | TEXT | True | The hexadecimal store ID | -| hash_1 | TEXT | True | The first hash to compare | -| hash_2 | TEXT | True | The second hash to compare | -| page | NUMBER | False | Enables pagination of the output and requests a specific page | +| Flag | Type | Required | Description | +| :------------------------------------------------------ | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------- | +| id | TEXT | True | The hexadecimal store ID | +| hash_1 | TEXT | True | The first hash to compare | +| hash_2 | TEXT | True | The second hash to compare | +| page | NUMBER | False | Enables pagination of the output and requests a specific page | | max_page_size | NUMBER | False | Set how many bytes to be included in a page. Only used if pagination is enabled. Default is 40 MB | :::info @@ -1056,8 +1039,7 @@ If an item is larger than `max_page_size`, an error will be thrown. ::: -
-Example +
Example ```json chia rpc data_layer get_kv_diff '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a", "hash_1":"0x7e193b814080e50aa7780bcf71fd0422a0397ad3e57dc1eac71d93183efb39ba", "hash_2":"0x2477500c19f0ddfb147049769ce54425a4c4e2994a25e63e51c389cb8f0e912f"}' @@ -1106,8 +1088,7 @@ Request Parameters:s | :--- | :--- | :------- | :----------------------- | | id | TEXT | True | The hexadecimal store ID | -
-Example +
Example ```json chia rpc data_layer get_local_root '{"id":"8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d"}' @@ -1145,8 +1126,7 @@ Request Parameters: | :--- | :--- | :------- | :-------------------------------------------------------- | | id | TEXT | True | The hexadecimal ID of the store for which to list mirrors | -
-Example +
Example ```json chia rpc data_layer get_mirrors '{"id":"0x1ad0908e248f48cc3e9b3cf8f68c748d2e3c5a2a933765032d3222086231ea5e"}' @@ -1188,8 +1168,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc data_layer get_owned_stores @@ -1225,17 +1204,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :---------- | :------- | :------------------------------------------ | +| Flag | Type | Required | Description | +| :---------------------------- | :---------- | :------- | :------------------------------------------ | | store_id | TEXT | True | The hexadecimal store ID | -| keys | STRING LIST | True | A list of keys for which to retrieve proofs | +| keys | STRING LIST | True | A list of keys for which to retrieve proofs | The proof is a proof of inclusion that a given key, value pair is in the specified datalayer store by chaining the Merkle hashes up to the published on-chain root hash. A user can generate a proof for multiple k,v pairs in the same datastore. -
-Example +
Example ```json chia rpc data_layer get_proof '{"store_id": "7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e", "keys": ["0x0003"]}' @@ -1287,8 +1265,7 @@ Request Parameters: | :--- | :--- | :------- | :----------------------- | | id | TEXT | True | The hexadecimal store ID | -
-Example 1 +
Example 1 Get the root hash of an owned store: @@ -1309,8 +1286,7 @@ Response:
-
-Example 2 +
Example 2 Get the root hash of a subscribed store. Notice that an invalid hash is shown: @@ -1352,8 +1328,7 @@ Request Parameters: | :--- | :--- | :------- | :------------------------------ | | ids | TEXT | True | A list of hexadecimal store IDs | -
-Example +
Example For this example, the first store is subscribed, so it will return an invalid root hash. The second store is owned, so the root hash will be valid: @@ -1406,8 +1381,7 @@ Request Parameters: | :--- | :--- | :------- | :----------------------- | | id | TEXT | True | The hexadecimal store ID | -
-Example +
Example ```json chia rpc data_layer get_root_history '{"id":"0x1163ac212bd5fe00efa86f8d3c4958cda08924870800d72dc332f508a1b2e35a"}' @@ -1469,9 +1443,9 @@ Response: ### `get_routes` -Functionality: Show a comprehensive list of RPC routes for the DataLayer +Functionality: List every HTTP path on the DataLayer RPC server (`DataLayerRpcApi` plus shared `RpcServer` routes). -Usage: chia rpc data_layer [OPTIONS] get_routes +Usage: chia rpc data_layer [OPTIONS] get_routes [REQUEST] Options: @@ -1482,8 +1456,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc data_layer get_routes @@ -1494,45 +1467,52 @@ Response: ```json { "routes": [ - "/wallet_log_in", - "/create_data_store", - "/get_owned_stores", + "/add_mirror", + "/add_missing_files", "/batch_update", - "/submit_pending_root", - "/get_value", + "/cancel_offer", + "/check_plugins", + "/clear_pending_roots", + "/close_connection", + "/create_data_store", + "/delete_key", + "/delete_mirror", + "/get_ancestors", + "/get_connections", "/get_keys", "/get_keys_values", - "/get_ancestors", - "/get_root", + "/get_kv_diff", "/get_local_root", + "/get_log_level", + "/get_mirrors", + "/get_network_info", + "/get_owned_stores", + "/get_proof", + "/get_root", + "/get_root_history", "/get_roots", - "/delete_key", + "/get_routes", + "/get_sync_status", + "/get_value", + "/get_version", + "/healthz", "/insert", - "/subscribe", - "/unsubscribe", - "/add_mirror", - "/delete_mirror", - "/get_mirrors", + "/make_offer", + "/multistore_batch_update", + "/open_connection", "/remove_subscriptions", + "/reset_log_level", + "/set_log_level", + "/stop_node", + "/submit_all_pending_roots", + "/submit_pending_root", + "/subscribe", "/subscriptions", - "/get_kv_diff", - "/get_root_history", - "/add_missing_files", - "/make_offer", "/take_offer", + "/unsubscribe", "/verify_offer", - "/cancel_offer", - "/get_sync_status", - "/check_plugins", - "/clear_pending_roots", - "/get_proof", "/verify_proof", - "/get_connections", - "/open_connection", - "/close_connection", - "/stop_node", - "/get_routes", - "/healthz" + "/wallet_log_in" ], "success": true } @@ -1561,8 +1541,7 @@ Request Parameters: | :--- | :--- | :------- | :----------------------- | | id | TEXT | True | The hexadecimal store ID | -
-Example +
Example ```json chia rpc data_layer get_sync_status '{"id": "39114b28a3674b6c2c0ed65d3518842fd17f9df46794f49cd223f9f3a463f09d"}' @@ -1601,10 +1580,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--- | :------- | :-------------------------------------- | -| id | TEXT | True | The hexadecimal store ID | -| key | TEXT | True | The hexadecimal key | +| Flag | Type | Required | Description | +| :----------------------------- | :--- | :------- | :-------------------------------------- | +| id | TEXT | True | The hexadecimal store ID | +| key | TEXT | True | The hexadecimal key | | root_hash | TEXT | False | The root hash from which to obtain data | :::info @@ -1616,8 +1595,7 @@ This parameter is obtainable by calling the [get_root](#get_root) RPC. ::: -
-Example +
Example Obtain the value for key `0x0001`. Pass in the `root_hash` to ensure the latest value is obtained: @@ -1660,8 +1638,7 @@ Request Parameters: | value | TEXT | True | The hexadecimal value | | fee | TEXT | False | Set the fee for the transaction, in mojos | -
-Example 1 +
Example 1 This example will create a key/value pair without `0x` prefixing: @@ -1680,8 +1657,7 @@ Response:
-
-Example 2 +
Example 2 This example will create a key/value pair with `0x` prefixing: @@ -1726,8 +1702,7 @@ Request Parameters: You must own the store listed as the `maker`, and you must be subscribed to the store listed as the `taker`, as will be demonstrated in the example. ::: -
-Example +
Example Before the offer is created, here are the Maker's store ID, keys and values: @@ -1930,8 +1905,7 @@ Request Parameters: | id | TEXT | True | The hexadecimal store ID | | urls | TEXT | True | A list of URLs from which to unsubscribe | -
-Example +
Example ```json chia rpc data_layer remove_subscriptions '{"id":"8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d", "urls":["http://www.example.com:8575"]}' @@ -1985,13 +1959,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--- | :--- | :------- | :----------------------------------------------------------------------- | -| id | TEXT | True | The hexadecimal store ID | +| Flag | Type | Required | Description | +| :--- | :--- | :------- | :--------------------------------------------------------------------------------------- | +| id | TEXT | True | The hexadecimal store ID | | urls | TEXT | True | A list of URLs where the data store resides. This list can be left blank | -
-Example 1 +
Example 1 Subscribe to a data store without specifying any URLs: @@ -2009,8 +1982,7 @@ Response:
-
-Example 2 +
Example 2 Subscribe to a data store using multiple URLs where that store resides: @@ -2045,8 +2017,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc data_layer subscriptions @@ -2086,13 +2057,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---- | :--- | :------- | :----------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :---- | :--- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------- | | offer | TEXT | False | The offer, in JSON format (the output from the `make_offer` RPC). Includes Maker and Taker information | -| fee | TEXT | False | Set the fee for the offer, in mojos | +| fee | TEXT | False | Set the fee for the offer, in mojos | -
-Example +
Example This example will use the offer file created in the [make_offer](#make_offer) example. @@ -2212,8 +2182,7 @@ The `unsubscribe` RPC may or may not delete any data, depending on which version ::: -
-Example +
Example ```json chia rpc data_layer unsubscribe '{"id":"8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d"}' @@ -2246,12 +2215,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---- | :--- | :------- | :----------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :---- | :--- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------- | | offer | TEXT | False | The offer, in JSON format (the output from the `make_offer` RPC). Includes Maker and Taker information | -
-Example 1 +
Example 1 This example will show a successful verification. It will use the offer file created in the [make_offer](#make_offer) example. @@ -2274,8 +2242,7 @@ Response:
-
-Example 2 +
Example 2 This example will show an **unsuccessful** verification. It will use the offer file created in the [make_offer](#make_offer) example, with one byte modified to simulate file corruption: @@ -2308,11 +2275,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| store_proofs | STRING | True | The proof to verify; requires a `proofs` parameter, which must contain the following parameters: `key_clvm_hash`, `value_clvm_hash`, `node_hash`, `layers`. See the example for usage. | -| coin_id | STRING | True | The ID of the coin to retrieve | -| inner_puzzle_hash | STRING | True | The proof's inner puzzle hash | +| Flag | Type | Required | Description | +| :---------------------------------------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| store_proofs | STRING | True | The proof to verify; requires a `proofs` parameter, which must contain the following parameters: `key_clvm_hash`, `value_clvm_hash`, `node_hash`, `layers`. See the example for usage. | +| coin_id | STRING | True | The ID of the coin to retrieve | +| inner_puzzle_hash | STRING | True | The proof's inner puzzle hash | Notes about this command: @@ -2326,8 +2293,7 @@ Notes about this command: For more help with constructing the `store_proofs` JSON, see the output from the [get_proof](#get_proof) RPC. For more examples, see chia-blockchain [PR #16845](https://github.com/Chia-Network/chia-blockchain/pull/16845). -
-Example +
Example ```json chia rpc data_layer verify_proof '{"coin_id": "0x774e5f9ba7a8afbfa7fd2050347b4a2d400d3cd530637a18b61b094bb5a0f756", "inner_puzzle_hash": "0x875cc80014bc72f2028c27500d5b44bf6906cd13ad16d7b5f4a5da77a06c8c2f", "store_proofs": {"proofs": [{"key_clvm_hash": "0xa143e7ffd81147f136f921fef88760c46c7a05f15b81995f9c5cfed2a737a3f1","layers": [], "node_hash": "0xe488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb", "value_clvm_hash": "0xed052604ee4ff3996c15ef9b2cb0925233a2e78b6168bb6e67d133e074109b42"}], "store_id": "0x7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e"}}' @@ -2372,8 +2338,7 @@ Request Parameters: | :---------- | :----- | :------- | :----------------------------------- | | fingerprint | STRING | True | The fingerprint of the wallet to use | -
-Example +
Example ```json chia rpc data_layer wallet_log_in '{"fingerprint":"3404181419"}' @@ -2410,12 +2375,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-----: | :--: | :------: | :------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------: | :--: | :------: | :------------------------------------------------------------------------------------- | | node_id | TEXT | True | The hex ID of the node to close, obtainable from [`get_connections`](#get_connections) | -
-Example +
Example ```json chia rpc data_layer close_connection '{"node_id":"0x8e961b617579d476419003728d6d71ab1b182f7d962e5db16f61ebfb157d771b"}' @@ -2465,8 +2429,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc data_layer get_connections @@ -2522,8 +2485,7 @@ Request Parameters: Example: -
-Example +
Example ```json chia rpc data_layer open_connection '{"host":"localhost", "port":"58444"}' @@ -2556,8 +2518,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc data_layer stop_node diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/did-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/did-rpc.md index 188afc379af..94cc2061279 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/did-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/did-rpc.md @@ -7,8 +7,7 @@ slug: /reference-client/rpc-reference/did-rpc import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -26,6 +25,43 @@ chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}'
+These methods are [wallet RPC](/reference-client/rpc-reference/wallet-rpc) calls: use `chia rpc wallet` with the command name (for example `did_get_did`). They are implemented on `WalletRpcApi` in the Chia reference client, together with the rest of the wallet. The HTTP server also registers shared routes from `RpcServer` (connections, version, logging, health, and so on). The full sorted list of all wallet HTTP paths is given in [get_routes on the wallet RPC page](/reference-client/rpc-reference/wallet-rpc#get_routes). + +:::info Removed in Chia 2.5.7 + +The reference client stopped exposing these wallet RPCs in [Chia blockchain 2.5.7](https://github.com/Chia-Network/chia-blockchain/blob/main/CHANGELOG.md#257-chia-blockchain-2025-11-12) (November 2025): `did_create_attest`, `did_get_information_needed_for_recovery`, `did_get_recovery_list`, `did_recovery_spend`, and `did_update_recovery_ids`. They are not documented here because they are no longer returned by `chia rpc wallet get_routes` on supported releases. + +::: + +### `get_routes` + +Functionality: List every path on the wallet RPC server: all `WalletRpcApi` handlers plus the shared `RpcServer` routes. + +Usage: chia rpc wallet [OPTIONS] get_routes [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_routes +``` + +Response: + +The response is a JSON object with `success` and a `routes` array. The canonical sorted list is kept in one place: [Wallet RPC — get_routes](/reference-client/rpc-reference/wallet-rpc#get_routes). + +
+ +--- + ## Reference ### `create_new_wallet` @@ -45,17 +81,16 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :----------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------- | -| wallet_type | True | This must be set to `did_wallet` in order to create a DID wallet | -| did_type | True | Set this to `new` to create a new DID | -| amount | True | Number of mojos to add to the DID initially. Minimum value is `1` | -| backup_dids | True | A list of DIDs to be used for recovery. Must match actual DIDs | +| Parameter | Required | Description | +| :----------------------------------------------------------------------------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------ | +| wallet_type | True | This must be set to `did_wallet` in order to create a DID wallet | +| did_type | True | Set this to `new` to create a new DID | +| amount | True | Number of mojos to add to the DID initially. Minimum value is `1` | +| backup_dids | True | A list of DIDs to be used for recovery. Must match actual DIDs | | num_of_backup_ids_needed | True | The number of backup DIDs required for recovery. Minimum value is `1`, maximum value is the number of DIDs in `backup_dids` | -| fee | False | An optional blockchain fee, in mojos | +| fee | False | An optional blockchain fee, in mojos | -
-Example +
Example ```json chia rpc wallet create_new_wallet '{"wallet_type": "did_wallet", "did_type": "new", "amount": 1, "backup_dids": ["did:chia:13p5fdxgm8e2pngdwp8m088t0etp7rgzx9ye2ju8v5ackcyg7t9nqx2um83"], "num_of_backup_ids_needed": 1, "fee": 10000000}' @@ -105,116 +140,6 @@ Profile 1: --- -### `did_create_attest` - -Functionality: Create an attest for a DID, to be used for recovery. This command will output the attest data, which can then be added or redirected to a file - -Usage: chia rpc wallet [OPTIONS] did_create_attest [REQUEST] - -Options: - -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------ | -| -j | --json-file | TEXT | False | Instead of REQUEST, provide a json file containing the request data | -| -h | --help | None | False | Show a help message and exit | - -Request Parameters: - -| Parameter | Required | Description | -| :-------- | :------- | :------------------------------------------- | -| wallet_id | True | The Wallet ID for which to create the attest | -| coin_name | True | The coin to use for the attest | -| pubkey | True | The public key to use for the attest | -| puzhash | True | The puzzle hash to use for the attest | - -
-Example - -For this example, we'll use a pre-existing DID. First, obtain the `coin_id` (`coin_name`): - -```json -chia rpc wallet did_get_did '{"wallet_id": 4}' -``` - -Response: - -```json -{ - "coin_id": "0x44a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c7", - "my_did": "did:chia:1d2x5wnm4sl4j2ena8ka3fyv8x7tzc9v520gstd3zfdu4pf6c2yksk8th4u", - "success": true, - "wallet_id": 4 -} -``` - -Next, obtain the `did_innerpuz` (`puzhash`): - -```json -chia rpc wallet did_get_current_coin_info '{"wallet_id": 4}' -``` - -Response: - -```json -{ - "did_amount": 1, - "did_innerpuz": "0xb83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea", - "did_parent": "0x7738c8bc6629a6ece9197280238fa2db9437a66d4dc09d8c7d8446956e91e905", - "my_did": "did:chia:1d2x5wnm4sl4j2ena8ka3fyv8x7tzc9v520gstd3zfdu4pf6c2yksk8th4u", - "success": true, - "wallet_id": 4 -} -``` - -Next, obtain the `Master public key` (`pubkey`); - -```json -chia keys show -``` - -Response: - -``` -Showing all public keys derived from your master seed and private key: - -Fingerprint: 3003259627 -Master public key (m): af8024892a231de462ed7f70abfc1a49372be4d2c34b80f9b48f06093a1629f7a0734c001eb0dd3942aeaecb372b70d2 -Farmer public key (m/12381/8444/0/0): 88305aa55e306dd25d433ce889b3c307f20076ce44429950fa507426197df27b5ce8cbd9df4ec166a3888d372c9ea91c -Pool public key (m/12381/8444/1/0): 85d02120064fe68236e2a274d8bc76100b2e8b632e454d4465db44b6dc9b6eabcdb66c9e44a04f3bed4a49fa45411886 -First wallet address: txch13w2ytvchereqawqjp4r09mqjhwk7unvndew2a400jxtu7q5kr7csqy70f7 -``` - -Finally, using the above values, output the attest data: - -```json -chia rpc wallet did_create_attest '{"wallet_id": 4, "coin_name": "0x44a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c7", "pubkey": "af8024892a231de462ed7f70abfc1a49372be4d2c34b80f9b48f06093a1629f7a0734c001eb0dd3942aeaecb372b70d2", "puzhash": "0xb83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea"}' -``` - -Response: - -```json -{ - "attest_data": "6a8d474f7587eb25667d3dbb14918737962c159453d105b6224b7950a758512d:0000000144a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c77ffee04b4796a1442b18ddb41644acd8de703ac23771a7bb779ff08cbc97cf290000000000000000ff01ffff3cffa044a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c780ffff31ffb0af8024892a231de462ed7f70abfc1a49372be4d2c34b80f9b48f06093a1629f7a0734c001eb0dd3942aeaecb372b70d2ffa0b83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea808080c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000:7738c8bc6629a6ece9197280238fa2db9437a66d4dc09d8c7d8446956e91e905:b83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea:1", - "info": [ - "7738c8bc6629a6ece9197280238fa2db9437a66d4dc09d8c7d8446956e91e905", - "b83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea", - 1 - ], - "message_spend_bundle": "0000000144a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c77ffee04b4796a1442b18ddb41644acd8de703ac23771a7bb779ff08cbc97cf290000000000000000ff01ffff3cffa044a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c780ffff31ffb0af8024892a231de462ed7f70abfc1a49372be4d2c34b80f9b48f06093a1629f7a0734c001eb0dd3942aeaecb372b70d2ffa0b83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea808080c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "success": true -} -``` - -The `attest_data` value can then be directed to a text file, which can later be used for recovery with the `did_recovery_spend` RPC. For example: - -```powershell -echo "6a8d474f7587eb25667d3dbb14918737962c159453d105b6224b7950a758512d:0000000144a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c77ffee04b4796a1442b18ddb41644acd8de703ac23771a7bb779ff08cbc97cf290000000000000000ff01ffff3cffa044a3e90ab1f103d6a259aa3009bdb34e9b092dce9f320f96342368df6b0555c780ffff31ffb0af8024892a231de462ed7f70abfc1a49372be4d2c34b80f9b48f06093a1629f7a0734c001eb0dd3942aeaecb372b70d2ffa0b83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea808080c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000:7738c8bc6629a6ece9197280238fa2db9437a66d4dc09d8c7d8446956e91e905:b83b62a297e44cb53878276e51db3daaf6b0a69ca8fdd4165c8c5bb1816289ea:1" > attest1 -``` - -
- ---- - ### `did_create_backup_file` Functionality: Output the backup data of a DID wallet's metadata. This output can then be saved or redirected to a file @@ -230,12 +155,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :----------------------------------------------------------------- | +| Parameter | Required | Description | +| :----------------------------- | :------- | :----------------------------------------------------------------- | | wallet_id | True | The Wallet ID of the DID wallet from which to obtain the coin info | -
-Example +
Example ```json chia rpc wallet did_create_backup_file '{"wallet_id": 3}' > wallet2.bak @@ -271,15 +195,14 @@ Options: Request Parameters: -| Parameter | Type | Required | Description | -| :----------------- | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------- | -| coin_id | STRING | True | The DID ID, launcher ID, or latest coin ID of the DID you want to recover. The most time-efficient of these is the latest coin ID | +| Parameter | Type | Required | Description | +| :----------------------------------------------------------- | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | +| coin_id | STRING | True | The DID ID, launcher ID, or latest coin ID of the DID you want to recover. The most time-efficient of these is the latest coin ID | | recovery_list_hash | STRING | False | Override the recovery list hash of the DID. Only set this if your last DID spend updated the recovery list | -| num_verification | NUMBER | False | Override the required verification number of the DID. Only set this if your last DID spend updated the required verification number | -| metadata | STRING | False | The new whole metadata in json format | +| num_verification | NUMBER | False | Override the required verification number of the DID. Only set this if your last DID spend updated the required verification number | +| metadata | STRING | False | The new whole metadata in json format | -
-Example 1 +
Example 1 If the DID belongs to the current wallet, the command should succeed: @@ -298,8 +221,7 @@ Response:
-
-Example 2 +
Example 2 If the DID does not belong to this wallet, the command will fail: @@ -332,12 +254,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :----------------------------------------------------------------- | +| Parameter | Required | Description | +| :----------------------------- | :------- | :----------------------------------------------------------------- | | wallet_id | True | The Wallet ID of the DID wallet from which to obtain the coin info | -
-Example +
Example ```json chia rpc wallet did_get_current_coin_info '{"wallet_id": 3}' @@ -375,12 +296,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :------------------------------------------------------------ | +| Parameter | Required | Description | +| :----------------------------- | :------- | :------------------------------------------------------------ | | wallet_id | True | The Wallet ID of the DID wallet for which to get the DID info | -
-Example +
Example ```json chia rpc wallet did_get_did '{"wallet_id": 3}' @@ -416,12 +336,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------ | :----- | :------- | :-------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------- | :----- | :------- | :--------------------------------------------------------------------------------------------------- | | coin_id | NUMBER | True | The coin ID of the DID get info (can be in the `0x618...` or `did:chia:16` format | -
-Example +
Example ```json chia rpc wallet did_get_info '{"coin_id": "0x618a2eee48b111517cbd4f8d11889dc78396c9bcbad11c135dcbedb12f60b58b"}' @@ -448,52 +367,6 @@ Response: --- -### `did_get_information_needed_for_recovery` - -Functionality: Display all relevant information needed to recover a given DID. This RPC must be called on a DID wallet that was created with `"did_type":"recovery"`. - -Usage: chia rpc wallet [OPTIONS] did_get_information_needed_for_recovery [REQUEST] - -Options: - -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------ | -| -j | --json-file | TEXT | False | Instead of REQUEST, provide a json file containing the request data | -| -h | --help | None | False | Show a help message and exit | - -Request Parameters: - -| Parameter | Required | Description | -| :-------- | :------- | :---------------------------------------------------------------------------- | -| wallet_id | True | The Wallet ID of the DID wallet from which to obtain the recovery information | - -
-Example - -```json -chia rpc wallet did_get_information_needed_for_recovery '{"wallet_id": 2}' -``` - -Response: - -```json -{ - "backup_dids": [ - "0x0fc4d8aea5b66cac7c29d93d9eee37b6c0bd9ffcd6b8e38e2c8810de5199c4d3" - ], - "coin_name": "025b4ed9eafab653a6e80c1c1603272cfec0e5c5591bb45a7025dadedba63e23", - "my_did": "did:chia:19z0ladugc29x36580yejgp0s6czq0axt4tq0w7kr9uk4042asusqvxldga", - "newpuzhash": "0x3929e3a268d3d04b8a40f226b66f0ab4f00b5c12fd628bc18f8ce573e76b291f", - "pubkey": "0xa1b184cf85e9804ba1df27acd2efd4622366315293f2c2e06eae7d9776cd3ef474edd4d0f10323e8a7a817b5a42317de", - "success": true, - "wallet_id": 2 -} -``` - -
- ---- - ### `did_get_metadata` Functionality: Fetch the metadata for a given wallet @@ -509,12 +382,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :----------------------------------------------------------------- | +| Parameter | Required | Description | +| :----------------------------- | :------- | :----------------------------------------------------------------- | | wallet_id | True | The Wallet ID of the DID wallet for which to get the metadata list | -
-Example +
Example ```json chia rpc wallet did_get_metadata '{"wallet_id": 3}' @@ -552,12 +424,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :------------------------------------------------------------------ | +| Parameter | Required | Description | +| :----------------------------- | :------- | :------------------------------------------------------------------ | | wallet_id | True | The Wallet ID of the DID wallet from which to obtain the public key | -
-Example +
Example ```json chia rpc wallet did_get_pubkey '{"wallet_id": 2}' @@ -576,50 +447,6 @@ Response: --- -### `did_get_recovery_list` - -Functionality: For a given wallet, fetch the recovery list, as well as the number of IDs required for recovery - -Usage: chia rpc wallet [OPTIONS] did_get_recovery_list [REQUEST] - -Options: - -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------ | -| -j | --json-file | TEXT | False | Instead of REQUEST, provide a json file containing the request data | -| -h | --help | None | False | Show a help message and exit | - -Request Parameters: - -| Parameter | Required | Description | -| :-------- | :------- | :----------------------------------------------------------------- | -| wallet_id | True | The Wallet ID of the DID wallet for which to get the recovery list | - -
-Example: - -```json -chia rpc wallet did_get_recovery_list '{"wallet_id": 3}' -``` - -Response: - -```json -{ - "num_required": 2, - "recovery_list": [ - "did:chia:1d2x5wnm4sl4j2ena8ka3fyv8x7tzc9v520gstd3zfdu4pf6c2yksk8th4u", - "did:chia:1gsarjll9lrd4kwxdglh28cjn3ln6u7ldfzsask9gw4tprzce20vsywwsqs" - ], - "success": true, - "wallet_id": 3 -} -``` - -
- ---- - ### `did_get_wallet_name` Functionality: Given a DID wallet's ID, retrieve the name of that wallet @@ -635,12 +462,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :------------------------------------------------------- | +| Parameter | Required | Description | +| :----------------------------- | :------- | :------------------------------------------------------- | | wallet_id | True | The Wallet ID of the DID wallet on which to get the name | -
-Example +
Example ```json chia rpc wallet did_get_wallet_name '{"wallet_id": 3}' @@ -675,14 +501,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :----- | :------- | :-------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :---------------------------------------- | :----- | :------- | :-------------------------------------------------------------- | | wallet_id | NUMBER | True | The Wallet ID of the DID wallet from which to spend the message | | coin_announcements | LIST | False | A list of coin announcements to include with the spend | | puzzle_announcements | LIST | False | A list of puzzle announcements to include with the spend | -
-Example +
Example ```json chia rpc wallet did_message_spend '{"wallet_id": 5}' @@ -714,346 +539,6 @@ Response: --- -### `did_recovery_spend` - -Functionality: Recover a DID to a new DID by using an attest file - -Usage: chia rpc wallet [OPTIONS] did_recovery_spend [REQUEST] - -Options: - -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------ | -| -j | --json-file | TEXT | False | Instead of REQUEST, provide a json file containing the request data | -| -h | --help | None | False | Show a help message and exit | - -Request Parameters: - -| Parameter | Required | Description | -| :---------- | :------- | :-------------------------------------------------------------------------------------------------------------- | -| wallet_id | True | The Wallet ID of the DID wallet to recover | -| attest_data | True | A list of attest files to be used for recovery | -| pubkey | False | The public key of the wallet to recover. If this is not provided, a temporary public key will be used instead | -| puzhash | False | The puzzle hash of the wallet to recover. If this is not provided, a temporary puzzle hash will be used instead | -| fee | False | An optional blockchain fee, in mojos | - -
-Example - -There are several steps involved in performing a DID recovery spend. We'll go through them one at a time here. - -For this example, we'll start with a brand new setup: a single fingerprint with a Chia wallet and some TXCH: - -```json -$ chia wallet show -Wallet height: 1190999 -Sync status: Synced -Balances, fingerprint: 2136152685 - -Chia Wallet: - -Total Balance: 28.312944999982 txch (28312944999982 mojo) - -Pending Total Balance: 28.312944999982 txch (28312944999982 mojo) - -Spendable: 28.312944999982 txch (28312944999982 mojo) - -Type: STANDARD_WALLET - -Wallet ID: 1 -``` - -We'll start by creating two DIDs, labeled "DID A" and "DID B". DID A is the one we'll recover later. - -```json -$ chia wallet did create -n "DID A" -a 1 -m 0.00001 -Successfully created a DID wallet with name DID A and id 2 on key 2136152685 -Successfully created a DID did:chia:1yk9vl86ek6duzah5pj0xtsp8wd5czqu9p3hvlsxw0c8cj3w95tssg0l2d6 in the newly created DID wallet - -$ chia wallet did create -n "DID B" -a 1 -m 0.00001 -Successfully created a DID wallet with name DID B and id 3 on key 2136152685 -Successfully created a DID did:chia:1l3hkwrlkmja526pzjuxhfm9c859hn64m2hwq76hfdletpfj09q6qf6e9k4 in the newly created DID wallet -``` - -At this point, both DIDs will show up. They are listed under Wallet IDs 2 and 3: - -```json -$ chia wallet show -Wallet height: 1191003 -Sync status: Synced -Balances, fingerprint: 2136152685 - -Chia Wallet: - -Total Balance: 28.312934999981 txch (28312934999981 mojo) - -Pending Total Balance: 28.31292499998 txch (28312924999980 mojo) - -Spendable: 0.899879999999 txch (899879999999 mojo) - -Type: STANDARD_WALLET - -Wallet ID: 1 - -DID A: - -Total Balance: 1.0 - -Pending Total Balance: 1.0 - -Spendable: 1.0 - -Type: DECENTRALIZED_ID - -DID ID: did:chia:1yk9vl86ek6duzah5pj0xtsp8wd5czqu9p3hvlsxw0c8cj3w95tssg0l2d6 - -Wallet ID: 2 - -DID B: - -Total Balance: 0.0 - -Pending Total Balance: 1.0 - -Spendable: 0.0 - -Type: DECENTRALIZED_ID - -DID ID: did:chia:1l3hkwrlkmja526pzjuxhfm9c859hn64m2hwq76hfdletpfj09q6qf6e9k4 - -Wallet ID: 3 -``` - -Next, update the recovery list of DID A. This command will add DID B as the recovery ID: - -```json -$ chia rpc wallet did_update_recovery_ids '{"wallet_id": 2, "new_list": ["did:chia:1l3hkwrlkmja526pzjuxhfm9c859hn64m2hwq76hfdletpfj09q6qf6e9k4"]}' -{ - "success": true -} -``` - -Now we can create a backup file of DID A: - -```json -chia rpc wallet did_create_backup_file '{"wallet_id": 2}' -{ - "backup_data": "e1995096382bcb7fef4c961bc09c32cbe0af929e768fc927133405271b3ca759:eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9:1:fc6f670ff6dcbb456822970d74ecb83d0b79eabb55dc0f6ae96ff2b0a64f2834:ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b083770b050c01211b8e966c7dc40fa970e5d150293c0615910c09482c1491dd87d9115b639e88f84b0c6fc634df4b7b0fff018080ffff04ffff01a0bd61b4e994cc949bfc9350386c1818aea4ff5a300e9acfeb9e0ff7111d26a453ffff04ffff0101ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa0258acf9f59b69bc176f40c9e65c02773698103850c6ecfc0ce7e0f8945c5a2e1a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080:1:{}", - "success": true, - "wallet_id": 2 -} -``` - -At this point we need to create a new wallet fingerprint. This will be the final location for the recovered DID: - -```json -chia keys generate -Generating private key -Added private key with public key fingerprint 2118200991 -WARNING: using a farmer address which we might not have the private keys for. We searched the first 50 addresses. Consider overriding txch13amy3jfp8kkmqa87eswytj3a8ef22nm8zwsf3ckptpm8rv72qtgqgvk6fs with txch1phed5va8r3ch94qr6kp8mu5hu52xz6u7267624vtq2lkl06zn73q3sryj6 -WARNING: using a pool address which we might not have the private keys for. We searched the first 50 addresses. Consider overriding txch13amy3jfp8kkmqa87eswytj3a8ef22nm8zwsf3ckptpm8rv72qtgqgvk6fs with txch1phed5va8r3ch94qr6kp8mu5hu52xz6u7267624vtq2lkl06zn73q3sryj6 -``` - -Show both wallet keys: - -```json -$ chia keys show -Showing all public keys derived from your master seed and private key: - -Fingerprint: 2118200991 -Master public key (m): 93e0afa4e8c537c8d6642225a45e267bc6f12fe9dfcbb3fab177645df6a7c8bb8fd62892b534ca82e4c05e45e774ccc3 -Farmer public key (m/12381/8444/0/0): b63fbd179e3089bee17bfb430f1a559ab16ec8217b0a26dbb9a9501a82840614c74167c76e759716aae9b6c1cf4a701a -Pool public key (m/12381/8444/1/0): 9028d7a806a6ddcb2e3266442002c70fba369fe5e46cc7fae0c4dcd12ffb1ce993752abdc45a1bf17d15918f1cfb7891 -First wallet address: txch1phed5va8r3ch94qr6kp8mu5hu52xz6u7267624vtq2lkl06zn73q3sryj6 - -Fingerprint: 2136152685 -Master public key (m): b9bcda4cd4affe38e4f8bbb2943eb478ed4799c1abfda150d583433e8f5e45b5d0eb57e459193a6a2d6ed6339f5d32cf -Farmer public key (m/12381/8444/0/0): 9521e9cb089d2185f5547cfed0547d3eb7d1b0dfb372174d6a46f813d02db20eb646820929ac30d0b314e7541d842f66 -Pool public key (m/12381/8444/1/0): a3a9f40c651f1ba0e56b33182920496939decc6a23bda6c6dc040644203b216ddf42f0a605fe6977b9d42fe30d734997 -First wallet address: txch1svp4tl59wzhz97lemf228jsrtlansej48wec5cuzxpc7g0g4tqcq0s5v68 -``` - -Sync the second wallet fingerprint and show the contents. So far, there is only a regular Chia wallet: - -```json -chia wallet show -Wallet keys: -1) * 2118200991 (Synced) -2) 2136152685 -Choose a wallet key [1-2] ('q' to quit, or Enter to use 2118200991): -Wallet height: 1191071 -Sync status: Synced -Balances, fingerprint: 2118200991 - -Chia Wallet: - -Total Balance: 0.0 txch (0 mojo) - -Pending Total Balance: 0.0 txch (0 mojo) - -Spendable: 0.0 txch (0 mojo) - -Type: STANDARD_WALLET - -Wallet ID: 1 -``` - -Now we can create a new wallet within the second fingerprint. This will have a did_type of "recovery". It will use the backup file of DID A. At this point, however, it will just be an empty DID because the recovery spend has not yet been performed. - -Note the values of `coin_name`, `pubkey` and `newpuzhash` as they will be used shortly when creating the attest: - -```json -chia rpc wallet create_new_wallet '{"wallet_type":"did_wallet", "did_type":"recovery", "backup_data":"e1995096382bcb7fef4c961bc09c32cbe0af929e768fc927133405271b3ca759:eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9:1:fc6f670ff6dcbb456822970d74ecb83d0b79eabb55dc0f6ae96ff2b0a64f2834:ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b083770b050c01211b8e966c7dc40fa970e5d150293c0615910c09482c1491dd87d9115b639e88f84b0c6fc634df4b7b0fff018080ffff04ffff01a0bd61b4e994cc949bfc9350386c1818aea4ff5a300e9acfeb9e0ff7111d26a453ffff04ffff0101ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa0258acf9f59b69bc176f40c9e65c02773698103850c6ecfc0ce7e0f8945c5a2e1a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080:1:{}"}' -{ - "backup_dids": [ - "0xfc6f670ff6dcbb456822970d74ecb83d0b79eabb55dc0f6ae96ff2b0a64f2834" - ], - "coin_list": [ - "0x7aa58b37be28b3dde7f8990bf9d32913e7cd89d2cd490196234bcab327645cf9", - "0x90d067146f4ffd80d37ecbd754e3a3b15c86186fcfb1113562d4ec12e24ca0ae", - 1 - ], - "coin_name": "7b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe5", - "my_did": "258acf9f59b69bc176f40c9e65c02773698103850c6ecfc0ce7e0f8945c5a2e1", - "newpuzhash": "1220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed9013", - "num_verifications_required": 1, - "pubkey": "8a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0ba", - "success": true, - "type": 8, - "wallet_id": 2 -} -``` - -Next, sync the original wallet and show the contents: - -```json -chia wallet show -Wallet keys: -1) 2118200991 -2) * 2136152685 (Synced) -Choose a wallet key [1-2] ('q' to quit, or Enter to use 2136152685): -Wallet height: 1191076 -Sync status: Synced -Balances, fingerprint: 2136152685 - -Chia Wallet: - -Total Balance: 28.31292499998 txch (28312924999980 mojo) - -Pending Total Balance: 28.31292499998 txch (28312924999980 mojo) - -Spendable: 28.31292499998 txch (28312924999980 mojo) - -Type: STANDARD_WALLET - -Wallet ID: 1 - -DID A: - -Total Balance: 1.0 - -Pending Total Balance: 1.0 - -Spendable: 1.0 - -Type: DECENTRALIZED_ID - -DID ID: did:chia:1yk9vl86ek6duzah5pj0xtsp8wd5czqu9p3hvlsxw0c8cj3w95tssg0l2d6 - -Wallet ID: 2 - -DID B: - -Total Balance: 1.0 - -Pending Total Balance: 1.0 - -Spendable: 1.0 - -Type: DECENTRALIZED_ID - -DID ID: did:chia:1l3hkwrlkmja526pzjuxhfm9c859hn64m2hwq76hfdletpfj09q6qf6e9k4 - -Wallet ID: 3 -``` - -Create the attest using DID B. The `coin_name`, `pubkey`, and `puzhash` (called `newpuzhash` above) all come from the recovery wallet in the new wallet fingerprint. - -```json -chia rpc wallet did_create_attest '{"wallet_id": 3, "coin_name": "0x7b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe5", "pubkey": "8a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0ba", "puzhash": "0x1220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed9013"}' -{ - "attest_data": "fc6f670ff6dcbb456822970d74ecb83d0b79eabb55dc0f6ae96ff2b0a64f2834:000000010aa0becc194467bf318773b2a9f2afb11372021cd91dbdd2c9b86ce62a0958ec295226d71b97c9ad9aa47bb4bdc7724c64426c587ccf726154af3e98d7f765b30000000000000000ff01ffff3cffa07b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe580ffff31ffb08a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0baffa01220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed9013808080c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000:9b28688c247e13f6d25d9213f56f1cb98efed8553d3fdf7b2bafb02946f10b1d:4e87afa498547c9086455b9e922208dc698816c4100d089884adbc35c6d5c036:1", - "info": [ - "9b28688c247e13f6d25d9213f56f1cb98efed8553d3fdf7b2bafb02946f10b1d", - "4e87afa498547c9086455b9e922208dc698816c4100d089884adbc35c6d5c036", - 1 - ], - "message_spend_bundle": "000000010aa0becc194467bf318773b2a9f2afb11372021cd91dbdd2c9b86ce62a0958ec295226d71b97c9ad9aa47bb4bdc7724c64426c587ccf726154af3e98d7f765b30000000000000000ff01ffff3cffa07b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe580ffff31ffb08a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0baffa01220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed9013808080c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "success": true -} -``` - -Send some money to the new wallet to be used during the recovery: - -```json -chia wallet send -t txch1phed5va8r3ch94qr6kp8mu5hu52xz6u7267624vtq2lkl06zn73q3sryj6 -a 1 -m 0.00001 -Wallet keys: -1) 2118200991 -2) * 2136152685 (Synced) -Choose a wallet key [1-2] ('q' to quit, or Enter to use 2136152685): -Submitting transaction... -Transaction submitted to nodes: [{'peer_id': 'f40100b8b46550eb75b79edab4de38611eb543ac8975e262c2d2bf1e1c594312', 'inclusion_status': 'SUCCESS', 'error_msg': None}] -Run 'chia wallet get_transaction -f 2136152685 -tx 0x09dc82f5d8737def4b0ec70e7cd6a92a3a00be8b31152d30fbe73bc939776187' to get status -``` - -Sync the new wallet and show its contents. Note that `Profile 1` has zero balance: - -```json -chia wallet show -Wallet keys: -1) * 2118200991 (Synced) -2) 2136152685 -Choose a wallet key [1-2] ('q' to quit, or Enter to use 2118200991): -Wallet height: 1191101 -Sync status: Synced -Balances, fingerprint: 2118200991 - -Chia Wallet: - -Total Balance: 1.0 txch (1000000000000 mojo) - -Pending Total Balance: 1.0 txch (1000000000000 mojo) - -Spendable: 1.0 txch (1000000000000 mojo) - -Type: STANDARD_WALLET - -Wallet ID: 1 - -Profile 1: - -Total Balance: 0.0 - -Pending Total Balance: 0.0 - -Spendable: 0.0 - -Type: DECENTRALIZED_ID - -DID ID: did:chia:1yk9vl86ek6duzah5pj0xtsp8wd5czqu9p3hvlsxw0c8cj3w95tssg0l2d6 - -Wallet ID: 2 -``` - -Now perform the recovery, passing in the attest_data obtained previously: - -```json -chia rpc wallet did_recovery_spend '{"wallet_id":2, "attest_data":["fc6f670ff6dcbb456822970d74ecb83d0b79eabb55dc0f6ae96ff2b0a64f2834:000000010aa0becc194467bf318773b2a9f2afb11372021cd91dbdd2c9b86ce62a0958ec295226d71b97c9ad9aa47bb4bdc7724c64426c587ccf726154af3e98d7f765b30000000000000000ff01ffff3cffa07b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe580ffff31ffb08a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0baffa01220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed9013808080c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000:9b28688c247e13f6d25d9213f56f1cb98efed8553d3fdf7b2bafb02946f10b1d:4e87afa498547c9086455b9e922208dc698816c4100d089884adbc35c6d5c036:1"]}' -{ - "spend_bundle": { - "aggregated_signature": "0xafc1f292dc4c6d6492a1d5ba760c4f28941398392f414f7e937b0695c68bd9d144bdbfba5956d5a49f4a02f0a72b2a5206345539b20a7ccc4a5ad7463e5c0bfeb6246511f9bdebfdcf55275e2c94833162e86ecc6335ae9a1c39073b24dae873", - "coin_solutions": [ - { - "coin": { - "amount": 0, - "parent_coin_info": "0x0aa0becc194467bf318773b2a9f2afb11372021cd91dbdd2c9b86ce62a0958ec", - "puzzle_hash": "0x295226d71b97c9ad9aa47bb4bdc7724c64426c587ccf726154af3e98d7f765b3" - }, - "puzzle_reveal": "0xff01ffff3cffa07b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe580ffff31ffb08a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0baffa01220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed90138080", - "solution": "0x80" - }, - { - "coin": { - "amount": 1, - "parent_coin_info": "0x7aa58b37be28b3dde7f8990bf9d32913e7cd89d2cd490196234bcab327645cf9", - "puzzle_hash": "0x90d067146f4ffd80d37ecbd754e3a3b15c86186fcfb1113562d4ec12e24ca0ae" - }, - "puzzle_reveal": "0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa0258acf9f59b69bc176f40c9e65c02773698103850c6ecfc0ce7e0f8945c5a2e1a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b083770b050c01211b8e966c7dc40fa970e5d150293c0615910c09482c1491dd87d9115b639e88f84b0c6fc634df4b7b0fff018080ffff04ffff01a0bd61b4e994cc949bfc9350386c1818aea4ff5a300e9acfeb9e0ff7111d26a453ffff04ffff0101ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa0258acf9f59b69bc176f40c9e65c02773698103850c6ecfc0ce7e0f8945c5a2e1a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080", - "solution": "0xffffa0767eec938e0b05170de23d79423404985e9f50dd1b43c3021fc66c42b9b83337ffa065ed09d2efb33577d189a0db02378a4de36eb228abfc1458e356f8f6353a2bf8ff0180ff01ffff80ff01ffa01220da328f91466714867ffeed7159db14d9522a784adf042beb91ffbaed9013ffffffa09b28688c247e13f6d25d9213f56f1cb98efed8553d3fdf7b2bafb02946f10b1dffa04e87afa498547c9086455b9e922208dc698816c4100d089884adbc35c6d5c036ff018080ffb08a1a8036d61a3bb5f2d751c90e643989f0db6ad2fd4e5aa63c6716e187e10c3493c2d59a58e688b78261211cd446d0baffffa0fc6f670ff6dcbb456822970d74ecb83d0b79eabb55dc0f6ae96ff2b0a64f283480ffa07b7cb8ea30d4bda2bb4d8bfaf82fbc0a6893d2e55c56d47c333d0d96b1509fe58080" - } - ] - }, - "success": true -} -``` - -Wait a few minutes for the recovery spend to be confirmed on the blockchain. Afterward, `Profile 1` will have a balance of 1.0: - -```json -chia wallet show -Wallet keys: -1) * 2118200991 (Synced) -2) 2136152685 -Choose a wallet key [1-2] ('q' to quit, or Enter to use 2118200991): -Wallet height: 1191108 -Sync status: Synced -Balances, fingerprint: 2118200991 - -Chia Wallet: - -Total Balance: 1.0 txch (1000000000000 mojo) - -Pending Total Balance: 1.0 txch (1000000000000 mojo) - -Spendable: 1.0 txch (1000000000000 mojo) - -Type: STANDARD_WALLET - -Wallet ID: 1 - -Profile 1: - -Total Balance: 1.0 - -Pending Total Balance: 1.0 - -Spendable: 1.0 - -Type: DECENTRALIZED_ID - -DID ID: did:chia:1yk9vl86ek6duzah5pj0xtsp8wd5czqu9p3hvlsxw0c8cj3w95tssg0l2d6 - -Wallet ID: 2 -``` - -
- ---- - ### `did_set_wallet_name` Functionality: Set the name of a DID wallet @@ -1069,13 +554,12 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :------------------------------------------------------- | +| Parameter | Required | Description | +| :----------------------------- | :------- | :------------------------------------------------------- | | wallet_id | True | The Wallet ID of the DID wallet on which to set the name | -| name | True | The new name of the DID wallet | +| name | True | The new name of the DID wallet | -
-Example +
Example ```json chia rpc wallet did_set_wallet_name '{"wallet_id": 3, "name": "My DID Wallet"}' @@ -1131,16 +615,15 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :----------------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | True | The Wallet ID of the DID wallet to transfer | -| inner_address | True | The address of the inner puzzle to which to transfer the DID | -| fee | False | An optional blockchain fee, in mojos | -| with_recovery_info | False | If `True`, transfer recovery info [Default: `True`] | -| reuse_puzhash | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Parameter | Required | Description | +| :----------------------------------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | True | The Wallet ID of the DID wallet to transfer | +| inner_address | True | The address of the inner puzzle to which to transfer the DID | +| fee | False | An optional blockchain fee, in mojos | +| with_recovery_info | False | If `True`, transfer recovery info [Default: `True`] | +| reuse_puzhash | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example ```json chia rpc wallet did_transfer_did '{"wallet_id": 4, "inner_address": "txch1r2hc8zaxmqetkwuqz99nspwa7dlhnyx6uuxlt8srrsd2n7pscwfqgjhy7h"}' @@ -1220,15 +703,14 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :------------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | True | The Wallet ID of the DID wallet for which to update the metadata | -| metadata | False | The updated metadata | -| fee | False | An optional blockchain fee, in mojos | +| Parameter | Required | Description | +| :--------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | True | The Wallet ID of the DID wallet for which to update the metadata | +| metadata | False | The updated metadata | +| fee | False | An optional blockchain fee, in mojos | | reuse_puzhash | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example ```json chia rpc wallet did_update_metadata '{"wallet_id": 3, "metadata": {"foo": "bar", "something": 5}}' @@ -1245,75 +727,3 @@ Response:
--- - -### `did_update_recovery_ids` - -Functionality: Append one or more IDs to be used for recovery of a DID wallet. The current list can be obtained with the did_get_recovery_list endpoint - -Usage: chia rpc wallet [OPTIONS] did_update_recovery_ids [REQUEST] - -Options: - -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------ | -| -j | --json-file | TEXT | False | Instead of REQUEST, provide a json file containing the request data | -| -h | --help | None | False | Show a help message and exit | - -Request Parameters: - -| Parameter | Required | Description | -| :------------------------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | True | The Wallet ID of the DID wallet for which to update the recovery IDs | -| new_list | True | The new recovery ID list. Each item from this list will be appended to the existing list | -| num_verifications_required | False | Optionally set the number of IDs required for wallet recovery. If not set, then the entire updated list will be required by default | -| fee | False | An optional blockchain fee, in mojos | -| reuse_puzhash | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | - -
-Example - -To show an example, first we need at least one DID to be used for recovery. In this case, we'll create two and use them both. - -Create one recovery DID: - -```json -chia wallet did create -n "Recovery DID 1" -``` - -Response: - -``` -Successfully created a DID wallet with name Recovery DID 1 and id 4 on key 3003259627 -Successfully created a DID did:chia:1d2x5wnm4sl4j2ena8ka3fyv8x7tzc9v520gstd3zfdu4pf6c2yksk8th4u in the newly created DID wallet -``` - -Create another recovery DID: - -```json -chia wallet did create -n "Recovery DID 2" -``` - -Response: - -``` -Successfully created a DID wallet with name Recovery DID 2 and id 6 on key 3003259627 -Successfully created a DID did:chia:1gsarjll9lrd4kwxdglh28cjn3ln6u7ldfzsask9gw4tprzce20vsywwsqs in the newly created DID wallet -``` - -Example of adding both recovery DIDs: - -```json -chia rpc wallet did_update_recovery_ids '{"wallet_id": 3, "new_list": ["did:chia:1d2x5wnm4sl4j2ena8ka3fyv8x7tzc9v520gstd3zfdu4pf6c2yksk8th4u", "did:chia:1gsarjll9lrd4kwxdglh28cjn3ln6u7ldfzsask9gw4tprzce20vsywwsqs"]}' -``` - -Response: - -```json -{ - "success": true -} -``` - -
- ---- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/farmer-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/farmer-rpc.md index 9aa336c9b3c..c454fbbaf01 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/farmer-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/farmer-rpc.md @@ -11,8 +11,7 @@ This document provides a comprehensive reference to Chia's Farmer RPC API. Route For Proof of Space 2 (PoS2) farming with V2 plots, connect to a Solver peer with [`connect_to_solver`](#connect_to_solver); solver HTTP endpoints are documented under [Solver RPC](/reference-client/rpc-reference/solver-rpc). -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -47,8 +46,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc farmer get_harvesters @@ -108,8 +106,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc farmer get_harvesters_summary @@ -158,16 +155,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--------- | :------- | :------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------- | | node_id | HEX STRING | True | This node's `node_id`, obtainable from the [get_harvesters](#get_harvesters) RPC | -| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | -| page_size | INTEGER | True | The number of entries per page to list | +| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | +| page_size | INTEGER | True | The number of entries per page to list | Note that the request parameters are automatically combined to create `PlotInfoRequestData`. -
-Example +
Example ```json chia rpc farmer get_harvester_plots_duplicates '{"node_id": "0xbefeeb05fa599f07c5be2b94b2d872b2516f03101ed49cc53312f086de197913", "page": 0, "page_size": 1}' @@ -205,16 +201,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--------- | :------- | :------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------- | | node_id | HEX STRING | True | This node's `node_id`, obtainable from the [get_harvesters](#get_harvesters) RPC | -| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | -| page_size | INTEGER | True | The number of entries per page to list | +| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | +| page_size | INTEGER | True | The number of entries per page to list | Note that the request parameters are automatically combined to create `PlotInfoRequestData`. -
-Example +
Example ```json chia rpc farmer get_harvester_plots_invalid '{"node_id": "0xbefeeb05fa599f07c5be2b94b2d872b2516f03101ed49cc53312f086de197913", "page": 0, "page_size": 1}' @@ -252,16 +247,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--------- | :------- | :------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------- | | node_id | HEX STRING | True | This node's `node_id`, obtainable from the [get_harvesters](#get_harvesters) RPC | -| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | -| page_size | INTEGER | True | The number of entries per page to list | +| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | +| page_size | INTEGER | True | The number of entries per page to list | Note that the request parameters are automatically combined to create `PlotInfoRequestData`. -
-Example +
Example ```json chia rpc farmer get_harvester_plots_keys_missing '{"node_id": "0xbefeeb05fa599f07c5be2b94b2d872b2516f03101ed49cc53312f086de197913", "page": 0, "page_size": 5}' @@ -305,16 +299,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--------- | :------- | :------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------- | | node_id | HEX STRING | True | This node's `node_id`, obtainable from the [get_harvesters](#get_harvesters) RPC | -| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | -| page_size | INTEGER | True | The number of entries per page to list | +| page | INTEGER | True | The page in the results sequence to list (starts with `0`) | +| page_size | INTEGER | True | The number of entries per page to list | Note that the request parameters are automatically combined to create `PlotInfoRequestData`. -
-Example +
Example ```json chia rpc farmer get_harvester_plots_valid '{"node_id": "0xbefeeb05fa599f07c5be2b94b2d872b2516f03101ed49cc53312f086de197913", "page": 0, "page_size": 1}' @@ -363,12 +356,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :---------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | | launcher_id | HEX STRING | True | The launcher_id from your pool, obtainable from the [get_pool_state](#get_pool_state) RPC | -
-Example +
Example ```json chia rpc farmer get_pool_login_link '{"launcher_id": "0x55244acf3017c2fc245020b46600827047dce8f54c982adaf95248ff2e955ad8"}' @@ -402,8 +394,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc farmer get_pool_state @@ -469,13 +460,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| search_for_private_key | BOOLEAN | True | List whether the private key (sk) is available for both the farmer and pool keys | +| Flag | Type | Required | Description | +| :------------------------------------------------------------------------------------ | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| search_for_private_key | BOOLEAN | True | List whether the private key (sk) is available for both the farmer and pool keys | | max_ph_to_search | INTEGER | False | The maximum number of puzzle hashes to search [Default: 500] If the wallet's derivation index is large, this number may be insufficient to locate the correct puzzle hashes. In this case, you may need to increase this value | -
-Example +
Example ```json chia rpc farmer get_reward_targets '{"search_for_private_key": false}' @@ -518,10 +508,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--- | :------ | :------- | :---------------------------------------- | -| host | STRING | True | Hostname or IP address of the solver peer | -| port | INTEGER | True | Port of the solver (`peer_server_port`) | +| Flag | Type | Required | Description | +| :--- | :------ | :------- | :--------------------------------------------------------- | +| host | STRING | True | Hostname or IP address of the solver peer | +| port | INTEGER | True | Port of the solver (`peer_server_port`) | :::note @@ -529,8 +519,7 @@ Use `port` as the solver **peer** listening port (`solver.port` in `config.yaml` ::: -
-Example +
Example ```json chia rpc farmer connect_to_solver '{"host": "127.0.0.1", "port": 8666}' @@ -572,8 +561,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc farmer get_routes @@ -633,12 +621,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------ | :--------- | :------- | :------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------- | :--------- | :------- | :------------------------------------------------------------------------------------- | | sp_hash | HEX STRING | True | The hash of a signage point, listed as `pos_ss_cc_challenge_hash` in the block details | -
-Example +
Example ```json chia rpc farmer get_signage_point '{"sp_hash": "0xd1d48067e1a355e69808201db516008c3d71c88d8c07fcee7c790f725e56e9ac"}' @@ -680,8 +667,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc farmer get_signage_points @@ -773,13 +759,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------- | :------- | :---------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------------------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | | launcher_id | HEX STRING | True | The launcher_id from your pool, obtainable from the [get_pool_state](#get_pool_state) RPC | -| payout_instructions | HEX STRING | True | The puzzle hash to be used as the new `payout_instructions` | +| payout_instructions | HEX STRING | True | The puzzle hash to be used as the new `payout_instructions` | -
-Example +
Example ```json chia rpc farmer set_payout_instructions '{"launcher_id": "0x55244acf3017c2fc245020b46600827047dce8f54c982adaf95248ff2e955ad8", "payout_instructions": "19d5a0c14e294e48451959819e8c7407c1a06f4f81c69a943ac86433a9ff29e6"}' @@ -812,13 +797,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :--------- | :------- | :--------------------------- | +| Flag | Type | Required | Description | +| :--------------------------------- | :--------- | :------- | :--------------------------- | | farmer_target | HEX STRING | False | Set the farmer reward target | | pool_target | HEX STRING | False | Set the pool reward target | -
-Example +
Example Set both targets: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/full-node-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/full-node-rpc.md index b123aca9fe9..22f42c24d9b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/full-node-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/full-node-rpc.md @@ -22,8 +22,7 @@ The [coinset CLI tool](https://github.com/coinset-org/cli) is also capable of re Need to test these RPC endpoints? Use the **[RPC Validation Tool](/guides/rpc-validation-tool)** to validate that your full node's RPC functionality is working correctly. ::: -
- Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -58,8 +57,8 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :--------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :--------------------------- | | header_hash | HEX STRING | True | The header hash of the block | :::note @@ -69,14 +68,13 @@ for spent coins, use the [get_puzzle_and_solution](#get_puzzle_and_solution) API ::: -
-Example +
Example -````mdx-code-block +```mdx-code-block ```json chia rpc full_node get_additions_and_removals '{"header_hash": "0xfb7891e9a4a9ca6f8a633e0632d82c2502f425526754f71aee5a55d6ad3933d8"}' ``` -```` +``` Response: @@ -351,8 +349,7 @@ Options: Request Parameters: None -
-Example +
Example ````mdx-code-block ```json @@ -390,8 +387,7 @@ Options: Request Parameters: None -
-Example +
Example ````mdx-code-block ```json @@ -781,8 +777,7 @@ Options: Request Parameters: None -
-Example +
Example ````mdx-code-block ```json @@ -826,12 +821,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :-------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :------------------------------------------------------------------------------------- | | header_hash | HEX STRING | True | Header hash (block identifier) of the block to get. | -
-Example +
Example Note that some blocks (such as the one from this example) are not transaction blocks: @@ -942,8 +936,19 @@ Options: Request Parameters: None -
-Example +:::note + +`average_block_time` is the average time in seconds between blocks (not specifically transaction blocks). The protocol target is 18.75 seconds, and this value is truncated in the response (for example `18`). It may be `null` on a very short chain or before the node has synced relevant blocks. If this value drifts by more than a few seconds for a sustained period, netspace likely changed since the latest difficulty adjustment. + +::: + +:::note + +`blockchain_state.space` is a network-space estimate in bytes (`uint128` in the node). It can exceed `Number.MAX_SAFE_INTEGER` (2^53 - 1). JavaScript and other IEEE-754 JSON parsers may lose precision; use a bigint-capable parser or treat the value as a string. See [RPC overview — large integers](/reference-client/rpc-reference/rpc). + +::: + +
Example ````mdx-code-block ```json @@ -957,6 +962,7 @@ Response: ```json { "blockchain_state": { + "average_block_time": 18, "block_max_cost": 11000000000, "difficulty": 1976, "genesis_challenge_initialized": true, @@ -1070,14 +1076,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :------ | :------- | :------------------------------------------------------------------ | -| start | INTEGER | True | The start height | -| end | INTEGER | True | The end height (non-inclusive) | -| exclude_header_hash | BOOLEAN | False | Whether to exclude the header hash in the response [Default: false] | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| start | INTEGER | True | The start height | +| end | INTEGER | True | The end height (non-inclusive) | +| exclude_header_hash | BOOLEAN | False | Whether to omit `header_hash` on each block in the response [Default: false] | +| exclude_reorged | BOOLEAN | False | When true, skip blocks whose hash no longer matches the canonical chain at that height (forked blocks) [Default: false] | -
-Example +
Example ````mdx-code-block ```json @@ -1351,8 +1357,7 @@ Options: Request Parameters: None -
-Example +
Example ````mdx-code-block ```json @@ -1394,12 +1399,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :------------------------ | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :------------------------ | | header_hash | HEX STRING | True | The block's `header_hash` | -
-Example +
Example ````mdx-code-block ```json @@ -1478,13 +1482,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---- | :------ | :------- | :----------------------------- | +| Flag | Type | Required | Description | +| :---- | :------ | :------- | :------------------------------------------------ | | start | INTEGER | True | The start height (inclusive) | | end | INTEGER | True | The end height (non-inclusive) | -
-Example +
Example Get two block records (`3 300 000` and `3 300 001`): @@ -1648,8 +1651,8 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----- | :------ | :------- | :------------------------------------------ | +| Flag | Type | Required | Description | +| :----- | :------ | :------- | :--------------------------------------------------------------------------------------- | | height | INTEGER | True | The height to get (must be \<= peak height) | :::note @@ -1658,8 +1661,7 @@ Note that not all blocks will have all fields set here (depending on transaction ::: -
-Example +
Example ````mdx-code-block ```json @@ -1758,8 +1760,8 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :------------------------ | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :------------------------ | | header_hash | HEX STRING | True | The block's `header_hash` | :::note @@ -1768,8 +1770,7 @@ Keep in mind that most blocks do not contain any transactions. These blocks will ::: -
-Example +
Example ````mdx-code-block ```json @@ -2016,8 +2017,8 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :------------------------ | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :------------------------ | | header_hash | HEX STRING | True | The block's `header_hash` | :::note @@ -2026,8 +2027,7 @@ Keep in mind that most blocks do not contain any transactions. These blocks will ::: -
-Example +
Example ````mdx-code-block ```json @@ -2136,15 +2136,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------- | :------- | :------------------------------------------------------------------ | -| hint | HEX STRING | True | The hint to examine | -| start_height | INTEGER | False | The block height at which to begin the search | -| end_height | INTEGER | False | The block height at which to end the search | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :--------- | :------- | :------------------------------------------------------------------------------------- | +| hint | HEX STRING | True | The hint to examine | +| start_height | INTEGER | False | The block height at which to begin the search | +| end_height | INTEGER | False | The block height at which to end the search | | include_spent_coins | BOOLEAN | False | A boolean indicating whether to include spent coins (default=false) | -
-Example +
Example ````mdx-code-block ```json @@ -2207,15 +2206,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------------- | :------- | :------------------------------------------------------------------ | -| names | HEX STRING ARRAY | True | A list of coin_ids to examine | -| start_height | INTEGER | False | The block height at which to begin the search | -| end_height | INTEGER | False | The block height at which to end the search | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :--------------- | :------- | :------------------------------------------------------------------------------------- | +| names | HEX STRING ARRAY | True | A list of coin_ids to examine | +| start_height | INTEGER | False | The block height at which to begin the search | +| end_height | INTEGER | False | The block height at which to end the search | | include_spent_coins | BOOLEAN | False | A boolean indicating whether to include spent coins (default=false) | -
-Example +
Example ````mdx-code-block ```json @@ -2278,15 +2276,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------------- | :------- | :------------------------------------------------------------------ | -| parent_ids | HEX STRING ARRAY | True | A list of parent IDs to examine | -| start_height | INTEGER | False | The block height at which to begin the search | -| end_height | INTEGER | False | The block height at which to end the search | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :--------------- | :------- | :------------------------------------------------------------------------------------- | +| parent_ids | HEX STRING ARRAY | True | A list of parent IDs to examine | +| start_height | INTEGER | False | The block height at which to begin the search | +| end_height | INTEGER | False | The block height at which to end the search | | include_spent_coins | BOOLEAN | False | A boolean indicating whether to include spent coins (default=false) | -
-Example +
Example ````mdx-code-block ```json @@ -2361,15 +2358,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------- | :------- | :------------------------------------------------------------------ | -| puzzle_hash | HEX STRING | True | The puzzle hash to search for | -| start_height | INTEGER | False | The block height at which to begin the search | -| end_height | INTEGER | False | The block height at which to end the search | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :--------- | :------- | :------------------------------------------------------------------------------------- | +| puzzle_hash | HEX STRING | True | The puzzle hash to search for | +| start_height | INTEGER | False | The block height at which to begin the search | +| end_height | INTEGER | False | The block height at which to end the search | | include_spent_coins | BOOLEAN | False | A boolean indicating whether to include spent coins (default=false) | -
-Example +
Example ````mdx-code-block ```json @@ -2468,15 +2464,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------------- | :------- | :------------------------------------------------------------------ | -| puzzle_hashes | HEX STRING ARRAY | True | An array of puzzle hashes to examine | -| start_height | INTEGER | False | The block height at which to begin the search | -| end_height | INTEGER | False | The block height at which to end the search | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :--------------- | :------- | :------------------------------------------------------------------------------------- | +| puzzle_hashes | HEX STRING ARRAY | True | An array of puzzle hashes to examine | +| start_height | INTEGER | False | The block height at which to begin the search | +| end_height | INTEGER | False | The block height at which to end the search | | include_spent_coins | BOOLEAN | False | A boolean indicating whether to include spent coins (default=false) | -
-Example +
Example ````mdx-code-block ```json @@ -2561,8 +2556,7 @@ The `name` (coin ID) can be obtained by hashing the Coin object: `sha256(parent ::: -
-Example +
Example ````mdx-code-block ```json @@ -2596,40 +2590,135 @@ Response: --- +### `get_constants` + +Functionality: Returns the consensus constants for the current network (e.g. mainnet, testnet) + +Usage: chia rpc full_node [OPTIONS] get_constants [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +````mdx-code-block +```json +chia rpc full_node get_constants +``` +```` + +Response: + +````mdx-code-block +```json +{ + "constants": { + "AGG_SIG_AMOUNT_ADDITIONAL_DATA": "0x0f7d90dff95ef7b5ef11cfb79e2e4cd6f7252e8d2cfc6d5e7916e9ba6df68b19", + "AGG_SIG_ME_ADDITIONAL_DATA": "0xccd5bb71183532bff220ba46c268991a3ff07eb358e8255a65c30a2dce0e5fbb", + "AGG_SIG_PARENT_ADDITIONAL_DATA": "0x5e25e0935d33e96112f46a7d4d08b3d18af51ef523ccef2f2e0dbace0f9de773", + "AGG_SIG_PARENT_AMOUNT_ADDITIONAL_DATA": "0x4ad57e3a9b6a14d6d5d3b80f6cc72ec25d59d5ea39a43eae7ee8e46081ed7a07", + "AGG_SIG_PARENT_PUZZLE_ADDITIONAL_DATA": "0x29a34e3ed5a47b8e5c0a5d9e09ea4db7e2d0f9d6c4b8e2a1f5c3d7b6a0e4f8c2", + "AGG_SIG_PUZZLE_ADDITIONAL_DATA": "0x3d8ea74c2ba36f6e8ae2b3fe16b5bd8dd6c33c47b8e0a3f9c2d1e5b4a7f0d6e8", + "AGG_SIG_PUZZLE_AMOUNT_ADDITIONAL_DATA": "0x9f4a2c8e1b5d3f7a0c6e2b4d8f1a3c5e7b9d0f2a4c6e8b0d2f4a6c8e0b2d4f6", + "BLOCKS_CACHE_SIZE": 5120, + "COST_PER_BYTE": 12000, + "DIFFICULTY_CHANGE_MAX_FACTOR": 3, + "DIFFICULTY_CONSTANT_FACTOR": "0x80000000000000000", + "DIFFICULTY_STARTING": 7, + "DISCRIMINANT_SIZE_BITS": 1024, + "EPOCH_BLOCKS": 4608, + "GENESIS_CHALLENGE": "0xccd5bb71183532bff220ba46c268991a00000000000000000000000000000000", + "GENESIS_PRE_FARM_FARMER_PUZZLE_HASH": "0x3d8765d3a597ec1d99663f6c9816d915b9f68613ac94009884c4addaefcce6af", + "GENESIS_PRE_FARM_POOL_PUZZLE_HASH": "0xd23da14695a188ae5708dd152263c4db883eb27edeb936178d4d988b8f3ce5fc", + "HARD_FORK2_HEIGHT": 4294967290, + "HARD_FORK_HEIGHT": 5496000, + "MAX_BLOCK_COST_CLVM": 11000000000, + "MAX_BLOCK_COUNT_PER_REQUESTS": 32, + "MAX_COIN_AMOUNT": 18446744073709551615, + "MAX_FUTURE_TIME2": 120, + "MAX_GENERATOR_REF_LIST_SIZE": 512, + "MAX_PLOT_SIZE_V1": 50, + "MAX_PLOT_STRENGTH": 32, + "MAX_SUB_SLOT_BLOCKS": 128, + "MAX_VDF_WITNESS_SIZE": 64, + "MEMPOOL_BLOCK_BUFFER": 10, + "MIN_BLOCKS_PER_CHALLENGE_BLOCK": 16, + "MIN_PLOT_SIZE_V1": 32, + "MIN_PLOT_STRENGTH": 2, + "NUMBER_OF_TIMESTAMPS": 11, + "NUMBER_ZERO_BITS_PLOT_FILTER_V1": 9, + "NUMBER_ZERO_BITS_PLOT_FILTER_V2": 5, + "NUM_SPS_SUB_SLOT": 64, + "NUM_SP_INTERVALS_EXTRA": 3, + "PLOT_FILTER_128_HEIGHT": 10542000, + "PLOT_FILTER_32_HEIGHT": 20643000, + "PLOT_FILTER_64_HEIGHT": 15592000, + "PLOT_FILTER_V2_FIRST_ADJUSTMENT_HEIGHT": 4294967291, + "PLOT_FILTER_V2_SECOND_ADJUSTMENT_HEIGHT": 4294967292, + "PLOT_FILTER_V2_THIRD_ADJUSTMENT_HEIGHT": 4294967293, + "PLOT_SIZE_V2": 28, + "PLOT_V1_PHASE_OUT_EPOCH_BITS": 8, + "POOL_SUB_SLOT_ITERS": 37600000000, + "SIGNIFICANT_BITS": 8, + "SLOT_BLOCKS_TARGET": 32, + "SOFT_FORK8_HEIGHT": 8655000, + "SOFT_FORK9_HEIGHT": 8655000, + "SUB_EPOCH_BLOCKS": 384, + "SUB_SLOT_ITERS_STARTING": 134217728, + "SUB_SLOT_TIME_TARGET": 600, + "TESTNET": false, + "WEIGHT_PROOF_RECENT_BLOCKS": 1000, + "WEIGHT_PROOF_THRESHOLD": 2 + }, + "success": true +} +``` +```` + +
+ +--- + ### `get_fee_estimate` Functionality: Obtain an estimated fee for one or more targeted times for a transaction to be included in the blockchain. -Usage: chia rpc wallet [OPTIONS] get_fee_estimate [REQUEST] +Usage: chia rpc full_node [OPTIONS] get_fee_estimate [REQUEST] Options: -| Short Command | Long Command | Type | Required | Description | -| :------------ | :----------- | :--- | :------- | :------------------------------------------------------------------ | -| -j | --json-file | TEXT | False | Instead of REQUEST, provide a json file containing the request data | -| -h | --help | None | False | Show a help message and exit | +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | Request Parameters: -| Parameter | Type | Required | Description | -| :----------- | :------------ | :------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| spend_bundle | FILENAME | True\* | The spend bundle file (in json format) for which to estimate the fee (\* Exactly one of `spend_bundle` or `cost` must be specified) | -| cost | INTEGER | True\* | The CLVM cost for which to estimate the fee (\* Exactly one of `spend_bundle` or `cost` must be specified) | -| target_times | INTEGER ARRAY | True | An array of the targeted times for transaction inclusion, in seconds. Each targeted time must be at least 0 | +| Parameter | Type | Required | Description | +| :-------------------------------- | :------------ | :------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| target_times | INTEGER ARRAY | True | Target inclusion horizons in seconds (each value must be ≥ 0). Used both for the estimate request and echoed in the response. | +| spend_bundle | OBJECT | True\* | JSON spend bundle dict. The node derives CLVM cost via mempool pre-validation. (\* Exactly **one** of `spend_bundle`, `cost`, or `spend_type`.) | +| cost | INTEGER | True\* | Explicit CLVM cost to estimate against. (\* Exactly **one** of `spend_bundle`, `cost`, or `spend_type`.) | +| spend_type | STRING | True\* | Named preset cost (multiplied by `spend_count`). Valid values: `send_xch_transaction`, `cat_spend`, `take_offer`, `cancel_offer`, `nft_set_nft_did`, `nft_transfer_nft`, `create_new_pool_wallet`, `pw_absorb_rewards`, `create_new_did_wallet`. (\* Exactly **one** of `spend_bundle`, `cost`, or `spend_type`.) | +| spend_count | INTEGER | False | When using `spend_type`, multiply the preset cost by this integer [Default: 1] | :::note -- If `spend_bundle` is specified, then the cost of that spend bundle will first be obtained, followed by obtaining the estimated fee for that cost. Therefore, it is computationally cheaper to use `cost` than it is to use `spend_bundle`, other other factors being equal. -- This RPC takes into account the current size of the mempool relative to its maximum size, as well as the fee in mojos per cost (5 by default) +- The request must contain **exactly one** of `spend_bundle`, `cost`, or `spend_type`. Using `cost` avoids validating a spend bundle and is typically cheaper than `spend_bundle`. +- If `spend_type` is used, the node applies a fixed internal cost preset for that wallet operation type; multiply by `spend_count` when batching multiple operations. +- This RPC takes into account mempool size relative to its maximum, recent blocks, and the fee estimator’s view of the mempool. ::: -
-Example +
Example -Obtain a fee estimate for a spendbundle with a CLVM cost of 20 million. Targeted inclusion times are 1, 5, and 10 minutes. - -Note that this example was completed at a time when the mempool was not busy, so the fee estimates are all `0`. +Obtain a fee estimate for a CLVM cost of 20 million mojos. Targeted inclusion times are 1, 5, and 10 minutes. Numeric results depend on mempool pressure and the fee estimator. ````mdx-code-block ```json @@ -2643,7 +2732,7 @@ Response: ```json { "current_fee_rate": 0.0342163071650677, - "estimates": [684326.1433013539, 4077.432021994343, 4077.432021994343], + "estimates": [684326, 4077, 4077], "fee_rate_last_block": 0.0, "fees_last_block": 0, "full_node_synced": true, @@ -2662,6 +2751,8 @@ Response: ``` ```` +`estimates` are total mojos suggested for the given `cost` (or derived cost) at each `target_times` entry, sorted to be non-increasing. +
--- @@ -2681,12 +2772,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---- | :--------- | :------- | :----------------------------------------------------------- | -| tx_id | HEX STRING | True | The spend bundle hash (tx ID) for which to retrieve the item | +| Flag | Type | Required | Description | +| :----------------------------------- | :--------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| tx_id | HEX STRING | True | The spend bundle hash (tx ID) for which to retrieve the item | +| include_pending | BOOLEAN | False | When true, include mempool items that are not yet fully validated / pending [Default: false] | -
-Example +
Example Start by obtaining all of the mempool tx IDs: @@ -2855,12 +2946,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :--------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------- | | coin_name | STRING | True | The ID of the coin to retreive. Must be in the mempool in order to return a result | -
-Example +
Example ````mdx-code-block ```json @@ -2966,6 +3056,79 @@ Response: --- +### `create_block_generator` + +Functionality: Builds a candidate block generator from the current mempool against the latest peak (simulated block construction). This call can be CPU- and memory-intensive and is intended for advanced diagnostics or tooling, not routine wallet use. + +Usage: chia rpc full_node [OPTIONS] create_block_generator [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None (send `{}`). + +:::info + +Requires an initialized blockchain with a peak and an active mempool. If there is no peak, the response contains empty generator fields. + +::: + +
Example + +````mdx-code-block +```json +chia rpc full_node create_block_generator +``` +```` + +Response: + +````mdx-code-block +```json +{ + "additions": [ + { + "amount": 499993713061, + "parent_coin_info": "0xb9792e0b3f30e636499a5d556514ae94398a90d1462760952d46ab526c3e4e90", + "puzzle_hash": "0x712d36b40c8202ad230f082f76416dc0a3828817fee70bd45da4f9fe8bcc6880" + }, + { + "amount": 1000000000000, + "parent_coin_info": "0xb9792e0b3f30e636499a5d556514ae94398a90d1462760952d46ab526c3e4e90", + "puzzle_hash": "0x83e00e39cfd151b957b9ad244c089285a8b507efe68e3a0eae6d7fb045cad570" + } + ], + "cost": 13662942, + "generator": "0xff01ffffffa0cadd2124b7e96e21aeec29c3f135d2bb9057abbe7d579129812866f1d005384affff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04fffe84016b6b7fff80808080fffe820db78080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0aaa7438398700e566695c0b517ef2fb4bb3d88b554caf3532ae0f3eae58ee9059b86beb1278fa9f3e322c71b678eeb44ff018080ff8600ae9f784ef4ffff80ffff01ffff3dffa0adc99692cc9455dc549686e9e998f8eb7be27686df6ea8729883f0d9e964de408080ff808080ffffa0c76892cda4119c4b0abf14c2e432c623614873dcbb3dc974ea4b8f4efc49fcebffff02fffe81abffff04ffff01b0aa77ea04f9f6ba2d552a452bbc6760189b620e71592b72492729254a17250ce58bbd461573c7803dfcc68225f55ff220ff018080ff8600ae9f7ae831ffff80ffff01ffff3cffa0fe72234c2676abec275c3dc3057d9428833be8d9580be57f689e8733240d86ff80ffff33ffa083e00e39cfd151b957b9ad244c089285a8b507efe68e3a0eae6d7fb045cad570ff8600e8d4a51000ff8080ffff33ffa0712d36b40c8202ad230f082f76416dc0a3828817fee70bd45da4f9fe8bcc6880ff857469f299a580ffff34ff835b8d808080ff8080808080", + "refs": [], + "removals": [ + { + "amount": 749999941681, + "parent_coin_info": "0xc76892cda4119c4b0abf14c2e432c623614873dcbb3dc974ea4b8f4efc49fceb", + "puzzle_hash": "0x3a9edc60a69f0add50e9655b8e5e28cfa21e7b86467544426bfd092b95d37451" + }, + { + "amount": 749999771380, + "parent_coin_info": "0xcadd2124b7e96e21aeec29c3f135d2bb9057abbe7d579129812866f1d005384a", + "puzzle_hash": "0x9f85ecd85958012961a3dd73dc15289229eed9857fb4916fcdc6b624f0e6e2f1" + } + ], + "sig": "0xa97ffddfad72703e2af85e3ce7c8c59246921f24c4a0e6bbc96ec51800425f0ef403d01dd9fd5a85254dedcc4d1ff858015e5cec3a733850e6f25c4c3bad227fa0c2da73475840dad032d700ec30bcdc5a633a954c6a36196104fb43378c28b6", + "success": true +} +``` +```` + +`generator` is the serialized block program; `refs` lists generator ref heights; `additions` and `removals` are coins; `sig` is the aggregated signature; `cost` is the CLVM cost of the generated bundle. + +
+ +--- + ### `get_network_info` Functionality: Retrieves information about the current network @@ -2981,8 +3144,7 @@ Options: Request Parameters: None -
-Example +
Example ````mdx-code-block ```json @@ -2995,6 +3157,7 @@ Response: ````mdx-code-block ```json { + "genesis_challenge": "0xccd5bb71183532bff220ba46c268991a00000000000000000000000000000000", "network_name": "mainnet", "network_prefix": "xch", "success": true @@ -3006,6 +3169,362 @@ Response: --- +### `get_connections` + +Functionality: Lists active peer connections for the full node’s server. Optionally filter by peer protocol role. + +Usage: chia rpc full_node [OPTIONS] get_connections [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :----------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| node_type | INTEGER | False | Filter by node role: `1` FULL_NODE, `2` HARVESTER, `3` FARMER, `4` TIMELORD, `5` INTRODUCER, `6` WALLET, `7` DATA_LAYER, `8` SOLVER. Omit to include every connection. | + +
Example + +````mdx-code-block +```json +chia rpc full_node get_connections '{"node_type": 1}' +``` +```` + +Response: + +````mdx-code-block +```json +{ + "connections": [ + { + "bytes_read": 142950063, + "bytes_written": 2420659, + "creation_time": 1678170508.123, + "last_message_time": 1678171624.456, + "local_port": 8444, + "node_id": "b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab", + "peer_host": "127.0.0.1", + "peer_port": 8444, + "peer_server_port": 8444, + "type": 1 + }, + { + "bytes_read": 870298, + "bytes_written": 51, + "creation_time": 1678170601.001, + "last_message_time": 1678171624.456, + "local_port": 8444, + "node_id": "17f2d4b4e0c8b3b8f86e6b2c6a5f6f6e4c3a2f1e0d9c8b7a6f5e4d3c2b1a0987", + "peer_host": "192.168.1.20", + "peer_port": 8444, + "peer_server_port": 8444, + "type": 1 + } + ], + "success": true +} +``` +```` + +The `type` field matches the peer's `NodeType` (see request table above). This example uses `node_type: 1` to show full-node peers only; your own peers and counts will vary based on current network connectivity. + +
+ +--- + +### `open_connection` + +Functionality: Opens an outbound connection from this full node to another peer (`host` / `port`). + +Usage: chia rpc full_node [OPTIONS] open_connection [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :--- | :------ | :------- | :------------------------------------ | +| host | STRING | True | Hostname or IP of the remote peer | +| port | INTEGER | True | Port of the remote peer’s Chia server | + +
Example + +````mdx-code-block +```json +chia rpc full_node open_connection '{"host": "introducer.chia.net", "port": 8444}' +``` +```` + +Response on success: + +````mdx-code-block +```json +{ + "success": true +} +``` +```` + +If the connection cannot be established, the response is `{"success": false, "error": "could not connect to ..."}`. + +
+ +--- + +### `close_connection` + +Functionality: Closes existing peer connections whose `node_id` matches the given 32-byte node identifier. + +Usage: chia rpc full_node [OPTIONS] close_connection [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :--------------------------- | :--------- | :------- | :------------------------------------------------------------------------------ | +| node_id | HEX STRING | True | Remote peer node ID (same format as reported by connections) | + +
Example + +````mdx-code-block +```json +chia rpc full_node close_connection '{"node_id": "b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab"}' +``` +```` + +Response: + +````mdx-code-block +```json +{} +``` +```` + +If no connection matches, the RPC fails with an error indicating the node ID was not found. + +
+ +--- + +### `stop_node` + +Functionality: Requests a graceful shutdown of the service via the RPC server’s `stop_cb` (same mechanism as a normal node stop). + +Usage: chia rpc full_node [OPTIONS] stop_node [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None (send `{}`). + +:::warning + +Stops the full node process. Use only on nodes you control; do not expose the RPC port publicly. + +::: + +
Example + +````mdx-code-block +```json +chia rpc full_node stop_node '{}' +``` +```` + +Response: + +````mdx-code-block +```json +{} +``` +```` + +
+ +--- + +### `get_version` + +Functionality: Returns the Chia reference client version string that the node was built with. + +Usage: chia rpc full_node [OPTIONS] get_version [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +````mdx-code-block +```json +chia rpc full_node get_version +``` +```` + +Response: + +````mdx-code-block +```json +{ + "success": true, + "version": "2.6.0" +} +``` +```` + +
+ +--- + +### `get_log_level` + +Functionality: Returns the current root logger level name and the list of levels accepted by `set_log_level`. + +Usage: chia rpc full_node [OPTIONS] get_log_level [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +````mdx-code-block +```json +chia rpc full_node get_log_level +``` +```` + +Response: + +````mdx-code-block +```json +{ + "available_levels": [ + "CRITICAL", + "FATAL", + "ERROR", + "WARN", + "WARNING", + "INFO", + "DEBUG", + "NOTSET" + ], + "level": "INFO", + "success": true +} +``` +```` + +
+ +--- + +### `set_log_level` + +Functionality: Sets the root logger to the given level for this process. Returns the new level, available levels, whether the change succeeded, and any validation errors. + +Usage: chia rpc full_node [OPTIONS] set_log_level [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :---- | :----- | :------- | :----------------------------------------------------- | +| level | STRING | True | Name of a logging level (see above) | + +
Example + +````mdx-code-block +```json +chia rpc full_node set_log_level '{"level": "INFO"}' +``` +```` + +Response: + +````mdx-code-block +```json +{ + "available_levels": ["CRITICAL", "ERROR", "WARNING", "INFO", "DEBUG", "NOTSET"], + "errors": [], + "level": "INFO", + "success": true +} +``` +```` + +The `errors` array lists unknown or invalid level strings when `success` is false. + +
+ +--- + +### `reset_log_level` + +Functionality: Restores logging to the level configured for this service in config (`log_level`, falling back to the default). + +Usage: chia rpc full_node [OPTIONS] reset_log_level [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None (send `{}`). + +
Example + +````mdx-code-block +```json +chia rpc full_node reset_log_level '{}' +``` +```` + +The JSON response matches `set_log_level`: current `level`, `available_levels`, `errors`, and `success`. + +
+ +--- + ### `get_network_space` Functionality: Retrieves an estimate of the netspace, which is the total plotted space of all farmers, in bytes @@ -3021,13 +3540,18 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------------------- | :--------- | :------- | :-------------------- | +| Flag | Type | Required | Description | +| :------------------------------------------------------------------------------------- | :--------- | :------- | :-------------------- | | older_block_header_hash | HEX STRING | True | The start header hash | | newer_block_header_hash | HEX STRING | True | The end header hash | -
-Example +:::note + +The response `space` field is a netspace estimate in bytes (`uint128` in the node). Values often exceed `Number.MAX_SAFE_INTEGER` (2^53 - 1). JavaScript and other IEEE-754 JSON parsers may lose precision; use a bigint-capable parser or treat the value as a string. See [RPC overview — large integers](/reference-client/rpc-reference/rpc). + +::: + +
Example ````mdx-code-block ```json @@ -3070,10 +3594,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------ | :--------- | :------- | :--------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------- | :--------- | :------- | :--------------------------------- | | coin_id | HEX STRING | True | Coin ID of the coin to look up | -| height | INTEGER | True | Height at which the coin was spent | +| height | INTEGER | True | Height at which the coin was spent | :::note @@ -3083,8 +3607,7 @@ By definition, coins that are unspent do not have their original puzzle or solut ::: -
-Example +
Example ````mdx-code-block ```json @@ -3130,10 +3653,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :--------- | :------- | :------------------------------------------------------------------------------- | -| sp_hash | HEX STRING | True\* | The hash of the output for a signage point (if it's in the middle of a sub slot) | -| challenge_hash | HEX STRING | True\* | The challenge_hash for the subslot (if it's an end of sub slot challenge) | +| Flag | Type | Required | Description | +| :---------------------------------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------------------- | +| sp_hash | HEX STRING | True\* | The hash of the output for a signage point (if it's in the middle of a sub slot) | +| challenge_hash | HEX STRING | True\* | The challenge_hash for the subslot (if it's an end of sub slot challenge) | :::note @@ -3141,8 +3664,7 @@ Request Parameters: ::: -
-Example +
Example ````mdx-code-block ```json @@ -3234,8 +3756,7 @@ Options: Request Parameters: None -
-Example +
Example ````mdx-code-block ```json @@ -3249,40 +3770,46 @@ Response: ```json { "routes": [ - "/get_blockchain_state", + "/close_connection", + "/create_block_generator", + "/get_additions_and_removals", + "/get_aggsig_additional_data", + "/get_all_mempool_items", + "/get_all_mempool_tx_ids", "/get_block", - "/get_blocks", "/get_block_count_metrics", - "/get_block_record_by_height", "/get_block_record", + "/get_block_record_by_height", "/get_block_records", "/get_block_spends", "/get_block_spends_with_conditions", - "/get_unfinished_block_headers", - "/get_network_space", - "/get_additions_and_removals", - "/get_initial_freeze_period", - "/get_network_info", - "/get_recent_signage_point_or_eos", - "/get_coin_records_by_puzzle_hash", - "/get_coin_records_by_puzzle_hashes", + "/get_blockchain_state", + "/get_blocks", "/get_coin_record_by_name", + "/get_coin_records_by_hint", "/get_coin_records_by_names", "/get_coin_records_by_parent_ids", - "/get_coin_records_by_hint", - "/push_tx", - "/get_puzzle_and_solution", - "/get_all_mempool_tx_ids", - "/get_all_mempool_items", + "/get_coin_records_by_puzzle_hash", + "/get_coin_records_by_puzzle_hashes", + "/get_connections", + "/get_constants", + "/get_fee_estimate", + "/get_log_level", "/get_mempool_item_by_tx_id", "/get_mempool_items_by_coin_name", - "/get_fee_estimate", - "/get_connections", - "/open_connection", - "/close_connection", - "/stop_node", + "/get_network_info", + "/get_network_space", + "/get_puzzle_and_solution", + "/get_recent_signage_point_or_eos", "/get_routes", - "/healthz" + "/get_unfinished_block_headers", + "/get_version", + "/healthz", + "/open_connection", + "/push_tx", + "/reset_log_level", + "/set_log_level", + "/stop_node" ], "success": true } @@ -3316,8 +3843,7 @@ blocks after it. ::: -
-Example +
Example ````mdx-code-block ```json @@ -3566,8 +4092,7 @@ This RPC returns `200` if successful. It is lightweight and can be queried often ::: -
-Example +
Example ````mdx-code-block ```json @@ -3605,12 +4130,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | :--- | :------- | :------------------------------ | +| Flag | Type | Required | Description | +| :-------------------------------- | :--- | :------- | :------------------------------ | | spend_bundle | JSON | True | Spend bundle to submit, in JSON | -
-Example +
Example ````mdx-code-block ```json diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/harvester-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/harvester-rpc.md index 79a1c0990c5..b6d9b2212ce 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/harvester-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/harvester-rpc.md @@ -9,8 +9,7 @@ import TabItem from '@theme/TabItem'; This document provides a comprehensive reference to Chia's Harvester RPC API. -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -55,8 +54,7 @@ Note that the new directory must already exist on the system ::: -
-Example +
Example First, add the directory to the local file system: @@ -107,8 +105,7 @@ As long as this command includes the required `filename` flag, it will always ou ::: -
-Example +
Example ```json chia rpc harvester delete_plot '{"filename": "/plots/plot-k25-2022-07-11-19-22-a2ece0fd13e017f7b88911be5f91aa1e1866c89964c863f743f5c92e07118805.plot"}' @@ -151,8 +148,7 @@ The plots will be grouped into three categories: ::: -
-Example +
Example ```json chia rpc harvester get_plots @@ -211,8 +207,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc harvester get_plot_directories @@ -249,8 +244,7 @@ Options: Request Parameters: None -
-Example +
Example ```json { @@ -303,8 +297,7 @@ If successful, this command will output `"success": true` ::: -
-Example +
Example ```json chia rpc harvester refresh_plots @@ -347,8 +340,7 @@ As long as this command includes the required `dirname` flag, it will always out ::: -
-Example +
Example ```json chia rpc harvester remove_plot_directory '{"dirname": "/plots_new"}' diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/nft-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/nft-rpc.md index 518941a2c7e..d8192edbc51 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/nft-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/nft-rpc.md @@ -7,8 +7,7 @@ slug: /reference-client/rpc-reference/nft-rpc import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -26,6 +25,37 @@ chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}'
+These methods are [wallet RPC](/reference-client/rpc-reference/wallet-rpc) calls: use `chia rpc wallet` with the command name (for example `nft_mint_nft`). They are implemented on `WalletRpcApi` in the Chia reference client, together with the rest of the wallet. The HTTP server also registers shared routes from `RpcServer` (connections, version, logging, health, and so on). The full sorted list of all wallet HTTP paths is given in [get_routes on the wallet RPC page](/reference-client/rpc-reference/wallet-rpc#get_routes). + +### `get_routes` + +Functionality: List every path on the wallet RPC server: all `WalletRpcApi` handlers plus the shared `RpcServer` routes. + +Usage: chia rpc wallet [OPTIONS] get_routes [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_routes +``` + +Response: + +The response is a JSON object with `success` and a `routes` array. The canonical sorted list is kept in one place: [Wallet RPC — get_routes](/reference-client/rpc-reference/wallet-rpc#get_routes). + +
+ +--- + ## Reference ### `nft_add_uri` @@ -43,14 +73,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :--------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID of the DID wallet to transfer | -| nft_coin_id | HEX STRING | True | The coin ID of the NFT on which to add a URI | -| key | STRING | True | Must be either `u` (data URI), `mu` (metadata URI), or `lu` (license URI) | -| uri | STRING | True | The URI to add | -| fee | NUMBER | False | The one-time blockchain fee to be used upon adding a URI | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :---------------------------------------------------- | :--------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID of the DID wallet to transfer | +| nft_coin_id | HEX STRING | True | The coin ID of the NFT on which to add a URI | +| key | STRING | True | Must be either `u` (data URI), `mu` (metadata URI), or `lu` (license URI) | +| uri | STRING | True | The URI to add | +| fee | NUMBER | False | The one-time blockchain fee to be used upon adding a URI | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | :::info @@ -60,8 +90,7 @@ Request Parameters: ::: -
-Example +
Example ```json chia rpc wallet nft_add_uri ' @@ -162,15 +191,15 @@ Options: Request Parameters: -| Parameter | Sub-Parameter | Required | Description | -| :-------------- | :------------------------------------------------------------------------------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| royalty_assets | Each royalty asset requires three sub-parameters, listed on the following lines | False | A list of NFTs for which to calculate royalties. If this parameter is not included, then nothing will be returned | -| | asset | True | The asset ID of the NFT to be traded. This is only used for display in the response; a bogus value may be used | -| | royalty_address | True | The address where the royalties will be sent. A bogus value may be used | -| | royalty_percentage | True | The number of basis points in the royalty. For example, a value of `321` equates to a 3.21% royalty | -| fungible_assets | Each fungible asset requires two sub-parameters, listed on the following lines | False | The assets against which to calculate royalties. If this parameter is not included, no royalties will be returned | -| | asset | True | The name of the asset for which to trade one or more NFTs. A bogus value may be used. Standard naming convention is `xch` for XCH or the asset ID for CATs. Note that no royalties are calculated for NFT:NFT trades, so NFT assets should not be included here | -| | amount | True | The amount (in mojos) to trade the NFT(s) for | +| Parameter | Sub-Parameter | Required | Description | +| :----------------------------------- | :------------------------------------------------------------------------------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| royalty_assets | Each royalty asset requires three sub-parameters, listed on the following lines | False | A list of NFTs for which to calculate royalties. If this parameter is not included, then nothing will be returned | +| | asset | True | The asset ID of the NFT to be traded. This is only used for display in the response; a bogus value may be used | +| | royalty_address | True | The address where the royalties will be sent. A bogus value may be used | +| | royalty_percentage | True | The number of basis points in the royalty. For example, a value of `321` equates to a 3.21% royalty | +| fungible_assets | Each fungible asset requires two sub-parameters, listed on the following lines | False | The assets against which to calculate royalties. If this parameter is not included, no royalties will be returned | +| | asset | True | The name of the asset for which to trade one or more NFTs. A bogus value may be used. Standard naming convention is `xch` for XCH or the asset ID for CATs. Note that no royalties are calculated for NFT:NFT trades, so NFT assets should not be included here | +| | amount | True | The amount (in mojos) to trade the NFT(s) for | A few things to note: @@ -184,8 +213,7 @@ A few things to note: - When NFTs are traded for other NFTs, no royalties are exchanged - Although this RPC has multiple required parameters, the `royalty_percentage` and `amount` are the only values used in these calculations. The `asset` is only required for display in the solution; it's just a naming convention to use `xch` or the `asset_id` -
-Example +
Example ```json chia rpc wallet nft_calculate_royalties '{ @@ -265,12 +293,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :--------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | wallet_id | NUMBER | False | The ID of the wallet in which to count NFTs [Default: null (count all NFTs)] | -
-Example 1 +
Example 1 Specify the correct NFT wallet: @@ -290,8 +317,7 @@ Response:
-
-Example 2 +
Example 2 If `wallet_id` is not specified, it will be treated as `null`: @@ -311,8 +337,7 @@ Response:
-
-Example 3 +
Example 3 If a non-NFT wallet is specified, an error will be thrown: @@ -345,12 +370,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----- | :----- | :------- | :-------------------- | +| Flag | Type | Required | Description | +| :-------------------------- | :----- | :------- | :-------------------- | | did_id | NUMBER | True | The DID ID to examine | -
-Example +
Example ```json chia rpc wallet nft_get_by_did '{"did_id": "did:chia:1kzxqrt8f2h8psr8zuzen9dxgmxx5v35s0rj3jy637qjannu3zlesds0el5"}' @@ -384,8 +408,8 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :--------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :--------------------------------------------------- | | coin_id | NUMBER | True | The coin ID of the NFT about which to retrieve info | | wallet_id | NUMBER | False | The Wallet ID of the NFT from which to retrieve info | @@ -395,8 +419,7 @@ Request Parameters: ::: -
-Example 1 +
Example 1 Get info for an NFT that is owned locally: @@ -446,8 +469,7 @@ Response:
-
-Example 2 +
Example 2 In the case where the NFT is not owned by the local wallet, you can obtain info from its NFT ID: @@ -513,14 +535,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :----- | :------- | :----------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID from which to retrieve the NFTs | +| Flag | Type | Required | Description | +| :------------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID from which to retrieve the NFTs | | start_index | NUMBER | False | The NFT index at which to start retrieving the NFTs [Default: `0`] | -| num | NUMBER | False | The maximum number of NFTs to retrieve [Default: `0`] | +| num | NUMBER | False | The maximum number of NFTs to retrieve [Default: `0`] | -
-Example +
Example ```json chia rpc wallet nft_get_nfts '{"wallet_id": 2}' @@ -579,8 +600,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet nft_get_wallets_with_dids @@ -620,12 +640,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :----------------------------- | | wallet_id | NUMBER | True | The Wallet ID of an NFT wallet | -
-Example +
Example ```json chia rpc wallet nft_get_wallet_did '{"wallet_id": 5}' @@ -659,27 +678,26 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------------------- | :----------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The ID of the NFT wallet to use for bulk minting | -| metadata_list | STRING ARRAY | True | A list of dicts containing the metadata for each NFT to be minted | -| royalty_percentage | NUMBER | False | The royalty that will go to the original artist each time the NFT is sold. The percentage is multiplied by 100 -- for example, to set a 3% royalty, set this value to 300. The default value is 0 | -| royalty_address | STRING | False | The wallet address of the NFT's artist. This is where royalties will be sent. It could be either an XCH address or a DID address | -| target_list | STRING ARRAY | False | A list of wallet addresses where the NFTs will be sent upon minting | -| mint_number_start | NUMBER | False | The starting point for mint number used in intermediate launcher puzzle. Default: 1 | -| mint_total | NUMBER | False | The total number of NFTs in the collection. Note that this is not necessarily reflective of the number of NFTs this command will create in the spend bundle, which is derived based on the `metadata_list`. For example, you could set `mint_total` to `1000` and pass only 10 dicts in `metadata_list`. | -| xch_coin_list | STRING ARRAY | False | A list of coins to be used for funding the minting spend. These coins can be created in the future | -| xch_change_target | HEX STRING | False | For use with bulk minting, so we can specify the puzzle hash that the change from the funding transaction goes to. | -| new_innerpuzhash | HEX STRING | False | The new inner puzzle hash for the DID once it is spent. For bulk minting we generally don't provide this as the default behaviour is to re-use the existing inner puzzle hash | -| new_p2_puzhash | HEX STRING | False | The new p2 puzzle hash for the DID once it is spent. For bulk minting we generally don't provide this as the default behaviour is to re-use the existing inner puzzle hash | -| did_coin_dict | DICTIONARY | False | The did coin to use for minting. Required for bulk minting when the DID coin will be created in the future | -| did_lineage_parent_hex | HEX STRING | False | The parent coin to use for the lineage proof in the DID spend. Needed for bulk minting when the coin will be created in the future | -| mint_from_did | BOOLEAN | False | Boolean to determine whether to mint from a DID. Default: false | -| fee | NUMBER | False | A blockchain fee to be deducted with each mint | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | - -
-Example +| Flag | Type | Required | Description | +| :------------------------------------------------------------------------------------ | :----------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The ID of the NFT wallet to use for bulk minting | +| metadata_list | STRING ARRAY | True | A list of dicts containing the metadata for each NFT to be minted | +| royalty_percentage | NUMBER | False | The royalty that will go to the original artist each time the NFT is sold. The percentage is multiplied by 100 -- for example, to set a 3% royalty, set this value to 300. The default value is 0 | +| royalty_address | STRING | False | The wallet address of the NFT's artist. This is where royalties will be sent. It could be either an XCH address or a DID address | +| target_list | STRING ARRAY | False | A list of wallet addresses where the NFTs will be sent upon minting | +| mint_number_start | NUMBER | False | The starting point for mint number used in intermediate launcher puzzle. Default: 1 | +| mint_total | NUMBER | False | The total number of NFTs in the collection. Note that this is not necessarily reflective of the number of NFTs this command will create in the spend bundle, which is derived based on the `metadata_list`. For example, you could set `mint_total` to `1000` and pass only 10 dicts in `metadata_list`. | +| xch_coin_list | STRING ARRAY | False | A list of coins to be used for funding the minting spend. These coins can be created in the future | +| xch_change_target | HEX STRING | False | For use with bulk minting, so we can specify the puzzle hash that the change from the funding transaction goes to. | +| new_innerpuzhash | HEX STRING | False | The new inner puzzle hash for the DID once it is spent. For bulk minting we generally don't provide this as the default behaviour is to re-use the existing inner puzzle hash | +| new_p2_puzhash | HEX STRING | False | The new p2 puzzle hash for the DID once it is spent. For bulk minting we generally don't provide this as the default behaviour is to re-use the existing inner puzzle hash | +| did_coin_dict | DICTIONARY | False | The did coin to use for minting. Required for bulk minting when the DID coin will be created in the future | +| did_lineage_parent_hex | HEX STRING | False | The parent coin to use for the lineage proof in the DID spend. Needed for bulk minting when the coin will be created in the future | +| mint_from_did | BOOLEAN | False | Boolean to determine whether to mint from a DID. Default: false | +| fee | NUMBER | False | A blockchain fee to be deducted with each mint | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | + +
Example ```json chia rpc wallet nft_mint_bulk '{ @@ -789,26 +807,25 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID in which to mint an NFT | -| uris | STRING ARRAY | True | A list of URIs to mark the location(s) of the NFT | -| hash | HEX STRING | True | The hash of the NFT's data. This should use sha256 for proper verification against the URI list | -| did_id | STRING | False | Optionally specify the DID to be associated with this NFT | -| meta_uris | STRING ARRAY | False | A list of URIs to mark the location(s) of the NFT's metadata | -| meta_hash | HEX STRING | False | The hash of the NFT's metadata | -| license_uris | STRING ARRAY | False | A list of URIs to mark the location(s) of the NFT's license | -| license_hash | HEX STRING | False | The hash of the NFT's license | -| royalty_address | STRING | False | The wallet address of the NFT's artist. This is where royalties will be sent. It could be either an XCH address or a DID address | -| royalty_percentage | NUMBER | False | The royalty that will go to the original artist each time the NFT is sold. The percentage is multiplied by 100 -- for example, to set a 3% royalty, set this value to 300. The default value is 0 | -| target_address | STRING | False | The wallet address of the initial owner of the NFT. This may be the same as the royalty address | -| edition_number | NUMBER | False | If this NFT has multiple editions (multiple identical copies of an NFT), then this parameter indicates the edition number of this NFT. | -| edition_total | NUMBER | False | If this NFT has multiple editions, then this parameter indicates the total number of editions of this NFT. This parameter should be used if and only if the `edition_number` parameter was also used | -| fee | NUMBER | False | The one-time blockchain fee to be used upon minting the NFT | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | - -
-Example 1 - Mint an NFT without using a DID +| Flag | Type | Required | Description | +| :-------------------------------------- | :----------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID in which to mint an NFT | +| uris | STRING ARRAY | True | A list of URIs to mark the location(s) of the NFT | +| hash | HEX STRING | True | The hash of the NFT's data. This should use sha256 for proper verification against the URI list | +| did_id | STRING | False | Optionally specify the DID to be associated with this NFT | +| meta_uris | STRING ARRAY | False | A list of URIs to mark the location(s) of the NFT's metadata | +| meta_hash | HEX STRING | False | The hash of the NFT's metadata | +| license_uris | STRING ARRAY | False | A list of URIs to mark the location(s) of the NFT's license | +| license_hash | HEX STRING | False | The hash of the NFT's license | +| royalty_address | STRING | False | The wallet address of the NFT's artist. This is where royalties will be sent. It could be either an XCH address or a DID address | +| royalty_percentage | NUMBER | False | The royalty that will go to the original artist each time the NFT is sold. The percentage is multiplied by 100 -- for example, to set a 3% royalty, set this value to 300. The default value is 0 | +| target_address | STRING | False | The wallet address of the initial owner of the NFT. This may be the same as the royalty address | +| edition_number | NUMBER | False | If this NFT has multiple editions (multiple identical copies of an NFT), then this parameter indicates the edition number of this NFT. | +| edition_total | NUMBER | False | If this NFT has multiple editions, then this parameter indicates the total number of editions of this NFT. This parameter should be used if and only if the `edition_number` parameter was also used | +| fee | NUMBER | False | The one-time blockchain fee to be used upon minting the NFT | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | + +
Example 1 - Mint an NFT without using a DID ```json chia rpc wallet nft_mint_nft '{ @@ -863,8 +880,7 @@ Response:
-
-Example 2 - Mint an NFT with a DID. Specify data, metadata, and license URIs and hashes, as well as royalties +
Example 2 - Mint an NFT with a DID. Specify data, metadata, and license URIs and hashes, as well as royalties ```json chia rpc wallet nft_mint_nft '{ @@ -989,15 +1005,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| nft_coin_list | STRING ARRAY | True | A list of coin IDs corresponding to the NFTs, along with the current wallet_ids. Syntax: `[{"nft_coin_id": COIN_ID/NFT_ID, "wallet_id": WALLET_ID}, ...]` | -| did_id | STRING | False | The ID of the DID to which to transfer the NFTs. [Default: no DID (reset the NFTs' DIDs)] | -| fee | NUMBER | False | An optional blockchain fee | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :------------------------------------------------------ | :----------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| nft_coin_list | STRING ARRAY | True | A list of coin IDs corresponding to the NFTs, along with the current wallet_ids. Syntax: `[{"nft_coin_id": COIN_ID/NFT_ID, "wallet_id": WALLET_ID}, ...]` | +| did_id | STRING | False | The ID of the DID to which to transfer the NFTs. [Default: no DID (reset the NFTs' DIDs)] | +| fee | NUMBER | False | An optional blockchain fee | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example Move four NFTs from one DID (wallet_id 6) to another (did:chia:1cxw5dqug4gavvgylx88zfkmqv235ryr6j9tvyjwwuga0pa52wjvqavdyar): @@ -1092,16 +1107,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID that holds the NFT on which to set the DID | -| nft_coin_id | NUMBER | True | The coin ID of the NFT on which to set the DID | -| did_id | NUMBER | False | Optionally specify the DID to be associated with this NFT. If this parameter is not specified, the DID will be Unassigned | -| fee | NUMBER | False | The one-time blockchain fee to be used upon adding a URI | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :---------------------------------------------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID that holds the NFT on which to set the DID | +| nft_coin_id | NUMBER | True | The coin ID of the NFT on which to set the DID | +| did_id | NUMBER | False | Optionally specify the DID to be associated with this NFT. If this parameter is not specified, the DID will be Unassigned | +| fee | NUMBER | False | The one-time blockchain fee to be used upon adding a URI | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example First, we'll show the details of an NFT that is not associated with a DID: @@ -1271,14 +1285,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :------ | :------- | :-------------------------------------------------- | -| wallet_id | NUMBER | True | The ID of an NFT wallet | -| coin_id | NUMBER | True | The coin_id of the NFT on which to set the status | -| in_transaction | BOOLEAN | True | A boolean to set the transaction status for the NFT | +| Flag | Type | Required | Description | +| :---------------------------------- | :------ | :------- | :--------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The ID of an NFT wallet | +| coin_id | NUMBER | True | The coin_id of the NFT on which to set the status | +| in_transaction | BOOLEAN | True | A boolean to set the transaction status for the NFT | -
-Example +
Example ```json chia rpc wallet nft_set_nft_status '{"wallet_id": 5, "coin_id": "0xb08c01ace955ce180ce2e0b332b4c8d98d46469078e5191351f025d9cf9117f3", "in_transaction": false}' @@ -1311,15 +1324,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| nft_coin_list | STRING ARRAY | True | A list of coin IDs corresponding to the NFTs, along with the current wallet_ids. Syntax: `[{"nft_coin_id": COIN_ID/NFT_ID, "wallet_id": WALLET_ID}, ...]` | -| target_address | STRING | True | The address to which to transfer the NFTs | -| fee | NUMBER | False | An optional blockchain fee | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :------------------------------------------------------ | :----------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| nft_coin_list | STRING ARRAY | True | A list of coin IDs corresponding to the NFTs, along with the current wallet_ids. Syntax: `[{"nft_coin_id": COIN_ID/NFT_ID, "wallet_id": WALLET_ID}, ...]` | +| target_address | STRING | True | The address to which to transfer the NFTs | +| fee | NUMBER | False | An optional blockchain fee | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example Transfer four NFTs from wallet 6 to a new address (this will also remove them from their DID custody): @@ -1405,16 +1417,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :--------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID of the NFT to transfer | -| target_address | STRING | True | The address to transfer the NFT to. For NFT0 this must be an XCH address. For NFT1 this could also be a DID address | -| nft_coin_id | HEX STRING | True | The coin ID of the NFT to transfer | -| fee | NUMBER | False | The one-time blockchain fee to be used upon transferring the NFT | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :---------------------------------------------------- | :--------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID of the NFT to transfer | +| target_address | STRING | True | The address to transfer the NFT to. For NFT0 this must be an XCH address. For NFT1 this could also be a DID address | +| nft_coin_id | HEX STRING | True | The coin ID of the NFT to transfer | +| fee | NUMBER | False | The one-time blockchain fee to be used upon transferring the NFT | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example ```json chia rpc wallet nft_transfer_nft ' diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/offer-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/offer-rpc.md index bded387f84c..3dd979fddb3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/offer-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/offer-rpc.md @@ -7,8 +7,7 @@ slug: /reference-client/rpc-reference/offer-rpc import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -26,6 +25,37 @@ chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}'
+These methods are [wallet RPC](/reference-client/rpc-reference/wallet-rpc) calls: use `chia rpc wallet` with the command name (for example `create_offer_for_ids`). They are implemented on `WalletRpcApi` in the Chia reference client, together with the rest of the wallet. The HTTP server also registers shared routes from `RpcServer` (connections, version, logging, health, and so on). The full sorted list of all wallet HTTP paths is given in [get_routes on the wallet RPC page](/reference-client/rpc-reference/wallet-rpc#get_routes). + +### `get_routes` + +Functionality: List every path on the wallet RPC server: all `WalletRpcApi` handlers plus the shared `RpcServer` routes. + +Usage: chia rpc wallet [OPTIONS] get_routes [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_routes +``` + +Response: + +The response is a JSON object with `success` and a `routes` array. The canonical sorted list is kept in one place: [Wallet RPC — get_routes](/reference-client/rpc-reference/wallet-rpc#get_routes). + +
+ +--- + ## Reference ### `cancel_offer` @@ -43,11 +73,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------- | -| trade_id | STRING | True | The `trade_id` of the Offer to cancel. Can be retrieved from an Offer file by calling `cdv inspect spendbundles ` | -| fee | NUMBER | False | An optional fee (in mojos) to include with the cancellation [Default: `0`] | -| secure | BOOLEAN | False | If `true`, then "cancel on blockchain," ie spend the coins being offered. If `false`, then cancel locally [Default: `true`] | +| Flag | Type | Required | Description | +| :---------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| trade_id | STRING | True | The `trade_id` of the Offer to cancel. Can be retrieved from an Offer file by calling `cdv inspect spendbundles ` | +| fee | NUMBER | False | An optional fee (in mojos) to include with the cancellation [Default: `0`] | +| secure | BOOLEAN | False | If `true`, then "cancel on blockchain," ie spend the coins being offered. If `false`, then cancel locally [Default: `true`] | :::note @@ -55,8 +85,7 @@ If you set `secure` to `false`, then the Offer will not be canceled on the block ::: -
-Example +
Example ```json chia rpc wallet cancel_offer '{"trade_id": "0x039492f84708b8a585ddaa0dd44fa8db1a6afdad799b0900e37dfc9097f1f351", "secure": false}' @@ -89,16 +118,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------- | -| secure | BOOLEAN | True | If `true`, then "cancel on blockchain," ie spend the coins being offered. If `false`, then cancel locally | -| fee | NUMBER | False | An optional fee (in mojos) to include with the cancellation [Default: `0`] | -| batch_size | NUMBER | False | The number of Offers to cancel in one batch [Default: `5`] | -| cancel_all | BOOLEAN | False | Cancel all Offers [Default: `false`] | -| asset_id | STRING | False | The ID of the asset to cancel; only used when `cancel_all` is `false` [Default: `xch`] | +| Flag | Type | Required | Description | +| :------------------------------ | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| secure | BOOLEAN | True | If `true`, then "cancel on blockchain," ie spend the coins being offered. If `false`, then cancel locally | +| fee | NUMBER | False | An optional fee (in mojos) to include with the cancellation [Default: `0`] | +| batch_size | NUMBER | False | The number of Offers to cancel in one batch [Default: `5`] | +| cancel_all | BOOLEAN | False | Cancel all Offers [Default: `false`] | +| asset_id | STRING | False | The ID of the asset to cancel; only used when `cancel_all` is `false` [Default: `xch`] | -
-Example +
Example ```json chia rpc wallet cancel_offers '{"secure": true, "batch_fee": 1, "batch_size": 2}' @@ -151,8 +179,7 @@ The Offer is not valid if it is in any of the following states: ::: -
-Example +
Example ```json chia rpc wallet check_offer_validity '{"offer": "offer1qqr83wcuu2rykcmqvpsxzgqq4gnsn0v2w6gchlaawrmeju4af4arrwu5s2kvce6at3nhmsa4v03kvgvc8furkat55swhlsmpwjj86a9ylhljq8mfs7jw6p044wxg9a7lhhuwphnff6my6aujm3m37wvl6q0kzy3tde6nh7w9j6d0nlchdsgk628m7aktm6jfqa47hwwnj705chexjdkhufx3fd9zegkcwhfknvg9auleg2neqcjpcj8mjehmfeks7gazhwlz4ffam6ukt3wwddlya3qah92s4wgqhr73797a5fyq68clmcfmhc85auqtzmuvure07v84jch8vzcwldm0qdf4uwatuj4xtjfxadlp37x8xf8nupxtz7jl7reyvj2fg9q5t057kfe95e2jdftx5etj2f6k2kjfdx48zmjwdx55j4jfwf4xzj24295hnxd7gfz425j72x99jc2kf9py56dxtxu62an2g4lxzkvwsegk5s27hed9j52f0eqhykn206h9vnnxt66mtqvw3ft85cqam9935q4wlmd45q9u7t5t86dl3g37vrrghz8aelwgga99mg3e0uylklaume8alal4xtksxxynga2v2echu8ksx4xnjsym2f5xv56wveex5hn34f0yzzkgadxu27dqvx4wyyssnxdmzcyn5tlsl0v0tnsalqhlwgly708udd0n9ee5q0lqnhm7hul7m8e6cxn3he9u3sz546dwmxtualtc0h5f89knj34tdmkrrvknf0pzat0ju7hm3a7hz7raqqkfalm408a6jtm6xn9a0lhchxu5z4dhf7wandtdah3qjdh844tjanauwj73kjap8ga08qujwarxwljxvalq3w88ll5vcra379zflxglfrvhwa844090t2cc53pafme08pcaa625hmzaw9hf320ekrc9zhdkmw484cr9zp3tclgr4fdrxv52xvegsdlqdefln5a47zuzfu7t8hh7f3y0fd5dcqktrt57ntn30xm6nja58d8kfh8rsct4lypkfyq0npsh2sxwddqvkk4rqdk03c5jz90yfs4glll3w888k40ml09v39n6xhpdhlz85lm9mcdjlsujrck85alr6lceqjgl0etsp9tv98mq48hkmvulalxn9vgn0nht9k6sayee0mdwyfp0wd67ewknh64pxsppf3gprjxwmgsdmrfj4l8ejtukh846a43sh036d6a3e80gkmjdmf3nfu0qr50vxrg0nmezadj5hkku0srmhefz57xxw5re2na6pku46t5neaaq5fzkda9kwcrqzramre95yeayjwnvk7cgqrw7kzddne7778jslravahl4ua8v2tklam7v9x0yc63l7mu7j8xkeu7t4unqs72l9q0th3npxakcgeynt8uaksf2edgpjtc07techllaakccnazlwm9ehu4wc08dhk7ufjn576jkwzem9m88jlhl3l3wtelltvvnvhvgvd5zq543hprajzagvtsamxaxn2vt4lzn83aagcvw8rt65l57a88ua4a0ls70tekewukd805hq9xeuwj9uy89pvgf4zyq053kluthp3d4z7h8vaa4nv75tmwlc5y3duk7l4aylcmwaqrdljzl4gjm62nuxdgftl0lqh9m7xmeaha0t7dc0tp3wrwah94w7xaltkvnq460f8l09atlnd0vueveq3glt7mka5xk28fas8hawnqamaa80nfhdr7jna5qvldunsnhh70ra78ze5ycatyhplvmlhc0xf8skk4fklj2pkwtxh30xwr03qr9ckmz7r97dwe8hlaajk0t6664dahv6y78anx29pmgxkdzmk3zj57am2ngdh05u699ce8k0qrrp5f3eccrkarcssjm4950tv63cfmf8dnh5nl9vp8w7hagjjuwm6udnftt24le2wnd79kadf4jxxrmuh5myxte6vh2sky9vlvnc3j2wjm079msdng0uan048n0t09lmsnn0mfl2teylev3avfgdupa32x57tjxe6t86phk6ypgrk4e2x92kasy447ds0te305gdsrrdvl9d8vurct22gqel9z8dh2pg2y3zdxjpa9t4ga98agazj4s3grz5g2cldpq5zez2jpdevdc7p28mfzrkru7nsk9vgdv9x7jmn9edtf5fn69xw84sxjaacjdemhdfsqaxu49dlzm0aq4rk0ptpxclwncekuk4yu29tgakdl53uwfdkaavr8dnmweljt66csujmjkeeznhecn9cx5aaw9du02wkkp09qkd8kmjyqtqqv6yzy7lk89vq"}' @@ -187,19 +214,20 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------- | -| offer | OBJECT | True | A dictionary `[str, int]` of the Offer to create (see the examples below for specifics) | -| fee | NUMBER | False | An optional fee (in mojos) to include with the Offer [Default: `0`] | -| validate_only | BOOLEAN | False | Set to `true` to verify the validity of a potential Offer, rather than actually creating an Offer [Default: `false`] | -| driver_dict | OBJECT | False | A dictionary `[str, Any]` containing metadata of the asset being requested, for example an NFT's on-chain metadata | -| min_coin_amount | NUMBER | False | The minimum coin size to be included in the Offer [Default: `0`] | -| max_coin_amount | NUMBER | False | The maximum coin size to be included in the Offer [Default: `0`] | -| solver | | False | Default: None | -| min_height | NUMBER | False | The minimum block height that must be reached before this Offer becomes valid [Default: `null` (not used)] | -| min_time | NUMBER | False | The minimum UNIX timestamp that must be reached before this Offer becomes valid [Default: `null` (not used)] | -| max_height | NUMBER | False | The maximum block height where this Offer is still considered valid, aka the expiry height [Default: `null` (not used)] | -| max_time | NUMBER | False | The maximum UNIX timestamp where this Offer is stil considered valid, aka the expiry timestamp [Default: `null` (not used)] | +| Flag | Type | Required | Description | +| :-------------------------------------------------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| offer | OBJECT | True | A dictionary `[str, int]` of the Offer to create (see the examples below for specifics) | +| fee | NUMBER | False | An optional fee (in mojos) to include with the Offer [Default: `0`] | +| validate_only | BOOLEAN | False | Set to `true` to verify the validity of a potential Offer, rather than actually creating an Offer [Default: `false`] | +| driver_dict | OBJECT | False | A dictionary `[str, Any]` containing metadata of the asset being requested, for example an NFT's on-chain metadata | +| min_coin_amount | NUMBER | False | The minimum coin size to be included in the Offer [Default: `0`] | +| max_coin_amount | NUMBER | False | The maximum coin size to be included in the Offer [Default: `0`] | +| solver | | False | Default: None | +| min_height | NUMBER | False | The minimum block height that must be reached before this Offer becomes valid [Default: `null` (not used)] | +| min_time | NUMBER | False | The minimum UNIX timestamp that must be reached before this Offer becomes valid [Default: `null` (not used)] | +| max_height | NUMBER | False | The maximum block height where this Offer is still considered valid, aka the expiry height [Default: `null` (not used)] | +| max_time | NUMBER | False | The maximum UNIX timestamp where this Offer is stil considered valid, aka the expiry timestamp [Default: `null` (not used)] | +| offer_only | BOOLEAN | False | If `true`, return only the offer without creating a trade record or transactions. The response keeps the same shape but `trade_record` will be `null` and `transactions` / `unsigned_transactions` will be empty. Useful when the full response would exceed WebSocket payload limits [Default: `false`] | :::note @@ -218,8 +246,13 @@ Your log file will contain `ASSERT_SECONDS_ABSOLUTE_FAILED` in this case, but th ::: -
-Example 1: sell an NFT +:::info `offer_only` behavior change in 2.7.2 + +Prior to 2.7.2, setting `offer_only` to `true` returned a different, trimmed response type that omitted `trade_record`, `transactions`, and `unsigned_transactions` fields entirely. Starting in 2.7.2, the response always uses the same shape as a normal `create_offer_for_ids` response, but with `trade_record` set to `null` and `transactions` / `unsigned_transactions` set to empty lists. This makes it easier to deserialize at call sites without type-checking the response format. + +::: + +
Example 1: sell an NFT This example will create an Offer to sell an NFT. First, list the NFTs in the local wallet. For example: @@ -358,8 +391,7 @@ It does not contain any sensitive information. A "thief" only has two options: a
-
-Example 2: buy an NFT +
Example 2: buy an NFT This example will create an Offer to buy an NFT. This example will create an Offer to buy an NFT. By definition, the NFT cannot be in your wallet, so you first need to query the blockchain to obtain an NFT's info based on its ID alone: @@ -533,8 +565,7 @@ chia rpc wallet create_offer_for_ids '{ "offer":{ "1":-100000000000,"b4158076fee
-
-Example 3: Expiring Offer +
Example 3: Expiring Offer In this example, we will offer 0.1 CATs (`Launcher ID: 91aa...004r`) in exchange for 1 TXCH (`Wallet ID: 1`). In addition, we will add an expiry timestamp so that this Offer will expire on Jan. 1, 2024: @@ -605,8 +636,7 @@ Response:
-
-Example 4: Offer in time window +
Example 4: Offer in time window **Per the above note, this example will create a valid Offer, but the reference wallet currently (as of 2.1.0) will not be able to read it.** @@ -696,19 +726,18 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| start | NUMBER | False | The first Offer to display, inclusive [Default: `0`] | -| end | NUMBER | False | The last Offer to display, exclusive [Default: `10`] | -| exclude_my_offers | BOOLEAN | False | If `true`, don't show Offers that originated from this wallet [Default: `false`] | -| exclude_taken_offers | BOOLEAN | False | If `true`, don't show any Offers with a status of `CONFIRMED` [Default: `false`] | -| include_completed | BOOLEAN | False | If `true`, show completed Offers [Default: `false`] | -| sort_key | STRING | False | Optionally change the sort order of the results, [sort_keys members](https://github.com/Chia-Network/chia-blockchain/blob/5f6c336e757534d3a36b1a03612e05b412a18c61/chia/wallet/transaction_sorting.py#L6) [Default: `confirmed_at_height`] | -| reverse | BOOLEAN | False | If `true`, reverse the results [Default: `false`] | -| file_contents | BOOLEAN | False | If `true`, return a summary for the Offer. If `false`, only return the Offer's basic metadata [Default: `false`] | +| Flag | Type | Required | Description | +| :------------------------------------------------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| start | NUMBER | False | The first Offer to display, inclusive [Default: `0`] | +| end | NUMBER | False | The last Offer to display, exclusive [Default: `10`] | +| exclude_my_offers | BOOLEAN | False | If `true`, don't show Offers that originated from this wallet [Default: `false`] | +| exclude_taken_offers | BOOLEAN | False | If `true`, don't show any Offers with a status of `CONFIRMED` [Default: `false`] | +| include_completed | BOOLEAN | False | If `true`, show completed Offers [Default: `false`] | +| sort_key | STRING | False | Optionally change the sort order of the results, [sort_keys members](https://github.com/Chia-Network/chia-blockchain/blob/5f6c336e757534d3a36b1a03612e05b412a18c61/chia/wallet/transaction_sorting.py#L6) [Default: `confirmed_at_height`] | +| reverse | BOOLEAN | False | If `true`, reverse the results [Default: `false`] | +| file_contents | BOOLEAN | False | If `true`, return a summary for the Offer. If `false`, only return the Offer's basic metadata [Default: `false`] | -
-Example +
Example Show the first Offer: @@ -798,13 +827,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :------ | :------- | :--------------------------------------------------------------------------------------------------------------- | -| trade_id | STRING | True | The `trade_id` of the Offer | +| Flag | Type | Required | Description | +| :--------------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| trade_id | STRING | True | The `trade_id` of the Offer | | file_contents | BOOLEAN | False | If `true`, return a summary for the Offer. If `false`, only return the Offer's basic metadata [Default: `false`] | -
-Example +
Example ```json chia rpc wallet get_offer '{"trade_id": "0x0958db8393a63dab6b2afa78abbfe91a0487e5b06e25174ec8c49d383f18afc0"}' @@ -895,8 +923,7 @@ Options: Request Parameters: None -
-Example +
Example ```bash chia rpc wallet get_offers_count @@ -932,13 +959,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :------ | :------- | :-------------------------------------------------------------------- | -| offer | STRING | True | The text of the Offer to summarize | +| Flag | Type | Required | Description | +| :------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------------------------------------- | +| offer | STRING | True | The text of the Offer to summarize | | advanced | BOOLEAN | False | Show advanced information, including expiration time [Default: false] | -
-Example 1 +
Example 1 The `offer` parameter is the pasted contents of an Offer file: @@ -988,8 +1014,7 @@ Response:
-
-Example 2: with advanced details +
Example 2: with advanced details This example will show the Offer's expiration timestamp (`max_time`): @@ -1046,13 +1071,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---- | :-------- | :------- | :-------------------------------------------------------------------- | -| offer | FILE PATH | True | The text of the Offer to take (must be in the `PENDING_ACCEPT` state) | -| fee | NUMBER | False | An optional fee (in mojos) to include with the Offer [Default: `0`] | +| Flag | Type | Required | Description | +| :---- | :-------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | +| offer | FILE PATH | True | The text of the Offer to take (must be in the `PENDING_ACCEPT` state) | +| fee | NUMBER | False | An optional fee (in mojos) to include with the Offer [Default: `0`] | -
-Example +
Example To take an Offer, paste its contents in the RPC call: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/rpc.md index 3581182d76d..54e0ef64c4e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/rpc.md @@ -4,8 +4,7 @@ title: RPC Overview slug: /reference-client/rpc-reference/rpc --- -
- Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -23,6 +22,24 @@ chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}'
+ + +:::warning + +### Large integers in JSON responses + +Some RPC responses include integers larger than `Number.MAX_SAFE_INTEGER` (2^53 - 1). Parsers that treat JSON numbers as IEEE-754 doubles may lose precision or fail. + +Full node routes that return especially large values include: + +- [`get_blockchain_state`](/reference-client/rpc-reference/full-node-rpc#get_blockchain_state) (`blockchain_state.space`, a network-space estimate) +- [`get_network_space`](/reference-client/rpc-reference/full-node-rpc#get_network_space) (`space` in the response) + +The simulator full node also exposes [`get_all_puzzle_hashes`](/reference-client/rpc-reference/simulator-rpc#get_all_puzzle_hashes), which can return large coin amounts in its `puzzle_hashes` map. + +Each affected endpoint documents the precise fields on its reference page. When building clients in JavaScript or other languages with limited integer types, treat these fields as strings or use a bigint-capable JSON parser. Verify behavior against a live node if your stack coerces JSON numbers automatically. +::: + The Chia node and services come with a JSON RPC API server that allows you to access information and control the services. These are accessible via HTTP, WebSockets, or via client SDKs. The ports can be configured in `~/.chia/mainnet/config/config.yaml`. @@ -41,6 +58,7 @@ Need to validate that your RPC endpoints are working correctly? Use the **[RPC V - Harvester: 8560 - Wallet: 9256 - DataLayer: 8562 +- Solver: 8667 - Crawler: 8561 - Timelord: 8557 @@ -202,13 +220,14 @@ namespace ChiaExamples | Service | Managed Objects | Associated API | Associated RPC API | | ----------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | -| FarmerService | [Farmer](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/farmer/farmer.py) | [FarmerAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/farmer/farmer_api.py) | [FarmerRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/farmer_rpc_api.py) | +| FarmerService | [Farmer](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/farmer/farmer.py) | [FarmerAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/farmer/farmer_api.py) | [FarmerRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/farmer/farmer_rpc_api.py) | | FullNodeService | [FullNode](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/full_node.py) | [FullNodeAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/full_node_api.py) | [FullNodeRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/full_node_rpc_api.py) | | HarvesterService | [Harvester](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/harvester/harvester.py) | [HarvesterAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/harvester/harvester_api.py) | [HarvesterRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/harvester_rpc_api.py) | | IntroducerService | [Introducer](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/introducer/introducer.py) | [IntroducerAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/introducer/introducer_api.py) | [FullNodeRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/full_node_rpc_api.py) | | CrawlerService | [Crawler](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/seeder/crawler.py) | [CrawlerAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/seeder/crawler_api.py) | [CrawlerRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/crawler_rpc_api.py) | | DataLayerService | [DataLayer](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/data_layer/data_layer.py) | [DataLayerAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/data_layer/data_layer_api.py) | [DataLayerRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/data_layer_rpc_api.py) | | TimelordService | [Timelord](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/timelord/timelord.py) | [TimelordAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/timelord/timelord_api.py) | [TimelordRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/timelord_rpc_api.py) | +| SolverService | [Solver](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/solver/solver.py) | [SolverAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/solver/solver_api.py) | [SolverRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/solver/solver_rpc_api.py) | | WalletService | [WalletNode](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/wallet_node.py) | [WalletNodeAPI](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/wallet_node_api.py) | [WalletRpcApi](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/rpc/wallet_rpc_api.py) | **Explanation:** @@ -238,14 +257,13 @@ Options: Request Services: -| Type | Required | Description | -| :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------ | -| STRING | True | The service to query for its log level; valid examples include: "crawler", "data_layer", "farmer", "full_node", "harvester", "timelord", "wallet" | +| Type | Required | Description | +| :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| STRING | True | The service to query for its log level; valid examples include: "crawler", "data_layer", "farmer", "full_node", "harvester", "solver", "timelord", "wallet" | Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_log_level @@ -287,18 +305,17 @@ Options: Request Services: -| Type | Required | Description | -| :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | -| STRING | True | Set the log level for this service; valid examples include: "crawler", "data_layer", "farmer", "full_node", "harvester", "timelord", "wallet" | +| Type | Required | Description | +| :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| STRING | True | Set the log level for this service; valid examples include: "crawler", "data_layer", "farmer", "full_node", "harvester", "solver", "timelord", "wallet" | Request Parameters: -| Flag | Type | Required | Description | -| :---- | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :---- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | | level | STRING | True | The log level to set for the designated service; valid levels are: "CRITICAL", "FATAL", "ERROR", "WARN", "WARNING", "INFO", "DEBUG", "NOTSET" | -
-Example +
Example ```json chia rpc wallet set_log_level ' @@ -345,14 +362,13 @@ Options: Request Services: -| Type | Required | Description | -| :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------- | -| STRING | True | Reset the log level for this service; valid examples include: "crawler", "data_layer", "farmer", "full_node", "harvester", "timelord", "wallet" | +| Type | Required | Description | +| :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| STRING | True | Reset the log level for this service; valid examples include: "crawler", "data_layer", "farmer", "full_node", "harvester", "solver", "timelord", "wallet" | Request Parameters: None -
-Example +
Example ```json chia rpc wallet reset_log_level diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/simulator-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/simulator-rpc.md index 06f6169e14f..a797ccebd1d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/simulator-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/simulator-rpc.md @@ -8,7 +8,7 @@ slug: /reference-client/rpc-reference/simulator-rpc The simulator gives you complete control of a private Chia blockchain, including the ability to advance and revert blocks as needed. -This page includes a comprehensive list of Chia's Remote Procedure Calls for using the simulator. +This page documents **simulator-only** full node RPCs (block farming, reorgs, chain inspection). The simulator’s HTTP API is `SimulatorFullNodeRpcApi`, which **extends** the standard [`FullNodeRpcApi`](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/full_node_rpc_api.py) with the routes below, and still exposes every normal full node route plus the shared [RPC server](/reference-client/rpc-reference/full-node-rpc) helpers (`get_network_info`, `get_connections`, `healthz`, logging, etc.). For all non-simulator endpoints, see [Full node RPC](/reference-client/rpc-reference/full-node-rpc). For more info, see the following: @@ -20,8 +20,7 @@ For more info, see the following: import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -58,14 +57,13 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :----------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| address | True | The address to use to farm the block | -| guarantee_tx_block | False | Set to `True` to farm a transaction block (ie, farm new blocks until a tx block is farmed); set to `False` to farm the next block, which could also be a transaction block, but is not guaranteed (Default: `False`) | -| blocks | False | Number of blocks to farm. If `guarantee_tx_block` is `True`, then each block will be a transaction block (Default: 1) | +| Parameter | Required | Description | +| :----------------------------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| address | True | The address to use to farm the block | +| guarantee_tx_block | False | JSON boolean: `true` forces each farmed block to be a **transaction** block (`farm_new_transaction_block`). `false` uses `farm_new_block` (next block may or may not be a transaction block). Default: `false`. | +| blocks | False | Number of blocks to farm. If `guarantee_tx_block` is `True`, then each block will be a transaction block (Default: 1) | -
-Example 1 +
Example 1 Farm a single block: @@ -84,13 +82,12 @@ Response:
-
-Example 2 +
Example 2 Farm three transaction blocks: ```json -chia rpc full_node farm_block '{"address": "txch1v3wjjapxvepyadvr2wgp7272md84lv6kmaxyxm4lq5le2jcc90zqkxhgv6", "guarantee_tx_block": "True", "blocks": 3}' +chia rpc full_node farm_block '{"address": "txch1v3wjjapxvepyadvr2wgp7272md84lv6kmaxyxm4lq5le2jcc90zqkxhgv6", "guarantee_tx_block": true, "blocks": 3}' ``` Response: @@ -108,7 +105,7 @@ Response: ### `get_all_blocks` -Functionality: Return a list of all blocks in the blockhain +Functionality: Return a list of all blocks in the blockchain Usage: chia rpc full_node [OPTIONS] get_all_blocks [REQUEST] @@ -121,11 +118,10 @@ Options: Request Parameters: None -
-Example +
Example ```json -chia rpc full_node get_all_blocks +chia rpc full_node get_all_blocks '{}' ``` Response (abbreviated): @@ -228,15 +224,14 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :------------------ | :------- | :------------------------------------------------------------------------------------ | +| Parameter | Required | Description | +| :------------------------------------------------------------ | :------- | :----------------------------------------------------------------------------------------------------------------------- | | include_spent_coins | False | Boolean, if `True` then spent coins will be included in the result (Default: `False`) | -
-Example +
Example ```json -chia rpc full_node get_all_coins +chia rpc full_node get_all_coins '{}' ``` Response (abbreviated): @@ -293,11 +288,16 @@ Options: Request Parameters: None -
-Example +:::note + +Coin amounts in the `puzzle_hashes` map can exceed `Number.MAX_SAFE_INTEGER` (2^53 - 1). JavaScript and other IEEE-754 JSON parsers may lose precision; use a bigint-capable parser or treat these values as strings. See [RPC overview — large integers](/reference-client/rpc-reference/rpc). + +::: + +
Example ```json -chia rpc full_node get_all_puzzle_hashes +chia rpc full_node get_all_puzzle_hashes '{}' ``` Response: @@ -338,11 +338,10 @@ Options: Request Parameters: None -
-Example +
Example ```json -chia rpc full_node get_auto_farming +chia rpc full_node get_auto_farming '{}' ``` Response: @@ -373,11 +372,10 @@ Options: Request Parameters: None -
-Example +
Example ```json -chia rpc full_node get_farming_ph +chia rpc full_node get_farming_ph '{}' ``` Response: @@ -395,7 +393,7 @@ You can then use `cdv encode` to convert this puzzle hash to an address: cdv encode --prefix txch 5fb3e0ccc23760a7f917a81e7872cc921f9ddbc86582dfb4f64eee66fad5e740 ``` -Response: +Example `cdv` output: ```bash txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2 @@ -420,15 +418,14 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :------------------- | :------- | :------------------------------------------------------------------ | -| num_of_blocks_to_rev | False | The number of blocks to go back (Default: 1) | -| num_of_new_blocks | False | The number of blocks to add (Default: 1) | -| revert_all_blocks | False | Boolean, set to `True` to fork all blocks (Default: `False`) | -| random_seed | False | String, used to randomize the seed, which will differentiate reorgs | +| Parameter | Required | Description | +| :------------------------------------------------------------------------------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| num_of_blocks_to_rev | False | The number of blocks to go back (Default: 1) | +| num_of_new_blocks | False | The number of blocks to add (Default: 1) | +| revert_all_blocks | False | Boolean, set to `True` to fork all blocks (Default: `False`) | +| random_seed | False | JSON boolean (default `true`): when `true`, the reorg uses a fresh random `bytes32` seed; when `false`, no random seed is passed (deterministic path). **Not** a string seed value—the request key name is historical. | -
-Example 1 +
Example 1 Starting from block 11, we'll revert 3 blocks and create 5 new blocks: @@ -447,13 +444,12 @@ Response:
-
-Example 2 +
Example 2 -Reorg with a random seed: +Reorg while disabling the random seed parameter: ```json -chia rpc full_node reorg_blocks '{"random_seed": "aaaaaa"}' +chia rpc full_node reorg_blocks '{"random_seed": false}' ``` Response: @@ -484,13 +480,12 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :---------------- | :------- | :------------------------------------------------------------- | +| Parameter | Required | Description | +| :---------------------------------------------------------- | :------- | :------------------------------------------------------------------------------------------------ | | num_of_blocks | False | The number of blocks to revert (Default: 1) | | delete_all_blocks | False | Boolean, set to `True` to revert all blocks (Default: `False`) | -
-Example 1 +
Example 1 Revert a single block: @@ -509,13 +504,12 @@ Response:
-
-Example 2 +
Example 2 Delete all blocks -- this will reset the blockchain: ```json -chia rpc full_node revert_blocks '{"delete_all_blocks": "True"}' +chia rpc full_node revert_blocks '{"delete_all_blocks": true}' ``` Response: @@ -546,12 +540,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :---------------------------------------- | +| Parameter | Required | Description | +| :----------------------------- | :------- | :---------------------------------------- | | auto_farm | True | Boolean to enable or disable auto farming | -
-Example 1 +
Example 1 Enable auto farming: @@ -570,8 +563,7 @@ Response:
-
-Example 2 +
Example 2 Disable auto farming: @@ -591,3 +583,79 @@ Response:
--- + +### `get_routes` + +Functionality: Returns every HTTP RPC path registered on this simulator full node: **standard full node** endpoints, **RPC server** helpers (`get_network_info`, `get_connections`, `healthz`, log level, etc.), and **simulator-only** routes (`/farm_block`, `/get_all_blocks`, `/reorg_blocks`, …). Paths are sorted alphabetically here for parity with `chia-blockchain` `main`; your client may return a different order. + +Usage: chia rpc full_node [OPTIONS] get_routes [REQUEST] + +Request Parameters: None + +
Example + +```json +chia rpc full_node get_routes +``` + +Response (paths merged from `FullNodeRpcApi`, `RpcServer`, and `SimulatorFullNodeRpcApi`): + +```json +{ + "routes": [ + "/close_connection", + "/create_block_generator", + "/farm_block", + "/get_additions_and_removals", + "/get_aggsig_additional_data", + "/get_all_blocks", + "/get_all_coins", + "/get_all_mempool_items", + "/get_all_mempool_tx_ids", + "/get_all_puzzle_hashes", + "/get_auto_farming", + "/get_block", + "/get_block_count_metrics", + "/get_block_record", + "/get_block_record_by_height", + "/get_block_records", + "/get_block_spends", + "/get_block_spends_with_conditions", + "/get_blockchain_state", + "/get_blocks", + "/get_coin_record_by_name", + "/get_coin_records_by_hint", + "/get_coin_records_by_names", + "/get_coin_records_by_parent_ids", + "/get_coin_records_by_puzzle_hash", + "/get_coin_records_by_puzzle_hashes", + "/get_connections", + "/get_farming_ph", + "/get_fee_estimate", + "/get_log_level", + "/get_mempool_item_by_tx_id", + "/get_mempool_items_by_coin_name", + "/get_network_info", + "/get_network_space", + "/get_puzzle_and_solution", + "/get_recent_signage_point_or_eos", + "/get_routes", + "/get_unfinished_block_headers", + "/get_version", + "/healthz", + "/open_connection", + "/push_tx", + "/reorg_blocks", + "/reset_log_level", + "/revert_blocks", + "/set_auto_farming", + "/set_log_level", + "/stop_node" + ], + "success": true +} +``` + +
+ +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/solver-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/solver-rpc.md index de7dbe04b12..874db5254ad 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/solver-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/solver-rpc.md @@ -18,8 +18,7 @@ The Solver participates in Proof of Space 2 (PoS2) farming with V2 plots. Farmer ::: -
- Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -54,8 +53,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc solver get_state @@ -88,8 +86,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc solver get_routes diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/vc-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/vc-rpc.md index 530f41d604f..c5277986f6b 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/vc-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/vc-rpc.md @@ -7,8 +7,7 @@ slug: /reference-client/rpc-reference/vc-rpc import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -
-Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -26,6 +25,37 @@ chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}'
+These methods are [wallet RPC](/reference-client/rpc-reference/wallet-rpc) calls: use `chia rpc wallet` with the command name (for example `vc_mint`). They are implemented on `WalletRpcApi` in the Chia reference client, together with the rest of the wallet. The HTTP server also registers shared routes from `RpcServer` (connections, version, logging, health, and so on). The full sorted list of all wallet HTTP paths is given in [get_routes on the wallet RPC page](/reference-client/rpc-reference/wallet-rpc#get_routes). + +### `get_routes` + +Functionality: List every path on the wallet RPC server: all `WalletRpcApi` handlers plus the shared `RpcServer` routes. + +Usage: chia rpc wallet [OPTIONS] get_routes [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_routes +``` + +Response: + +The response is a JSON object with `success` and a `routes` array. The canonical sorted list is kept in one place: [Wallet RPC — get_routes](/reference-client/rpc-reference/wallet-rpc#get_routes). + +
+ +--- + ## Reference ### `vc_add_proofs` @@ -47,8 +77,7 @@ Request Parameters: | :-------- | :--------- | :------- | :---------------------------------------------------- | | proofs | DICTIONARY | True | A dictionary of key/value pairs to be added as proofs | -
-Example +
Example Add two example proofs: @@ -83,14 +112,13 @@ Options: Request Parameters: -| Parameter | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------------------- | -| vc_id | STRING | True | The launcher ID of a Verifiable Credential | +| Parameter | Type | Required | Description | +| :------------------------- | :----- | :------- | :----------------------------------------- | +| vc_id | STRING | True | The launcher ID of a Verifiable Credential | This RPC returns the `vc_record` representing the specified Verifiable Credential -
-Example +
Example ```json chia rpc wallet vc_get '{"vc_id": "0x75ea50e79d6020c655306bc27208fc454d656c3d45246763146a626cca17871d"}' @@ -148,15 +176,14 @@ Options: Request Parameters: -| Parameter | Type | Required | Description | -| :-------- | :------ | :------- | :---------------------------------------------------- | +| Parameter | Type | Required | Description | +| :-------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------ | | start | INTEGER | False | The index to start the list at [default: 0] | | count | INTEGER | False | The maximum number of results to return [default: 50] | This RPC returns all `vc_records` in the specified range, along with any proofs associated with the roots contained within. -
-Example +
Example In this example, there are two existing credentials: @@ -226,8 +253,7 @@ Request Parameters: This RPC returns a dictionary of root hashes mapped to dictionaries of key value pairs of 'proofs'. -
-Example +
Example ```json chia rpc wallet vc_get_proofs_for_root '{"root": "96c9597578333c840f895f30af6d40b9f6c0d69100db1a13ae2e26e4c94acdd3"}' @@ -264,16 +290,15 @@ Options: Request Parameters: -| Parameter | Type | Required | Description | -| :------------- | :----- | :------- | :----------------------------------------------------------------------------------- | -| did_id | STRING | True | The ID of the DID that will be minting the VC | +| Parameter | Type | Required | Description | +| :---------------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | +| did_id | STRING | True | The ID of the DID that will be minting the VC | | target_address | STRING | False | The address where the VC will be sent upon minting [Default: send to minting wallet] | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | This RPC returns a `vc_record` containing all the information of the soon-to-be-confirmed VC, as well as any relevant transactions. -
-Example +
Example If the Proof Provider does not yet have a DID, you can mint one now: @@ -437,17 +462,16 @@ Options: Request Parameters: -| Parameter | Type | Required | Description | -| :--------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------ | -| vc_id | STRING | True | The launcher ID of the Verifiable Credential to spend | -| new_puzhash | None | False | The puzzle hash where the VC will be sent (can be derived from an XCH address) | -| new_proof_hash | None | False | Can be used to update the vc's proofs -- the new root/proof hash | -| provider_inner_puzhash | STRING | False | Can be used to update the vc's proofs -- the proof provider's inner puzzle hash | -| reuse_puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from [Default: generate new puzzle hash] | -| fee | None | False | An optional blockchain fee, in mojos | +| Parameter | Type | Required | Description | +| :--------------------------------------------------------------- | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| vc_id | STRING | True | The launcher ID of the Verifiable Credential to spend | +| new_puzhash | None | False | The puzzle hash where the VC will be sent (can be derived from an XCH address) | +| new_proof_hash | None | False | Can be used to update the vc's proofs -- the new root/proof hash | +| provider_inner_puzhash | STRING | False | Can be used to update the vc's proofs -- the proof provider's inner puzzle hash | +| reuse_puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from [Default: generate new puzzle hash] | +| fee | None | False | An optional blockchain fee, in mojos | -
-Example +
Example ```json chia rpc wallet vc_spend '{"vc_id": "0x75ea50e79d6020c655306bc27208fc454d656c3d45246763146a626cca17871d", "new_puzhash": "0x0b56c02785c476c05612e800cb1493d6a2c08d75bde3305159087b179eb736b2", "new_proof_hash": "96c9597578333c840f895f30af6d40b9f6c0d69100db1a13ae2e26e4c94acdd3", "fee": 100000000}' @@ -656,14 +680,13 @@ Options: Request Parameters: -| Parameter | Type | Required | Description | -| :------------ | :------ | :------- | :------------------------------------------------------------------------------------------------------------------ | -| vc_parent_id | STRING | True | The parent ID of the VC coin | -| reuse_puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from [Default: generate new puzzle hash] | -| fee | INTEGER | False | An optional blockchain fee, in mojos | +| Parameter | Type | Required | Description | +| :----------------------------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| vc_parent_id | STRING | True | The parent ID of the VC coin | +| reuse_puzhash | None | False | If this flag is set, then send the VC back to the same puzzle hash it came from [Default: generate new puzzle hash] | +| fee | INTEGER | False | An optional blockchain fee, in mojos | -
-Example +
Example First, the proof provider can obtain the VC's `parent_coin_info` by calling `vc_get` on the launcher ID: @@ -839,8 +862,7 @@ In order to obtain a proof hash: The following example accomplishes each of these steps in Javascript: -
-Javascript Example +
Javascript Example In order to run this example: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/wallet-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/wallet-rpc.md index d14bb816259..919c3bc2e46 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/wallet-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/rpc-reference/wallet-rpc.md @@ -9,8 +9,7 @@ import TabItem from '@theme/TabItem'; 本文档提供了Chia钱包RPC API 的全面参考(不包含DID及NFT，这两者有专门的章节介绍)。 -
- Note about Windows command escaping +
Note about Windows command escaping This document will use Linux/MacOS RPC syntax. When running rpc commands on Windows, you'll need to escape all quotes with backslashes. @@ -45,12 +44,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :--------- | :------- | :------------------------- | +| Flag | Type | Required | Description | +| :------- | :--------- | :------- | :------------- | | mnemonic | TEXT ARRAY | True | 一个24字助记词，表示为数组 | -
-Example +
Example ```json chia rpc wallet add_key '{"mnemonic": ["hint", "dice", "session", "fun", "budget", "strong", "album", "lava", "tackle", "sudden", "garage", "people", "bundle", "federal", "chest", "process", "vicious", "behave", "nephew", "zero", "vital", "ocean", "artist", "lawsuit"]}' @@ -84,13 +82,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------------- | :----- | :------- | :----------------------------------------------------------------- | -| fingerprint | NUMBER | True | The wallet's fingerprint, obtainable by running `chia wallet show` | -| max_ph_to_search | NUMBER | False | 要搜索的拼图哈希的最大数量[默认：100] | +| Flag | Type | Required | Description | +| :------------------------------------------------------------------------------ | :----- | :------- | :------------------------------------------------------------------------ | +| fingerprint | NUMBER | True | The wallet's fingerprint, obtainable by running `chia wallet show` | +| max_ph_to_search | NUMBER | False | 要搜索的拼图哈希的最大数量[默认：100] | -
-Example +
Example ```json chia rpc wallet check_delete_key '{"fingerprint": 874731676, "max_ph_to_search": 200}' @@ -133,8 +130,7 @@ Request Parameters: None ::: -
-Example +
Example ```json chia rpc wallet delete_all_keys @@ -171,8 +167,7 @@ Request Parameters: | :---------- | :----- | :------- | :----------------------------------------------------------------- | | fingerprint | NUMBER | True | The wallet's fingerprint, obtainable by running `chia wallet show` | -
-Example +
Example ```json chia rpc wallet delete_key '{"fingerprint": 874731676}' @@ -205,8 +200,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet generate_mnemonic @@ -265,8 +259,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_logged_in_fingerprint @@ -310,8 +303,7 @@ This RPC will show the private key and seed phrase for the given fingerprint. Us ::: -
-Example +
Example ```json chia rpc wallet get_private_key '{"fingerprint": 2473794447}' @@ -352,8 +344,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_public_keys @@ -391,8 +382,7 @@ Request Parameters: | :---------- | :----- | :------- | :----------------------------------------------------------------- | | fingerprint | NUMBER | True | The wallet's fingerprint, obtainable by running `chia wallet show` | -
-Example +
Example ```json chia rpc wallet log_in '{"fingerprint": 2818719465}' @@ -430,8 +420,7 @@ Request Parameters: None Note that the auto claim settings are configurable in `~/.chia/mainnet/config/config.yaml` in the `auto_claim:` section. -
-Example +
Example ```json chia rpc wallet get_auto_claim @@ -468,8 +457,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_height_info @@ -503,8 +491,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_network_info @@ -514,6 +501,7 @@ Response: ```json { + "genesis_challenge": "0xccd5bb71183532bff220ba46c268991a00000000000000000000000000000000", "network_name": "mainnet", "network_prefix": "xch", "success": true @@ -539,8 +527,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_sync_status @@ -580,8 +567,7 @@ Request Parameters: | :----- | :----- | :------- | :--------------------------------------------------- | | height | NUMBER | True | The block height for which to retrieve the timestamp | -
-Example +
Example This example is from testnet10, so the timestamp won't match the equivalent call on mainnet: @@ -617,9 +603,9 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | :--------- | :------- | :------------------------------------------------------------------- | -| transactions | TEXT ARRAY | True | A list of transactions to push | +| Flag | Type | Required | Description | +| :----------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| transactions | TEXT ARRAY | True | A list of transactions to push | | fee | NUMBER | False | Add a transaction fee (in mojos) for the entire request [Default: 0] | :::info note @@ -645,8 +631,8 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | :--- | :------- | :------------------------------------- | +| Flag | Type | Required | Description | +| :-------------------------------- | :--- | :------- | :-------------------------------------------------------- | | spend_bundle | TEXT | True | The spend bundle (transaction) to push | --- @@ -666,17 +652,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :------ | :------- | :----------------------------------------------------------------------- | -| enabled | BOOLEAN | TRUE | Set to `true` to enable auto claim, or `false` to disable it | +| Flag | Type | Required | Description | +| :------------------------------ | :------ | :------- | :----------------------------------------------------------------------- | +| enabled | BOOLEAN | TRUE | Set to `true` to enable auto claim, or `false` to disable it | | tx_fee | NUMBER | TRUE | The default transaction fee to be used for claims, in mojos | | min_amount | NUMBER | TRUE | The minimum value, in mojos, of a claim to be included in the auto claim | | batch_size | NUMBER | TRUE | The maximum number of claims to process in one spend bundle | If one or more flags is missing, this RPC will succeed and set the missing flag back to the default value. -
-Example +
Example Start by obtaining a baseline: @@ -733,12 +718,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----- | :------ | :------- | :----------------------------------------------- | +| Flag | Type | Required | Description | +| :----- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------- | | enable | BOOLEAN | False | Set to `true` to enable resync [Default: `true`] | -
-Example +
Example ```json chia rpc wallet set_wallet_resync_on_startup @@ -773,22 +757,21 @@ Options: Request Parameters (all wallet types): -| Flag | Type | Required | Description | -| :---------- | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------ | | wallet_type | STRING | True | The type of wallet to create. Must be one of `cat_wallet`, `did_wallet`, `dao_wallet`, `nft_wallet`, or `pool_wallet` | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | `cat_wallet` Parameters: -| Flag | Type | Required | Description | -| :------- | :----- | :------- | :-------------------------------------------------------------------------------------------------- | -| mode | STRING | True | Must be either `new` or `existing` | -| name | STRING | False | The name of the wallet to create or modify [Default: `CAT` followed by the beginning of the CAT ID] | -| amount | NUMBER | True\* | \*Required if `mode` is `new`. Specify the value, in mojos, of this wallet | -| asset_id | STRING | True\* | \*Required if `mode` is `existing`. Specify the `asset_id` of the wallet to update | +| Flag | Type | Required | Description | +| :---------------------------- | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| mode | STRING | True | Must be either `new` or `existing` | +| name | STRING | False | The name of the wallet to create or modify [Default: `CAT` followed by the beginning of the CAT ID] | +| amount | NUMBER | True\* | \*Required if `mode` is `new`. Specify the value, in mojos, of this wallet | +| asset_id | STRING | True\* | \*Required if `mode` is `existing`. Specify the `asset_id` of the wallet to update | -
-Example 1 (CAT wallet with name) +
Example 1 (CAT wallet with name) Create a new CAT wallet called `test` and send it 100 mojos: @@ -838,8 +821,7 @@ test:
-
-Example 2 (CAT wallet without name) +
Example 2 (CAT wallet without name) Create a new CAT wallet without specifying a name: @@ -895,19 +877,18 @@ CAT 348dfae821c76f0a...: `did_wallet` Parameters: -| Flag | Type | Required | Description | -| :----------------------- | :----------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| did_type | STRING | True | Must be either `new` or `recovery`. If `recovery`, then each of the following parameters will be ignored | -| backup_dids | STRING ARRAY | True\* | \*Required if `did_type` is `new`. An array of backup DID IDs to be used for recovery. Must match actual DIDs | +| Flag | Type | Required | Description | +| :----------------------------------------------------------------------------------------------------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| did_type | STRING | True | Must be either `new` or `recovery`. If `recovery`, then each of the following parameters will be ignored | +| backup_dids | STRING ARRAY | True\* | \*Required if `did_type` is `new`. An array of backup DID IDs to be used for recovery. Must match actual DIDs | | num_of_backup_ids_needed | NUMBER | True\* | \*Required if `did_type` is `new`. The number of backup DIDs required for recovery. Minimum value is `1`, maximum value is the number of DIDs in `backup_dids` | -| metadata | DICT | False | The metadata of the DID | -| wallet_name | STRING | False | The name of the DID wallet [Default: None] | -| amount | NUMBER | True\* | \*Required if `did_type` is `new`. Specify the initial value of this wallet, in mojos. Minimum value is `1` | +| metadata | DICT | False | The metadata of the DID | +| wallet_name | STRING | False | The name of the DID wallet [Default: None] | +| amount | NUMBER | True\* | \*Required if `did_type` is `new`. Specify the initial value of this wallet, in mojos. Minimum value is `1` | Note: Because `backup_dids` is required, you must already have access to a DID in order to run this RPC for a did_wallet. If you do not already have a DID, then run [the CLI command](/reference-client/cli-reference/did-cli#create) to create a DID wallet instead. -
-Example 3 (DID wallet) +
Example 3 (DID wallet) Create a new DID wallet with one backup DID: @@ -959,24 +940,23 @@ Profile 1: `dao_wallet` Parameters: -| Flag | Type | Required | Description | -| :------------- | :-------- | :------- | :------------------------------------------------------------------------------------------------------------------------- | -| mode | STRING | True | Must be either `new` or `existing` | -| name | STRING | False | A name to give to the DAO new/existing wallet [Default: None] | -| dao_rules | JSON DICT | True\* | \*Required if `mode` is `new`; this is a json dictionary of the new DAO's rules | +| Flag | Type | Required | Description | +| :------------------------------------------------------- | :-------- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| mode | STRING | True | Must be either `new` or `existing` | +| name | STRING | False | A name to give to the DAO new/existing wallet [Default: None] | +| dao_rules | JSON DICT | True\* | \*Required if `mode` is `new`; this is a json dictionary of the new DAO's rules | | amount_of_cats | NUMBER | False\* | \*Only used if `mode` is `new`; this is the number of DAO CATs (in mojos) to create when initializing the DAO [Default: 0] | -| filter-amount | NUMBER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | -| fee | NUMBER | False\* | \*Only used if `mode` is `new`; this is a blockchain fee to add to the transaction to create the DAO treasury [Default: 0] | -| fee_for_cat | NUMBER | False\* | \*Only used if `mode` is `new`; this is a blockchain fee to add to the transaction to create the DAO CATs [Default: 0] | -| treasury_id | STRING | True\* | \*Required if `mode` is `existing`; this is the treasury ID of the DAO to join | +| filter-amount | NUMBER | False | The minimum number of votes a proposal needs before the wallet will recognise it \[default: 1] | +| fee | NUMBER | False\* | \*Only used if `mode` is `new`; this is a blockchain fee to add to the transaction to create the DAO treasury [Default: 0] | +| fee_for_cat | NUMBER | False\* | \*Only used if `mode` is `new`; this is a blockchain fee to add to the transaction to create the DAO CATs [Default: 0] | +| treasury_id | STRING | True\* | \*Required if `mode` is `existing`; this is the treasury ID of the DAO to join | Notes: - When `mode` is `new`, this RPC has a similar functionality to the [create](/reference-client/cli-reference/dao-cli/#create) DAO CLI command. - When `mode` is `existing`, this RPC has a similar functionality to the [add](/reference-client/cli-reference/dao-cli/#add) DAO CLI command. -
-Example 4 (New DAO wallet) +
Example 4 (New DAO wallet) Create a new wallet with some basic DAO rules; also mint CATs and include transaction fees: @@ -992,8 +972,7 @@ For this example, we'll use the wallet with ID 7. This wallet is ty
-
-Example 5 (Join existing DAO) +
Example 5 (Join existing DAO) To join a DAO, set `mode` to `existing`: @@ -1011,13 +990,12 @@ The type of wallet to create. The type of wallet to create. Must be one of -Example 6 (NFT wallet without DID) +
Example 6 (NFT wallet without DID) Create a new NFT wallet that is not associated with a DID: @@ -1037,8 +1015,7 @@ Response:
-
-Example 7 (NFT wallet with DID) +
Example 7 (NFT wallet with DID) Create an NFT wallet that is associated with a DID. First, create the DID: First, create the DID: @@ -1073,12 +1050,12 @@ Response: `pool_wallet` Parameters: -| Flag | Type | Required | Description | -| :---------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| mode | STRING | True | Must be either `new` of `recovery`. However, `recovery` has not been implemented, so currently (version 1.6) it will automatically fail | -| initial_target_state | STRING | True | This info should be sent from the daemon. `PoolState` is a type that is serialized to the blockchain to track the state of the user's pool singleton `target_puzzle_hash` is either the pool address, or the self-pooling address that pool rewards will be paid to. `target_puzzle_hash` is NOT the `p2_singleton` puzzle that block rewards are sent to. The `p2_singleton` address is the initial address, and the `target_puzzle_hash` is the final destination. `relative_lock_height` is zero when in `SELF_POOLING` state | -| p2_singleton_delayed_ph | STRING | True\* | \*Required if `mode` is `new`. This is the puzzle hash to which payouts will go | -| p2_singleton_delay_time | INTEGER | False | The time (in seconds) to delay payments [Default: None ] | +| Flag | Type | Required | Description | +| :------------------------------------------------------------------------------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| mode | STRING | True | Must be either `new` of `recovery`. However, `recovery` has not been implemented, so currently (version 1.6) it will automatically fail | +| initial_target_state | STRING | True | This info should be sent from the daemon. `PoolState` is a type that is serialized to the blockchain to track the state of the user's pool singleton `target_puzzle_hash` is either the pool address, or the self-pooling address that pool rewards will be paid to. `target_puzzle_hash` is NOT the `p2_singleton` puzzle that block rewards are sent to. The `p2_singleton` address is the initial address, and the `target_puzzle_hash` is the final destination. `relative_lock_height` is zero when in `SELF_POOLING` state | +| p2_singleton_delayed_ph | STRING | True\* | \*Required if `mode` is `new`. This is the puzzle hash to which payouts will go | +| p2_singleton_delay_time | INTEGER | False | The time (in seconds) to delay payments [Default: None ] | --- @@ -1097,33 +1074,32 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | :------ | :------- | :----------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :-------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | include_data | BOOLEAN | False | Set to `true` to include all coin info for this wallet [Default: `true`] | -| type | INTEGER | False | The type of wallet to retrieve. See below for valid types | +| type | INTEGER | False | The type of wallet to retrieve. See below for valid types | Valid wallet types (the `type` parameter) include the following integers: -| Name | type | -| :--------------- | ---: | -| STANDARD_WALLET | 0 | -| ATOMIC_SWAP | 2 | -| AUTHORIZED_PAYEE | 3 | -| MULTI_SIG | 4 | -| CUSTODY | 5 | -| CAT | 6 | -| RECOVERABLE | 7 | -| DECENTRALIZED_ID | 8 | -| POOLING_WALLET | 9 | -| NFT | 10 | -| DATA_LAYER | 11 | +| Name | type | +| :--------------------------------------------------------- | ---: | +| STANDARD_WALLET | 0 | +| ATOMIC_SWAP | 2 | +| AUTHORIZED_PAYEE | 3 | +| MULTI_SIG | 4 | +| CUSTODY | 5 | +| CAT | 6 | +| RECOVERABLE | 7 | +| DECENTRALIZED_ID | 8 | +| POOLING_WALLET | 9 | +| NFT | 10 | +| DATA_LAYER | 11 | | DATA_LAYER_OFFER | 12 | -| VC | 13 | +| VC | 13 | More types may be added in the future. See [wallet_types.py](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/util/wallet_types.py) for an up-to-date list of valid types. -
-Example 1 +
Example 1 Get all info for all wallets: @@ -1150,8 +1126,7 @@ Response:
-
-Example 2 +
Example 2 Get NFT wallet info (NFT type = 10): @@ -1203,15 +1178,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------ | -| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | -| number_of_coins | INTEGER | True | The number of coins to combine [Default: combine all coins, up to `coin_num_limit`] | -| largest_first | BOOLEAN | False | Set to `True` to prioritize combining the largest coins first [Default: False] | -| target_coin_ids | TEXT ARRAY | False | Only combine these coins [Default: Disabled] | +| Flag | Type | Required | Description | +| :----------------------------------------------------------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | +| number_of_coins | INTEGER | True | The number of coins to combine [Default: combine all coins, up to `coin_num_limit`] | +| largest_first | BOOLEAN | False | Set to `True` to prioritize combining the largest coins first [Default: False] | +| target_coin_ids | TEXT ARRAY | False | Only combine these coins [Default: Disabled] | | target_coin_amount | INTEGER | False | Select coins until this amount (in XCH or CAT) is reached. Combine all selected coins into one coin [Default: None] | -| coin_num_limit | INTEGER | False | Combine up to this many coins [Default: 500] | -| fee | INTEGER | False | An optional blockchain fee, in mojos | +| coin_num_limit | INTEGER | False | Combine up to this many coins [Default: 500] | +| fee | INTEGER | False | An optional blockchain fee, in mojos | +| push | BOOLEAN | False | Option to push the transaction to the chain or not (default: false) | :::warning @@ -1249,7 +1225,7 @@ It is not recommended to increase the value of `coin_num_limit` to a value highe For this example, combine as many coins as are required until a target of 2 trillion mojos is reached. Include a blockchain fee of 25 million mojos: ```json -chia rpc wallet combine_coins '{"wallet_id": 1, "target_coin_amount": 2000000000000, "number_of_coins": 2, "fee": 25000000}' +chia rpc wallet combine_coins '{"wallet_id": 1, "target_coin_amount": 2000000000000, "number_of_coins": 2, "fee": 25000000, "push": true}' ``` Response: @@ -1401,8 +1377,7 @@ Response:
-
-Example 2 +
Example 2 First, list some coins to combine. The following command will list all coins in the wallet. (It is also possible to obtain a more nuanced listing by running the [list](/reference-client/cli-reference/wallet-cli/#list) command): @@ -1615,18 +1590,18 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :----------- | :------- | :----------------------------------------------------------------------------------------- | -| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | -| additions | TEXT ARRAY | True | A list of puzzle hashes and amounts to be included | -| min_coin_amount | NUMBER | False | The minimum coin amount to send [Default: 0] | -| max_coin_amount | NUMBER | False | The maximum coin amount to send [Default: 0] | -| exclude_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | -| coins | TEXT ARRAY | True | A list of coins to include | -| exclude_coins | TEXT ARRAY | True | A list of coins to exclude | -| coin_announcements | TEXT ARRAY | False | A list of coin announcements, which includes `coin_id`, `message`, and `morph_bytes` | -| puzzle_announcements | TEXT ARRAY | False | A list of puzzle announcements, which includes `puzzle_hash`, `message`, and `morph_bytes` | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| Flag | Type | Required | Description | +| :------------------------------------------------------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------- | +| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | +| additions | TEXT ARRAY | True | A list of puzzle hashes and amounts to be included | +| min_coin_amount | NUMBER | False | The minimum coin amount to send [Default: 0] | +| max_coin_amount | NUMBER | False | The maximum coin amount to send [Default: 0] | +| exclude_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | +| coins | TEXT ARRAY | True | A list of coins to include | +| exclude_coins | TEXT ARRAY | True | A list of coins to exclude | +| coin_announcements | TEXT ARRAY | False | A list of coin announcements, which includes `coin_id`, `message`, and `morph_bytes` | +| puzzle_announcements | TEXT ARRAY | False | A list of puzzle announcements, which includes `puzzle_hash`, `message`, and `morph_bytes` | +| fee | NUMBER | False | An optional blockchain fee, in mojos | --- @@ -1645,12 +1620,11 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :--------------------------------------------------------------------------------------------------------------------- | +| Parameter | Required | Description | +| :-------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ids | False | Set to delete notifications only from the specified IDs. [Default: delete from all IDs] [Default: delete from all IDs] | -
-Example +
Example ```json chia rpc wallet delete_notifications @@ -1683,12 +1657,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :----------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the wallet from which to delete transactions | -
-Example +
Example ```json chia rpc wallet delete_unconfirmed_transactions '{"wallet_id": 2}' @@ -1721,14 +1694,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---- | :----- | :------- | :----------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :---- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------- | | index | NUMBER | True | The new derivation index. The new derivation index. Must be larger than the previous index | Note: The derivation index is the minimum number of addresses the wallet will examine. It's not possible to decrease this number. It's not possible to decrease this number. -
-Example +
Example ```json chia rpc wallet extend_derivation_index '{"index": 436}' @@ -1764,8 +1736,7 @@ Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_coin_records @@ -1816,15 +1787,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------ | :--------- | :------- | :-------------------------------------------------- | -| names | TEXT ARRAY | True | A list of coin names from which to retrieve records | -| start_height | NUMBER | False | The block height at which to start the query | -| end_height | NUMBER | False | The block height at which to end the query | -| include_spent_coins | BOOLEAN | False | Include spent coins in the result [Default: false] | +| Flag | Type | Required | Description | +| :------------------------------------------------------------ | :--------- | :------- | :--------------------------------------------------------------------------------------------------------------------- | +| names | TEXT ARRAY | True | A list of coin names from which to retrieve records | +| start_height | NUMBER | False | The block height at which to start the query | +| end_height | NUMBER | False | The block height at which to end the query | +| include_spent_coins | BOOLEAN | False | Include spent coins in the result [Default: false] | -
-Example +
Example ```json chia rpc wallet get_coin_records_by_names '{"names": ["0xeb17e80fcb72f15bfb28924f0bcd684df626646dca282bc88098cb0d59ffe1bb"]}' @@ -1855,6 +1825,47 @@ Response: --- +### `get_puzzle_and_solution` + +Functionality: Fetches the CLVM puzzle reveal and solution for a **spent** coin. The wallet looks up the coin, then requests the full node (via a connected peer) to resolve the spend that matches the spent height. + +Usage: chia rpc wallet [OPTIONS] get_puzzle_and_solution [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :----------------------------- | :--------- | :------- | :------------------------------------ | +| coin_name | HEX STRING | True | The coin ID (name) | + +
Example + +```json +chia rpc wallet get_puzzle_and_solution '{"coin_name": "0x7a639649fa2b6b4233cab7bf98b3da01be182afba622eb377011ac0940cd83c8"}' +``` + +Response: + +```json +{ + "puzzle_reveal": "0xff02ffff01...", + "solution": "0xffa0...", + "success": true +} +``` + +Returns hex-encoded `puzzle_reveal` and `solution` for the spend. Fails if the coin is missing, unspent, or the full node cannot return the spend. + +
+ +--- + ### `get_current_derivation_index` 功能：获取当前钱包的当前派生索引（derivation index） @@ -1870,8 +1881,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_current_derivation_index @@ -1905,8 +1915,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_farmed_amount @@ -1929,6 +1938,92 @@ Response: --- +### `get_fee_estimate` + +Functionality: Retrieve a fee estimate (in mojos per CLVM cost) from a connected full node peer. This allows wallet clients to get fee guidance without calling the full node RPC directly. Requires the wallet to be connected to at least one full node peer. + +Usage: chia rpc wallet [OPTIONS] get_fee_estimate [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_fee_estimate +``` + +Response: + +```json +{ + "fee_per_cost": 0, + "success": true +} +``` + +
+ +:::note + +The returned `fee_per_cost` value is in mojos per 1 CLVM cost. A value of `0` indicates that the mempool is not currently congested. + +If the wallet is not connected to a full node peer, this RPC will return an error. + +::: + +:::info How it works + +This is a simplified wrapper around the full node's [`get_fee_estimate`](/reference-client/rpc-reference/full-node-rpc#get_fee_estimate) RPC. The full node version accepts `target_times`, `cost`, and an optional `spend_bundle` as request parameters. + +The wallet version takes no parameters — it automatically uses the current UTC timestamp as a single time target and requests the fee estimate from a connected full node peer via the wallet-to-full-node protocol. The result is a single `fee_per_cost` value representing the estimated fee rate at the current moment. + +Use this endpoint when you want a quick fee estimate without needing to specify custom time targets or cost values. For more granular control (e.g., estimating fees across multiple time horizons), use the [full node `get_fee_estimate`](/reference-client/rpc-reference/full-node-rpc#get_fee_estimate) RPC directly. + +::: + +--- + +### `get_full_node_peer_count` + +Functionality: Returns the number of full node peers currently connected to the wallet node + +Usage: chia rpc wallet [OPTIONS] get_full_node_peer_count [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_full_node_peer_count +``` + +Response: + +```json +{ + "peer_count": 1, + "success": true +} +``` + +
+ +--- + ### `get_next_address` 功能： 获取HD树中的下一个地址，并可选择显示最新的地址。 @@ -1944,13 +2039,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :------ | :------- | :----------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :------ | :------- | :----------------------------------------------------------------------------- | | wallet_id | TEXT | True | The ID of the wallet from which to obtain the next address | | new_address | BOOLEAN | True | If `true`, then create a new address, else display the latest existing address | -
-Example +
Example ```json chia rpc wallet get_next_address '{"wallet_id": 2, "new_address": false}' @@ -1985,14 +2079,13 @@ Options: Request Parameters: -| Parameter | Required | Description | -| :-------- | :------- | :------------------------------------------------------------------------------------------------------------------------------ | +| Parameter | Required | Description | +| :-------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ids | False | Set to receive notifications only from the specified IDs. [Default: receive from all IDs] [Default: receive from all IDs] | | start | False | The number corresponding to the first notification to list. [Default: the first notification] [Default: the first notification] | | end | False | The number corresponding to the last notification to list. [Default: the last notification] [Default: the last notification] | -
-Example +
Example If no parameters are set, then all notifications will be listed from all IDs: @@ -2034,17 +2127,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------------- | :----------- | :------- | :------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The ID of the wallet from which to display coins | +| Flag | Type | Required | Description | +| :-------------------------------------------------------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The ID of the wallet from which to display coins | | min_coin_amount | NUMBER | False | The smallest coin to be selected in this query [Default: No minimum] | | max_coin_amount | NUMBER | False | The largest coin to be selected in this query [Default: No maximum] | -| excluded_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | -| excluded_coins | TEXT ARRAY | False | A list of coins to exclude | -| excluded_coin_ids | TEXT ARRAY | False | A list of coin IDs to exclude | +| excluded_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | +| excluded_coins | TEXT ARRAY | False | A list of coins to exclude | +| excluded_coin_ids | TEXT ARRAY | False | A list of coin IDs to exclude | -
-Example +
Example List all unspent coins from wallet 1: @@ -2094,12 +2186,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :---------------------------------- | :--- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | transaction_id | TEXT | True | The ID of the transaction to obtain. This is listed as `name` in the output of the [get_transactions](#get_transactions) RPC | -
-Notes about transactions +
Notes about transactions The transaction history is not deterministic due to heuristics we use to counter privacy features of the blockchain. This means, a couple of details cannot be fetched fully: - The transaction IDs can and will change if you resync the wallet - Transactions of assets other than xch (cat, nft, ...) which include a fee will cause a second fee-transaction in the xch currency wallet (wallet 1) @@ -2111,8 +2202,7 @@ The transaction history is not deterministic due to heuristics we use to counter For accurate records, you should keep a local record of transactions (TXs) and the Offer files made.
-
-Example +
Example ```json chia rpc wallet get_transaction '{"transaction_id": "0x43f6811a4daf18622fc7f132f5166a1246056b4a983b7befccb7e4b2e2c57f3b"}' @@ -2177,17 +2267,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID of the wallet from which to obtain transactions | -| start | NUMBER | False | The sequence number of the first transaction to show [Default: 0] | -| end | NUMBER | False | The sequence number of the last transaction to show [Default: 50] | +| Flag | Type | Required | Description | +| :------------------------------ | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID of the wallet from which to obtain transactions | +| start | NUMBER | False | The sequence number of the first transaction to show [Default: 0] | +| end | NUMBER | False | The sequence number of the last transaction to show [Default: 50] | | sort_key | NUMBER | False | Specify the key for sorting, [sort_keys members](https://github.com/Chia-Network/chia-blockchain/blob/5f6c336e757534d3a36b1a03612e05b412a18c61/chia/wallet/transaction_sorting.py#L6) [Default: `confirmed_at_height`] | -| reverse | BOOLEAN | False | Set to `true` to sort the results in reverse order [Default: false] | -| to_address | STRING | False | Only include transactions with this `to_address` [Default: None] | +| reverse | BOOLEAN | False | Set to `true` to sort the results in reverse order [Default: false] | +| to_address | STRING | False | Only include transactions with this `to_address` [Default: None] | -
-Notes about transactions +
Notes about transactions By default, the function lists the oldest transactions first. This is recommended for building a transaction history due to pagination. If reverse is set to true, it lists the newest transactions first. This is most useful for fetching recent transactions. @@ -2204,8 +2293,7 @@ The transaction history is not deterministic due to heuristics we use to counter
-
-Example 1: List a single XCH transaction +
Example 1: List a single XCH transaction Start by listing all wallets associated with the currently synced fingerprint: @@ -2321,8 +2409,7 @@ chia rpc wallet get_transactions '{"wallet_id": 1, "start": 3, "end": 4}'
-
-Example 2: List all transactions for a CAT +
Example 2: List all transactions for a CAT Start by listing all wallets associated with the currently synced fingerprint: @@ -2444,12 +2531,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--- | :------- | :------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :--- | :------- | :------------------------------------------------------- | | wallet_id | TEXT | True | The wallet ID from which to obtain the transaction count | -
-Example +
Example ```json chia rpc wallet get_transaction_count '{"wallet_id": 2}' @@ -2484,12 +2570,11 @@ Options: Request Parameters: -| Parameter | TYPE | Required | Description | -| :------------- | :----- | :------- | :------------------------------------------------------- | +| Parameter | TYPE | Required | Description | +| :---------------------------------- | :----- | :------- | :------------------------------------------------------- | | transaction_id | STRING | True | The ID of the transaction for which to retrieve the memo | -
-Example +
Example ```json chia rpc wallet get_transaction_memo '{"transaction_id": "0x21899b89bf36154e44c2277e9bfb6cff0574d7e9df4e100b782b03ab2476e171"}' @@ -2527,12 +2612,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :----------------------------------------------------------- | | wallet_id | NUMBER | True | The Wallet ID of the wallet from which to obtain the balance | -
-Example +
Example ```json chia rpc wallet get_wallet_balance '{"wallet_id": 1}' @@ -2577,12 +2661,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :--- | :------- | :----------------------------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------ | :--- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | | wallet_ids | LIST | False | A list of Wallet IDs from which to obtain the balance [Default: list info for all wallets] | -
-Example +
Example Get the balance and other info for wallets 1 and 2: @@ -2643,17 +2726,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------------- | :----------- | :------- | :------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The ID of the wallet from which to select coins | -| amount | NUMBER | True | The number of mojos to select | +| Flag | Type | Required | Description | +| :-------------------------------------------------------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The ID of the wallet from which to select coins | +| amount | NUMBER | True | The number of mojos to select | | min_coin_amount | NUMBER | False | The smallest coin to be selected in this query [Default: No minimum] | | max_coin_amount | NUMBER | False | The largest coin to be selected in this query [Default: No maximum] | -| excluded_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | -| excluded_coins | TEXT ARRAY | False | A list of coins to exclude | +| excluded_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | +| excluded_coins | TEXT ARRAY | False | A list of coins to exclude | -
-Example 1 +
Example 1 Select 1000 mojos. Note that in this wallet, the smallest coin is worth `999 996 796` mojos, so that coin is selected: @@ -2678,8 +2760,7 @@ Response:
-
-Example 2 +
Example 2 Attempt to select 1000 mojos with `max_coin_amount` set to `10 000`. As in the previous example, the smallest coin in the wallet is worth `999 996 796` mojos, so the coin selection will fail: @@ -2719,8 +2800,7 @@ Request Parameters: | amount | NUMBER | True | The number of mojos to include with this message | | fee | NUMBER | False | An optional blockchain fee, in mojos | -
-Example 1: Send a generic message +
Example 1: Send a generic message ```json chia rpc wallet send_notification '{"target": "8c436f983d5bcbdb92d6d029a4113da580f2fc43b943e92ddf06a9f54e5f5003", "message": "fadedcab", "amount": 10000000, "fee": 10000000}' @@ -2796,8 +2876,7 @@ Response:
-
-Example 2: Send an NFT notification +
Example 2: Send an NFT notification In this example, we will attempt to buy the following NFT: @@ -3011,21 +3090,20 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | -| address | TEXT | True | The destination address | -| amount | NUMBER | True | The number of mojos to send | -| fee | NUMBER | False | An optional blockchain fee, in mojos | -| memos | TEXT ARRAY | False | An optional array of memos to be sent with the transaction | -| min_coin_amount | NUMBER | False | The minimum coin amount to send [Default: 0] | -| max_coin_amount | NUMBER | False | The maximum coin amount to send [Default: 0] | -| exclude_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | -| exclude_coin_ids | TEXT ARRAY | False | A list of coin IDs to exclude | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :------------------------------------------------------------- | :----------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | +| address | TEXT | True | The destination address | +| amount | NUMBER | True | The number of mojos to send | +| fee | NUMBER | False | An optional blockchain fee, in mojos | +| memos | TEXT ARRAY | False | An optional array of memos to be sent with the transaction | +| min_coin_amount | NUMBER | False | The minimum coin amount to send [Default: 0] | +| max_coin_amount | NUMBER | False | The maximum coin amount to send [Default: 0] | +| exclude_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | +| exclude_coin_ids | TEXT ARRAY | False | A list of coin IDs to exclude | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example ```json chia rpc wallet send_transaction '{"wallet_id": 1, "address": "xch1fev2qaclwpcue9kx4p39dzfxpzaavvcz5v3lhx77cxha7f0tjjlsngh5k0", "amount": 1000, "fee": 1, "memos":["memo1"]}' @@ -3110,16 +3188,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :--------- | :------- | :----------------------------------------------------------------- | -| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | -| additions | TEXT ARRAY | True | A list of puzzle hashes, amounts, and memos to be included | -| coins | TEXT ARRAY | False | Optional declaration of coins to be used | -| fee | NUMBER | False | An optional blockchain fee, in mojos | -| push | BOOLEAN | False | Option to push the transaction to the chain or not (default: true) | +| Flag | Type | Required | Description | +| :----------------------------- | :--------- | :------- | :---------------------------------------------------------------------------------------------------- | +| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | +| additions | TEXT ARRAY | True | A list of puzzle hashes, amounts, and memos to be included | +| coins | TEXT ARRAY | False | Optional declaration of coins to be used | +| fee | NUMBER | False | An optional blockchain fee, in mojos | +| push | BOOLEAN | False | Option to push the transaction to the chain or not (default: true) | -
-Example +
Example ```json chia rpc wallet send_transaction_multi '{"wallet_id": 1, "additions": [{"amount": 1000, "puzzle_hash": "0xd826f3ef83e1752771426f90eadb24e42a78948cb7f747da85c05daab1b1e156"},{"amount": 500, "puzzle_hash": "0x45d4b5bd3f1e2c28483cae0eab27921adabff3300cb7d1241ba1a9628727197d", "memos": ["hello", "world"]}],"fee": 100}' @@ -3127,7 +3204,7 @@ chia rpc wallet send_transaction_multi '{"wallet_id": 1, "additions": [{"amount" Response: -````mdx-code-block +```mdx-code-block ```json { "success": true, @@ -3315,9 +3392,8 @@ Response: } ] } -```` - -```` + ``` +```
@@ -3343,12 +3419,11 @@ Request Parameters: | address | STRING | True | The address to use for signing. The address to use for signing. Must possess the key for this address | | message | STRING | True | The message to include with the signature | -
-Example +
Example ```json chia rpc wallet sign_message_by_address '{"address":"xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46", "message":"test"}' -```` +``` Response: @@ -3379,13 +3454,12 @@ Options: Request Parameters: -| Parameter | TYPE | Required | Description | -| :-------- | :----- | :------- | :------------------------------------------------------------------------------------------------------ | +| Parameter | TYPE | Required | Description | +| :-------- | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------- | | id | STRING | True | The DID or NFT ID to use for signing. Must possess the key for this ID Must possess the key for this ID | -| message | STRING | True | The message to include with the signature | +| message | STRING | True | The message to include with the signature | -
-Example +
Example ```json chia rpc wallet sign_message_by_id '{"id":"nft12dfld077vn3ywp4vdx9ljg96k89kpr6jlqwkm7lgaf3g8jwn2l4q6eytqs", "message":"test"}' @@ -3420,16 +3494,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :----------- | :------- | :----------------------------------------------------------------------------------------------------------------- | -| coin_ids | STRING ARRAY | True | List of coin IDs to be spent | +| Flag | Type | Required | Description | +| :------------------------------ | :----------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| coin_ids | STRING ARRAY | True | List of coin IDs to be spent | | batch_size | NUMBER | False | The number of coins to spend per bundle, [Default: `batch_size` obtainable from [get_auto_claim](#get_auto_claim)] | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | When examining the on-chain metadata for a transaction, a coin with `"type": 6` is a clawback coin to be received by this wallet, and a coin with `"type": 7` is a clawback coin sent from this wallet. -
-Example +
Example First, list a clawback transaction. For this example, we will specify the `to_address`. @@ -3676,13 +3749,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :--------------------------------------------------------------------------------------- | -| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | -| target_coin_id | TEXT | True | The ID of the coin to split | +| Flag | Type | Required | Description | +| :-------------------------------------------------------- | :------ | :------- | :---------------------------------------------------------------------------------------------------------- | +| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | +| target_coin_id | TEXT | True | The ID of the coin to split | | number_of_coins | INTEGER | True | The number of new coins to create, excluding the remainder coin (minimum 1, maximum 500) | -| amount_per_coin | INTEGER | True | The amount of each newly created coin, in XCH | -| fee | INTEGER | False | An optional blockchain fee, in mojos | +| amount_per_coin | INTEGER | True | The amount of each newly created coin, in XCH | +| fee | INTEGER | False | An optional blockchain fee, in mojos | +| push | BOOLEAN | False | Option to push the transaction to the chain or not (default: false) | :::info @@ -3705,7 +3779,7 @@ The minimum number of new coins is 1. "Splitting" one coin into one new coin cou Split a coin into three new coins of 100 mojos apiece, plus a remainder coin. Include a blockchain fee of 25 million mojos. ```json - chia rpc wallet split_coins '{"wallet_id": 1, "target_coin_id": "0x0451adca5edd164d524fea976792b73e8f745b8210fa8f890fca34a3d258a8d7", "number_of_coins": 3, "amount_per_coin": 100, "fee": 25000000}' + chia rpc wallet split_coins '{"wallet_id": 1, "target_coin_id": "0x0451adca5edd164d524fea976792b73e8f745b8210fa8f890fca34a3d258a8d7", "number_of_coins": 3, "amount_per_coin": 100, "fee": 25000000, "push": true}' ``` Response: @@ -3884,13 +3958,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :----------- | :--- | :------- | :------------------------------------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :-------------------------------- | :--- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | signing_mode | TEXT | False | Specify the type of signature to verify \[Default: BLS with hex input\] (see below for more info) | -| pubkey | TEXT | True | The public key of the signature to verify | -| message | TEXT | True | The message to verify | -| signature | TEXT | True | The signature to verify | -| address | TEXT | True | The address, which must be derived from `pubkey` | +| pubkey | TEXT | True | The public key of the signature to verify | +| message | TEXT | True | The message to verify | +| signature | TEXT | True | The signature to verify | +| address | TEXT | True | The address, which must be derived from `pubkey` | The signing mode strings are [stored in an enum](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/types/signing_mode.py). As of Chia 2.0.0, valid signing mode strings include: @@ -3927,14 +4001,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| secure | BOOLEAN | True | Set to `true` to cancel on the blockchain by spending the coin(s) being offered; set to `false` to cancel in the wallet only. If `false`, the offer could still be taken if it has been shared | -| trade_id | TEXT | True | The ID of the offer to cancel | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| Flag | Type | Required | Description | +| :---------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| secure | BOOLEAN | True | Set to `true` to cancel on the blockchain by spending the coin(s) being offered; set to `false` to cancel in the wallet only. If `false`, the offer could still be taken if it has been shared | +| trade_id | TEXT | True | The ID of the offer to cancel | +| fee | NUMBER | False | An optional blockchain fee, in mojos | -
-Example +
Example ```json chia rpc wallet cancel_offer '{"secure": true, "trade_id": "c4d9f06599e4ba30edfabecc72a03db7d7e86c003ab83520002a844cfebf2ef5", "fee": 1}' @@ -3967,16 +4040,15 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| secure | BOOLEAN | True | Set to `true` to cancel on the blockchain by spending the coin(s) being offered; set to `false` to cancel in the wallet only. If `false`, the offer could still be taken if it has been shared | -| batch_fee | NUMBER | False | The fee, in mojos, to add to each batch cancellation [Default: 0] | -| batch_size | NUMBER | False | The number of offers to cancel in each batch [Default: 5] | -| cancel_all | BOOLEAN | False | Set to `true` to cancel all offers for all assets [Default: `false`] | -| asset_id | TEXT | False | If `cancel_all` is false, then only cancel the specified type of asset [Default: `xch`] | +| Flag | Type | Required | Description | +| :------------------------------ | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| secure | BOOLEAN | True | Set to `true` to cancel on the blockchain by spending the coin(s) being offered; set to `false` to cancel in the wallet only. If `false`, the offer could still be taken if it has been shared | +| batch_fee | NUMBER | False | The fee, in mojos, to add to each batch cancellation [Default: 0] | +| batch_size | NUMBER | False | The number of offers to cancel in each batch [Default: 5] | +| cancel_all | BOOLEAN | False | Set to `true` to cancel all offers for all assets [Default: `false`] | +| asset_id | TEXT | False | If `cancel_all` is false, then only cancel the specified type of asset [Default: `xch`] | -
-Example +
Example ```json chia rpc wallet cancel_offers '{"secure": true}' @@ -4009,12 +4081,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :--- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :---------------------------- | :--- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------- | | asset_id | TEXT | True | The ID of the CAT whose name you would like to retrieve. This CAT must be listed in your `DEFAULT_CATS`, ie the CATs your wallet recognizes | -
-Example +
Example ```json chia rpc wallet cat_asset_id_to_name '{"asset_id": "1f9fd0d4a1221241df986f042e014c056571062c82a5ba9b88c866c92808e1a9"}' @@ -4049,12 +4120,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :----------------------------------------------------------- | | wallet_id | NUMBER | True | The wallet ID of the CAT whose ID you would like to retrieve | -
-Example +
Example ```json chia rpc wallet cat_get_asset_id '{"wallet_id": 2}' @@ -4089,12 +4159,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :------------------------------------------------------------- | | wallet_id | NUMBER | True | The wallet ID of the CAT whose name you would like to retrieve | -
-Example +
Example ```json chia rpc wallet cat_get_name '{"wallet_id": 2}' @@ -4129,13 +4198,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :------------------------------------------------------- | | wallet_id | NUMBER | True | The ID of the wallet whose name you would like to change | -| name | TEXT | True | The new name for the wallet | +| name | TEXT | True | The new name for the wallet | -
-Example +
Example ```json chia rpc wallet cat_set_name '{"wallet_id": 2, "name": "New CAT Wallet"}' @@ -4169,26 +4237,25 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :----------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | -| additions | TEXT ARRAY | True\* | \*Must include either `additions` or `amount`. A list of puzzle hashes and amounts to be included | -| amount | NUMBER | True\* | \*Must include either `additions` or `amount`. The number of mojos to send | -| inner_address | TEXT | True | The destination address | -| memos | TEXT ARRAY | False | An optional array of memos to be sent with the transaction | -| coins | TEXT ARRAY | False | A list of coins to include in the spend | -| min_coin_amount | NUMBER | False | The minimum coin amount to send [Default: 0] | -| max_coin_amount | NUMBER | False | The maximum coin amount to send [Default: 0] | -| exclude_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | -| exclude_coin_ids | TEXT ARRAY | False | A list of coin IDs to exclude | -| fee | NUMBER | False | An optional blockchain fee, in mojos | -| extra_delta | TEXT | False\* | The CAT's `extra_delta` parameter; \*If specified, then `tail_reveal` and `tail_solution` must also be specified | -| tail_reveal | TEXT | False\* | The CAT's `tail_reveal` parameter; \*If specified, then `extra_delta` and `tail_solution` must also be specified | -| tail_solution | TEXT | False\* | The CAT's `tail_solution` parameter; \*If specified, then `extra_delta` and `tail_reveal` must also be specified | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | - -
-Example +| Flag | Type | Required | Description | +| :------------------------------------------------------------- | :----------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | TEXT | True | The wallet ID for the origin of the transaction | +| additions | TEXT ARRAY | True\* | \*Must include either `additions` or `amount`. A list of puzzle hashes and amounts to be included | +| amount | NUMBER | True\* | \*Must include either `additions` or `amount`. The number of mojos to send | +| inner_address | TEXT | True | The destination address | +| memos | TEXT ARRAY | False | An optional array of memos to be sent with the transaction | +| coins | TEXT ARRAY | False | A list of coins to include in the spend | +| min_coin_amount | NUMBER | False | The minimum coin amount to send [Default: 0] | +| max_coin_amount | NUMBER | False | The maximum coin amount to send [Default: 0] | +| exclude_coin_amounts | NUMBER ARRAY | False | A list of coin amounts to exclude | +| exclude_coin_ids | TEXT ARRAY | False | A list of coin IDs to exclude | +| fee | NUMBER | False | An optional blockchain fee, in mojos | +| extra_delta | TEXT | False\* | The CAT's `extra_delta` parameter; \*If specified, then `tail_reveal` and `tail_solution` must also be specified | +| tail_reveal | TEXT | False\* | The CAT's `tail_reveal` parameter; \*If specified, then `extra_delta` and `tail_solution` must also be specified | +| tail_solution | TEXT | False\* | The CAT's `tail_solution` parameter; \*If specified, then `extra_delta` and `tail_reveal` must also be specified | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | + +
Example ```json chia rpc wallet cat_spend '{"wallet_id": 7, "amount": 1, "inner_address": "xch19mpn09rnn62nlur7h05naeeq2m6lprdr48f3cgt9j6s8a2h3kk6qdydujd", "fee": 1}' @@ -4296,8 +4363,7 @@ Request Parameters: | :---- | :--- | :------- | :--------------------------------- | | offer | TEXT | True | The contents of the offer to check | -
-Example +
Example ```json chia rpc wallet check_offer_validity '{"offer": "offer1qqzh3wcuu2rykcmqvpsxygqqwc7hynr6hum6e0mnf72sn7uvvkpt68eyumkhelprk0adeg42nlelk2mpagr90qq0a37v8lc9pfxkwhdhlns4tnwtx933g0gsj06neuds6jjugly4k5x7we0x39h9ur65y2cmwttg00ht60xnjly6zhduf0h9hmedaq67yh89uafrzctmgrka06llmvv9uhze9tqqpd38v8zcv4x32hhe7wueh4t8vd9cn6uhqk7vejppfygfgtje8usle5c5ukqmlw72va4pv8mweg5ztmcakwex27z9uamchklr2mtk7ax4tadcte8hq98380vuxcnfkjxndkjxrdk68rdk69rdk68ga95mfr2xhump4wrstastammnc2aav3hrd4ej8gexus0gje2urasruamdvrwvas9wm56mykj42pj6cp0vlymr5daw8k9e780kxd46wsh9u4e4tk7dw49w2epylahdz44aq2kj4ypthrsme4qwdncgdnwhlcw2amlhhsl6z0wlca7573y7knevrjjz4kpg80gnrlmlx7q6lh2rdtll6j6kh72t66vmwn25gwh5eqsd6wpqc6yqkn9luteq6nz0hh7yln3r7ct9yqecrfh95lyzace38xayytnu7x2fl4whv40e6etxehv03mwzdlnfttaxckmea7xle3hs0tzvlmdlch7qjzul97gymhjsew40ef2vmf6m8m4ntw0x08ceu7xkxm0fxjut754n9qd2anljlwpk49z4472n65af226w03fha2j7hyshuuh8gdr68z3a67atjcnl07vswj0clutncre6wt4la0au8vdlmxjn7fe8mqald7l8rh2hgls66uxhutuzdqmnr0ljlkyulq5t67rru25jnxjjyxntvllt2n4j244utj7ahu6avas47nlhrah2p5uursd0uteccgjtncy6e62uvn6tathamz0m0rfweuaaq5mevp6klth99dhf0f6hcqksxfpqmvhlpvyrtj2qjmvnwyr96saajuyp8vm70h7vhtw93vkmj7llmquru84g0vv80fd3eg65vhfrlm5yrgzs4pa95el4wa6w9nfkgvvazzek9eef4kd6zr6rjue6culxd8wdg5dglrevft9lc7hfljuc70hx9uq587fl64gp3s467zj58nvdaawuet3lvft8hvynv5j83tlg5phaeteme079hw6xn5dn54tm602ln2vgknvammql8fe7zuqzvfq20gc9s4d4"}' @@ -4331,16 +4397,17 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| offer | TEXT | True | The offer to create | -| validate_only | BOOLEAN | False | Only validate the offer instead of creating it [Default: false] | -| driver_dict | DICT | True | A dictionary of keys and values associated with the offer | -| min_coin_amount | NUMBER | False | The minimum coin amount to select for the offer [Default: none] | -| max_coin_amount | NUMBER | False | The maximum coin amount to select for the offer [Default: none] | -| solver | TEXT | False | A marshalled solver | -| fee | NUMBER | False | An optional blockchain fee, in mojos | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :-------------------------------------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| offer | TEXT | True | The offer to create | +| validate_only | BOOLEAN | False | Only validate the offer instead of creating it [Default: false] | +| driver_dict | DICT | True | A dictionary of keys and values associated with the offer | +| min_coin_amount | NUMBER | False | The minimum coin amount to select for the offer [Default: none] | +| max_coin_amount | NUMBER | False | The maximum coin amount to select for the offer [Default: none] | +| solver | TEXT | False | A marshalled solver | +| fee | NUMBER | False | An optional blockchain fee, in mojos | +| offer_only | BOOLEAN | False | If `true`, return only the offer without creating a trade record or transactions. The response keeps the same shape but `trade_record` will be `null` and `transactions` / `unsigned_transactions` will be empty. Useful when the full response would exceed WebSocket payload limits [Default: false] | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | --- @@ -4359,19 +4426,18 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| start | NUMBER | False | The sequence number of the first offer to show [Default: 0] | -| end | NUMBER | False | The sequence number of the last offer to show [Default: 10] | -| exclude_my_offers | BOOLEAN | False | Set to `true` to exclude offers you originated [Default: false] | -| exclude_taken_offers | BOOLEAN | False | Set to `true` to exclude offers that have already been taken [Default: false] | -| include_completed | BOOLEAN | False | Set to `true` to include offers that have been taken [Default: false] | -| sort_key | NUMBER | False | Specify the key for sorting, [sort_keys members](https://github.com/Chia-Network/chia-blockchain/blob/5f6c336e757534d3a36b1a03612e05b412a18c61/chia/wallet/transaction_sorting.py#L6) [Default: `confirmed_at_height`] | -| reverse | BOOLEAN | False | Set to `true` to sort the results in reverse order [Default: false] | -| file_contents | BOOLEAN | False | Set to `true` to display the contents of each offer [Default: false] | +| Flag | Type | Required | Description | +| :------------------------------------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| start | NUMBER | False | The sequence number of the first offer to show [Default: 0] | +| end | NUMBER | False | The sequence number of the last offer to show [Default: 10] | +| exclude_my_offers | BOOLEAN | False | Set to `true` to exclude offers you originated [Default: false] | +| exclude_taken_offers | BOOLEAN | False | Set to `true` to exclude offers that have already been taken [Default: false] | +| include_completed | BOOLEAN | False | Set to `true` to include offers that have been taken [Default: false] | +| sort_key | NUMBER | False | Specify the key for sorting, [sort_keys members](https://github.com/Chia-Network/chia-blockchain/blob/5f6c336e757534d3a36b1a03612e05b412a18c61/chia/wallet/transaction_sorting.py#L6) [Default: `confirmed_at_height`] | +| reverse | BOOLEAN | False | Set to `true` to sort the results in reverse order [Default: false] | +| file_contents | BOOLEAN | False | Set to `true` to display the contents of each offer [Default: false] | -
-Example +
Example ```json chia rpc wallet get_all_offers @@ -4443,8 +4509,7 @@ Options: Request Parameters: None -
-Example +
Example Get the default CAT list: @@ -4486,6 +4551,49 @@ Response: --- +### `crcat_approve_pending` + +Functionality: Moves CR-CAT coins that are awaiting approval into the wallet’s spendable balance (claims pending-approval balance). Builds and pushes transactions subject to standard transaction parameters. + +Usage: chia rpc wallet [OPTIONS] crcat_approve_pending [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :--------------------------------------------------------------------------------- | :------ | :------- | :-------------------------------------------------------------------------------------------------- | +| wallet_id | INTEGER | True | CR-CAT wallet id | +| min_amount_to_claim | INTEGER | True | Minimum amount (in mojos) required to include a coin when claiming pending funds | +| fee | INTEGER | False | Blockchain fee in mojos | +| reuse_puzhash | BOOLEAN | False | Standard transaction flag (see other wallet TX RPCs) | +| push | BOOLEAN | False | Whether to push the transaction to the full node | +| sign | BOOLEAN | False | Whether to sign automatically | +| allow_unsynced | BOOLEAN | False | Allow when wallet is not fully synced | + +:::note + +`min_amount_to_claim` filters which pending coins are included; set it to `0` or a small value to claim all pending balance per implementation defaults where applicable. + +::: + +
Example + +```json +chia rpc wallet crcat_approve_pending '{"wallet_id": 5, "min_amount_to_claim": 1, "fee": 1000}' +``` + +Response follows other transaction endpoints (`transactions`, `unsigned_transactions`, etc., populated by the `@tx_endpoint` wrapper). + +
+ +--- + ### `get_offer` Functionality: Show the details of one offer @@ -4501,13 +4609,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------ | :--- | :------- | :------------------------------------------------------------------------------------------------------------------------------- | -| trade_id | TEXT | True | The offer's ID | +| Flag | Type | Required | Description | +| :--------------------------------- | :--- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| trade_id | TEXT | True | The offer's ID | | file_contents | TEXT | False | The contents of the offer. The contents of the offer. Required if the offer's info is not stored in the database for this wallet | -
-Example +
Example ```json chia rpc wallet get_offer '{"trade_id": "c4d9f06599e4ba30edfabecc72a03db7d7e86c003ab83520002a844cfebf2ef5"}' @@ -4583,8 +4690,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_offers_count @@ -4620,13 +4726,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------- | :------ | :------- | :---------------------------------------------------------- | -| offer | TEXT | True | The offer for which to retrieve a summary | +| Flag | Type | Required | Description | +| :------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------------ | +| offer | TEXT | True | The offer for which to retrieve a summary | | advanced | BOOLEAN | False | Set to `true` to show a detailed summary [Default: `false`] | -
-Example +
Example ```json chia rpc wallet get_offer_summary '{"offer": "offer1qqzh3wcuu2rykcmqvpsxygqqwc7hynr6hum6e0mnf72sn7uvvkpt68eyumkhelprk0adeg42nlelk2mpagr90qq0a37v8lc9pfxkwhdhlns4tnwtx933g0gsj06neuds6jjugly4k5x7we0x39h9ur65y2cmwttg00ht60xnjly6zhduf0h9hmedaq67yh89uafrzctmgrka06llmvv9uhze9tqqpd38v8zcv4x32hhe7wueh4t8vd9cn6uhqk7vejppfygfgtje8usle5c5ukqmlw72va4pv8mweg5ztmcakwex27z9uamchklr2mtk7ax4tadcte8hq98380vuxcnfkjxndkjxrdk68rdk69rdk68ga95mfr2xhump4wrstastammnc2aav3hrd4ej8gexus0gje2urasruamdvrwvas9wm56mykj42pj6cp0vlymr5daw8k9e780kxd46wsh9u4e4tk7dw49w2epylahdz44aq2kj4ypthrsme4qwdncgdnwhlcw2amlhhsl6z0wlca7573y7knevrjjz4kpg80gnrlmlx7q6lh2rdtll6j6kh72t66vmwn25gwh5eqsd6wpqc6yqkn9luteq6nz0hh7yln3r7ct9yqecrfh95lyzace38xayytnu7x2fl4whv40e6etxehv03mwzdlnfttaxckmea7xle3hs0tzvlmdlch7qjzul97gymhjsew40ef2vmf6m8m4ntw0x08ceu7xkxm0fxjut754n9qd2anljlwpk49z4472n65af226w03fha2j7hyshuuh8gdr68z3a67atjcnl07vswj0clutncre6wt4la0au8vdlmxjn7fe8mqald7l8rh2hgls66uxhutuzdqmnr0ljlkyulq5t67rru25jnxjjyxntvllt2n4j244utj7ahu6avas47nlhrah2p5uursd0uteccgjtncy6e62uvn6tathamz0m0rfweuaaq5mevp6klth99dhf0f6hcqksxfpqmvhlpvyrtj2qjmvnwyr96saajuyp8vm70h7vhtw93vkmj7llmquru84g0vv80fd3eg65vhfrlm5yrgzs4pa95el4wa6w9nfkgvvazzek9eef4kd6zr6rjue6culxd8wdg5dglrevft9lc7hfljuc70hx9uq587fl64gp3s467zj58nvdaawuet3lvft8hvynv5j83tlg5phaeteme079hw6xn5dn54tm602ln2vgknvammql8fe7zuqzvfq20gc9s4d4", "advanced": true}' @@ -4674,8 +4779,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_stray_cats @@ -4709,17 +4813,16 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| offer | TEXT | True | The offer to create | -| min_coin_amount | NUMBER | False | The minimum coin amount to select for taking the offer [Default: none] | -| max_coin_amount | NUMBER | False | The maximum coin amount to select for taking the offer [Default: none] | -| solver | TEXT | False | A marshalled solver | -| fee | NUMBER | False | An optional blockchain fee, in mojos | -| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | +| Flag | Type | Required | Description | +| :-------------------------------------------------------- | :------ | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| offer | TEXT | True | The offer to create | +| min_coin_amount | NUMBER | False | The minimum coin amount to select for taking the offer [Default: none] | +| max_coin_amount | NUMBER | False | The maximum coin amount to select for taking the offer [Default: none] | +| solver | TEXT | False | A marshalled solver | +| fee | NUMBER | False | An optional blockchain fee, in mojos | +| reuse_puzhash | BOOLEAN | False | If `true`, will not generate a new puzzle hash / address for this transaction only. Note that setting this parameter to `true` will override the global default setting from config.yaml | -
-Example +
Example ```json chia rpc wallet take_offer '{"offer": "offer1qqzh3wcuu2rykcmqvpsxvgqqwc7hynr6hum6e0mnf72sn7uvvkpt68eyumkhelprk0adeg42nlelk2mpagr90qq0a37v8lc9pfxkwhdhlns4tnwtx933g0gsj06neuds6jjugly4k5x7we0x39h9ur65kfq0nl5ef86n4uv9hlnlhhqs4zu99cwjzf6fp675f8gne67qh42lhyhlxuemvtgqtwftqcjr4t524a70nhx9u2emrfwv7h9c94nxvsv2eqz2rujflx87vxp84jxh6hjnh0grq7mk29q6l78drkfjks408w79ahu6x6alhf420fw27fec0mufmmrp2y6d5sqmdksg6dksgcdk3gcdxn60gdx6gz347qcdtjuz7vxl7uu7zhtt50cmdwv32yfh9r7yx2hq7vylhvmrqmn8vrt7uxje4542svkkqtm8cxuar0tea3w0pmaend2n58e09wd2ahnr4ftjx2f8ldmg4d0gz4s4eq2acuz7vurnv7xrue4h7rkh7aaaa87snmh78038yf8447tqvks4dswpm6ycl7me8jxhu65m6al74k44lsj7hnxmy642z4exc8rxssgxx3qp5e0lzugx4hlada38auvlkqefpx2q6vm9c9nmlnjvfqfd3a9zaln6wf7y9hn4289cu9chjjha0wkmejcd56dmlaln80cakqe0jmln0uq58ek2uufhf9enazlz55e4nah0ntxhujdw03tmufvak7z09ckadt7gqj4t9laluraacee9z4ujekmy7e04w7h229nmtnnlul2ntkckge0rnvhvan4e42xtjzz07l7p7wsz8dlwll9mhv734uuj2t7hxlu0hesm6a7h29x7pfmjmrn0xgut0u0lstxcnr7j3vmjd8565g532cn2lwm5ad27vtzuh4dm8h0h29hk7460lcgx8txung0pl7pzxnyjpwhwjhrflj62flk7nkug7f7d8m04kurr09s2tmewvkd6u478yuqz6g75yramlqzsjvxxfxtaqdg5d0vnp5tmsumnlmx6ejudykahm7wm8uup3tn7rpa63d79x9992fhaud82s5dqwqgr5my703zjparwu8e2t6fedl2lvl0gvww3g73s9le8hqh3el00xma08qh3y6cku6vlu4jal0xh204xd07dymgtr0lfdnknmr8nhe0mhwalcj6pa4z2vux3qu3jc8mdhtmxl5uppk256uk6r794af5xfsuhxwp5a6sdcmwexlg5hhkgw3d66ycj42cc6l8lw3w4td8wu330lszmvzklqry5zxm8t34psew5z6g9k70lm0aaxkghx5afmhxqwtl7f9kycy9uhdhmdchlzesfphs89gmsz7c9nref02n4nau8h2hn7hdpg0sm4h0t9zrrnc6ajdev7s88a90lwpj6r2k782sz4kllpdn077hdvr7ua68g5e0e674h6e5008zvzavnra64c6v6p8nf33zkuulxsppk4ywx2wmdj0e66j82a8l5m4e5ajzw67dchhsuua9hafr3y4qcm2m0cthf8wf4ka2ts0m0hst0cjntnkfghphysfjm7egnych2mc3wly2827ln2ltqxv32wwkx7flukf7rg4tr25j38774tpq5lqc8l5tvv3mdjcl4llgyqrnekfxyz26de6"}' @@ -4817,11 +4920,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :--------------- | :----- | :------- | :-------------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID to which to absorb funds (must be of type `POOLING_WALLET`) | +| Flag | Type | Required | Description | +| :------------------------------------------------------------------------------ | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID to which to absorb funds (must be of type `POOLING_WALLET`) | | max_spends_in_tx | NUMBER | False | The maximum number of reward transactions to roll into the absorb transaction [Default: no maximum] | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | :::note @@ -4831,11 +4934,11 @@ This RPC will only succeed if the wallet has accumulated unspent coinbase reward --- -### `pw_join_pool` +### `register_remote_coins` -Functionality: Join a pool +Functionality: Registers remote (watch-only) coin IDs with a **remote** wallet so they are tracked. The wallet must be a `RemoteWallet` instance for `wallet_id`. -Usage: chia rpc wallet [OPTIONS] pw_join_pool [REQUEST] +Usage: chia rpc wallet [OPTIONS] register_remote_coins [REQUEST] Options: @@ -4846,16 +4949,47 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------------- | :----- | :------- | :--------------------------------------------------------------------------------------------- | -| wallet_id | NUMBER | True | The Wallet ID to use to join the pool (must be of type `POOLING_WALLET`) | -| target_puzzlehash | TEXT | True | This is the target of where rewards will be sent to from the singleton. Controlled by the pool | -| pool_url | TEXT | True | The URL of the pool to join | -| relative_lock_height | NUMBER | True | The number of blocks required to wait when attempting to leave the pool | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| Flag | Type | Required | Description | +| :----------------------------- | :----------- | :------- | :----------------------------------------------------------- | +| wallet_id | INTEGER | True | Remote wallet id | +| coin_ids | ARRAY OF HEX | True | Coin names (IDs) to register for tracking | -
-Example +
Example + +```json +chia rpc wallet register_remote_coins '{"wallet_id": 2, "coin_ids": ["0xabc...", "0xdef..."]}' +``` + +Response: empty object on success. + +
+ +--- + +### `pw_join_pool` + +Functionality: Join a pool + +Usage: chia rpc wallet [OPTIONS] pw_join_pool [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :------------------------------------------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------- | +| wallet_id | NUMBER | True | The Wallet ID to use to join the pool (must be of type `POOLING_WALLET`) | +| target_puzzlehash | TEXT | True | This is the target of where rewards will be sent to from the singleton. Controlled by the pool | +| pool_url | TEXT | True | The URL of the pool to join | +| relative_lock_height | NUMBER | True | The number of blocks required to wait when attempting to leave the pool | +| fee | NUMBER | False | An optional blockchain fee, in mojos | + +
Example Join Spacepool: @@ -4996,10 +5130,10 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :----------------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------ | | wallet_id | NUMBER | True | The Wallet ID to use for self-pooling (must be of type `POOLING_WALLET`) | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | :::info @@ -5007,8 +5141,7 @@ This command will only succeed if `wallet_id` is a member of a pool. ::: -
-Example +
Example Leave Spacepool: @@ -5149,12 +5282,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :-------- | :----- | :------- | :------------------------------------------------------------------------------ | +| Flag | Type | Required | Description | +| :----------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------- | | wallet_id | NUMBER | True | The Wallet ID for which to obtain the status (must be of type `POOLING_WALLET`) | -
-Example +
Example ```json chia rpc wallet pw_status '{"wallet_id": 9}' @@ -5222,8 +5354,7 @@ For more info on creating a new data store and obtaining a root hash, see [the D ::: -
-Example +
Example ```json chia rpc wallet create_new_dl '{"fee": 1, "root": "0x0000000000000000000000000000000000000000000000000000000000000000"}' @@ -5363,13 +5494,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------ | :----- | :------- | :------------------------------------ | +| Flag | Type | Required | Description | +| :--------------------------- | :----- | :------- | :------------------------------------ | | coin_id | TEXT | True | The `coin_id` of the mirror to delete | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | -
-Example +
Example ```json chia rpc wallet dl_delete_mirror '{"coin_id": "a6f36cf305c59db988ee0c1c39546ae9577ce75fd9cabe18cdacf94d8168077b", "fee": 1}' @@ -5433,6 +5563,33 @@ Response: --- +### `dl_verify_proof` + +Functionality: Verifies a DataLayer proof of inclusion for a singleton coin. The JSON body must be a full `DLProof` (`store_proofs`, `coin_id`, `inner_puzzle_hash`). The wallet uses your connected full node to validate the proof. + +Usage: chia rpc wallet [OPTIONS] dl_verify_proof [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request parameters are the `DLProof` streamable fields. See the `DLProof` type in the Chia reference client; proofs are typically produced by DataLayer tooling. Related: [DataLayer RPC](/reference-client/rpc-reference/datalayer-rpc). + +
Example + +```json +chia rpc wallet dl_verify_proof @proof.json +``` + +Response includes `success`, whether the on-chain root matches (`current_root`), and `verified_clvm_hashes` with per-key verification details. + +
+ +--- + ### `dl_get_mirrors` Functionality: Get all of the mirrors for a specific singleton @@ -5448,12 +5605,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--- | :------- | :-------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--- | :------- | :-------------------------------------- | | launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | -
-Example +
Example ```json chia rpc wallet dl_get_mirrors '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e"}' @@ -5495,15 +5651,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :----- | :------- | :----------------------------------------------------------- | -| launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | +| Flag | Type | Required | Description | +| :---------------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------- | +| launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | | min_generation | NUMBER | False | The first generation of singleton to show [Default: none] | | max_generation | NUMBER | False | The last generation of the singleton to show [Default: none] | | num_results | NUMBER | False | The number of results to show [Default: show all results] | -
-Example +
Example ```json chia rpc wallet dl_history '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e"}' @@ -5569,13 +5724,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :------------- | :------ | :------- | :----------------------------------------------------- | -| launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | +| Flag | Type | Required | Description | +| :---------------------------------- | :------ | :------- | :------------------------------------------------------------------------------------------------------------------------- | +| launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | | only_confirmed | BOOLEAN | False | Only show the latest confirmed record [Default: false] | -
-Example +
Example ```json chia rpc wallet dl_latest_singleton '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e"}' @@ -5623,15 +5777,14 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--------- | :------- | :------------------------------------------------------------------------------------------------------------------------------ | -| launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | -| urls | TEXT ARRAY | True | A list of URLs to be used for the mirror | -| amount | NUMBER | True | The value of the mirror (in mojos) to spend to create the mirror. In theory, mirrors with a higher `amount` will be prioritized | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| Flag | Type | Required | Description | +| :------------------------------- | :--------- | :------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | +| urls | TEXT ARRAY | True | A list of URLs to be used for the mirror | +| amount | NUMBER | True | The value of the mirror (in mojos) to spend to create the mirror. In theory, mirrors with a higher `amount` will be prioritized | +| fee | NUMBER | False | An optional blockchain fee, in mojos | -
-Example +
Example ```json chia rpc wallet dl_new_mirror '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e", "urls":["http://www.example.com:8575", "http://www.example2.com:8575"], "amount":10, "fee": 1}' @@ -5717,8 +5870,7 @@ Options: Request Parameters: None -
-Example +
Example ```json chia rpc wallet dl_owned_singletons @@ -5784,13 +5936,12 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--- | :------- | :-------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--- | :------- | :-------------------------------------- | | launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | -| root | TEXT | True | The root hash of an existing data store | +| root | TEXT | True | The root hash of an existing data store | -
-Example +
Example ```json chia rpc wallet dl_singletons_by_root '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e", "root": "0x0000000000000000000000000000000000000000000000000000000000000000"}' @@ -5840,12 +5991,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--- | :------- | :-------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--- | :------- | :-------------------------------------- | | launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | -
-Example +
Example ```json chia rpc wallet dl_stop_tracking '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e"}' @@ -5878,12 +6028,11 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :--- | :------- | :-------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :--- | :------- | :-------------------------------------- | | launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | -
-Example +
Example ```json chia rpc wallet dl_track_new '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e"}' @@ -5937,14 +6086,13 @@ Options: Request Parameters: -| Flag | Type | Required | Description | -| :---------- | :----- | :------- | :-------------------------------------- | +| Flag | Type | Required | Description | +| :------------------------------- | :----- | :------- | :-------------------------------------- | | launcher_id | TEXT | True | The launcher ID of the DataLayer wallet | | new_root | TEXT | True | The new root hash of the data store | -| fee | NUMBER | False | An optional blockchain fee, in mojos | +| fee | NUMBER | False | An optional blockchain fee, in mojos | -
-Example +
Example ```json chia rpc wallet dl_update_root '{"launcher_id": "0x4aecd65d5fd0dcac59ef41ad5a74134e38b3e8334aebb1356972b7e9c793a09e", "new_root": "0x0000000000000000000000000000000000000000000000000000000000000000", "fee": 1}' @@ -6027,12 +6175,11 @@ Note: Inherited from RPC Server Request Parameters: -| Flag | Type | Required | Description | -| :------ | :--- | :------- | :--------------------------------------------------------------- | +| Flag | Type | Required | Description | +| :--------------------------- | :--- | :------- | :------------------------------------------------------------------------------------ | | node_id | TEXT | True | The hex ID of the node to close, obtainable from get_connections | -
-Example +
Example ```json chia rpc wallet close_connection '{"node_id":"0x8e961b617579d476419003728d6d71ab1b182f7d962e5db16f61ebfb157d771b"}' @@ -6058,8 +6205,7 @@ Note: Inherited from RPC Server Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_connections @@ -6097,8 +6243,7 @@ Functionality: List all available RPC routes Request Parameters: None -
-Example +
Example ```json chia rpc wallet get_routes @@ -6109,130 +6254,139 @@ Response: ```json { "routes": [ - "/log_in", - "/get_logged_in_fingerprint", - "/get_public_keys", - "/get_private_key", - "/generate_mnemonic", "/add_key", - "/delete_key", + "/apply_signatures", + "/cancel_offer", + "/cancel_offers", + "/cat_asset_id_to_name", + "/cat_get_asset_id", + "/cat_get_name", + "/cat_set_name", + "/cat_spend", "/check_delete_key", - "/delete_all_keys", - "/set_wallet_resync_on_startup", - "/get_sync_status", - "/get_height_info", - "/push_tx", - "/push_transactions", - "/farm_block", - "/get_timestamp_for_height", - "/set_auto_claim", - "/get_auto_claim", - "/get_initial_freeze_period", - "/get_network_info", - "/get_wallets", + "/check_offer_validity", + "/close_connection", + "/combine_coins", + "/crcat_approve_pending", + "/create_new_dl", "/create_new_wallet", - "/get_wallet_balance", - "/get_wallet_balances", - "/get_transaction", - "/get_transactions", - "/get_transaction_count", - "/get_next_address", - "/send_transaction", - "/send_transaction_multi", - "/spend_clawback_coins", - "/get_coin_records", - "/get_farmed_amount", + "/create_offer_for_ids", "/create_signed_transaction", + "/delete_all_keys", + "/delete_key", + "/delete_notifications", "/delete_unconfirmed_transactions", - "/select_coins", - "/get_spendable_coins", + "/did_create_backup_file", + "/did_find_lost_did", + "/did_get_current_coin_info", + "/did_get_did", + "/did_get_info", + "/did_get_metadata", + "/did_get_pubkey", + "/did_get_wallet_name", + "/did_message_spend", + "/did_set_wallet_name", + "/did_transfer_did", + "/did_update_metadata", + "/dl_delete_mirror", + "/dl_get_mirrors", + "/dl_history", + "/dl_latest_singleton", + "/dl_new_mirror", + "/dl_owned_singletons", + "/dl_singletons_by_root", + "/dl_stop_tracking", + "/dl_track_new", + "/dl_update_multiple", + "/dl_update_root", + "/dl_verify_proof", + "/execute_signing_instructions", + "/extend_derivation_index", + "/gather_signing_info", + "/generate_mnemonic", + "/get_all_offers", + "/get_auto_claim", + "/get_cat_list", + "/get_coin_records", "/get_coin_records_by_names", + "/get_connections", "/get_current_derivation_index", - "/extend_derivation_index", + "/get_farmed_amount", + "/get_fee_estimate", + "/get_full_node_peer_count", + "/get_height_info", + "/get_log_level", + "/get_logged_in_fingerprint", + "/get_network_info", + "/get_next_address", "/get_notifications", - "/delete_notifications", - "/send_notification", - "/sign_message_by_address", - "/sign_message_by_id", - "/verify_signature", - "/get_transaction_memo", - "/cat_set_name", - "/cat_asset_id_to_name", - "/cat_get_name", - "/get_stray_cats", - "/cat_spend", - "/cat_get_asset_id", - "/create_offer_for_ids", - "/get_offer_summary", - "/check_offer_validity", - "/take_offer", "/get_offer", - "/get_all_offers", + "/get_offer_summary", "/get_offers_count", - "/cancel_offer", - "/cancel_offers", - "/get_cat_list", - "/did_set_wallet_name", - "/did_get_wallet_name", - "/did_update_recovery_ids", - "/did_update_metadata", - "/did_get_pubkey", - "/did_get_did", - "/did_recovery_spend", - "/did_get_recovery_list", - "/did_get_metadata", - "/did_create_attest", - "/did_get_information_needed_for_recovery", - "/did_get_current_coin_info", - "/did_create_backup_file", - "/did_transfer_did", - "/did_message_spend", - "/did_get_info", - "/did_find_lost_did", - "/nft_mint_nft", + "/get_private_key", + "/get_public_keys", + "/get_puzzle_and_solution", + "/get_routes", + "/get_spendable_coins", + "/get_stray_cats", + "/get_sync_status", + "/get_timestamp_for_height", + "/get_transaction", + "/get_transaction_count", + "/get_transaction_memo", + "/get_transactions", + "/get_version", + "/get_wallet_balance", + "/get_wallet_balances", + "/get_wallets", + "/healthz", + "/log_in", + "/nft_add_uri", + "/nft_calculate_royalties", "/nft_count_nfts", - "/nft_get_nfts", "/nft_get_by_did", - "/nft_set_nft_did", - "/nft_set_nft_status", + "/nft_get_info", + "/nft_get_nfts", "/nft_get_wallet_did", "/nft_get_wallets_with_dids", - "/nft_get_info", - "/nft_transfer_nft", - "/nft_add_uri", - "/nft_calculate_royalties", "/nft_mint_bulk", + "/nft_mint_nft", "/nft_set_did_bulk", + "/nft_set_nft_did", + "/nft_set_nft_status", "/nft_transfer_bulk", + "/nft_transfer_nft", + "/open_connection", + "/push_transactions", + "/push_tx", + "/pw_absorb_rewards", "/pw_join_pool", "/pw_self_pool", - "/pw_absorb_rewards", "/pw_status", - "/create_new_dl", - "/dl_track_new", - "/dl_stop_tracking", - "/dl_latest_singleton", - "/dl_singletons_by_root", - "/dl_update_root", - "/dl_update_multiple", - "/dl_history", - "/dl_owned_singletons", - "/dl_get_mirrors", - "/dl_new_mirror", - "/dl_delete_mirror", - "/vc_mint", + "/register_remote_coins", + "/reset_log_level", + "/select_coins", + "/send_notification", + "/send_transaction", + "/send_transaction_multi", + "/set_auto_claim", + "/set_log_level", + "/set_wallet_resync_on_startup", + "/sign_message_by_address", + "/sign_message_by_id", + "/spend_clawback_coins", + "/split_coins", + "/stop_node", + "/submit_transactions", + "/take_offer", + "/vc_add_proofs", "/vc_get", "/vc_get_list", - "/vc_spend", - "/vc_add_proofs", "/vc_get_proofs_for_root", + "/vc_mint", "/vc_revoke", - "/get_connections", - "/open_connection", - "/close_connection", - "/stop_node", - "/get_routes", - "/healthz" + "/vc_spend", + "/verify_signature" ], "success": true } @@ -6255,8 +6409,7 @@ Request Parameters: | host | TEXT | True | The IP or URL of the node to connect to | | port | INTEGER | True | The port through which to connect to the remote node | -
-Example +
Example ```json chia rpc wallet open_connection '{"host":"localhost", "port":"8444"}' @@ -6282,8 +6435,7 @@ Note: Inherited from RPC Server Request Parameters: None -
-Example +
Example ```json chia rpc wallet stop_node @@ -6298,3 +6450,381 @@ Response: ```
+ +--- + +### `gather_signing_info` + +Functionality: Builds signing instructions for the given spends (offline / hardware-wallet friendly flow). Pair with `apply_signatures` and `submit_transactions`. + +Usage: chia rpc wallet [OPTIONS] gather_signing_info [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :----- | :---- | :------- | :---------------------------------- | +| spends | ARRAY | True | List of `Spend` objects to sign for | + +Response: `signing_instructions` (use with `execute_signing_instructions` or an external signer). + +
Example + +```json +chia rpc wallet gather_signing_info '{ + "spends": [ + { + "coin": { + "amount": 21999981855456, + "parent_coin_id": "0xedee4defe510196869f53da7877236e56a0b097640b48c1b6c1a20bb92257a16", + "puzzle_hash": "0x58d4fa1f9b0069a41119662f38457ac2ff35ddf74b9fd01762e3da2c97112d3e" + }, + "puzzle": "0xff02ffff01ff02...ff018080", + "solution": "0xff80ffff01ffff3c...ff8080" + } + ] +}' +``` + +This request uses a real spend shape and non-empty payload, matching the structures returned by wallet transaction-building RPCs on this page. + +
+ +--- + +### `apply_signatures` + +Functionality: Applies collected `SigningResponse` entries to the provided spends and returns signed transactions ready for submission. + +Usage: chia rpc wallet [OPTIONS] apply_signatures [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :------------------------------------- | :---- | :------- | :--------------------------- | +| spends | ARRAY | True | Same `Spend` list as signing | +| signing_responses | ARRAY | True | Responses from your signer | + +Response: `signed_transactions` (pass to `submit_transactions`). + +
Example + +```json +chia rpc wallet apply_signatures '{ + "spends": [ + { + "coin": { + "amount": 21999981855456, + "parent_coin_id": "0xedee4defe510196869f53da7877236e56a0b097640b48c1b6c1a20bb92257a16", + "puzzle_hash": "0x58d4fa1f9b0069a41119662f38457ac2ff35ddf74b9fd01762e3da2c97112d3e" + }, + "puzzle": "0xff02ffff01ff02...ff018080", + "solution": "0xff80ffff01ffff3c...ff8080" + } + ], + "signing_responses": [ + { + "hook": "0x5164cb7113616036c959df00ffa45f0a06e1f1c8d04ac3c811b0f20f591c6d26", + "signature": "0xa71cf8d85b4f30aeb63e0f6e1f478f55f19f5dba8cd5f6d9a2746f4d30f15c3f..." + } + ] +}' +``` + +Response returns `signed_transactions` suitable for `submit_transactions`. + +
+ +--- + +### `submit_transactions` + +Functionality: Submits already-signed transactions to the wallet / full node; returns mempool IDs for each. + +Usage: chia rpc wallet [OPTIONS] submit_transactions [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :--------------------------------------- | :---- | :------- | :----------------------- | +| signed_transactions | ARRAY | True | `SignedTransaction` list | + +Response: `mempool_ids` (one per submitted spend bundle). + +
Example + +```json +chia rpc wallet submit_transactions '{ + "signed_transactions": [ + { + "transaction_info": { + "spends": [ + { + "coin": { + "amount": 21999981855456, + "parent_coin_id": "0xedee4defe510196869f53da7877236e56a0b097640b48c1b6c1a20bb92257a16", + "puzzle_hash": "0x58d4fa1f9b0069a41119662f38457ac2ff35ddf74b9fd01762e3da2c97112d3e" + }, + "puzzle": "0xff02ffff01ff02...ff018080", + "solution": "0xff80ffff01ffff3c...ff8080" + } + ] + }, + "signatures": [ + { + "type": "bls_12381_aug_scheme", + "signature": "0xa71cf8d85b4f30aeb63e0f6e1f478f55f19f5dba8cd5f6d9a2746f4d30f15c3f..." + } + ] + } + ] +}' +``` + +Response returns `mempool_ids` for the submitted bundles. + +
+ +--- + +### `execute_signing_instructions` + +Functionality: Executes signing instructions (hardware wallet, remote signer, etc.) and returns `signing_responses`. Often used with output from `gather_signing_info`. + +Usage: chia rpc wallet [OPTIONS] execute_signing_instructions [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :---------------------------------------- | :------ | :------- | :--------------------------------------------------------------------------------------------------------- | +| signing_instructions | OBJECT | True | `SigningInstructions` payload | +| partial_allowed | BOOLEAN | False | Allow partial results [Default: false] | + +Response: `signing_responses` for `apply_signatures`. + +
Example + +```json +chia rpc wallet execute_signing_instructions '{ + "signing_instructions": { + "key_hints": { + "path_hints": [ + { + "path": [12381, 8444, 2, 19], + "root_fingerprint": "0x428c4870" + } + ], + "sum_hints": [ + { + "final_pubkey": "0x8b3488cda8b3a32bcb74058bfb10c93a642d987908e6aec880dc85bf81b4b872b9f2cc6e08df73f62019ff593a2de1fd", + "fingerprints": ["0x619bc5cd"], + "synthetic_offset": "0x64771976abb4a834675485d405228f1d42de0fe66ff8a15fcccb3edc5318ffed" + } + ] + }, + "targets": [ + { + "fingerprint": "0xb995704b", + "hook": "0x5164cb7113616036c959df00ffa45f0a06e1f1c8d04ac3c811b0f20f591c6d26", + "message": "0x45c51f68a927c0a5cab76e23821c14ed48508a03680d0f2b8171110fd424a381..." + } + ] + }, + "partial_allowed": false +}' +``` + +Response returns `signing_responses` for `apply_signatures`. + +
+ +--- + +### `get_version` + +Functionality: Returns the Chia reference client version string. + +Usage: chia rpc wallet [OPTIONS] get_version [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_version +``` + +Response: + +```json +{ + "success": true, + "version": "2.6.0" +} +``` + +
+ +--- + +### `get_log_level` + +Functionality: Returns the root logger level and accepted level names for `set_log_level`. + +Usage: chia rpc wallet [OPTIONS] get_log_level [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None + +
Example + +```json +chia rpc wallet get_log_level +``` + +Response: + +```json +{ + "available_levels": [ + "CRITICAL", + "FATAL", + "ERROR", + "WARN", + "WARNING", + "INFO", + "DEBUG", + "NOTSET" + ], + "level": "INFO", + "success": true +} +``` + +A wallet log-level change applies to the wallet process only. To set a different level on the full node, call the same endpoints on the `full_node` service (`chia rpc full_node get_log_level` / `set_log_level`). + +
+ +--- + +### `set_log_level` + +Functionality: Sets the root logging level for the wallet process. + +Usage: chia rpc wallet [OPTIONS] set_log_level [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: + +| Flag | Type | Required | Description | +| :---- | :----- | :------- | :------------- | +| level | STRING | True | Log level name | + +
Example + +```json +chia rpc wallet set_log_level '{"level": "INFO"}' +``` + +Response includes `level`, `available_levels`, `errors`, and `success`. + +
+ +--- + +### `reset_log_level` + +Functionality: Resets logging to the level from wallet service configuration. + +Usage: chia rpc wallet [OPTIONS] reset_log_level [REQUEST] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------- | :------- | :------------------------------------------------------------------------------------ | +| -j | --json-file | FILENAME | False | Optionally instead of REQUEST you can provide a json file containing the request data | +| -h | --help | None | False | Show a help message and exit | + +Request Parameters: None (use `{}`). + +
Example + +```json +chia rpc wallet reset_log_level '{}' +``` + +Response matches `set_log_level`. + +
+ +--- + +### `healthz` + +Functionality: Lightweight liveness check from the RPC server. + +Usage: chia rpc wallet [OPTIONS] healthz [REQUEST] + +Request Parameters: None + +
Example + +```json +chia rpc wallet healthz +``` + +Response: + +```json +{ + "success": true +} +``` + +
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/locating-keys.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/locating-keys.md index 10cf08569ad..be8dfdb4680 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/locating-keys.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/locating-keys.md @@ -7,7 +7,7 @@ import WalletKeyDetails from '@site/static/img/troubleshooting/wallet_key_detail import WalletKeysOverview from '@site/static/img/troubleshooting/wallet_keys_overview.png'; import WalletLogout from '@site/static/img/troubleshooting/wallet_logout.png'; -This doc assumes you have chia installed and will overview both the CLI and GUI methods of identifying various keys.\ +This doc assumes you have chia installed and will overview both the CLI and GUI methods of identifying various keys. Please refer to the [Installation page](/reference-client/install-and-setup/installation) if you do not have chia installed. ## Keys Overview @@ -72,7 +72,7 @@ chia keys show ``` :::warning -`chia keys show --show-mnemonic-seed`\ +`chia keys show --show-mnemonic-seed` displays the _Master Private Key, Farmer Private Key, and Seed Phrase / Mnemonic_ **NEVER** share these with anyone. ::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/logging-reference.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/logging-reference.md index 2e062dcc3e2..f30c7a31430 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/logging-reference.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/logging-reference.md @@ -10,12 +10,12 @@ Chia blockchain nodes consist of several components that each handle different a ## Log file Location: -| OS | Location | -| ------- | ----------------------------------------------------------------- | -| Linux | `~/.chia/mainnet/log/debug.log` | -| Windows | `\$env:USERPROFILE\.chia\mainnet\log\debug.log` | -| Windows | `C:\Users\\.chia\mainnet\log\debug.log` | -| MacOS | `\$HOME/.chia/mainnet/log/debug.log` (`/Users//.chia…`) | +| OS | Location | +| ------- | ----------------------------------------------------------------------------------- | +| Linux | `~/.chia/mainnet/log/debug.log` | +| Windows | `$env:USERPROFILE\.chia\mainnet\log\debug.log` | +| Windows | `C:\Users\\.chia\mainnet\log\debug.log` | +| MacOS | `$HOME/.chia/mainnet/log/debug.log` (`/Users//.chia…`) | ## Log File Management: @@ -58,17 +58,17 @@ Your options for log levels are `ERROR`, `WARN`, `INFO`, and `DEBUG`. ## Node Components: -| Component | Function | -| ---------------- | ----------------------------------------------- | -| farmer_server | Signage stuff about signs and things | -| harvester_server | Gathers and shares plot information | -| timelord_server | Manages Verifiable Delay Functions for the node | -| wallet_server | Controls wallet functions | +| Component | Function | +| ---------------------------------------------------------- | ----------------------------------------------- | +| farmer_server | Signage stuff about signs and things | +| harvester_server | Gathers and shares plot information | +| timelord_server | Manages Verifiable Delay Functions for the node | +| wallet_server | Controls wallet functions | | full_node_server | This component manages the node | ## Log Message Format: -| Field | 内容 | +| Field | 内容 | | ----------------- | -------------------------------- | | Date/time | in ISO format, in local timezone | | Node Component | see the list above | @@ -94,73 +94,73 @@ Another log message you will see is `Updated Wallet peak to height x, weight y` ## Other Normal Log Messages: -| Component | Message | Direction | Destination | Cross component | -| ----------------- | ------------------------------------------------ | --------- | ----------- | -------------------- | -| mempool_manager | add_spendbundle took x seconds | | | | -| mempool_manager | It took x to pre validate transaction | | | | -| full_node | Added unfinished_block x, not farmed by us | | | | -| full_node | Already compactified block: | | | | -| full_node | Duplicate compact proof. Height: x | | | | -| full_node | Finished signage point x/64: | | | | -| full_node | Scanning the blockchain for uncompact blocks. | | | | -| full_node | Updated peak to height x | | | | -| full_node_server | new_compact_vdf | to/from | peer | | -| full_node_server | new_peak | to/from | peer | | -| full_node_server | new_peak_timelord | to | localhost | from timelord_server | -| full_node_server | new_peak_wallet | to | localhost | from wallet_server | -| full_node_server | new_signage_point | to | localhost | from farmer_server | -| full_node_server | new_signage_point_or_end_of_sub_slot | to/from | peer | | -| full_node_server | new_transaction | to/from | peer | | -| full_node_server | new_unfinished_block | to/from | peer | | -| full_node_server | new_unfinished_block_timelord | to/from | localhost | | -| full_node_server | request_block | to/from | peer | | -| full_node_server | request_block_header | from | localhost | to wallet_server | -| full_node_server | request_compact_vdf | to/from | peer | | -| full_node_server | request_compact_proof_of_time | to | localhost | from timelord_server | -| full_node_server | request_signage_point_or_end_of_sub_slot | to/from | peer | | -| full_node_server | request_transaction | to/from | peer | | -| full_node_server | request_unfinished_block | to/from | peer | | -| full_node_server | respond_block | to/from | peer | | -| full_node_server | respond_compact_vdf | to/from | peer | | -| full_node_server | respond_signage_point | to/from | peer | | -| full_node_server | respond_transaction | to/from | peer | | -| full_node_server | respond_unfinished_block | to/from | peer | | -| wallet_server | request_block_header | to | localhost | from full_node | -| wallet_server | respond_block_header | from | localhost | to full_node | -| wallet_server | new_peak_wallet | from | localhost | to full_node | -| wallet_blockchain | Updated Wallet peak to height x, weight y | | | | -| timelord_server | new_peak_timelord | from | localhost | to full_node | -| timelord_server | new_unfinished_block_timelord | from | localhost | to full_node | -| timelord_launcher | VDF client x: VDF Client: Discriminant = | | | | -| VDF Client | Sending Proof, Sent Proof, Stopped everything! | | | | -| harvester_server | farming_info | to/from | localhost | | -| harvester_server | new_signage_point_harvester | from | localhost | to farmer_server | -| harvester | x plots were eligible for farming | | | | -| plot_tools | Loaded a total of x plots of size y in z seconds | | | | -| plot_tools | Searching directories | | | | -| farmer_server | new_signage_point | from | localhost | to full_node | -| farmer_server | farming_info | from | localhost | to full_node | -| farmer_server | new_signage_point_harvester | to | localhost | from harvester | - -| Source | Level | Message | Description | -| ----------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| daemon asyncio | ERROR | Task exception was never retrieved future: ` exception=ValueError('list.remove(x): x not in list')>` | | -| full_node asyncio | ERROR | SSL error in data received protocol: `` | | -| full_node full_node_server | ERROR | Exception: Failed to fetch block `N` from \{'host': `IP ADDRESS`, 'port': 8444\}, timed out, \{'host': `IP ADDRESS`, 'port': 8444\}. | Peer disconnected, other peer connections will take over | -| full_node full_node_server | ERROR | Exception: ``, closing connection None. | Peer disconnected | -| full_node full_node_server | WARNING | [Errno 32] Broken pipe `IP Address` | Peer disconnected | -| full_node full_node_server | WARNING | Cannot write to closing transport `IP Address` | Peer disconnected | -| harvester src.plotting.plot_tools | WARNING | Not farming plot `plotfilename`. Size is `filesize` GiB, but expected at least: 99.06 GiB. We assume the file is being copied. | Periodic scan for new plots have discovered partial file - OK if you are in the middle of copying a file | -| harvester src.plotting.plot_tools | WARNING | Directory: `Dir1` does not exist. | One of your monitored plot folders is no longer accessible - eg external drive offline - if permanent remove from GUI or `chia plots remove -d ` | -| harvester src.plotting.plot_tools | WARNING | Have multiple copies of the plot `plotfilename`, not adding it. | | -| harvester src.plotting.plot_tools | INFO | Not checking subdirectory `Dir1/directory`, subdirectories not added by default | | -| full_node full_node_server | INFO | Connection closed: `IP Address`, node id: `hex` | Peer disconnected | -| full_node src.full_node.full_node | INFO | ⏲️ Finished signage point `N`/64: `hex` | | -| full_node src.full_node.full_node | INFO | Added unfinished_block `hex`, not farmed | | -| harvester src.plotting.plot_tools | INFO | Searching directories [`Dir1`,`Dir2`] | | -| harvester src.plotting.plot_tools | INFO | Loaded a total of `N` plots of size `size` TiB, in `time` seconds | | -| harvester src.harvester.harvester | INFO | `X` plots were eligible for farming `hex`... Found `Y` proofs. Time: `Time` s. Total `Z` plots | This is a vital message and should be seen at regular intervals. Note that `Time` is ideally < 1s. If drive is in sleep mode, may show ~10 seconds, and should be prevented | -| wallet src.wallet.wallet_blockchain | INFO | 💰 Updated wallet peak to height `HEIGHT`, weight `WEIGHT`, | | +| Component | Message | Direction | Destination | Cross component | +| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ----------- | ----------------------------------------- | +| mempool_manager | add_spendbundle took x seconds | | | | +| mempool_manager | It took x to pre validate transaction | | | | +| full_node | Added unfinished_block x, not farmed by us | | | | +| full_node | Already compactified block: | | | | +| full_node | Duplicate compact proof. Height: x | | | | +| full_node | Finished signage point x/64: | | | | +| full_node | Scanning the blockchain for uncompact blocks. | | | | +| full_node | Updated peak to height x | | | | +| full_node_server | new_compact_vdf | to/from | peer | | +| full_node_server | new_peak | to/from | peer | | +| full_node_server | new_peak_timelord | to | localhost | from timelord_server | +| full_node_server | new_peak_wallet | to | localhost | from wallet_server | +| full_node_server | new_signage_point | to | localhost | from farmer_server | +| full_node_server | new_signage_point_or_end_of_sub_slot | to/from | peer | | +| full_node_server | new_transaction | to/from | peer | | +| full_node_server | new_unfinished_block | to/from | peer | | +| full_node_server | new_unfinished_block_timelord | to/from | localhost | | +| full_node_server | request_block | to/from | peer | | +| full_node_server | request_block_header | from | localhost | to wallet_server | +| full_node_server | request_compact_vdf | to/from | peer | | +| full_node_server | request_compact_proof_of_time | to | localhost | from timelord_server | +| full_node_server | request_signage_point_or_end_of_sub_slot | to/from | peer | | +| full_node_server | request_transaction | to/from | peer | | +| full_node_server | request_unfinished_block | to/from | peer | | +| full_node_server | respond_block | to/from | peer | | +| full_node_server | respond_compact_vdf | to/from | peer | | +| full_node_server | respond_signage_point | to/from | peer | | +| full_node_server | respond_transaction | to/from | peer | | +| full_node_server | respond_unfinished_block | to/from | peer | | +| wallet_server | request_block_header | to | localhost | from full_node | +| wallet_server | respond_block_header | from | localhost | to full_node | +| wallet_server | new_peak_wallet | from | localhost | to full_node | +| wallet_blockchain | Updated Wallet peak to height x, weight y | | | | +| timelord_server | new_peak_timelord | from | localhost | to full_node | +| timelord_server | new_unfinished_block_timelord | from | localhost | to full_node | +| timelord_launcher | VDF client x: VDF Client: Discriminant = | | | | +| VDF Client | Sending Proof, Sent Proof, Stopped everything! | | | | +| harvester_server | farming_info | to/from | localhost | | +| harvester_server | new_signage_point_harvester | from | localhost | to farmer_server | +| harvester | x plots were eligible for farming | | | | +| plot_tools | Loaded a total of x plots of size y in z seconds | | | | +| plot_tools | Searching directories | | | | +| farmer_server | new_signage_point | from | localhost | to full_node | +| farmer_server | farming_info | from | localhost | to full_node | +| farmer_server | new_signage_point_harvester | to | localhost | from harvester | + +| Source | Level | Message | Description | +| -------------------------------------------------------------------------------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| daemon asyncio | ERROR | Task exception was never retrieved future: ` exception=ValueError('list.remove(x): x not in list')>` | | +| full_node asyncio | ERROR | SSL error in data received protocol: `` | | +| full_node full_node_server | ERROR | Exception: Failed to fetch block `N` from \{'host': `IP ADDRESS`, 'port': 8444\}, timed out, \{'host': `IP ADDRESS`, 'port': 8444\}. | Peer disconnected, other peer connections will take over | +| full_node full_node_server | ERROR | Exception: ``, closing connection None. | Peer disconnected | +| full_node full_node_server | WARNING | [Errno 32] Broken pipe `IP Address` | Peer disconnected | +| full_node full_node_server | WARNING | Cannot write to closing transport `IP Address` | Peer disconnected | +| harvester src.plotting.plot_tools | WARNING | Not farming plot `plotfilename`. Size is `filesize` GiB, but expected at least: 99.06 GiB. We assume the file is being copied. | Periodic scan for new plots have discovered partial file - OK if you are in the middle of copying a file | +| harvester src.plotting.plot_tools | WARNING | Directory: `Dir1` does not exist. | One of your monitored plot folders is no longer accessible - eg external drive offline - if permanent remove from GUI or `chia plots remove -d ` | +| harvester src.plotting.plot_tools | WARNING | Have multiple copies of the plot `plotfilename`, not adding it. | | +| harvester src.plotting.plot_tools | INFO | Not checking subdirectory `Dir1/directory`, subdirectories not added by default | | +| full_node full_node_server | INFO | Connection closed: `IP Address`, node id: `hex` | Peer disconnected | +| full_node src.full_node.full_node | INFO | ⏲️ Finished signage point `N`/64: `hex` | | +| full_node src.full_node.full_node | INFO | Added unfinished_block `hex`, not farmed | | +| harvester src.plotting.plot_tools | INFO | Searching directories [`Dir1`,`Dir2`] | | +| harvester src.plotting.plot_tools | INFO | Loaded a total of `N` plots of size `size` TiB, in `time` seconds | | +| harvester src.harvester.harvester | INFO | `X` plots were eligible for farming `hex`... Found `Y` proofs. Time: `Time` s. Total `Z` plots | This is a vital message and should be seen at regular intervals. Note that `Time` is ideally < 1s. If drive is in sleep mode, may show ~10 seconds, and should be prevented | +| wallet src.wallet.wallet_blockchain | INFO | 💰 Updated wallet peak to height `HEIGHT`, weight `WEIGHT`, | | ## Log Search Commands @@ -181,7 +181,7 @@ You can also use strings from any other log lines in the below command to search Functionality: Output log lines that contain the string in terminal -Usage: `find "\$HOME/.chia/mainnet/log" -type f -exec grep -Hn "[STRING]" {} \;` +Usage: `find "$HOME/.chia/mainnet/log" -type f -exec grep -Hn "[STRING]" {} \;` Options: @@ -192,13 +192,12 @@ Options: | `: WARNING` | WARNING | Outputs all warning log lines | | `proofs. Time:` | INFO | Outputs all proof check log lines | -
-Example +
Example Request: ```bash -find "\$HOME/.chia/mainnet/log" -type f -exec grep -Hn "ing service" {} \; +find "$HOME/.chia/mainnet/log" -type f -exec grep -Hn "ing service" {} \; ``` Response: @@ -230,7 +229,7 @@ You can also use strings from any other log lines in the below command to search Functionality: Output log lines that contain the string in powershell -Usage: `Get-ChildItem -Path \$env:USERPROFILE\.chia\mainnet\log\ -recurse | Select-String -Pattern "[STRING]"` +Usage: `Get-ChildItem -Path $env:USERPROFILE\.chia\mainnet\log\ -recurse | Select-String -Pattern "[STRING]"` Options: @@ -241,13 +240,12 @@ Options: | `: WARNING` | WARNING | Outputs all warning log lines | | `proofs. Time:` | INFO | Outputs all proof check log lines | -
-Example +
Example Request: ```bash -Get-ChildItem -Path \$env:USERPROFILE\.chia\mainnet\log\ -recurse | Select-String -Pattern "ing service" +Get-ChildItem -Path $env:USERPROFILE\.chia\mainnet\log\ -recurse | Select-String -Pattern "ing service" ``` Response: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/node-syncing.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/node-syncing.md index a7df4cccc83..2c82be267e0 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/node-syncing.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/node-syncing.md @@ -6,6 +6,102 @@ slug: /reference-client/troubleshooting/node-syncing import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; +## Using the Official Database Snapshot Torrent + +:::note +This process assumes you already have chia installed and all files are present in their default locations, to confirm make sure the `~/.chia/mainnet/db/` directory exists. + +If you are upgrading from a version prior to Chia 2.1.0, verify your config file (`~/.chia/mainnet/config/config.yaml`) has the correct value under the `full_node` section for `database_path` (v1 vs the current v2): +`db/blockchain_v2_CHALLENGE.sqlite` + +When starting chia for the first time with the database snapshot it can take upwards of 30 minutes for it to verify the db and load. +::: + +Using the GUI: + +1. Download the torrent file from https://www.chia.net/downloads/#database-checkpoint (mainnet and testnet database torrents are available) +2. Use a torrent client to download the full db (bittorrent, qbittorrent, and transmission have be used successfully for this) +3. Unpack/reassemble the torrent file that was downloaded (on windows one can use 7zip, Mac and linux have built in tools that work for this) +4. Move the db and associated files to the correct folder (`~/.chia/mainnet/db/` is the default location for these files) + +Using the CLI (Linux and MacOS only): + + + +1. Set your network (change to `testnet11` for the testnet db): + +```bash +NETWORK="mainnet" +``` + +2. Install a torrent client (aria is used in the below examples, other torrent clients can be used). + +```bash +sudo apt install aria2 +``` + +3. Download the torrent using the network identifier set earlier. Note this can take a couple of hours depending on network speeds. + +```bash +aria2c --seed-time=0 "https://torrents.chia.net/databases/$NETWORK/$NETWORK.latest.tar.gz.torrent" --dir="$HOME/Downloads" +``` + +4. Unpack the DB using the network identifier and wildcard for the date in the file name + +```bash +ARCHIVE=$(find "$HOME/Downloads" -name "$NETWORK.*.tar.gz" -type f | sort -r | head -n1) && echo "Extracting $ARCHIVE - this may take upwards of 35 minutes with no visible progress..." && { tar -xf "$ARCHIVE" -C "$HOME/Downloads" || { echo "Error: Extraction failed, please verify the file downloaded properly and try again"; } } +``` + +5. Move the db and associated files to the correct folder. Make sure to update the final directory path if needed and note that any existing files with the same names will be overwritten. + +```bash +echo "Moving files to Chia directory - this may take upwards of 5 minutes with no visible progress..." && mv -f "$HOME/Downloads/blockchain_v2_$NETWORK.sqlite" ~/.chia/mainnet/db/ && mv -f "$HOME/Downloads/height-to-hash" ~/.chia/mainnet/db/ && mv -f "$HOME/Downloads/sub-epoch-summaries" ~/.chia/mainnet/db/ +``` + + + + +1. Set your network (change to `testnet11` for the testnet db): + +```bash +NETWORK="mainnet" +``` + +2. Install a torrent client (aria is used in the below examples, other torrent clients can be used). + +```bash +brew install aria2 +``` + +3. Download the torrent using the network identifier set earlier. Note this can take a couple of hours depending on network speeds. + +```bash +aria2c --seed-time=0 "https://torrents.chia.net/databases/$NETWORK/$NETWORK.latest.tar.gz.torrent" --dir="$HOME/Downloads" +``` + +4. Unpack the DB using the network identifier and wildcard for the date in the file name + +```bash +ARCHIVE=$(find "$HOME/Downloads" -name "$NETWORK.*.tar.gz" -type f | sort -r | head -n1) && echo "Extracting $ARCHIVE - this may take upwards of 35 minutes with no visible progress..." && { tar -xf "$ARCHIVE" -C "$HOME/Downloads" || { echo "Error: Extraction failed, please verify the file downloaded properly and try again"; } } +``` + +5. Move the db and associated files to the correct folder. Make sure to update the final directory path if needed and note that any existing files with the same names will be overwritten. + +```bash +echo "Moving files to Chia directory - this may take upwards of 5 minutes with no visible progress..." && mv -f "$HOME/Downloads/blockchain_v2_$NETWORK.sqlite" ~/.chia/mainnet/db/ && mv -f "$HOME/Downloads/height-to-hash" ~/.chia/mainnet/db/ && mv -f "$HOME/Downloads/sub-epoch-summaries" ~/.chia/mainnet/db/ +``` + + + + +## Port Forwarding Settings + Forwarding port 8444 can solve some sync issues and it also helps improve Chia's overall network health. Port 8444 is the [port](https://en.wikipedia.org/wiki/Port_%28computer_networking%29) through which other Chia computers can communicate with your PC. When you set up port forwarding on port 8444, the Chia software on your computer allows other nodes to easily communicate and sync the Chia blockchain with your node. @@ -52,27 +148,19 @@ values={[ - ``` - Mainnet Introducer: `introducer.chia.net:8444` - + Note: please only use the CNI operated nodes as a last resort for connecting to peers, these nodes might be running different client versions and are not intended to be used as trusted full nodes. - CNI Operated Full Node: `node.chia.net` - Additionally, you can also visit either of the below websites that are frequently updated with available nodes listening on port 8444: - - [ChiaNodes.com](https://ChiaNodes.com) - - [chia.keva.app](https://chia.keva.app) - ``` - - ``` - DNS Introducer: `dns-introducer-testnet11.chia.net` - Legacy Introducer: `introducer-testnet11.chia.net:58444` - + Note: please only use the CNI operated nodes as a last resort for connecting to peers, these nodes might be running different client versions and are not intended to be used as trusted full nodes. - CNI Operated Full Node: `testnet11-node.chia.net` - ``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/timelords.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/timelords.md index 9e84cfad4d3..e5304b8cf61 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/timelords.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/troubleshooting/timelords.md @@ -30,8 +30,7 @@ This is due to the two instances of each log, for example the log where others c `cat ~/.chia/mainnet/log/debug.log | grep "stimated"` : static output of the current estimated IPS as seen by the network (note this will be lower than the IPS reported by the ASIC software).\ `cat ~/.chia/mainnet/log/debug.log | grep "kipping"` : statis output of peak heights added to the node. If a height is skipped than very likely your timelord created the PoT, if the height is not skipped then a different timelord created the PoT. -
-Example Estimated IPS Logs +
Example Estimated IPS Logs These logs indicate your timelord has completed a Proof of Time, note there are three VDF chains and the specific VDF that was completed will be indicated. Also note that this does not mean your timelord is the fastest timelord, only that it completed a PoT. @@ -49,8 +48,7 @@ Response:
-
-Example Skipping Peak Log +
Example Skipping Peak Log These logs indicate your timelord is skipping the peak height, one can reasonably assume that they have completed the Proof of Time the fastest or at least as fast as the other timelords.\ Note: a capital `S` is used here to just pull the Skipping peak logs. @@ -67,8 +65,7 @@ Response:
-
-Example Not Skipping Peak Log +
Example Not Skipping Peak Log These logs indicate your timelord is not skipping the peak height, this means that your timelord was not the fastest at completing the PoT and it is getting the peak from a peer node.\ Note: a lower case `s` is used here to just pull the Not skipping peak logs. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/cat-wc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/cat-wc.md index 4844fbbae85..6196080d609 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/cat-wc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/cat-wc.md @@ -10,14 +10,14 @@ slug: /reference-client/walletconnect/cat-wc Gets the wallet name and id of a given CAT, by its asset id. -| Parameter | Type | Description | -| --------- | -------- | ----------- | -| `assetId` | `string` | Asset id. | +| Parameter | Type | Description | +| --------- | -------- | ------------------------- | +| `assetId` | `string` | Asset id. | #### Output Data -| Parameter | Type | Description | -| ---------- | --------- | ----------------------- | +| Parameter | Type | Description | +| ---------- | --------- | --------------------------------------- | | `name` | `string` | Wallet name. | | `walletId` | `number` | Wallet id. | | `success` | `boolean` | Backend success status. | @@ -26,9 +26,9 @@ Gets the wallet name and id of a given CAT, by its asset id. Gets the asset id of a CAT by its wallet id. -| Parameter | Type | Description | -| ---------- | -------- | ----------- | -| `walletId` | `number` | Wallet id. | +| Parameter | Type | Description | +| ---------- | -------- | -------------------------- | +| `walletId` | `number` | Wallet id. | #### Output Data @@ -38,19 +38,19 @@ The output is a hex encoded asset id of type `string`. Sends an amount of CAT mojos in a given wallet to a recipient address. -| Parameter | Type | Description | -| ----------------------------------- | ---------- | ----------------------------------------- | -| `walletId` | `number` | CAT wallet id to use coins from. | -| `amount` | `number` | Amount in mojos. | -| `fee` | `number` | Transaction fee in mojos. | -| `address` | `string` | Bech32m encoded recipient address. | -| `waitForConfirmation?` _(optional)_ | `boolean` | Whether to wait for inclusion in a block. | -| `memos?` _(optional)_ | `string[]` | A list of coin memos (such as hint). | +| Parameter | Type | Description | +| ------------------------------------------------------ | ---------- | ----------------------------------------------------------------------- | +| `walletId` | `number` | CAT wallet id to use coins from. | +| `amount` | `number` | Amount in mojos. | +| `fee` | `number` | Transaction fee in mojos. | +| `address` | `string` | Bech32m encoded recipient address. | +| `waitForConfirmation?` _(optional)_ | `boolean` | Whether to wait for inclusion in a block. | +| `memos?` _(optional)_ | `string[]` | A list of coin memos (such as hint). | #### Output Data -| Parameter | Type | Description | -| --------------- | -------------------------------------------------------------------------------------- | ----------------------- | +| Parameter | Type | Description | +| --------------- | -------------------------------------------------------------------------------------- | --------------------------------------- | | `transaction` | [`TransactionRecord`](/reference-client/walletconnect/walletconnect#transactionrecord) | Transaction record. | | `transactionId` | `string` | Transaction id. | | `success` | `boolean` | Backend success status. | @@ -59,8 +59,8 @@ Sends an amount of CAT mojos in a given wallet to a recipient address. Imports a CAT by its asset id into the wallet, and assigns a name to it. -| Parameter | Type | Description | -| --------- | -------- | ------------ | +| Parameter | Type | Description | +| --------- | -------- | ---------------------------- | | `assetId` | `string` | Asset id. | | `name` | `string` | Wallet name. | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/did-wc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/did-wc.md index 111af0a3e5a..e2666381484 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/did-wc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/did-wc.md @@ -10,8 +10,8 @@ slug: /reference-client/walletconnect/did-wc Creates a new DID profile. -| Parameter | Type | Description | -| ---------------------- | ---------- | ----------------------------- | +| Parameter | Type | Description | +| ---------------------- | ---------- | --------------------------------------------- | | `amount` | `number` | Amount in mojos. | | `fee` | `number` | Transaction fee in mojos. | | `backupDids` | `string[]` | Associated backup DIDs. | @@ -19,25 +19,25 @@ Creates a new DID profile. #### Output Data -| Parameter | Type | Description | -| ---------- | ------------------------------------------------------------------------ | ---------------------------- | +| Parameter | Type | Description | +| ---------- | ------------------------------------------------------------------------ | --------------------------------------------------------------- | | `type` | [`WalletType`](/reference-client/walletconnect/walletconnect#wallettype) | Type of wallet (8 for DIDs). | -| `myDid` | `string` | Bech32m encoded DID address. | -| `walletId` | `number` | Created wallet id. | -| `success` | `boolean` | Backend success status. | +| `myDid` | `string` | Bech32m encoded DID address. | +| `walletId` | `number` | Created wallet id. | +| `success` | `boolean` | Backend success status. | ### `chia_setDIDName` Sets the name of a DID wallet. -| Parameter | Type | Description | -| ---------- | -------- | ------------ | +| Parameter | Type | Description | +| ---------- | -------- | ---------------------------- | | `walletId` | `number` | Wallet id. | | `name` | `string` | Wallet name. | #### Output Data -| Parameter | Type | Description | -| ---------- | --------- | ----------------------- | +| Parameter | Type | Description | +| ---------- | --------- | --------------------------------------- | | `walletId` | `number` | Wallet id. | | `success` | `boolean` | Backend success status. | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/nft-wc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/nft-wc.md index 96566cc84bb..1ea8f2f1d8e 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/nft-wc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/nft-wc.md @@ -10,8 +10,8 @@ slug: /reference-client/walletconnect/nft-wc Requests a full or paginated list of NFTs. -| Parameter | Type | Description | -| ------------ | ---------- | -------------------------------- | +| Parameter | Type | Description | +| ------------ | ---------- | ------------------------------------------------ | | `walletIds` | `number[]` | NFT wallet ids. | | `num` | `number` | Number of NFTs to fetch. | | `startIndex` | `number` | Index to start from in the list. | @@ -24,8 +24,8 @@ The output is an object of type [`Record`](#nftinfo), where t Gets information about a specific NFT. -| Parameter | Type | Description | -| --------- | -------- | ---------------- | +| Parameter | Type | Description | +| --------- | -------- | -------------------------------- | | `coinId` | `string` | NFT launcher id. | #### Output Data @@ -34,27 +34,27 @@ The output is an object of type [`NftInfo`](#nftinfo). ### `chia_mintNFT` -| Parameter | Type | Description | -| -------------------------------- | ------------------------------- | ------------------------------------- | -| `walletId` | `number` | NFT wallet id. | -| `royaltyAddress` _(optional)_ | string | null | Address royalty is sent to. | -| `royaltyPercentage` _(optional)_ | number | null | Creator royalty percent. (1000 = 1%) | -| `targetAddress` _(optional)_ | string | null | Address NFT is sent to upon mint. | -| `uris` | `string[]` | List of NFT content URIs. | -| `hash` | `string` | Hash of the NFT content. | -| `metaUris` | `string[]` | List of metadata URIs. | -| `metaHash` _(optional)_ | string | null | Hash of the metadata. | -| `licenseUris` | `string[]` | List of the license URIs. | -| `licenseHash` _(optional)_ | string | null | Hash of the license. | -| `editionNumber` _(optional)_ | number | null | Number of the current NFT in edition. | -| `editionTotal` _(optional)_ | number | null | How many NFTs in the current edition. | -| `didId` _(optional)_ | string | null | The DID used during an NFT mint. | -| `fee` _(optional)_ | number | null | Transaction fee in mojos. | +| Parameter | Type | Description | +| --------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------- | +| `walletId` | `number` | NFT wallet id. | +| `royaltyAddress` _(optional)_ | string | null | Address royalty is sent to. | +| `royaltyPercentage` _(optional)_ | number | null | Creator royalty percent. (1000 = 1%) | +| `targetAddress` _(optional)_ | string | null | Address NFT is sent to upon mint. | +| `uris` | `string[]` | List of NFT content URIs. | +| `hash` | `string` | Hash of the NFT content. | +| `metaUris` | `string[]` | List of metadata URIs. | +| `metaHash` _(optional)_ | string | null | Hash of the metadata. | +| `licenseUris` | `string[]` | List of the license URIs. | +| `licenseHash` _(optional)_ | string | null | Hash of the license. | +| `editionNumber` _(optional)_ | number | null | Number of the current NFT in edition. | +| `editionTotal` _(optional)_ | number | null | How many NFTs in the current edition. | +| `didId` _(optional)_ | string | null | The DID used during an NFT mint. | +| `fee` _(optional)_ | number | null | Transaction fee in mojos. | #### Output Data -| Parameter | Type | Description | -| ------------- | -------------------------------------------------------------------------- | ----------------------- | +| Parameter | Type | Description | +| ------------- | -------------------------------------------------------------------------- | --------------------------------------- | | `nftId` | `string` | The NFT id. | | `spendBundle` | [`SpendBundle`](/reference-client/walletconnect/walletconnect#spendbundle) | Created spend bundle. | | `success` | `boolean` | Backend success status. | @@ -62,8 +62,8 @@ The output is an object of type [`NftInfo`](#nftinfo). ### `chia_transferNFT` -| Parameter | Type | Description | -| --------------- | ---------- | --------------------------------------- | +| Parameter | Type | Description | +| --------------- | ---------- | ------------------------------------------------------- | | `walletId` | `number` | NFT wallet id. | | `launcherId` | `string` | NFT launcher id. | | `nftCoinIds` | `string[]` | NFT coin ids. | @@ -72,32 +72,32 @@ The output is an object of type [`NftInfo`](#nftinfo). #### Output Data -| Parameter | Type | Description | -| --------------------- | -------------------------------------------------------------------------- | --------------------- | -| `walletId` | number | number[] | NFT wallet id(s). | -| `spendBundle` | [`SpendBundle`](/reference-client/walletconnect/walletconnect#spendbundle) | Created spend bundle. | -| `txNum?` _(optional)_ | `number` | Transaction number. | +| Parameter | Type | Description | +| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | +| `walletId` | number | number[] | NFT wallet id(s). | +| `spendBundle` | [`SpendBundle`](/reference-client/walletconnect/walletconnect#spendbundle) | Created spend bundle. | +| `txNum?` _(optional)_ | `number` | Transaction number. | ### `chia_getNFTsCount` -| Parameter | Type | Description | -| ----------- | ---------- | --------------- | +| Parameter | Type | Description | +| ----------- | ---------- | ------------------------------- | | `walletIds` | `number[]` | NFT wallet ids. | #### Output Data The output is an object of type `Record`, where the keys are wallet ids. It has the following additional key: -| Parameter | Type | Description | -| --------- | -------- | --------------------- | +| Parameter | Type | Description | +| --------- | -------- | ------------------------------------- | | `total` | `number` | Total number of NFTs. | ### `chia_setNFTDID` Sets the owner DID associated with a given NFT. -| Parameter | Type | Description | -| --------------- | ---------- | ---------------------------- | +| Parameter | Type | Description | +| --------------- | ---------- | -------------------------------------------- | | `walletId` | `number` | Wallet id. | | `nftLauncherId` | `string` | NFT launcher id. | | `nftCoinIds` | `string[]` | NFT coin ids. | @@ -106,8 +106,8 @@ Sets the owner DID associated with a given NFT. #### Output Data -| Parameter | Type | Description | -| ------------- | -------------------------------------------------------------------------- | ----------------------- | +| Parameter | Type | Description | +| ------------- | -------------------------------------------------------------------------- | --------------------------------------- | | `walletId` | `number` | Wallet id. | | `spendBundle` | [`SpendBundle`](/reference-client/walletconnect/walletconnect#spendbundle) | Created spend bundle. | | `success` | `boolean` | Backend success status. | @@ -116,32 +116,32 @@ Sets the owner DID associated with a given NFT. ### NFTInfo -| Parameter | Type | Description | -| --------------------------- | ------------------------------- | -------------------------------------- | -| `nftId` | `string` | The NFT id. | -| `launcherId` | `string` | The launcher id. | -| `nftCoinId` | `string` | The current coin id. | -| `nftCoinConfirmationHeight` | `number` | Current NFT coin confirmation height | -| `ownerDid` | string | null | The owner DID. | -| `royaltyPercentage` | number | null | Creator royalty percent. (1000 = 1%) | -| `royaltyPuzzleHash` | string | null | Puzzle hash royalty is sent to. | -| `royaltyAddress` | `string` | Address royalty is sent to. | -| `targetAddress` | `string` | Address NFT is sent to upon mint. | -| `uris` | `string[]` | List of NFT content URIs. | -| `hash` | `string` | Hash of the NFT content. | -| `metaUris` | `string[]` | List of metadata URIs. | -| `metaHash` | `string` | Hash of the metadata. | -| `licenseUris` | `string[]` | List of the license URIs. | -| `licenseHash` | `string` | Hash of the license. | -| `editionTotal` | `number` | How many NFTs in the current edition. | -| `editionNumber` | `number` | Number of the current NFT in edition. | -| `updaterPuzhash` | `string` | Puzzle hash of the metadata updater. | -| `chainInfo` | `string` | Information saved on the chain. | -| `mintHeight` | `number` | Block height when the NFT was minted. | -| `supportsDid` | `boolean` | Whether the inner puzzle supports DID. | -| `p2Address` | `string` | The innermost puzzle hash of the NFT. | -| `pendingTransaction` | `boolean` | Whether the NFT is pending for a tx. | -| `didId` | string | null | The DID used during an NFT mint. | -| `minterDid` | string | null | The minter DID. | -| `launcherPuzhash` | `string` | Singleton launcher puzzle hash. | -| `offChainMetadata` | string | null | Serialized off-chain metadata. | +| Parameter | Type | Description | +| --------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------- | +| `nftId` | `string` | The NFT id. | +| `launcherId` | `string` | The launcher id. | +| `nftCoinId` | `string` | The current coin id. | +| `nftCoinConfirmationHeight` | `number` | Current NFT coin confirmation height | +| `ownerDid` | string | null | The owner DID. | +| `royaltyPercentage` | number | null | Creator royalty percent. (1000 = 1%) | +| `royaltyPuzzleHash` | string | null | Puzzle hash royalty is sent to. | +| `royaltyAddress` | `string` | Address royalty is sent to. | +| `targetAddress` | `string` | Address NFT is sent to upon mint. | +| `uris` | `string[]` | List of NFT content URIs. | +| `hash` | `string` | Hash of the NFT content. | +| `metaUris` | `string[]` | List of metadata URIs. | +| `metaHash` | `string` | Hash of the metadata. | +| `licenseUris` | `string[]` | List of the license URIs. | +| `licenseHash` | `string` | Hash of the license. | +| `editionTotal` | `number` | How many NFTs in the current edition. | +| `editionNumber` | `number` | Number of the current NFT in edition. | +| `updaterPuzhash` | `string` | Puzzle hash of the metadata updater. | +| `chainInfo` | `string` | Information saved on the chain. | +| `mintHeight` | `number` | Block height when the NFT was minted. | +| `supportsDid` | `boolean` | Whether the inner puzzle supports DID. | +| `p2Address` | `string` | The innermost puzzle hash of the NFT. | +| `pendingTransaction` | `boolean` | Whether the NFT is pending for a tx. | +| `didId` | string | null | The DID used during an NFT mint. | +| `minterDid` | string | null | The minter DID. | +| `launcherPuzhash` | `string` | Singleton launcher puzzle hash. | +| `offChainMetadata` | string | null | Serialized off-chain metadata. | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/offer-wc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/offer-wc.md index 0f4fa3a2b59..e7f9d85e115 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/offer-wc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/offer-wc.md @@ -10,8 +10,8 @@ slug: /reference-client/walletconnect/offer-wc Gets a list of offers, based on certain search criteria. -| Parameter | Type | Description | -| ---------------------------------- | --------- | -------------------------------- | +| Parameter | Type | Description | +| ----------------------------------------------------- | --------- | ------------------------------------------------ | | `start?` _(optional)_ | `number` | Start index. | | `end?` _(optional)_ | `number` | End index. | | `sortKey?` _(optional)_ | `string` | Sort key. | @@ -29,8 +29,8 @@ Gets the number of owned offers, taken offers, and total offers. #### Output Data -| Parameter | Type | Description | -| ------------------ | --------- | ----------------------- | +| Parameter | Type | Description | +| ------------------ | --------- | --------------------------------------- | | `myOffersCount` | `number` | Number of owned offers. | | `takenOffersCount` | `number` | Number of taken offers. | | `total` | `number` | Total number of offers. | @@ -40,30 +40,30 @@ Gets the number of owned offers, taken offers, and total offers. Cancels an offer either on-chain by spending the coins or off-chain by only removing it from the list. -| Parameter | Type | Description | -| --------- | --------- | ------------------------------------- | +| Parameter | Type | Description | +| --------- | --------- | ----------------------------------------------------- | | `tradeId` | `string` | Trade id. | | `secure` | `boolean` | Whether to cancel the offer on-chain. | | `fee` | `number` | Transaction fee in mojos. | #### Output Data -| Parameter | Type | Description | -| --------- | --------- | ----------------------- | +| Parameter | Type | Description | +| --------- | --------- | --------------------------------------- | | `success` | `boolean` | Backend success status. | ### `chia_checkOfferValidity` Checks whether or not an offer is still valid. -| Parameter | Type | Description | -| ----------- | -------- | --------------------------- | +| Parameter | Type | Description | +| ----------- | -------- | ------------------------------------------- | | `offerData` | `string` | Bech32m encoded offer data. | #### Output Data -| Parameter | Type | Description | -| --------- | --------- | --------------------------- | +| Parameter | Type | Description | +| --------- | --------- | ------------------------------------------- | | `id` | `string` | Trade id. | | `valid` | `boolean` | Whether the offer is valid. | @@ -71,15 +71,15 @@ Checks whether or not an offer is still valid. Accepts an offer and completes the transaction. -| Parameter | Type | Description | -| --------- | -------- | --------------------------- | +| Parameter | Type | Description | +| --------- | -------- | ------------------------------------------- | | `offer` | `string` | Bech32m encoded offer data. | | `fee` | `number` | Transaction fee in mojos. | #### Output Data -| Parameter | Type | Description | -| ------------- | --------------------------------------------------------------------- | ----------------------- | +| Parameter | Type | Description | +| ------------- | --------------------------------------------------------------------- | --------------------------------------- | | `tradeRecord` | [`TradeRecord`](/reference-client/walletconnect/offer-wc#traderecord) | Trade record. | | `success` | `boolean` | Backend success status. | @@ -87,14 +87,14 @@ Accepts an offer and completes the transaction. Gets the summary object of an offer. -| Parameter | Type | Description | -| ----------- | -------- | --------------------------- | +| Parameter | Type | Description | +| ----------- | -------- | ------------------------------------------- | | `offerData` | `string` | Bech32m encoded offer data. | #### Output Data -| Parameter | Type | Description | -| --------- | -------------- | ----------------------- | +| Parameter | Type | Description | +| --------- | -------------- | --------------------------------------- | | `id` | `string` | Trade id. | | `summary` | `TradeSummary` | Trade summary. | | `success` | `boolean` | Backend success status. | @@ -103,14 +103,14 @@ Gets the summary object of an offer. Gets the data of an offer. -| Parameter | Type | Description | -| --------- | -------- | ----------- | -| `offerId` | `string` | Trade id. | +| Parameter | Type | Description | +| --------- | -------- | ------------------------- | +| `offerId` | `string` | Trade id. | #### Output Data -| Parameter | Type | Description | -| ------------- | --------------------------------------------------------------------- | --------------------------- | +| Parameter | Type | Description | +| ------------- | --------------------------------------------------------------------- | ------------------------------------------- | | `offer` | `string` | Bech32m encoded offer data. | | `tradeRecord` | [`TradeRecord`](/reference-client/walletconnect/offer-wc#traderecord) | Trade record. | | `success` | `boolean` | Backend success status. | @@ -119,14 +119,14 @@ Gets the data of an offer. Gets the trade record of an offer. -| Parameter | Type | Description | -| --------- | -------- | ----------- | -| `offerId` | `string` | Trade id. | +| Parameter | Type | Description | +| --------- | -------- | ------------------------- | +| `offerId` | `string` | Trade id. | #### Output Data -| Parameter | Type | Description | -| ------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | +| Parameter | Type | Description | +| ------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `offer` | `null` | Use [`chia_getOfferData`](/reference-client/walletconnect/offer-wc#chia_getofferdata) if you need this. | | `tradeRecord` | [`TradeRecord`](/reference-client/walletconnect/offer-wc#traderecord) | Trade record. | | `success` | `boolean` | Backend success status. | @@ -135,17 +135,17 @@ Gets the trade record of an offer. Creates an offer for wallet ids. -| Parameter | Type | Description | -| ------------------------------------- | --------- | ----------------------------------- | -| `offer` | `any` | Offered asset amounts. | -| `driverDict` | `any` | Driver dict object. | +| Parameter | Type | Description | +| -------------------------------------------------------- | --------- | --------------------------------------------------- | +| `offer` | `any` | Offered asset amounts. | +| `driverDict` | `any` | Driver dict object. | | `validateOnly?` _(optional)_ | `boolean` | Whether to only validate the offer. | | `disableJSONFormatting?` _(optional)_ | `boolean` | Whether to disable JSON formatting. | #### Output Data -| Parameter | Type | Description | -| ------------- | --------------------------------------------------------------------- | --------------------------- | +| Parameter | Type | Description | +| ------------- | --------------------------------------------------------------------- | ------------------------------------------- | | `offer` | `string` | Bech32m encoded offer data. | | `tradeRecord` | [`TradeRecord`](/reference-client/walletconnect/offer-wc#traderecord) | Trade record. | @@ -153,9 +153,9 @@ Creates an offer for wallet ids. ### TradeRecord -| Parameter | Type | Description | -| ------------------ | --------------------------------------------------------------------- | -------------------------------------------- | -| `acceptedAtTime` | number | null | Timestamp when the trade was accepted. | +| Parameter | Type | Description | +| ------------------ | --------------------------------------------------------------------- | ------------------------------------------------------------ | +| `acceptedAtTime` | number | null | Timestamp when the trade was accepted. | | `coinsOfInterest` | [`Coin[]`](/reference-client/walletconnect/walletconnect#coin) | Coins involved in trade. | | `confirmedAtIndex` | `number` | Confirmation block index. | | `createdAtTime` | `number` | Timestamp when the trade was created. | @@ -165,7 +165,7 @@ Creates an offer for wallet ids. | `sentTo` | [`Peer[]`](/reference-client/walletconnect/walletconnect#peer) | Peers the transaction was sent to. | | `status` | [`TradeStatus`](/reference-client/walletconnect/offer-wc#tradestatus) | Trade status. | | `summary` | `any` | Trade summary metadata. | -| `takenOffer` | string | null | Taken bech32m encoded offer data. | +| `takenOffer` | string | null | Taken bech32m encoded offer data. | | `tradeId` | `string` | Trade id. | | `_offerData` | `string` | Bech32m encoded offer data. | @@ -173,11 +173,11 @@ Creates an offer for wallet ids. Values that can be returned for the trade_status. Note that offers cannot be resynced and are not available on-chain so granular trade_status is not always available. -| Value | | -| ----------------- | ------------------------------------------------------------------------------------- | -| `PENDING_ACCEPT` | Acceptance has been pushed to the chain and is pending confirmation. | -| `PENDING_CONFIRM` | Acceptance has been pushed to the chain and is pending confirmation. | +| Value | | +| ----------------- | ------------------------------------------------------------------------------------------------------------------------ | +| `PENDING_ACCEPT` | Acceptance has been pushed to the chain and is pending confirmation. | +| `PENDING_CONFIRM` | Acceptance has been pushed to the chain and is pending confirmation. | | `PENDING_CANCEL` | Cancelation has been pushed to the chain (if applicable) and is pending confirmation. | | `CANCELLED` | Offer cancellation has been confirmed onchain (if applicable). | -| `CONFIRMED` | Offer acceptance has been confirmed onchain. | -| `FAILED` | Offer acceptance failed, review logs for reasoning of failure. | +| `CONFIRMED` | Offer acceptance has been confirmed onchain. | +| `FAILED` | Offer acceptance failed, review logs for reasoning of failure. | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/walletconnect.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/walletconnect.md index 08473e4b58f..ac67d6b578c 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/walletconnect.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/walletconnect/walletconnect.md @@ -18,14 +18,14 @@ You can install our [example WalletConnect dApp](https://github.com/Chia-Network Logs in to a wallet key (account), as identified by its fingerprint. -| Parameter | Type | Description | -| ------------- | -------- | ------------------- | +| Parameter | Type | Description | +| ------------- | -------- | ----------------------------------- | | `fingerprint` | `number` | Wallet fingerprint. | #### Output Data -| Parameter | Type | Description | -| ------------- | --------- | ----------------------- | +| Parameter | Type | Description | +| ------------- | --------- | --------------------------------------- | | `fingerprint` | `number` | Wallet fingerprint. | | `success` | `boolean` | Backend success status. | @@ -33,22 +33,22 @@ Logs in to a wallet key (account), as identified by its fingerprint. Gets the wallet's master public key. -| Parameter | Type | Description | -| ------------- | -------- | ------------------- | +| Parameter | Type | Description | +| ------------- | -------- | ----------------------------------- | | `fingerprint` | `number` | Wallet fingerprint. | #### Output Data -| Parameter | Type | Description | -| --------- | -------- | ------------------------------ | +| Parameter | Type | Description | +| --------- | -------- | ---------------------------------------------- | | `pubkey` | `string` | Hex encoded master public key. | ### `chia_getWallets` Gets a list of wallet ids associated with the current account. -| Parameter | Type | Description | -| ------------- | --------- | ---------------------------- | +| Parameter | Type | Description | +| ------------- | --------- | -------------------------------------------- | | `includeData` | `boolean` | Whether to include metadata. | #### Output Data @@ -59,8 +59,8 @@ The output is a value of type [`WalletInfo`](/reference-client/walletconnect/wal Gets a transaction record by its id. -| Parameter | Type | Description | -| --------------- | -------- | --------------- | +| Parameter | Type | Description | +| --------------- | -------- | ------------------------------- | | `transactionId` | `string` | Transaction id. | #### Output Data @@ -71,8 +71,8 @@ The output is a value of type [`TransactionRecord`](/reference-client/walletconn Gets the various wallet balances for a given wallet id, as shown in the GUI. -| Parameter | Type | Description | -| ------------------------ | -------- | -------------------------------- | +| Parameter | Type | Description | +| ------------------------------------------- | -------- | ------------------------------------------------ | | `walletId?` _(optional)_ | `number` | Wallet id to get the balance of. | #### Output Data @@ -83,8 +83,8 @@ The output is a value of type [`WalletBalance`](/reference-client/walletconnect/ Gets the address of the current derivation index. -| Parameter | Type | Description | -| ------------------------ | -------- | -------------------------------- | +| Parameter | Type | Description | +| ------------------------------------------- | -------- | ------------------------------------------------ | | `walletId?` _(optional)_ | `number` | Wallet id to get the address of. | #### Output Data @@ -95,8 +95,8 @@ The output is a bech32m encoded address of type `string`. Gets the address of the next derivation index. -| Parameter | Type | Description | -| -------------------------- | --------- | ------------------------------------- | +| Parameter | Type | Description | +| --------------------------------------------- | --------- | ----------------------------------------------------- | | `walletId?` _(optional)_ | `number` | Wallet id to get the address of. | | `newAddress?` _(optional)_ | `boolean` | Whether to increase derivation index. | @@ -108,19 +108,19 @@ The output is a bech32m encoded address of type `string`. Sends an amount of mojos in a given wallet to a recipient address. -| Parameter | Type | Description | -| ----------------------------------- | ---------- | ----------------------------------------- | -| `amount` | `number` | Amount in mojos. | -| `fee` | `number` | Transaction fee in mojos. | -| `address` | `string` | Bech32m encoded recipient address. | -| `walletId?` _(optional)_ | `number` | Wallet id to use coins from. | -| `waitForConfirmation?` _(optional)_ | `boolean` | Whether to wait for inclusion in a block. | -| `memos?` _(optional)_ | `string[]` | A list of coin memos (such as hint). | +| Parameter | Type | Description | +| ------------------------------------------------------ | ---------- | ----------------------------------------------------------------------- | +| `amount` | `number` | Amount in mojos. | +| `fee` | `number` | Transaction fee in mojos. | +| `address` | `string` | Bech32m encoded recipient address. | +| `walletId?` _(optional)_ | `number` | Wallet id to use coins from. | +| `waitForConfirmation?` _(optional)_ | `boolean` | Whether to wait for inclusion in a block. | +| `memos?` _(optional)_ | `string[]` | A list of coin memos (such as hint). | #### Output Data -| Parameter | Type | Description | -| --------------- | -------------------------------------------------------------------------------------- | ----------------------- | +| Parameter | Type | Description | +| --------------- | -------------------------------------------------------------------------------------- | --------------------------------------- | | `transaction` | [`TransactionRecord`](/reference-client/walletconnect/walletconnect#transactionrecord) | Transaction record. | | `transactionId` | `string` | Transaction id. | | `success` | `boolean` | Backend success status. | @@ -135,15 +135,15 @@ In order to ensure the message being signed isn't a transaction, the message is --- -| Parameter | Type | Description | -| --------- | -------- | ---------------------------------------- | +| Parameter | Type | Description | +| --------- | -------- | -------------------------------------------------------- | | `message` | `string` | Message to sign. | | `id` | `string` | DID to sign the message with the key of. | #### Output Data -| Parameter | Type | Description | -| -------------- | --------- | -------------------------------- | +| Parameter | Type | Description | +| -------------- | --------- | ------------------------------------------------ | | `latestCoinId` | `string` | Latest DID singleton coin id. | | `pubkey` | `string` | Hex encoded DID public key. | | `signature` | `string` | Hex encoded BLS12-381 signature. | @@ -160,15 +160,15 @@ In order to ensure the message being signed isn't a transaction, the message is --- -| Parameter | Type | Description | -| --------- | -------- | -------------------------------------------- | +| Parameter | Type | Description | +| --------- | -------- | ------------------------------------------------------------ | | `message` | `string` | Message to sign. | | `address` | `string` | Address to sign the message with the key of. | #### Output Data -| Parameter | Type | Description | -| ------------- | --------- | -------------------------------- | +| Parameter | Type | Description | +| ------------- | --------- | ------------------------------------------------ | | `pubkey` | `string` | Hex encoded address public key. | | `signature` | `string` | Hex encoded BLS12-381 signature. | | `signingMode` | `string` | Signing mode used. | @@ -178,18 +178,18 @@ In order to ensure the message being signed isn't a transaction, the message is Verifies a signature over a message from a given public key. -| Parameter | Type | Description | -| --------------------------- | -------- | -------------------------------- | -| `message` | `string` | Message to verify. | -| `pubkey` | `string` | Hex encoded public key. | -| `signature` | `string` | Hex encoded BLS12-381 signature. | +| Parameter | Type | Description | +| ---------------------------------------------- | -------- | ------------------------------------------------ | +| `message` | `string` | Message to verify. | +| `pubkey` | `string` | Hex encoded public key. | +| `signature` | `string` | Hex encoded BLS12-381 signature. | | `address?` _(optional)_ | `string` | Address used for signing. | | `signingMode?` _(optional)_ | `string` | Signing mode used. | #### Output Data -| Parameter | Type | Description | -| --------- | --------- | ------------------------------- | +| Parameter | Type | Description | +| --------- | --------- | ----------------------------------------------- | | `isValid` | `boolean` | Whether the signature is valid. | | `success` | `boolean` | Backend success status. | @@ -199,8 +199,8 @@ Gets the current sync status of the wallet. #### Output Data -| Parameter | Type | Description | -| -------------------- | --------- | ---------------------------------------- | +| Parameter | Type | Description | +| -------------------- | --------- | -------------------------------------------------------- | | `genesisInitialized` | `boolean` | Whether the genesis is initialized. | | `synced` | `boolean` | Whether the wallet is fully synced. | | `syncing` | `boolean` | Whether the wallet is currently syncing. | @@ -210,26 +210,26 @@ Gets the current sync status of the wallet. ### WalletInfo -| Parameter | Type | Description | -| --------- | ------------------------------------------------------------------------ | ---------------------------------------- | -| `id` | `number` | The wallet id. | -| `name` | `string` | The name of the wallet. | -| `type` | [`WalletType`](/reference-client/walletconnect/walletconnect#wallettype) | The type of the wallet. | +| Parameter | Type | Description | +| --------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- | +| `id` | `number` | The wallet id. | +| `name` | `string` | The name of the wallet. | +| `type` | [`WalletType`](/reference-client/walletconnect/walletconnect#wallettype) | The type of the wallet. | | `data` | `any` | Extra info (unused for standard wallet). | -| `meta` | `any` | Metadata specific to each wallet type. | +| `meta` | `any` | Metadata specific to each wallet type. | #### CAT Metadata -| Parameter | Type | Description | -| --------- | -------- | ------------- | +| Parameter | Type | Description | +| --------- | -------- | ----------------------------- | | `assetId` | `string` | Asset id. | | `name` | `string` | Display name. | #### NFT Metadata -| Parameter | Type | Description | -| --------- | -------- | ----------- | -| `did` | `string` | Owner DID. | +| Parameter | Type | Description | +| --------- | -------- | -------------------------- | +| `did` | `string` | Owner DID. | ### WalletType @@ -250,25 +250,25 @@ Gets the current sync status of the wallet. ### TransactionRecord -| Parameter | Type | Description | -| ------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------- | -| `confirmedAtHeight` | `number` | Block height the tx was confirmed. | -| `createdAtTime` | `number` | The timestamp when the tx was created. | -| `toPuzzleHash` | `string` | The destination puzzle hash. | -| `amount` | `number` | The amount sent in mojos. | -| `feeAmount` | `number` | The transaction fee in mojos. | -| `confirmed` | `boolean` | Whether the tx was confirmed. | -| `sent` | `number` | Number of peers the tx was sent to. | -| `sentTo` | [`Peer[]`](/reference-client/walletconnect/walletconnect#peer) | The peers the tx has been sent to. | +| Parameter | Type | Description | +| ------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | +| `confirmedAtHeight` | `number` | Block height the tx was confirmed. | +| `createdAtTime` | `number` | The timestamp when the tx was created. | +| `toPuzzleHash` | `string` | The destination puzzle hash. | +| `amount` | `number` | The amount sent in mojos. | +| `feeAmount` | `number` | The transaction fee in mojos. | +| `confirmed` | `boolean` | Whether the tx was confirmed. | +| `sent` | `number` | Number of peers the tx was sent to. | +| `sentTo` | [`Peer[]`](/reference-client/walletconnect/walletconnect#peer) | The peers the tx has been sent to. | | `spendBundle` | [SpendBundle](/reference-client/walletconnect/walletconnect#spendbundle) | null | The associated spend bundle. | -| `additions` | [`Coin[]`](/reference-client/walletconnect/walletconnect#coin) | Created coins in the block. | -| `removals` | [`Coin[]`](/reference-client/walletconnect/walletconnect#coin) | Spent coins in the block. | -| `walletId` | `number` | The wallet id. | -| `toAddress` | `string` | The bech32m encoded `to_puzzle_hash`. | -| `trade_id` | string | null | | -| `type` | [`TransactionType`](/reference-client/walletconnect/walletconnect#transactiontype) | The type of transaction. | -| `name` | `string` | The transaction's id. | -| `memos` | `Memo[]` | The memos associated with the tx. | +| `additions` | [`Coin[]`](/reference-client/walletconnect/walletconnect#coin) | Created coins in the block. | +| `removals` | [`Coin[]`](/reference-client/walletconnect/walletconnect#coin) | Spent coins in the block. | +| `walletId` | `number` | The wallet id. | +| `toAddress` | `string` | The bech32m encoded `to_puzzle_hash`. | +| `trade_id` | string | null | | +| `type` | [`TransactionType`](/reference-client/walletconnect/walletconnect#transactiontype) | The type of transaction. | +| `name` | `string` | The transaction's id. | +| `memos` | `Memo[]` | The memos associated with the tx. | ### TransactionType @@ -289,11 +289,11 @@ This is a tuple with the following parameters. --- -| Parameter | Type | Description | -| ---------------------------- | ---------------------------------------------------------------------------------- | -------------------------- | +| Parameter | Type | Description | +| ----------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------ | | `peerId` _(item 1)_ | `string` | Peer id. | | `inclusionStatus` _(item 2)_ | [`InclusionStatus`](/reference-client/walletconnect/walletconnect#inclusionstatus) | Inclusion status. | -| `errorMessage` _(item 3)_ | string | null | Error message, if present. | +| `errorMessage` _(item 3)_ | string | null | Error message, if present. | ### InclusionStatus @@ -305,31 +305,31 @@ This is a tuple with the following parameters. ### SpendBundle -| Parameter | Type | Description | -| --------------------- | ------------------------------------------------------------------------ | ------------------------------------------ | +| Parameter | Type | Description | +| --------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------- | | `coinSpends` | [`CoinSpend[]`](/reference-client/walletconnect/walletconnect#coinspend) | The coin spends. | | `aggregatedSignature` | `string` | The G2Element of the aggregated signature. | ### CoinSpend -| Parameter | Type | Description | -| -------------- | ------------------------------------------------------------ | ------------------------------------------------ | +| Parameter | Type | Description | +| -------------- | ------------------------------------------------------------ | ---------------------------------------------------------------- | | `coin` | [`Coin`](/reference-client/walletconnect/walletconnect#coin) | The coin that is being spent. | | `puzzleReveal` | `string` | The puzzle reveal in serialized CLVM hex format. | | `solution` | `string` | The solution in serialized CLVM hex format. | ### Coin -| Parameter | Type | Description | -| -------------- | -------- | -------------------- | +| Parameter | Type | Description | +| -------------- | -------- | ------------------------------------ | | `parentCoinId` | `string` | The parent coin id. | | `puzzleHash` | `string` | The puzzle hash. | | `amount` | `number` | The amount in mojos. | ### WalletBalance -| Parameter | Type | Description | -| -------------------------- | -------- | ----------------------------------------- | +| Parameter | Type | Description | +| -------------------------- | -------- | --------------------------------------------------------- | | `confirmedWalletBalance` | `number` | The confirmed balance. | | `unconfirmedWalletBalance` | `number` | The unconfirmed balance. | | `spendableBalance` | `number` | The spendable balance. |