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 e0a2f9fb043..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 插件 @@ -149,7 +149,7 @@ import Runnable from '@site/src/components/Runnable.tsx'; ### 链接 -- [Chialisp基本概念](https://chialisp.com/chialisp-concepts/)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- General [chialisp concepts](https://chialisp.com/chialisp-concepts/): overviews of currying, inner puzzles, and morphing conditions. - 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. 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 4fd799a9bf3..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 插件 @@ -168,7 +168,7 @@ import Runnable from '@site/src/components/Runnable.tsx'; ### 链接 -- [Chialisp基本概念](https://chialisp.com/chialisp-concepts/)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- General [chialisp concepts](https://chialisp.com/chialisp-concepts/): overviews of currying, inner puzzles, and morphing conditions. - 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. 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 eb8030dc683..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 插件 @@ -221,7 +221,7 @@ True ### 链接 -- [Chialisp基本概念](https://chialisp.com/chialisp-concepts/)：包括柯里化（currying）、内部谜题（inner puzzles）和条件变换（morphing conditions）的概述。 +- General [chialisp concepts](https://chialisp.com/chialisp-concepts/): overviews of currying, inner puzzles, and morphing conditions. - 指导性的[Chialisp演练](https://docs.chia.net/guides/)：安装、创建智能币和使用BLS签名的指南。 - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md index 412fc704ce5..c42f38476d3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/challenges-plot-filters.md @@ -85,8 +85,8 @@ slug: /challenges-plot-filters ### 链接 -- 更多的[耕种基础知识](https://docs.chia.net/reference-client/farming/farming-basics)：绘图、矿池和奖励的概述。 -- 详细的[架构概述](https://docs.chia.net/chia-blockchain/architecture/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- More [farming basics](https://docs.chia.net/reference-client/farming/farming-basics): overviews of plotting, pooling, and rewards. +- In depth [architecture overview](https://docs.chia.net/chia-blockchain/architecture/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md index 025eace22b5..83d64d0bb8d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/farming-overview.md @@ -116,8 +116,8 @@ k32 ### 链接 -- 更多的[耕种基础知识](https://docs.chia.net/reference-client/farming/farming-basics)：绘图、矿池和奖励的概述。 -- 详细的[架构概述](https://docs.chia.net/chia-blockchain/architecture/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- More [farming basics](https://docs.chia.net/reference-client/farming/farming-basics): overviews of plotting, pooling, and rewards. +- In depth [architecture overview](https://docs.chia.net/chia-blockchain/architecture/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md index e1e73206b60..63d5d87a618 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/first-plot.md @@ -36,8 +36,8 @@ slug: /first-plot ### 链接 -- 更多的[耕种基础知识](https://docs.chia.net/reference-client/farming/farming-basics)：绘图、矿池和奖励的概述。 -- 详细的[架构概述](https://docs.chia.net/chia-blockchain/architecture/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- More [farming basics](https://docs.chia.net/reference-client/farming/farming-basics): overviews of plotting, pooling, and rewards. +- In depth [architecture overview](https://docs.chia.net/chia-blockchain/architecture/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md index 368f07a4246..55366fae1df 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/academy/plotting-farming/pools.md @@ -84,8 +84,8 @@ slug: /pools ### 链接 -- 更多的[耕种基础知识](https://docs.chia.net/reference-client/farming/farming-basics)：绘图、矿池和奖励的概述。 -- 详细的[架构概述](https://docs.chia.net/chia-blockchain/architecture/architecture-overview)：描述农民、收割机、钱包等之间的交互。 +- More [farming basics](https://docs.chia.net/reference-client/farming/farming-basics): overviews of plotting, pooling, and rewards. +- In depth [architecture overview](https://docs.chia.net/chia-blockchain/architecture/architecture-overview): describing the interactions between Farmers, Harvesters, Wallets, etc. - Chialisp[详细文档](https://chialisp.com/)：提供有关Chialisp各个方面的详细信息。 - Support [in discord](https://discord.gg/chia): for further support join our discord server and ask in the #chialisp or #support channels. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/architecture-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/architecture-overview.md new file mode 100644 index 00000000000..b27a17ab1ba --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/architecture-overview.md @@ -0,0 +1,10 @@ +--- +title: 架构概览 +slug: /chia-blockchain/architecture/architecture-overview +--- + +![chia-architecture](/img/chia-network-architecture.png) + +上图展示了 Chia 的网络架构。 一台机器可以运行其中一个以上的过程。 事实上，默认配置是同时运行四个过程：耕种、全节点、收割和钱包。 许多农民还会选择运行电子图形用户界面和矿池。 此外，少数农民，特别是拥有较多硬盘（PiB）农场的农民，会选择运行Timelord（时间领主）。 + +让我们逐个讨论这些进程，以及连接它们的协议。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/farmers.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/farmers.md new file mode 100644 index 00000000000..a0e6b2cf7d7 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/farmers.md @@ -0,0 +1,15 @@ +--- +title: 耕种 +slug: /chia-blockchain/architecture/farmers +--- + +Chia的农民与比特币矿工相似。 他们通过在其储存的地块中找到有效的空间证明来获得区块奖励和费用。 耕种进程并不会保留一个区块链的副本，而由他们信任的一个完整节点来提供更新。 完整节点和耕种进程使用耕种协议相互沟通。 + +耕种机通过收割协议与收割机交流（收割机是一台单独的机器，包括实际储存地块的耕种机在内）。 + +耕种机运行时要等待全节点的更新， 大约每9秒钟给他们新的标点(相当于抽签获奖号)。 然后，耕种机向每个收割机发送标点，以检查其是否赢得了空间证明。 如果收割机找到了有效证明，就会将其发给耕种机，证明分为两类： + +- 完整证明必须符合或超过网络难度水平所要求的质量。 这些证明将发送到完整节点，然后创建一个新的区块。 +- 部分证明是用于矿池来估算节点的总存储量。 + +耕种机也有一个私钥，这个私钥既用于当发现完整获胜证明时签署区块，也用于签署部分证明，这些证明随后被送到矿池。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/full-nodes.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/full-nodes.md new file mode 100644 index 00000000000..af9fe8a8735 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/full-nodes.md @@ -0,0 +1,17 @@ +--- +title: 全节点 +slug: /chia-blockchain/architecture/full-nodes +--- + +Chia点对点系统的核心由全节点组成。 全节点有以下几项责任： + +1. 保留一个区块链的副本。 +2. 验证区块链。 +3. 使用点对点协议通过网络广播新区块、交易和验证。 +4. (可选) 通过钱包协议提供轻量客户端(钱包)。 +5. (可选) 与农民通信。 +6. (可选) 与时间领主通信。 + +农民通常会在进行耕种进程的同时进行一个全节点进程。 全节点不赚取报酬或费用，但是它们对于保持共识规则和系统安全非常重要。 运行一个全节点可以让用户对区块链的完整状态有信心，并且避免信任他人。 + +全节点总是随机连接到网络中的其他全节点。 全节点定期向对等节点传送自己的信息(IP地址和端口)。 这样整个网络就知道它们仍在运行。 全节点还将所有新区块和交易广播给他们的对等节点， 这样网络中的所有节点共同保存了一个完整的区块链副本。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/harvesters.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/harvesters.md new file mode 100644 index 00000000000..a60b52e96ca --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/harvesters.md @@ -0,0 +1,27 @@ +--- +title: 收割机 +slug: /chia-blockchain/architecture/harvesters +--- + +收割机是一些独立的机器，由农民控制。 在大规模耕作活动中，农民可能与许多收割机连接在一起。 + +收割机通过从磁盘检索质量或证明来控制实际的绘图文件。 最小容量的图(也是最常见的) 是 k32，大约相当于100 GiB。 每次递增一个k值，绘图大小大约加倍，所以一块k33地块大约为200 GiB，k34大约为400 GiB等。 + +每4608个区块，难度水平会自动调整，为每两个信标点选择一个空间证明——在整个网络空间上。 这是目标平均值——每个信标点也可以有零或多个证明。 这导致大约每24小时会进行难度调整。 + +在一个指定地块，收割机必须执行两项任务才能找到有效的证明： + +1. 获取初始质量 — 这需要进行大约7次随机磁盘扫描，在慢速HDD上就是70毫秒。 +2. (仅在初始质量足够高的情况下执行) 获取完整的证明——这需要大约64次磁盘扫描，在慢速HDD上就是 640 毫秒。 + +就大多数挑战而言，质量 ( 步骤1) 很低，所以没有必要获取全部证明（步骤2）。 一个节点有28秒的时间返回一个证明，所以磁盘I/O 不会是一个限制因素， 即使证明存储在慢速HDD上。 + +:::note +Tape drives are too slow for farming. The protocol was designed to support hard disks, but nothing slower. It is possible to use tape for long-term plot storage, only transferring the plots to disks for occasional farming, but this is likely a very rare use case. +::: + +Finally, harvesters also maintain a private key for each plot. The blocks are signed with these keys, which is an important concept in Chia. It means that even when a farmer is a member of a pool, the farmer still controls the contents of a block. This is quite different from other blockchains' pooling protocols, where the pool operators are the ones signing the blocks. + +:::info +The harvester algorithm is discussed in greater detail in the [Harvester Algorithm page](/chia-blockchain/consensus/chains/harvester-algorithm). +::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/light-clients.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/light-clients.md new file mode 100644 index 00000000000..2c48f033152 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/light-clients.md @@ -0,0 +1,29 @@ +--- +title: Light Clients +slug: /chia-blockchain/architecture/light-clients +--- + +Light client support is another benefit of Proof of Space and Time (PoST) when compared with Proof of Stake (PoS). In PoST, all proofs can be verified objectively and cryptographically, while maintaining the requirement to control an actual resource at a certain point in time. With Chia's consensus, a candidate chain can be compared to an alternate chain objectively for weight, even after being offline for a long time, without relying on a central authority. + +For light clients that want to sync up quickly to the chain (for example, mobile wallets), a full node can create a small-sized proof that can convince the light client that the weight of a chain is close to some value. This is called a proof of weight. + +Naively, the light client could download every single block and all the required proofs and verify them. But, with a large number of blocks, this would require a lot of bandwidth and CPU. + +A more efficient method relies on a protocol similar to [Flyclient](https://eprint.iacr.org/2019/226.pdf). The node (Prover) sends all the sub-epoch summaries from the fork point, including difficulty resets, to the light client. + +There is only one sub-epoch every 384 blocks, so the summaries will only reach a few MB of data. + +The node also deterministically samples several sub-epochs based on the challenge of the last block. Sub-epochs have a chance to be chosen proportional to the difficulty during that sub-epoch. For the chosen sub-epoch, the light client downloads one of the challenge chain blocks (which are approximately 1/32 of all blocks), and computes the average infusion iterations of all challenge blocks in that sub-epoch. Based on this time, the light client can extrapolate how many blocks the reward chain contains. + +For example, if the challenge blocks all occur with very small iterations (close to the beginning of the sub-slot), there are likely many blocks in that sub-slot. Conversely, if the iterations are close to the middle of the sub-slot, there is likely only one block per sub-slot. This allows the light client to only download 1/32 of the blocks in each sub-slot, but still get a good estimate of the total weight. + +Furthermore, the last few sub-epochs should be downloaded in full for the light client. +This adds a small amount of data, but prevents attackers from creating small forks at the end of the chain. + +The main difference between this protocol and Flyclient is that blocks are not committed to using a Merkle mountain range, but instead the light client downloads the entire list of sub-epoch hashes from genesis, guaranteeing that the queried sub-epochs are included in the chain. Another difference is that entire sections are downloaded, as opposed to individual blocks. + +As of December 2021, more analysis needs to be done on how many sub-epochs should be downloaded and what the bounds are for what the proof of weight implies. + +## Obtaining Transactions + +Light clients can fetch the transactions that they are interested in, without having to download every single block or block header. Two wallet protocols are available for this, a less efficient one that maintains better privacy, and a super efficient one that has a privacy tradeoff, namely that the wallet must ask a node for payments made to certain addresses. Both of these protocols are currently supported in the Wallet API. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool.md new file mode 100644 index 00000000000..1d5ef40f2e1 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/mempool.md @@ -0,0 +1,114 @@ +--- +title: Mempool +slug: /chia-blockchain/architecture/mempool +--- + +The mempool (or memory pool) is a collection of transactions stored by full nodes, usually in memory, before they are confirmed on the blockchain. The mempool is not dictated by the consensus rules; a farmer can change how their mempool functions and customize the rules without permission from other full nodes. + +The mempool is a required 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. + +## Validation + +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. + +## Fee Required for Inclusion + +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 20 blocks. This true for both mainnet and testnet11. +- 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%. +- This limitation will be increased gradually, until it reaches 100%, or 11 billion cost -- the limit enforced by the consensus rules. +- The size (in CLVM cost) of the mempool is `mempool blocks * max cost per block * block size limit`. + - In version 2.2, this amounts to `20 * 11 billion * 0.6`, which equals 132 billion. + - When the block limiter is lifted, the total size will be `20 * 11 billion`, or 220 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. + +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. + +:::info Testnet11 info + +Testnet10 is constantly 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. 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). + +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 every transaction in the mempool has a fee of at least five mojos per cost. In order for your transaction to be added, 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. + +## 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 (can include additional spends) +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](https://docs.chia.net/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 replace by fee logic can be found [here](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/full_node/mempool_manager.py#L678)in the codebase) + +## Block Creation + +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. + +Coin spends cannot impact other coin spends, which is a very nice property of UTXO systems, and allows parallelization of validation and block creation. The aggregate +spend bundle also has one aggregate signature, which is a combination of every signature from every transaction in that block. + +For performance reasons, the chia-blockchain codebase currently creates only smaller blocks (less than 50% of the maximum size) in order to keep the blockchain smaller and easier to run. This "throttle" is likely to be removed in future versions, after additional optimizations have been performed. + +## Updating the Mempool + +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/pools.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/pools.md new file mode 100644 index 00000000000..9553db8b50f --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/pools.md @@ -0,0 +1,18 @@ +--- +title: Pools +slug: /chia-blockchain/architecture/pools +--- + +Pools allow farmers to smooth out their rewards by earning based on proof of space partials, as opposed to winning blocks. + +Pools require the use of portable plots. These plots are tied to a plot NFT that the farmer must create. This NFT sits on Chia's blockchain, and it allows users to switch between pools. + +Pools create and spend **coinbase transactions**, but in Chia's pool protocol they do not actually choose the contents of blocks. This gives more power to farmers and thus decreases the influence of centralized pools. + +Farmers periodically send partials, which contain a proof of space and a signature, to pools. The pools use these partial proofs to determine how much space the farmers have dedicated, which in turn determines the farmer's portion of the reward when the pool wins a block. + +When a farmer who is a member of a pool wins a block, 7/8 of the reward goes to the pool, which is later distributed to the participants. The farmer keeps the other 1/8 of the reward. This was an intentional design decision. If a farmer didn't receive a direct reward for creating a block, the operator of a competing pool might have had a financial incentive to join a pool (that they didn't run) with a large number of plots, and neglect to create a block when they found a valid proof, thereby spoiling the competing pool. + +:::info +For more info, see our [Pool Farming page](/reference-client/farming/pool-farming), as well as this site's [Pool Protocol page](/chia-blockchain/protocol/pool/pool-protocol) page. +::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/timelords.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/timelords.md new file mode 100644 index 00000000000..0328bc785e6 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/timelords.md @@ -0,0 +1,65 @@ +--- +title: Timelords +slug: /chia-blockchain/architecture/timelords +--- + +Timelords support the network by creating sequential proofs of time (using a [Verifiable Delay Function](/chia-blockchain/consensus/proof-of-time)) and broadcasting them approximately every nine seconds. This provides "deterministic randomness", which is used to decide the winning proofs of space. + +Since this computation is sequential, very little energy is consumed, as opposed to proof-of-work systems, where computation is parallelizable. For example, if 100 timelords are doing the same computation on a proof of time, they will all create the exact same output. + +:::info +The timelord algorithm is explained in the [Timelord Algorithm page](/chia-blockchain/consensus/timelords). +::: + +A timelord is required to connect to exactly one full node, typically on the same machine. This connection is verified with a certificate. This 1:1 architecture has a large security benefit: it keeps the timelord sandboxed in its own private network. That way, the full node protocol is the only protocol that requires total security. If more than one full node could connect to the same timelord, it would add a potential attack vector to the network. + +Timelords do not directly earn rewards. Furthermore, only the fastest timelord on the network will broadcast proofs at any given time. Therefore, only one timelord is required to keep the network running, and most farmers will not feel compelled to run one. However, farmers with multi-PiB farms may want to run a timelord, both for redundancy and for protection against temporary local latency issues. + +If someone controls the fastest timelord in the world, it doesn't give them much of an advantage at winning rewards. However, they could potentially orphan or censor other farmers, depending on how much faster their timelord is. + +Furthermore, an attacker with a significantly faster timelord than anyone else could potentially run a long-range attack against the network with less than 42.7% of the total netspace. For security purposes, it is very important to maintain open designs of VDF hardware. + +:::info +You can learn about potential attacks against Chia's network in the [Attacks and Countermeasures page](/chia-blockchain/consensus/attacks-and-countermeasures). +::: + +## Types of Timelords + +There are two primary types of Timelords: Regular and Blueboxes. + +The first is the core Timelord and can be either a software Timelord or a hardware Timelord (ASIC) that takes in Proofs of Space and uses a single fastest core to perform repeated squaring in a [class group of unknown order](https://github.com/Chia-Network/vdf-competition/blob/master/classgroups.pdf) as fast as possible. Beside each running VDF (referred to as a vdf_client in the application and source) is a set of proof generation threads that accumulate the proof that the time calculation's number of iterations was done correctly. + +The second are Bluebox Timelords. Blueboxes are most any machine - especially things like old servers or gaming machines - that scour the historical chain looking for uncompressed proofs of time. So that the chain moves quickly, the regular Timelords use a faster method of generating proofs of time but the proofs are larger, which takes your Raspberry Pi a lot more time and effort to validate and sync the blockchain. A Bluebox picks up an uncompressed Proof of Time and recreates it, but this time with the slower and more compact proofs generated at the end. Those are then gossiped around to everyone so they can replace the large and slow to verify Proofs of Time with the compact and much quicker to validate version of exactly the same thing. + +## Running a Timelord + +The network only requires one running Timelord to keep moving (liveness.) The way Timelords race is like they are on a series of 100 meter dashes. Each one takes off with the last good Proof of Space and tries to get to the total number of iterations required to complete a given Proof of Space. Better Proofs of Space require less iterations to prove. When the fastest Timelord announces the Proof of Time for this Proof of Space all of the other Timelords stop racing and are magically teleported to the starting line of the next 100 meter dash to start it all over again. + +It's good to have a few Timelords out there. There can be things like routing flaps or the overzealous backhoe that takes large swaths of the internet offline. If the fastest Timelord was just about to win the current dash when its internet blinked off in a fury of construction misadventure, then the second fastest will win that dash and the next dashes - until the fastest returns. One of the key qualities about Proofs of Time is that given the same Proof of Space, their output and proof are always the same (though the proofs can be larger or smaller and harder or easier to validate - they all end up with the same outcome.) + +The Company plans to run a few Timelords around the world - and some backups too - to ensure that all Farmers and nodes can hear the beat that the Timelords are calling. + +For installation and usage documentation please refer [here](/reference-client/install-and-setup/timelord-install). + +## Troubleshooting a Timelord + +For troubleshooting steps please refer to the documentation [here](/reference-client/troubleshooting/timelords). + +## The Future of Timelords + +In 2023, CNI received its first batch of ASIC timelords. When run as a cluster of three VDFs, these timelords could hit upwards of one million IPS. This was approximately four times the speed of the fastest non-ASIC timelords. After installing several timelords in strategic locations globally, and after thorough testing on private testnets, the company added the ASICs to a public testnet. Finally, after [years of designing](https://www.businesswire.com/news/home/20211013005324/en/Chia-Partners-With-Supranational-to-Create-Industry-Leading-Proof-of-Space-Time-Security) the ASICs and months of testing them, they were activated on mainnet in October 2023. + +The next step was to distribute some of the remaining ASIC timelords to a select list of applicants, as detailed in a [blog post](https://www.chia.net/2023/10/26/asic-timelords-faster-than-fast-chia-network/). This process ensures a high amount of global redundancy on this critical network infrastructure. + +Of course, as technology improves, the ASIC design will need to be updated. However, this process is extremely costly, and the current generation is already pushing upon the limits imposed by the laws of physics. We expect the current crop to remain the fastest timelords in the world for years to come. However, this process is extremely costly, and the current generation is already pushing upon the limits imposed by the laws of physics. We expect the current crop to remain the fastest timelords in the world for years to come. + +## Timelords and Attacks + +One of the things that is great about [Chia's new consensus](/chia-blockchain/consensus/consensus-intro) is that it makes it almost impossible for a Farmer with a maliciously faster Timelord to selfishly Farm. Due to the way the new consensus works, a Farmer with a faster Timelord is basically compelled to prove time for all the farmers winning blocks around him also. Maliciously running a faster Timelord can give a benefit when attempting to 51% attack the network, so it is still important that over time we push the Timelord speeds as close to the maximum speeds of the silicon processes available. We expect to have the time and the resources to do that right and make open-source hardware versions widely available. + +## Terminology + +- VDF: verifiable delay function, another way to say "proof of time" +- Timelord launcher: a small program which launches "vdf client" processes over and over, to perform the actual VDF calculations. +- VDF client: a C++ process which performs a VDF computation and then shuts down +- Timelord: The timelord communicates with the node, and is what decides which VDF tasks to assign to which clients. The vdf clients connect through HTTP to the timelord. So you can have the timelord in a separate machine as the timelord launcher diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/wallets.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/wallets.md new file mode 100644 index 00000000000..19243d22ba2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/architecture/wallets.md @@ -0,0 +1,8 @@ +--- +title: Wallets +slug: /chia-blockchain/architecture/wallets +--- + +Wallets can communicate with full nodes through the wallet protocol. This is similar to Bitcoin's SPV protocol: it allows verification of transactions and block weight, without the bandwidth and CPU requirements of full nodes. + +Wallet nodes are similar to full nodes, in that they are servers which communicate to other peers in the network. A common use case is to run a wallet locally along with a full node, where the wallet only connects to the full node. Wallets use [light clients](/chia-blockchain/architecture/light-clients) to download weight proofs from nodes to quickly validate which blockchain is the longest. They then ask full nodes to scan the blockchain for their desired transactions. The wallet is also responsible for managing private keys, as well as generating, storing and sending transactions. The wallet exposes an RPC HTTPS websocket JSON API, which user interfaces can use to execute commands. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/addresses.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/addresses.md new file mode 100644 index 00000000000..a08117ea33b --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/addresses.md @@ -0,0 +1,37 @@ +--- +title: Addresses +slug: /chia-blockchain/coin-set-model/addresses +--- + +Puzzle hashes in Chia are 32-byte values. These can be displayed in hex, but this can lead to errors due to typos, and a poor user experience. Therefore, Chia displays puzzle hashes in a custom format called an _address_. The encoding scheme used is [bech32m](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki). + +Address: `xch1pwrzyy35qxk0rz76jl0648fvt6ql905vwd7zs0scjqant5sf25lql4hz3z` + +Puzzle hash: `0b8622123401acf18bda97dfaa9d2c5e81f2be8c737c283e18903b35d209553e` + +An address is just a different way to display the puzzle hash, which contains some additional data (checksum) at the end to find errors. Puzzle hashes can be converted to addresses and vice versa. + +bech32m addresses have several features which make them attractive: + +- [Checksum](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki#specification), which makes addresses invalid if only one character is modified. +- An XCH prefix to distinguish from other cryptocurrencies. +- Shorter than hex, and more compact than base58 addresses (and fit better in QR codes). + +The blockchain consensus code does not operate with addresses; addresses are only used in user facing applications. + +Spacescan.io has a handy bi-directional [bech32m \<\> puzzle hash converter](https://www.spacescan.io/xch/tools/puzzlehashconvertor). + +# Chia Burn Address + +You can send unwanted tokens to this addresses to make them unspendable: + +- Mainnet burn address: `xch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ks6e8mvy` +- Testnet burn address: `txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh` + +:::warning +Do not send anything to these addresses unless you want it to be inaccessible forever. +::: + +A traditional bech32m puzzle hash for a burn address is all zeros ending in "dead": `0x000000000000000000000000000000000000000000000000000000000000dead`. Converting this to an address, you end up with the burn addresses above. + +You can use a [puzzle hash converter](https://www.spacescan.io/tools/converter/address) to verify for yourself. 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 new file mode 100644 index 00000000000..1799534a3d9 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/clvm-vs-evm.md @@ -0,0 +1,34 @@ +--- +title: CLVM vs EVM +slug: /chia-blockchain/coin-set-model/clvm-vs-evm +--- + +We'll start with a brief description of CLVM. For details on the inner workings of CLVM, see our [CLVM reference](https://chialisp.com/clvm "CLVM reference on chialisp.com"). + +- CLVM is the compiled, minimal version of ChiaLisp that is used by the Chia network. +- CLVM is built out of cons boxes and atoms. Cons boxes contain two items, which can be either an atom or another cons box. +- All CLVM programs can be represented as a binary tree. Evaluation is similar to that of standard Lisp. +- CLVM uses a minimal operator set, most of which are a single letter. + +## 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. | + +--- + +We chose CLVM over EVM for the reasons outlined above, and especially because of these advantages: + +- Sandboxing – coins are independent from one another, providing for strong security +- Composability – inner puzzles make it possible for coins to take on the functionality of other coins +- Interoperability – all coins output a list of conditions, so they can inherently interoperate with one another, even if not explicitly designed to do so +- No side effects - Auditing is easy; reentrancy is not possible 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 new file mode 100644 index 00000000000..48de4377906 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-account.md @@ -0,0 +1,117 @@ +--- +title: Coin Set vs Account Model +slug: /chia-blockchain/coin-set-model/coin-set-vs-account +--- + +In the account model used in many blockchains such as Ethereum, Solana and Algorand, balances are kept in accounts. These are permanent data structures which do not get destroyed when they send funds. + +In this section, we'll focus on Ethereum and how its account model compares with Chia's coin set model. + +## Ethereum's account model + +In terms of keeping track of state, Ethereum's account model functions similarly to legacy banks. Accounts, balances and smart contracts are persisted on the blockchain. + +Accounts and contracts have money associated with them. The source code governing how money may be spent is a first class object. + +A typical Ethereum transaction would look like the following: + +Alice wants to send 1 eth to Bob. To complete this transaction, 1 eth is subtracted from Alice's balance, and 1 eth is added to Bob's balance. There is no need to calculate the history of how Alice acquired 1 eth prior to this transaction. In order for the transaction to be processed, the system only needs to know that Alice's balance was at least 1 eth. + +## Chia's coin set model + +There are no accounts or balances, but rather only coins (see the [Coin Set Intro page](/chia-blockchain/coin-set-model/intro) for more info). Coins are first class objects; they are the only data that is persisted on the blockchain. Each coin has a parent, allowing for its history to be tracked to its coinbase. + +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 | +| ----- | ---------------------------------------------------- | --------------------------------------------------- | +| 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 | + +## Advantages of the account model + +### Monetary fungibility + +#### Account + +An account only has a balance, so it's difficult to make a logical case that some money should be treated differently than other money. Money is "mixed" by default. + +#### Coin set + +Coins can be combined by spending them, but they cannot be "mixed" by adding a balance to an account. This means that some coins might be viewed differently than others, even if they have the same value. + +This has already happened with Bitcoin. Due to its high energy consumption, some people have refused to buy bitcoins that can be traced to mining with fossil fuels. This affects Bitcoin's fungibility because not all coins are viewed equally. + +### Ease of programming + +#### Account + +Solidity shares similar paradigms in programming to web development, so there is a large pool of programmers who can learn it fairly quickly. When programming a smart contract, the programmer can simply store all balances in an array. Transactions involve little more than adding to, and subtracting from, balances. All other logic is contained within the same program. It's simple to combine multiple transactions that affect the same program in the same block. + +#### Coin set + +Transactions might involve spending and creating many coins, so a programmer must think about the rules governing how coins may be spent, and how coins will interact with each other. This makes programming in Chia more difficult than in Ethereum. However, auditing is much easier in Chia (see the [CLVM vs EVM page](/chia-blockchain/coin-set-model/clvm-vs-evm) for more info). + +--- + +## Advantages of the coin set model + +### Scalability + +#### Coin set + +Because verification is built into the coin set model, so is scaling. If a coin's "owner" loses the private key required to spend the coin, the coin becomes unspendable. However, the overall system is unaffected, so scaling does not become more difficult. + +Additionally, because each coin spend is independent, the system is very parallelizable. + +#### Account + +If an account's owner loses their private key, then any code or messages referring to that account cannot be processed. This can be propagated across the entire system, making solutions such as sharding more difficult. + +### Privacy + +#### Coin set + +With a click of a button, a user can add a new address for each transaction; each new coin can be stored in a different address. This makes blacklisting difficult. + +#### Account + +Each user typically has just one account. It's possible to create additional accounts in order to use more than one address. However, high fees typically discourage users from doing this. Also, it's easy to blacklist an ETH address. + +### Determinism + +#### Coin set + +Coins can only be spent once, making the results deterministic (if you run the same program multiple times, you'll get the same result each time). Because of this, re-applying mempool transactions after a new block is not necessary. + +Note, however, that smart coins _could_ be designed such that multiple people could spend the same coin, which would potentially reduce determinism for those coins. + +#### Account + +Multiple people can execute the same code within a smart contract. The order of execution could affect the results, which therefore reduces determinism. + +### Sandboxing + +#### Coin set + +Coin value is split between many coins, increasing sandboxing, and therefore security. One program cannot call or affect another. If a coin is hacked, only that coin's owner can have money stolen. + +#### Account + +Value is stored within a single account or contract. Multiple people can execute the same smart contract code. If a contract is hacked, everyone who participates could have money stolen. + +### Database size + +#### Coin set + +Programmable features are not stored directly on chain. Instead, coins use hashing to allow for later verification of their contents. + +Chia's database growth depends on transaction type and utilization but may reach 170 GB annual growth with 100% full blocks (further improvements to database compression are possible). Kryder's Law dictates that storage capacity will grow exponentially in the short-to-medium term, whereas the database will grow linearly. In early 2022, an SSD capable of storing Chia's database cost less than $50. This should hold true for the foreseeable future, even as Chia's database continues to expand. + +#### Account + +User account information, as well as transaction data, is small. However, smart contracts are stored on chain. Because of this, Ethereum's database will likely grow more rapidly than Bitcoin's or Chia's. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-utxo.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-utxo.md new file mode 100644 index 00000000000..1ecf55dfc9e --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/coin-set-vs-utxo.md @@ -0,0 +1,28 @@ +--- +title: Coin Set vs UTXO Model +slug: /chia-blockchain/coin-set-model/coin-set-vs-utxo +--- + +The UTXO and coin set models of accounting are very similar and are often used interchangeably. This is fine in most contexts; coin set is based on UTXO, and there is a much larger difference between the coin set and account models. However, there are a few key differences, which we'll discuss in this section. + +## First class objects + +In the UTXO model, _transactions_ are first class objects. Each transaction has an ID and an output number, which is persisted in the system's overall state. + +In the coin set model, _coins_ are first class objects (everything is a coin). "Transaction" is a term used to represent the spending of some coins and the creation of others. Coins are the only information persisted in the system's overall state. + +## Transaction/coin processing + +In Bitcoin's UTXO model, an individual block's transactions are organized as a Merkle tree, where each transaction in a block is a leaf, and the coinbase transaction is the root. The leaves must be sorted in topological, or natural, order. If transaction B spends an output of transaction A, then both A and B are allowed to occur in the same block, but A must be stored in an earlier position than B in the Merkle tree. The logic required to build such a tree requires a large amount of processing power. (See this [Medium article](https://medium.com/fcats-blockchain-incubator/understanding-the-bitcoin-blockchain-header-a2b0db06b515) for more info.) + +In Chia's coin set model, each of a block's transactions occur simultaneously. Chia uses two Merkle trees – one for removing coins, and one for adding them. + +In a single Chia block, multiple coins can be created, and multiple coins can be spent. Individual coins can even be created and spent in the same block – these are known as _ephemeral_ coins. As long as the rules governing how the coins may be spent are followed, and as long as the total value added and removed is balanced (other than the coinbase coins), the transactions are valid. + +This design comes with two advantages over UTXO: it removes the complex logic required to build a valid Merkle tree, and it reduces the viability of certain types of MEV such as front-running, back-running, and sandwich attacks. + +## Signature type + +Chia uses BLS signatures, which allow for all signatures in a block to be combined, as if each block were a single transaction. This happens non-interactively - the parent of each coin is chosen automatically. For example, if three coins are spent and two are created, typically one of the spent coins will be designated as the parent of both of the new coins. + +Bitcoin has used signatures based on the Elliptic Curve Digital Signature Algorithm (ECDSA) since its inception. These signatures don't allow for transactions to be aggregated, so each one must be validated independently. As of the Taproot upgrade in 2021, Bitcoin is also able to use Schnorr signatures, which allow for aggregation. Schnorr signatures are an improvement over ECDSA, but they don't offer the ability to combine all signatures in a block into a single signature. They also use large Merkle trees to generate M of N multisigs, and they rely on random numbers to aggregate signatures. The BLS signatures used by Chia fix all of these problems, and more. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/conditions.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/conditions.md new file mode 100644 index 00000000000..0a137469adb --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/conditions.md @@ -0,0 +1,7 @@ +--- +title: Conditions +slug: /chia-blockchain/coin-set-model/conditions +--- + +This page has been moved. A comprehensive list of Chialisp conditions is now available on our site dedicated to Chialisp: +https://chialisp.com/conditions/ 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 new file mode 100644 index 00000000000..fe0a8b5001b --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/costs.md @@ -0,0 +1,176 @@ +--- +title: Costs +slug: /chia-blockchain/coin-set-model/costs +--- + +Cost is a unit of measurement that represents resources expended to record a transaction in a block. Cost is a unit of measurement that is used to represent the available space in a block. It is measured by the amount of computing power required to execute the programs within it, as well as the physical drive space required to store data on each node's machine. + +:::info +The maximum cost per block is 11,000,000,000 (11 billion), which is typically equivalent to around 400 KB of space. However, not every block is completely full. + +It is important to keep the cost usage of programs on the Chia blockchain as low as possible, to minimize the network pressure and resulting fees incurred. +::: + +## Cost Calculation + +Cost has several components. First, every CLVM program uses a certain amount of cost during execution, based on the operators and the values they are called on. You can refer to the [Cost page](https://chialisp.com/costs) on the Chialisp website to learn more about the cost of various CLVM operators. + +Additionally, certain conditions in a coin spend have a cost associated with them as well. A few common examples are [`CREATE_COIN`](https://chialisp.com/conditions#create-coin) and [`AGG_SIG_ME`](https://chialisp.com/conditions#agg-sig-me), which are expensive operations. + +Finally, each byte of data that gets added to the blockchain has a cost of 12,000. Spend bundles are created using a serialized format of CLVM programs, calculated by running [opc](https://chialisp.com/commands#serialize) on the original CLVM program. Each two-digit pair of this format is equivalent to one byte, which costs 12,000 to store on the blockchain. + +Aside from cost, the maximum number of atoms and pairs (counted separately) in a CLVM program is 2^31 apiece. If this threshold is exceeded, the program will terminate. However, this is likely a moot point, since it's extremely unlikely to write a program with this many atoms or pairs without exceeding the maximum cost per block. + +## Minimum Specs - Farming {#farming-spec} + +The minimum spec machine to run a full node is the Raspberry Pi 4. How do we know if this machine can stay synced? The worst case scenario occurs when multiple full transaction blocks are created with the minimum amount of time between them. This will temporarily put maximum load on the system. If the Pi can stay synced in this scenario, then it easily should be able to stay synced under normal load. + +The first question we must answer is how much time elapses between transaction blocks. The first question we must answer is how much time elapses between transaction blocks. Chia's consensus mandates that at least three signage points must be reached before infusion_iterations may occur, so the minimum time between blocks is the following: + +``` +3 signage points * signage point time +3 signage points * (600 seconds per sub-slot / 64 signage points per sub-slot) +3 signage points * 9.375 seconds per signage point +``` + +Which is 28.125 seconds. + +:::note +The **average** time between transaction blocks is [51.95 seconds](/chia-blockchain/consensus/chains/foliage#transaction-block-time). The lower a given time interval between transaction blocks (down to 28.125 seconds), the lower the probability of a transaction block being created in that time interval. +::: + +A transaction block is considered "full" when it contains 2000 outputs. For this document, we'll assume this translates to 1000 vanilla transactions, each with two inputs and two outputs. This would give the network an average of 19.25 (1000/51.95) transactions per second. + +:::note +A transaction with only one input and one output is also possible. In theory, a block could therefore hold up to 2000 transactions, in which case the network would process an average of 38.5 (2000/51.95) transactions per second. +::: + +With this goal in mind, Chia has created a **generator program** that processes 2000 compressed inputs and outputs. This program simulates a "full block". + +To calculate the total amount of time for a Raspberry Pi 4 to process a full block, we must take into account three factors: + +- The time required to run the generator program (2000 inputs and outputs) + - The Raspberry Pi 4 accomplishes this in 5.2 seconds +- The time required to validate 2000 public keys + - 2.2 seconds +- The time required to validate 2000 aggregate signatures + - 10.63 seconds + +Therefore, the total amount of time required for a Raspberry Pi 4 to process a full block is 5.2 + 2.2 + 10.63 = 18.03 seconds. This is 10.095 seconds faster than the minimum time between blocks, and 33.92 seconds faster than the average. When considering other factors such as network latency and time required to fetch a full proof ([640 ms on a slow HDD](/chia-blockchain/consensus/proof-of-space-1.0#farming)), this still allows plenty of leeway for a Raspberry Pi 4 to stay synced and collect farming rewards. + +## Minimum Specs - Syncing {#syncing-specs} + +As a benchmark, we use the Raspberry Pi 4, Chia's minimum spec machine for farming. A Raspberry Pi 4 has four cores, so it can validate a pre-existing block in 18.03 / 4 = 4.5075 seconds, which is around 11.5 times the average real-time rate of 51.95 seconds. Even in the worst-case scenario where every transaction block is full, the Pi can sync faster than the chain is being created. + +## Maximum Block Cost {#max-block-cost} + +Now that we've established that a Raspberry Pi 4 can, indeed, sync and farm, even when every transaction block is full, we'll calculate the maximum cost per block. + +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 +2. Generator program size (each byte has a cost) +3. Generator program coins (each new coin has a cost) + +In the case of calculating the maximum cost, these three categories are to be given equal weight. We'll go through each of the categories individually. + +#### Generator Execution + +(This is the first half of 1, above.) + +An Intel Macbook Pro was used as a reference platform to determine baseline costs based on CPU usage. The costs were then hand-tweaked for various reasons: + +- To ascribe additional cost to operations that allocate memory, i.e. the operand per-byte cost was inflated. This additional cost is called `MALLOC_PER_BYTE_COST` and amounts to 10 cost per byte. +- The especially CPU intensive BLS operations (`point_add` and `pubkey_for_exp`) had their cost inflated to not differ too much from the Raspberry Pi 4. +- Some operations that do not allocate memory and end up being common in relatively simple programs had their cost deflated. Specifically, `if`, `cons`, `listp`, `first`, and `rest`. + +The result is that the generator program has an execution cost of 1 317 054 957. + +#### Generator Signature Validation + +(This is the second half of 1, above.) + +The signature validation cost is based on computation time. BLS operations involve public key and aggregate signature validation, which are multiplied by the number of outputs. + +- Time per public key validation: 0.179370 ms +- Time per aggregate signature validation: 0.972140 ms +- Total time for 2000 key and signature validations: (0.179370 + 0.972140) \* 2000 = 2303.02 ms + +Each 1 cost is designed to require 1 nanosecond, so we need to multiply the result by 1 million (ns/ms). + +- Cost for the generator program's BLS operations: `2303.02 * 1 000 000 = 2 303 020 000`. + +Using this info, we can also calculate the cost of each `AGG_SIG_UNSAFE` and `AGG_SIG_ME` condition in all CLVM programs: + +- Cost per BLS condition: `(0.179370 + 0.972140) * 1 000 000 = 1 151 510`. We round this number up to 1 200 000. + +### Generator Cost {#generator-cost} + +(This is the total cost of 1, above.) + +Taking the previous two calculations into account, the total cost to execute and run the BLS operations of the generator program is: `1 317 054 957 + 2 303 020 000 = 3 620 074 957`. + +### Generator Program Size {#generator-size} + +(This is the cost of 2, above.) + +We know that 1, 2, and 3 all will be assigned equal maximum costs, which we've already established is 3 620 074 957. This is the size-based cost of the generator program. + +The generator program itself is 298 249 bytes. Each byte, therefore has a cost of `3 620 074 957 / 298 249 = 12 137.76`. We round this number to 12 000 per byte. This is the cost per bye of all CLVM programs. + +### Generator Program Coins + +(This is the cost of 3, above.) + +Just like the previous calculation, the total cost of the generator program's coins is 3 620 074 957. The generator program creates 2000 coins, so the cost per `CREATE_COIN` in all CLVM programs is `3 620 074 957 / 2000 = 1 810 037.4785`. We round this number to 1 800 000. + +### Maximum Cost Per Block + +To calculate the maximum cost per block, we simply add the generator program's execution, size, and coin costs: + +Theoretical maximum cost per block: `3 620 074 957 + 3 620 074 957 + 3 620 074 957 = 10 860 224 871` We round this number to 11 000 000 000. + +### Maximum Block Size + +The theoretical maximum size of a single block is `maximum cost per block / cost per byte`, or `11 000 000 000 / 12 000 = 916 667 bytes`. However, this number ignores the costs of all operators. If you want a CLVM program to do anything useful, the maximum size would be closer to 400 KB. + +Even this number is not realistic because it assumes that a single program will take up an entire block. The maximum number of vanilla transactions (with two outputs) per block is 1000. Therefore, if there is fee pressure on Chia's blockchain, a 400 KB program would need to include a larger fee than the top 1000 vanilla transactions in the mempool -- combined -- in order for a farmer to include it. + +### Estimated Transaction Costs + +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/#fee-required-for-inclusion) 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) | + +### Exact spend bundle costs + +[xch.dev](https://xch.dev) has a tool to [generate the exact cost](https://xch.dev/#/tools) for a spend bundle. Simply paste your spend bundle or Offer file to view its CLVM cost, along with its contents. For example, [this spend bundle](https://xch.dev/#/tools/c52710f8834d0320b3f4b94193fe2b4707e397f31d22e767313d72ea8b9a21b0) will spend 33 coins and will incur a CLVM cost of around 536 million. + +In addition, the website also lists the exact cost of spend bundles that have already been added to the blockchain. Simply click on a transaction block height, then click on a spent coin to view its cost. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/intro.md new file mode 100644 index 00000000000..205b174bc0c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/intro.md @@ -0,0 +1,101 @@ +--- +sidebar_label: Introduction +title: Coin Set Intro +slug: /chia-blockchain/coin-set-model/intro +--- + +In any given blockchain, one of the most fundamental questions is, "How do we keep track of the state of the whole system?" Bitcoin uses the Unspent Transaction Output (UTXO) model. Ethereum, along with many other blockchains, use the account model. Chia uses the _coin set_ model, which is similar to UTXO. + +The differences between the above models will be covered in the [Coin Set vs UTXO page](/chia-blockchain/coin-set-model/coin-set-vs-utxo) and the [Coin Set vs Account page](/chia-blockchain/coin-set-model/coin-set-vs-account). For now, we'll start with a brief explanation of the coin set model. + +The mantra _everything is a coin_ will go a long way in helping you to understand the coin set model. There are no accounts. There are only coins. + +Coins may only be spent once and anyone can attempt to spend them. However coins are locked with specific rules. They are written in Chialisp, a Turing-complete language with no side effects, allowing for complex functionality, including composability and interoperability between coins. + +The [majority of Chia's coins](https://chialisp.com/standard-transactions/) have one simple rule – "Anyone with the right private key can spend me." + +## Key Features + +- As stated above, Chia's blockchain only understands coins. There are no accounts at the blockchain level. +- Technically the coins do not have owners. Anyone can attempt to spend any coin. Most coins are secured such that only someone who possesses a certain public/private key pair may spend them. This person is the coin's de facto "owner." +- The _coin set_ is the total set of all coins on Chia's blockchain. +- The minimum value of a coin is 0 mojos. The theoretical maximum value of a coin is around 18 million XCH (2^64-1 mojos). Each coin can be of any value within this range. + - Note 1: One use case for a zero-mojo coin is to convey information. For example, upon being spent, a zero-mojo coin could make an announcement for a singleton to recreate itself + - Note 2: [Singletons](https://chialisp.com/singletons) must have an odd-numbered value, so their minimum value is 1 mojo (1 trillionth of an XCH) +- The first block of Chia's blockchain introduced four coins to the coin set, with a total value of 21 million XCH. This is the pre-farm, controlled by Chia Network Inc. +- Each additional block introduces a reward of two coins to the coin set (see the [Block Rewards page](/chia-blockchain/consensus/block-validation/block-rewards#farmer-vs-pool-reward) for more info). For the first three years of Chia's blockchain, the targeted daily average to be introduced is 9216 XCH. This amount will be cut in half in 2024, 2027, 2030, and 2033, after which the targeted daily average will always be 576 XCH. While the exact amount introduced on any given day will vary slightly, one can predict the total amount of XCH in the coin set at any given time, with a high degree of accuracy. +- Each coin can only be spent once. Thus, a coin has only two states: unspent and spent. (Technically, there is a third state: not created. This happens when there is a re-org and the creation transaction gets reverted. Re-orgs in Chia are rare, though possible.) +- A coin's value cannot be destroyed. Instead, when a coin is spent, its value is released. One or more new coins will be created in the same block, the total value of which will equal the value of the spent coin. +- The coins themselves are highly programmable, so a wide variety of behavior is possible when a coin is spent. + +## Blockchain + +The Chia blockchain, as explained in the consensus section, is a linked list of blocks, agreed upon by nodes. Nodes also maintain a table of coins. At a low level, a coin in Chia is a record of ownership of a certain amount of XCH, which can be unlocked by providing the correct puzzle and a valid solution. + +These 3 properties make up each coin, and when hashed together form its id: + +- Parent Coin Id +- Puzzle Hash (hash of the program) +- Amount (in mojos) + +The ID of a coin is computed by hashing together its three fields, where amount is encoded in CLVM format: + +```chialisp +(sha256 parent_coin_id puzzle_hash amount) +``` + +Because the id is a sha256 hash, coins can never be changed. They can only be created and then spent once. + +## Puzzles + +A puzzle is a type of CLVM program that outputs [conditions](https://chialisp.com/conditions) that determine the result of the spend. + +Each coin has a puzzle associated with it that determines how, when, and by whom this coin can be spent. It must be chosen at the time of the coin's creation. + +For example, if Bob wanted to pay Alice, Bob would create a coin with a puzzle (and thus a puzzle hash) which Alice knows how to unlock. Bob can create a coin worth 5 XCH using Alice's puzzle hash, so that only Alice can unlock it. + +Puzzle hashes are addresses. When you send XCH to someone's address, you're doing this exact thing. + +## Spends + +When Alice wants to spend her coin, she creates a spend bundle that reveals the coin she will spend, the original puzzle, and the solution to that puzzle. The solution usually involves things such as conditions (which can include recipients of the coin). In a standard transaction, Alice is the only one that knows the private key used to sign the transaction, and thus controls that coin. + +The network has no concept of accounts, or of coin ownership. Anybody can attempt to spend any coin on the network. It's up to the puzzles to prevent coins from being stolen or spent in unintended ways. + +The data required to spend a coin is: + +- Coin Id +- Puzzle (serialized CLVM program) +- Solution (serialized CLVM value) + +A coin also has the option of requiring an aggregate signature in order to spend it. + +You can read more on the [Spend Bundle page](/chia-blockchain/coin-set-model/spend-bundles). + +## Value Added and Spent + +Value may only be added to the coin set via the pre-farm (a one-time occurrence) and block rewards (which occur with each transaction block). Value can never be destroyed, though it can be "bricked," for example by sending it to an address for which nobody possesses the private keys. + +Typically, in a block's combined spend bundle, value added will be equal to value spent, other than the block rewards. By definition, there are two possible exceptions: + +- Value added > value spent -- This is not allowed, so the transaction will be rejected. The rejection will usually happen at the mempool level, though a malicious actor could write their own mempool to accept the transaction, in which case the blockchain will reject it. +- Value added < value spent -- This is allowed, so the transaction will succeed. If the value added is less than the value spent the remaining value will be rewarded to the farmer of the block containing the transaction awarded as a tip (you probably don't want to do that!). + +## Account Model vs Coin Set Model + +In the account model, which is used by Ethereum and many other systems, balances are kept in accounts. These are permanent data structures which do not get destroyed when they send funds. There are some tradeoffs between the account model and the coin set model (similar to Bitcoin's UTXO model). + +### Benefits of the Account Model + +- All logic and state can be stored in one program and one account, simplifying development. +- It is simple to combine multiple transactions that affect the same dApp in one block. +- Users and wallets only have to keep track of one account for all of their balances (although the UTXO model can support this). + +### Benefits of the Coin Set Model + +- Very parallelizable since each coin spend is independent. +- Coin value is split between many coins, increasing sandboxing and security. One program cannot call or affect another. +- Deterministic operation of every spend. +- More efficient storage of state (although this depends on implementation). +- Increased privacy, since one user usually has many coins. +- Re-applying mempool transactions after a new block is not necessary due to deterministic results. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/security.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/security.md new file mode 100644 index 00000000000..af20398368a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/security.md @@ -0,0 +1,63 @@ +--- +title: Security +slug: /chia-blockchain/coin-set-model/security +--- + +When creating smart coins, security concerns should be at the front of your mind. The language is specifically designed to secure money on a network with _no centralized authority_ to enforce rules. The only thing standing in the way of attackers and potentially large sums of money is how you design smart coins. + +## Signing the Solution {#signing} + +When you push a transaction, it gets gossiped to other nodes until it finds one who will put it into a block. Every node chooses what will be passed on to the next node. If it likes, it can change some data before it forwards it. + +This is why the aggregated signature is part of the spend bundle. It allows you to mark data as valid only if there is also a signature that vouches for its correctness. Signatures are how you prevent nodes from changing your transaction in malicious ways. If they do, the spend will no longer be valid. + +Signing is especially important when looking at solution values. The puzzle reveal is secured by the puzzle hash on the coin. The solution, however, can be anything. Most of the time when you are spending a coin, the output conditions are passed in somehow through the solution. If you don't sign those conditions (or the delegated puzzle that generates them) you must assume that an attacker is going to notice and attempt to substitute their own values. + +Sometimes, it is necessary to have solution values that logistically cannot be signed, but also should not be changed. In scenarios like these, you should try to have a signed coin use announcements to assert that the coin is being spent with the correct information. + +## Asserting Coin Information {#asserting} + +Signing is how you prevent nodes from messing with your own spends, but sometimes you want to create coins that will be traded around with specific rules. As a result, you don't know who will be spending the coin, and you don't know if they will be honest. + +Using [inner puzzles](/guides/chialisp-inner-puzzles), you can enforce rules on your child coins by [currying](/guides/chialisp-currying) and wrapping tree hashes. However, there are times when you also want to enforce truths about yourself or your parent. + +This is where the `ASSERT_MY_*` family of condition opcodes comes in. When you need information (`parent_coin_info`, `puzzle_hash`, `amount`) about your coin to use in the puzzle, it cannot always be curried in by an honest party. Sometimes, it will need to be passed in through the solution. + +The solution should always be treated as if it is being solved by malicious or careless parties. If any coin information is being passed in, it should be asserted with opcodes to ensure that the network, who can see that information, can confirm it. + +Keep in mind that `ASSERT_MY_COIN_ID` will actually implicitly assert all three of the pieces of information in a coin. The same is true of `ASSERT_MY_PARENT_ID` for parent coins, which is particularly useful since there is no such thing as `ASSERT_MY_PARENT_PUZZLE_HASH`, for example. + +## Replay Attacks {#replay} + +Another huge concern when creating your spends is whether they will be valid if parts of them are excluded or reused. This kind of attack is the reason why `AGG_SIG_UNSAFE` is labeled the way it is. + +If you sign something with `AGG_SIG_UNSAFE`, the only data that is being signed is the message you are trying to sign. Once you sign and push it, that signature lives on the blockchain forever. If you later create a puzzle that is locked up with the need for the same signature, an attacker can find the signature you used last time and reuse it. + +This is why you should try to always use `AGG_SIG_ME` if possible. Not only does it make you commit to the coin ID in the signature (something that is unique to every spend), but it also commits to the genesis challenge of the network you are on. A revealed signature for a coin on testnet could be replayed in mainnet otherwise. + +Exclusion should also be a concern at the forefront of your mind. Oftentimes, you will be spending multiple coins in the same bundle, and they should all be tied together into one aggregated signature. If you have good reason not to sign one of them, make sure you know what happens if it gets excluded from the bundle. + +Furthermore, aggregated signatures can't be disaggregated into smaller signatures _unless_ you have previously signed one of the smaller combinations of public key-message pairs in the bundle. The attacker can exclude the rest of the transactions that contain `AGG_SIG` conditions and reuse the smaller signature again on the remaining transactions. They can also calculate the remaining aggregated signature and perhaps sign every spend except the one the exclude. This is known as **signature subtraction** and is another great reason to use `AGG_SIG_ME` as much as possible. + +## "Flash Loan from God" Attack {#flash-loans} + +An interesting angle that also has to be considered during the building of your coins is how their security holds up if a party that is spending them has infinite money. This may seem ridiculous except that cryptocurrency enables **flash loans** to exist which are instant loans of money with no conditions except that they are returned to the owner within the same block. + +Take for example, a piggybank coin that only allows you to withdraw funds once the amount of the piggybank has grown to a determined savings goal. If a person wants to retrieve their funds early, they can borrow money equal to their savings goal, cash out the piggybank, and then return the money that they borrowed. + +There's also potential to use vast sums of borrowed money to influence the price of something, if that price is calculated programmatically. If you have enough money, you can singularly simulate a bunch of trades to influence the price calculation to the price you desire, make a transaction at that price, and then return all of the money you borrowed to simulate trading while keeping the profits. + +Fortunately, this attack has a relatively easy fix, and that is to add an `(ASSERT_HEIGHT_RELATIVE 1)` condition to prevent the money from being returned in the same block. + +## Puzzle and Solution Reveals {#reveals} + +Remember to think about when puzzles and solutions are revealed. They are revealed only at spend time of the coin that is committed to them. The only thing that the network sees prior to that is the parent coin and the puzzle hash. This can be an advantage, since you can hide sensitive information for spending the coin inside the puzzle hash before it is ever revealed. However, once the puzzle is revealed, it's revealed forever, so that sensitive information cannot be considered sensitive again. + +Also keep in mind that if a parent coin is currying information to its child coin before it creates it, that will be public before the child coin is spent. For some wallets, this is an advantage since you may want certain data about a coin's puzzle to calculate whether or not it's yours. However, if you were trying to use a plain-text password, that won't be very secure. +Instead, make sure to pre-commit to things with hashes and then assert that they are revealed correctly later. + +## Conclusion + +Hopefully you have a better idea of what risks are involved when creating a smart coin. It's very worth your time to try and exploit your puzzles by passing in dangerous solutions or leaving out transactions/signatures. + +You're not just trying to protect against bad actors, but also against people accidentally bricking their coins. Puzzles are usually pretty permanent, so it's worth the extra time. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/spend-bundles.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/spend-bundles.md new file mode 100644 index 00000000000..19792750104 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/coin-set-model/spend-bundles.md @@ -0,0 +1,87 @@ +--- +title: Spend Bundles +slug: /chia-blockchain/coin-set-model/spend-bundles +--- + +A spend bundle is a set of spends of multiple coins, which is usually submitted to full nodes for inclusion into the blockchain. In Bitcoin, the equivalent data structure would be the transaction. + +Here is the spend bundle's basic construction: + +```python +class CoinSpend: + coin: Coin + puzzle_reveal: SerializedProgram + solution: SerializedProgram + +class SpendBundle: + coin_spends: List[CoinSpend] + aggregated_signature: G2Element +``` + +As you can see in the code sample above, a spend bundle is a group of coin spends, where each coin spend includes the coin being spent, the puzzle program, and the solution program. Each solution is passed into each puzzle and run through the CLVM, where it outputs conditions. Two of the conditions -- `AGG_SIG_ME` and `AGG_SIG_UNSAFE` -- require +that a signature be present in order for the spend to be valid. + +Usually when making a transaction, a user would combine multiple spends, to achieve the desired value of the transaction. Users can also combine coins that represent [CATs](https://chialisp.com/cats) (Chia Asset Tokens), and send different types of values in the same spend bundle. + +## Aggregate Signatures + +In Bitcoin, each spend has its own signature or signatures, one for each `(public key, message)` combination. Then, each signature `s_i` is passed through a signature verification algorithm: `V(s, m, pk) -> T/F`, with the message `m` and public key `pk`, and would be valid if and only if `V` returns true. + +In Chia, BLS signatures are used. These signatures can be combined (added) together to produce an aggregate signature of the same size as the originals. Let's say we have three spend bundles, each with its own pair: + +``` +s1 m1 pk1 +s2 m2 pk2 +s3 m3 pk3 +``` + +With BLS signatures, farmers combine all three signatures `s1, s2, and s3` into one signature `s_agg`. The BLS signature verification can take multiple public keys and messages: `V(s, [m1, m2, ... mx], [pk1, pk2, ... pkx]) -> T/F`. + +This allows the farmer to combine all three spend bundles into one spend bundle, with only one signature, which means less data is transmitted and stored on chain and disk. + +Another benefit of these aggregate signatures is that when spending multiple coins, users will only transmit one signature, instead of one or more per spend. More information can be found in the [BLS Keys page](/chia-blockchain/keys/keys-and-signatures). You can also read the [code for BLS signatures](https://github.com/Chia-Network/bls-signatures). + +## Coins vs Spend Bundles + +One major difference between Chia and other UTXO-based blockchain systems is that spend bundles are not a first-class object in the block database. Each block in Chia contains a list of removals and additions, where removals are the coins spent in that block, and additions are the coins added in that block. + +Let's say a farmer wants to include 1000 spend bundles into a block. First, they can combine all spend bundles into one, and then they can make the block. Each block will have exactly one signature for all spends. Full nodes that verify and store this block do not need to know the original information of which spends were bundled with which other spends. + +## Additions and Removals + +In the figure below, you can see a spend bundle that was created by a user. The removals in the spend bundle are coins A, B, and C, and the additions are coins D and E. This is very similar to how the standard transaction script works in `chia-blockchain`. + +
+drawing +
+ +Let's go through the different components in the image. First, let's say Alice wants to send 13 XCH to Bob. Alice looks at her coin database, and selects 3 unspent coins (A, B, and C) that add up to at least 13 XCH. Each one of these coins has an associated CLVM puzzle, which has a public key encoded inside of it. Let's denote these public keys as `pkA`, `pkB`, and `pkC`. Alice needs to generate the puzzle and solution for each of the +spends, in order to create the spend bundle. + +Each puzzle, when run with the solutions, returns an `AGG_SIG` condition (either AGG_SIG_ME or AGG_SIG_UNSAFE). This means that a signature is required from the respective public key, in order for this spend to be valid. + +Instead of providing 3 signatures, we can use BLS signature arithmetic to combine all three into one signature. There are two benefits to doing this: + +1. The resulting spend bundle will be smaller in bytes. +2. The spend bundle can not be unbundled (the signature cannot be de-aggregated). + +That is, an attacker who obtains Alice's spend bundle is not able to pull apart the spend bundle in order to spend just one of the coins. When Alice sends this spend bundle to the Chia network, other full nodes will run the CLVM programs, collect all the `AGG_SIG` conditions, and then verify them using the aggregate signature provided in the spend bundle. + +The first puzzle here for coin A also returns two `CREATE_COIN` conditions. This means that two coins must be added to the coin database in order for spend A to be valid: + +1. Coin D is for Bob (puzzle hash 0x1b54f and 13 XCH). +2. Coin E is Alice's change. She spent 14 XCH, but only wanted to send 13 XCH to Bob. Each coin's value must be spent entirely, so Alice needs to send 1 XCH to herself as change. + +Note that the puzzle hash of coin E is the same as that of coin A. Puzzle hashes can be reused. When spending coin E, Alice would sign with the same key as before, but would most likely use a different message that spends to another recipient. + +Also note that only the first spend is creating the coins. This is the normal way to combine spends, since each coin must have exactly one parent. Spend A, by itself, would not be valid, since it creates more value (14 XCH) than it spends (5 XCH). However, the spend becomes valid when combined with spends B and C. + +Full nodes receive, validate, and store the spend bundle in memory. However, when creating a new block, farming nodes will combine many spend bundles from different users. This creates one large spend bundle with one signature. When looking at just the block, it is not always clear which spends were bundled together initially. However, we can see the net additions and removals in the whole block. + +## What do full nodes store on-chain? + +Puzzles are only revealed when coins are spent; the puzzles are saved on-chain afterward for record-keeping purposes. + +Full nodes, therefore, store the history of the blockchain, which includes all revealed puzzles and solutions, for all spent coins. Full nodes also store a list of unspent coins, which only contains puzzle hashes, and not puzzles. + +Users are responsible for remembering and storing their own puzzles in order to spend their coins. Usually these are regenerated on the fly by wallet software, based on templates. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/analysis.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/analysis.md new file mode 100644 index 00000000000..7e56eb4434d --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/analysis.md @@ -0,0 +1,80 @@ +--- +title: Analysis +slug: /chia-blockchain/consensus/analysis +--- + +## Safety + +The safety of Chia's consensus is similar to that of other Nakamoto consensus algorithms like Bitcoin. There is no guaranteed finality, but the more confirmations a transaction has, the safer it is. + +A transaction needs a certain number of confirmations for a receiver to assume that it cannot be re-orged, under the < 42.7% (\* vdf advantage) colluding assumption. Since farmers can theoretically sign multiple blocks at the same height, more _confirmations_ should be used in Chia than in Bitcoin. However, Chia doesn't require anywhere near as much _clock time_ as Bitcoin for a transaction to be considered safe. + +In Chia, there are two main reasons to wait for a certain number of confirmations: + +1. To be confident there won't be a chain re-org. As discussed in the [Foliage page](/chia-blockchain/consensus/chains/foliage), a small re-org is a natural occurrence in blockchains, though rare in Chia. + +To be confident that there won't be a chain re-org, you should wait for six blocks to be created (around two minutes after the first confirmation). + +2. Just in case there is a foliage re-org attack, as described in the [Attacks and Countermeasures page](/chia-blockchain/consensus/attacks-and-countermeasures#bribe-foliage). This type of attack would require an attacker to discover the identity of -- and successfully bribe -- a large and consecutive number of anonymous block winners. This attack would be difficult to pull off, so it is expected to be extremely rare, if it is ever even attempted. + +If you want to be nearly certain that even a successful foliage re-org attack won't reverse your transaction, you should wait for 32 blocks to be created (around ten minutes after the first confirmation). + +It's worth noting that the 54% requirement only pertains to _non-colluding_ space, rather than _honest_ farming space. Profit-seeking farmers gain very little by deviating from the protocol. + +There is the added assumption that at least one fast timelord must be connected to the non-colluding portion of the network, and that the attacker's timelord is not significantly faster. A redundant set of ASIC timelords have been distributed globally. It will extremely difficult and costly to build a significantly faster timelord. + +## Liveness + +The liveness of the Chia consensus system is one of its greatest strengths. Like Bitcoin, the Chia system continues advancing even when a majority of the space goes offline. Unlike bitcoin, though, the system does not slow down significantly when this happens, since not all blocks are transaction blocks. Therefore transaction throughput does not drop significantly if many participants go offline. + +The network will continue to advance even if only one farmer is online, although there will be many empty slots, since a transaction block can only be created if it's below the sub-slot iterations threshold. + +Of course, in the event of a long-term network split, the effects are that one chain must be chosen, so there can be large re-orgs in this case. The network will automatically choose the heavier chain, similar to PoW. + +## Comparison to Nakamoto PoW + +("+" means a pro for Chia) + +- (+) Different resources. PoSpace is ASIC-resistant and therefore anyone can participate in farming. +- (+) Hopefully more decentralized. (Analysis in mainnet's first year shows this to be the case.) +- (+) Easy merge farming. Other cryptocurrencies can use the same format, and everyone can share the space (assuming their farming computers have sufficient disk space and memory). (Note that the blockchain with the largest netspace will probably be the only secure one, since the farmers can attack smaller ones. This is especially true of blockchains with less than 50% of the top chain's netspace -- the remaining farmers who have not joined the smaller chain could collude to join, and attack, that chain.) +- (+) Minimum energy used, since only a few nodes run VDFs, and these are not parallelized. Very low marginal cost to farm. +- (+) More consistent transaction block times (targeted average is one per 52 seconds, as discussed in the [Foliage page](/chia-blockchain/consensus/chains/foliage)). +- (+) Less susceptible to selfish mining attacks. +- (+) Smaller orphan rates and forks, since blocks can be included in parallel. +- (+) Continues to advance at nearly the same rate when space decreases, since only around 1/3 of blocks include transactions. PoW Nakamoto Consensus slows down linearly when hashrate drops. + +* (-) Drawback of more potential attackers (large companies). Hardware is general purpose, and therefore attackers could switch between farming, attacking, and using for data storage. +* (-) If an attacker acquires a significantly faster VDF, they could gain a space advantage. +* (-) More complexity due to sub slots and VDFs, potentially more cryptographic assumptions. + +## Comparison to Proof of Stake + +Chia's consensus algorithm could also be used for Proof of Stake, where the space farmers are replaced by stakers who own coins in the system. The benefit would be the ability to slash (delete people's stake), and farmers would have "skin in the game", but there are some concerns if Proof of Stake is used. ("+" means benefit for using space vs stake). + +- (+) An attacker can transfer their stake to someone else, but fork the chain right before their stake is transferred. In this alternate chain, the attacker still has all of their stake, and can therefore advance the chain. The "nothing at stake" issue is different in PoS than in PoSpace since creating a PoSpace requires a physical resource (hard drive space), while creating a PoS only requires a key. +- (+) An attacker can guarantee their share of the whole monetary supply, by staking their rewards (the rich get richer), since the total number of coins is limited. +- (+) There might be situations where the attacker can grind on many different ways to transfer stake. Perhaps this can be mitigated by requiring a long period before stake becomes active. +- (+) Registration is required, you cannot participate in proof of stake until you sign up. This reduces privacy and scalability (how many people can stake). +- (+) Higher barrier to entry: security deposits and slashing make it difficult for small users to participate. Slashing can be a huge risk for participants in the network. Centralized custodians lead to a less distributed set of participants. +- (+) Some assumptions are required to perform light client syncs in Proof of Stake. Source: [Flyclient paper](https://eprint.iacr.org/2019/226.pdf). + +* (-) Skin in the game: with PoS, the consensus can slash people's stake, and also requires some investment into the system (exposure to price). In Proof of Space, hard drives can be used for other purposes and there is no ability to "slash" people's hardware. + +## Comparison to BFT consensus algorithms + +Proof of Space could also be used as a Sybil-resistant mechanism in order to bootstrap a Byzantine consensus (k-agreement) system. Filecoin, and many Proof of Stake systems use aspects of Byzantine consensus. + +The pros and cons of using Chia Nakamoto Consensus vs Byzantine consensus, which vary from algorithm to algorithm ("+" means a pro for Chia): + +- (+) Much simpler. +- (+) No registration requirement. +- (+) No scalability requirement (scales to millions of farmers). +- (+) More censorship resistant. As long as a small portion of the farming space does not censor, eventually you can get into the blockchain. +- (+) No liveness requirements, potentially fewer network assumptions. +- (+) Fully objective (A node can compare chain 1 and chain 2, and immediately know which one is heavier). No need for checkpoints with ⅔ consensus. +- (+) Better light client support. See the [Flyclient paper](https://eprint.iacr.org/2019/226.pdf) for more info. + +* (-) No finality, only probabilistic. +* (-) Need to wait longer for transaction confirmations (related to no finality). +* (-) Less consistent block times and transaction throughput. 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 new file mode 100644 index 00000000000..22a8aa3a429 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/attacks-and-countermeasures.md @@ -0,0 +1,212 @@ +--- +title: Attacks and Countermeasures +slug: /chia-blockchain/consensus/attacks-and-countermeasures +--- + +## Majority Attack {#majority} + +In a majority attack, an attacker creates an alternate chain which eventually reaches a higher weight than the honest chain, and forces users to re-org. This attack is present on many blockchain networks including Chia's, as well as on Proof-of-Work systems. It is colloquially known as a "51% attack" because the attacker must control more than half of the blockchain's resources (hashrate for PoW, netspace for PoST) in order to succeed. + +Chia's consensus makes this attack more complex to evaluate than in Proof-of-Work systems. In analyzing this attack, there are several variables at play: + +- Number of timelords (regardless of speed) + - The attacker must control at least one timelord for the attack to be possible. + - With exactly one timelord, the attacker can only build one private chain. + - With an unbounded number of timelords, the attacker can build multiple chains simultaneously, keeping the best one while discarding the rest. This allows the attacker to create slots with fewer blocks, giving them a "double-dip" advantage, discussed in detail below. +- Timelord speed (regardless of number) + - If the attacker has a single timelord, the amount of storage required for the attack is directly correlated to the speed of the attacker's timelord relative to the speed of the fastest honest timelord on the network. + - For example (ceteris paribus), if the attacker's timelord is twice as fast as the fastest honest timelord on the network, then the attacker's space will be twice as "valuable." + - Additionally, the double-dip advantage will increase as the timelord's speed increases. However, due to the minimum block requirement, this advantage will hit its maximum limit with a timelord that is somewhat less than twice as fast as the fastest honest timelord on the network. Also, multiple timelords are required to gain any double-dip advantage at all. +- Duration of attack + - For attacks lasting less than one epoch (~4608 blocks or 1 day), we must assume the worst case for the attacker's double-dip advantage, based on the speed and number of timelords. + - For attacks lasting one epoch or longer, the minimum double-dip advantage can always be used. This is because the difficulty will adjust during the attack, so the attacker will lose the ability to create slots with fewer blocks. + +Before we can evaluate the percentage requirements for various scenarios, we must first calculate the range for the double-dip advantage. + +The paper [Proof-of-Stake Longest Chain Protocols: Security vs Predictability](https://arxiv.org/pdf/1910.02218.pdf) outlines the equation to derive the minimum percentage of the network space an attacker would be required to have in order to undertake a majority attack, for chains using between 1 and 10 consecutive blocks with the same challenge. However, Chia uses a larger -- and variable -- amount of consecutive blocks with the same challenge. Because of this, we must solve the equation for two additional values: + +- 16 -- This is the minimum number of blocks in a slot. (See the [Overflow Blocks and Weight page](/chia-blockchain/consensus/chains/overflow-blocks.md#minimum-block-requirement) for more info.) In the worst-case scenario, an attacker with an unbounded number of fast timelords could theoretically create a chain that always uses this minimum number, as explained in the next section. + +- 32 -- This is the targeted number of blocks per sub-slot. (See the [Challenges page](/chia-blockchain/consensus/chains/challenges) for more info.) There will be some natural variance in this number, but an attacker who does not have the fastest timelord will not be able to manipulate it. + +Here's the code to solve for these values in Wolfram alpha, where c is the number of consecutive blocks with the same challenge: + +```bash +% Wolfram +% solve q=-(c*p)/(ln(-p)+(c-1)ln(1-p)) , -ln(-p)-(c-1)ln(1-p)=-1+(c-1)*(p/(1-p)), c=16 ,f=1/(1+q) +% Solution over the reals: p≈-0.438787 ∧ q≈1.34313 c=32 +% Solution over the reals:p≈-0.616585 ∧ q≈1.4678 c=16 +% 1/(1+1.4678)= 0.405219 +% 1/(1+1.34313) = 0.4267795 +``` + +Using `DD` to represent the double-dip advantage, + +- With a single timelord, `DD` is always 1 (no advantage), regardless of the timelord's speed. This is because the attacker will only be able to build a single private chain. +- With an unbounded number of timelords, `DD` will exist in a range, such that 1.34313 < `DD` < 1.4678. This range has a maximum value due to the minimum of 16 blocks per slot. + +In addition to `DD`, we'll use the following variables in our calculations: + +- `SH` is the total space of the honest nodes on the network +- `VH` is the speed of the fastest honest timelord (VDF) +- `SA` is the attacker's total space +- `VA` is the speed of the attacker's timelord (VDF) + +Using these variables, the formula to calculate when an attacker is able to create a chain at the same speed as the honest chain is: + +``` +SH * VH = SA * VA * DD +``` + +If we normalize the network's honest space and fastest timelord to equal 1, then in order for the attack to succeed, the product of the attacker's space, timelord speed, and double-dip advantage must be at least 1: + +``` +SA * VA * DD >= 1 +``` + +The formula to calculate the minimum `SA` then becomes: + +``` +SA = 1 / (VA * DD) +``` + +Finally, the formula to calculate the minimum netspace percentage required for the attack is: + +``` +% = (SA / (1 + SA)) * 100 +``` + +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. | + +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. | + +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. + +It is reasonable to assume that if a majority attack were attempted, the attacker's timelord wouldn't be significantly faster than the fastest honest timelord. Furthermore, it is unlikely that the attacker could gain access to an unbounded number of timeords, so the attacker would not gain the double-dip advantage. Therefore, Chia uses a base line assumption of 51% of the netspace required for a majority attack to have a chance at succeeding. + +To reduce the possibility of an attacker gaining access to a fast timelord, Chia network has [developed and distributed ASIC timelord](https://www.chia.net/2023/10/26/asic-timelords-faster-than-fast-chia-network/) globally. + +## Extending Many Chains {#many-chains} + +As discussed in the previous section, if an attacker is making their own private chain, they can choose which block gets infused into the challenge chain, and can therefore try many different infusions, such that they get the best possible chain. + +Due to the average of 32 blocks with the same challenge, the attacker can only try about 32 different combinations (figuring out which block to include in the challenge chain). The exponential branching that results from trying each of these would give a small boost in space for the attacker. For example, someone with 5 PiB can pretend to have 6 or 7 PiB. + +The reason for receiving just a minor boost is because the alternative chains being tried are inferior and less likely to overtake the longest one. This has been analyzed in the [PoSAT paper](https://arxiv.org/abs/2010.08154). + +If there were a new proof of space challenge for every single block, the attacker could multiply their space by a factor of e=2.718, where only 27% would be required to overtake the network. Chia has chosen to mitigate this attack vector by setting the expected number of blocks per sub-slot to 32. This increases the attacker's required space to 42.7%. + +However, Chia also chose not to increase the number of blocks per sub-slot to a number greater than 32. Doing so would decrease the time between blocks, which would allow a timelord that is only slightly faster than all others to orphan blocks more easily. As it stands, with 32 blocks per sub-slot, an attacker would need to have a significantly faster timelord than everyone else in order to successfully orphan any blocks. + +Furthermore, the [PoSAT paper](https://arxiv.org/abs/2010.08154) shows that increasing the number of blocks per challenge increases security at a very slow rate, so increasing this number slightly does not provide much benefit. + +If the attacker were to manipulate the difficulty, they could change it so that they get fewer reward blocks per slot. Then they could either include or exclude each block, and exponentially extend all chains simultaneously. This would allow the attacker to multiply their space by a small factor. It is not clear whether this attack gains very much, since the attacker must change the difficulty, which requires sacrificing some weight. However, to prevent this attack, there is a requirement that at least 16 reward chain blocks must be created for a challenge block to be included. This brings the attacker's required space in the worst case scenario (with unlimited slightly faster timelords) from 27% up to 42.7%, as discussed above. + +## Global Hard Drive Space {#space} + +There is a concern that if the Chia network does not have a significant amount of space compared to the available free space of hard drive manufacturers or large companies, then it will be vulnerable to long-range attacks. Therefore the more space taken by the Chia network, the more secure the network is. + +We believe this type of attack is unlikely, though. Large data centers and companies with significant amounts of storage tend not to have much _unused_ storage available to hold Chia plots. And the more space that comes onto Chia's network, the lower the rewards per TB. With the netspace currently (December 2021) sitting at 35 EiB, companies will find it difficult to justify buying drives or deleting business data. Furthermore, creating a plot requires a fixed amount of upfront time and money (from current calculations, about 1kWh for a k32, or about 10 cents, which is $1 per terabyte). + +The most likely long-term scenario is that rewards per TB will be sufficiently low to discourage people and companies from acquiring new storage just to farm Chia. Most of the new netspace in the future will therefore come from used storage, often from hard disks that otherwise would have been bound for a landfill. This will serve two purposes: preventing the attack laid out here, and keeping Chia green. + +## 100% Attack {#100-percent} + +If the difficulty adjustment were triggered every X timelord slots, as opposed to every X blocks, this would allow for a 100% attack, where all farmers collude to constantly decrease or increase the difficulty. + +Under normal operation, there are 32 blocks per slot. + +Under the hypothetical 100% attack: + +1. The difficulty would be artificially cut in half, temporarily allowing 64 blocks to be created per slot. +2. The difficulty would then be artificially increased by 4x, temporarily allowing 16 blocks per slot. +3. Repeat step 1. + +The result of this attack would be to create an average of (64+16)/2 = 40 block rewards per slot, a 25% increase in rewards. This is why Chia chose to trigger the difficulty adjustment based on the number of blocks. If this attack were attempted under the current system, it would slow down and speed up the network, but it would not yield any extra rewards. + +## Short Range Replotting Attack {#replotting} + +Plotting usually takes a few minutes to a few hours, even on fast hardware, but it is parallelizable and getting faster. + +Someday in the future, an attacker with high-end hardware could begin creating a plot after a signage point is released, and complete the plot before the infusion point. The attacker could then delete the plot after obtaining the quality rating (or after submitting the proof if it's eligible). This would allow the attacker to create a plot that automatically passes the filter, effectively allowing them to farm without storing any space. This attack only becomes feasible if it is possible to create a plot in less than 28 seconds (before the infusion). + +If we assume the worst-case scenario of a farmer being able to create a plot instantly, +the question becomes, what is the cost and what is the benefit of the attack? + +The cost is the electricity, memory, hardware and infrastructure needed to create a plot. The electricity required to create a k32 plot is currently around $0.10, or around $1 per TB. + +The benefit would be the same benefit as storing that plot for 80 minutes (the signage point interval times the plot filter constant). This is because the attacker can always create a plot that passes the plot filter. Assuming $5 per year value per terabyte, the value of a 1TB plot for 80 minutes is $0.00094. Therefore with current plotting software and hardware, it is significantly cheaper to store the plots as opposed to recreating them. + +Another way to look at the benefit of this attack: If the attacker can create a plot that always passes the filter, it will be the equivalent of storing 512 plots locally. Which is cheaper, storing 512 plots or running this attack? + +If 1 TB of HDD storage costs $15, it would cost around $750 to purchase enough space to store 512 plots. If we account for a low-end computer on which to run a farmer, the total cost of this system is roughly $1000. Therefore, the replotting attack only becomes economically feasible on a system worth less than $1000. If this attack ever becomes possible, it will likely cost at least an order of magnitude more to run the attack than to store the plots. (And keep in mind, the price of storage tends to fall every year, so the benefit of the attack is constantly decreasing, even as its feasibility is increasing.) + +The plot filter constant is very useful to reduce the amount of disk lookups farmers must do. With a plot filter of 512, Instead of 7-9 disk reads per plot every 9 seconds, farmers only need to do about 7-9 reads for every 80 minutes. + +The downside of the plot filter constant is that it provides a multiplier of replotting benefit to an attacker, so it must not be set too high. With a plot filter constant of 512, 1/512 plots are valid for every challenge. The attacker can then only create plots that pass the filter, therefore not needing to create the other 511/512ths. + +Setting the filter constant to 512 provides a 512x multiplier. If the replotting attack ever becomes economically feasible, one mitigation would be to decrease the filter, thus decreasing the attack's benefit. The other mitigation would be to increase the minimum plot size, thus decreasing the feasibility of the attack. + +In any case, this attack will not become feasible until at least 2026, given projected improvements in hardware speed. + +## Faster Timelord (But Not 51% Attack) {#faster-timelord} + +With the fastest timelord in the system, an attacker can more effectively perform a long-range attack: they can expand their space while farming in a private chain. + +If the attacker does not reach a total of 40.5% of space (with the timelord boosting and extending many chains as above), the usefulness of the faster timelord decreases substantially. This is because inclusion and exclusion of blocks does not depend on how fast you can perform the VDF, but instead depends on whether it's less than the sub-slot iterations. Furthermore, an attacker needs the space of the rest of the network in order to advance, and therefore must release the challenges to the network. + +In certain cases where blocks come very close together, having a faster timelord can allow an attacker to orphan certain blocks, although this does not increase rewards in the short term (it would hurt others, but not benefit the attacker), and has a risk of undermining the network in the long term (orphaning blocks decreases public trust). + +## Selfish Farming {#selfish-farming} + +Selfish farming occurs when an attacker farms blocks in private, and only releases them when they are at risk of being surpassed by the honest chain. + +In Nakamoto PoW this provides significant gains, because at any point at which the miner is ahead of the rest of the network, the rest of the network is wasting their hashpower on a chain that will not win. + +In Chia consensus, a "selfish" farmer could withhold a proof until just before the infusion point, but this would provide zero benefit versus submitting the proof right away. There can be multiple block winners per signage point, so farming is not a zero-sum game as it is in PoW. Furthermore, the timelord cannot accept proofs for an infusion point that has already passed, so farmers are not allowed to stack a large number of proofs to be infused later. + +## Farmer Bribe Trunk Attack {#bribe-trunk} + +An interesting attack explored in the [PoSAT white paper](https://arxiv.org/abs/2010.08154) is the bribing attack, which takes advantage of the predictability of the elected "leaders" in each slot. The authors analyze a Proof of Stake chain, and argue that when participants know that they are going to win in advance, there is a potential bribing attack. + +In Chia, if participants knew in advance which plots would win, each user could notify an attacker that they'd be willing to participate in the attack. If the number of participants reached a certain threshold, they could completely re-org the chain (or orphan those who do not participate, censor transactions, etc). This attack does NOT require the majority of the space in the network to participate; it only requires a certain threshold of winners within a short time frame. Furthermore, it is undetectable, since the attacker can make a normal looking chain. + +This problem is not present in this revision of the Chia consensus algorithm. This problem is solved by reducing the predictability: each farmer does not know for sure if their proof of space is fully eligible until the signage point. Therefore an attacker must bribe a large majority of the space to pull off this attack. + +## Farmer Bribe Foliage Re-Org Attack {#bribe-foliage} + +Since blocks are signed by PoSpace keys, a farmer can theoretically sign multiple blocks with the same PoSpace, at the same height. The attack requires a malicious party to bribe farmers with a certain amount of funds for them to provide a signature of an alternate chain. It does not require the attacker to have a faster timelord. + +If the attacker can convince every single farmer N blocks deep to sign, they can revert or reorder any transaction in those N blocks. This attack requires 100% compliance, likely from unwitting participants. As soon as those participants learn of the attack, at least some of them would probably stop. It is therefore only a short-term attack. + +One potential prevention for this attack would be to use fraud proofs. However, these enable other attacks and complicate behavior, so they were not chosen. + +Instead, the solution is simply to wait longer. After 32 blocks (approximately 10 minutes), we can make a reasonable assumption that at least one farmer is following the protocol and not double signing. If 57.4% is non-colluding (the assumption for 42.7% attack resilience), the probability of a reversal after 32 blocks is `0.426^32` or `1.38*10^-12= 0.00000000000138`. Furthermore, this attack is detectable, so it is not easy to pull off. + +Each user can choose their own threshold for which they accept a transaction/block as final. For example, in cases where the total network space drops suddenly, users can be more careful and not consider transactions final, in case there is another existing fork, due to a network split. + +## Orphaning Transaction Blocks for Fees {#orphaning} + +Transaction blocks are different from non-transaction blocks, since they contain transaction fees. These may surpass block rewards. For example, Ethereum has had created some blocks with 2 eth of rewards and 8 eth of fees. ([EIP 1559](https://eips.ethereum.org/EIPS/eip-1559) changes the calculation significantly, so this is just a historical example of what is possible in other chains.) + +In Chia this will be more extreme, since not every block contains transactions. This leads to attacks where the 2nd place farmer ignores the 1st place in an attempt to win the transaction block. If the 2nd block comes less than 28 seconds after the 1st, they do not specify the previous block, and thus the 2nd place cannot orphan the 1st. The 3rd place could orphan both, but nobody would follow this chain since it is shorter. + +However, if there are no blocks within 28 seconds of the 1st block, the 2nd could orphan the 1st, but they would have to convince the next block to farm on their alternate chain. An easier attack would be if the attacker controlled both the 2nd and 3rd, in which case they could ignore the first and still be longer. These orphaning attacks do not allow the attacker to steal rewards, but rather allow the attacker to slightly lower the difficulty. Since they are very situational and require a lot of space, attempting this attack will likely harm the network more than the potential gain to the attacker. + +## Orphan Rate {#orphan-rate} + +In Chia consensus, two competing blocks around the same time can both be included into the blockchain in parallel, without knowing about each other (although at most one can be a transaction block). When multiple blocks are included at the same time, the result is a chain with a higher weight. This means that the orphan rate in Chia will be essentially zero, assuming low network latency. If network latency exceeds the infusion delay (30-40 seconds), then orphaning of a block is almost guaranteed, so it is more of a step-function. This is in contrast with Nakamoto-PoW in which the orphan rate is high if there is network delay, and decreases smoothly as network condition improves, but never reaches zero. 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 new file mode 100644 index 00000000000..4bbb827b085 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-format.md @@ -0,0 +1,76 @@ +--- +title: 区块格式 +slug: /chia-blockchain/consensus/block-validation/block-format +--- + +## 完整块 + +The full block is the data structure that contains all information required for validating and adding block `N`, assuming all blocks up to `N - 1` have already been added. 完整块均通过网络协议发送，有时为了后续向其他节点提供服务，也会存储在磁盘上。 + +完整块拥有区块链的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`). +- **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. +- **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. +- **transactions_info**: Optional[TransactionsInfo]: Transaction related metadata that is not relevant for light clients (not actual transactions), only for tx blocks. +- **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. + +## transactions_generator update + +Chia underwent a hard fork in version 2.1.0. This included updates to the `transactions_generator` code. + +### When + +The hard fork will activate at block `5 496 000`, which is expected to occur in June 2024. All nodes need to be compatible with the new implementation prior to this block. + +### Why + +Among other changes, the `transactions_generator` code was ported to Rust. + +There were multiple reasons for this update: + +- As an optimization -- Rust is generally more performant than Python +- To support back refs +- To make block validation faster +- To enable compression with block refs by referencing subtrees of prior transactions + +### Where + +The code for these changes is held in two primary locations: + +- The [clvm_rs](https://github.com/Chia-Network/clvm_rs/blob/main/src/serde/de_br.rs) repo has the new serialization and deserialization code. +- The [chia_rs](https://github.com/Chia-Network/chia_rs/tree/main/crates/chia-consensus/src/gen) repo has the consensus generator code. +- The Rust program for running the generator is [run_block_generator.rs](https://github.com/Chia-Network/chia_rs/blob/main/crates/chia-consensus/src/gen/run_block_generator.rs). + +### What + +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. + + About the new serialization format: + + The atom `0xfe` is followed by another atom, which is interpreted as a path into the environment (the same form as in CLVM). It references a node from a part of the tree that has already been deserialized (thus, allowing for de-duplicating sub-trees). + +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. + - The work done by the ROM no longer charges a CLVM cost, which has two primary benefits: + - It allows farmers to put more transactions into blocks. + - It makes it easier for the farmer to predict the total cost of a block as it's including transactions. + +[CHIP-0011](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md#block-generator-optimizations) contains more info about the generator optimizations. 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 new file mode 100644 index 00000000000..73fb9c4a8d0 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-rewards.md @@ -0,0 +1,60 @@ +--- +title: Block Rewards +slug: /chia-blockchain/consensus/block-validation/block-rewards +--- + +In Chia, the issuance schedule, also referred to as the block reward schedule, determines how many XCH get created with every block that gets farmed on the network. +1 XCH, or 1 Chia, is equivalent to 1,000,000,000,000 or 1x10^12 or 1 trillion mojos. +All consensus code uses mojos; XCH is used as a conveniently larger unit. + +## Strategic Reserve (pre-farm) + +The first block of the network pays out 21 million XCH, divided into a 1/8 coin and a 7/8 coin, to an address that Chia Network Inc controls. The purpose and future usage of the funds is described in the [business white paper](https://www.chia.net/whitepaper). + +## Halvings + +All other coins go through a formula, where the block reward starts at 2 XCH per block, and halves every 3 years, a total of 4 times. The exact block at which halvings occur is `32 * 6 * 24 * 365 * 3 * x`, where x is the index of the halving, starting at 1. + +``` +0-3 years: 2 XCH +3-6 years: 1 XCH +6-9 years: 0.5 XCH +9-12 years: 0.25 XCH +12+: 0.125 XCH +``` + +After the start of year 12, 0.125 XCH is created in perpetuity. + +## Reward claims + +In most cryptocurrencies, the creator of a block pays themselves based on the _current_ block reward. In Chia, there is a slight difference -- block rewards are paid in a _future_ block, depending on whether the farmer's block is a transaction block or not. + +- Option 1: If the farmer's block is a transaction block, the farmer will get paid on the next transaction block. +- Option 2: If the farmer's block is not a transaction block, the farmer will get paid on the next transaction block after the next transaction block (next next). + +Fees are also paid at the same time. Let's say a farmer creates a transaction block with 4.9 XCH of outputs, but 5 XCH of inputs (excluding reward claims). In this case, they will receive the remaining 0.1 XCH as a fee, plus their block reward, for a total of 2.1 XCH, in the next transaction block. + +Therefore, Chia coins are never destroyed. In a given block, any portion of a spent coin that is not added into a new coin will be sent to the farmer as a fee. This topic is covered in more detail in the [Mempool page](/chia-blockchain/architecture/mempool). + +## Farmer vs Pool reward + +The block reward is divided into two coins. The first coin goes to the farmer puzzle hash, which is specified by the farmer, and usually goes straight to the farmer's wallet. This contains 1/8 of the total value. This is referred to as the _farmer coin_. + +The second coin, with 7/8 of the value, is called the _pool coin_. This coin can go to one of two places: + +1. If a _pool public key_ is specified for the winning plot, then the reward is sent to the address signed by that public key. The _pool public key_ is usually used for solo farming, and sent directly to the farmer's wallet. +2. Otherwise, a _pool address_ must be encoded into the plot, and the reward is sent to the address. The _pool address_ is usually used along with the official Chia pooling protocol, and a pay-to-singleton address is used. + +## Rewards schedule + +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 | + +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 new file mode 100644 index 00000000000..ed32baf02ba --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/block-validation/block-validation.md @@ -0,0 +1,146 @@ +--- +title: Block Validation +slug: /chia-blockchain/consensus/block-validation/block-validation +--- + +Block validation in Chia is composed of two parts: header validation and body validation. + +The header validation performs consensus algorithm-related checks, such as proof of space and time, signage points and infusion points, previous block hashes, foliage hashes, and timestamps. Notably, it does not validate any CLVM, coin spends, or signatures. Usually, for efficiency, light clients will want to validate headers but not the body. + +Body validation entails running all puzzles for spent coins, reading the coin database, verifying signatures, checking for duplicate or invalid removals and additions, etc. + +Validating a block in Chia will require access to some blocks in the past, up to a maximum theoretical value of three times the max number of blocks in a slot (3x128=384), but usually only a few are needed. Also, information regarding previous sub-epochs and epochs is needed for validation, as well as the current system timestamp. Implementations +can cache only some recent blocks instead of storing all blocks in memory. `chia-blockchain` maintains a database of BlockRecords, which contain only the important pieces of block information required for validating future blocks. + +## Full Sync vs Normal Operation + +There are two cases when a node might verify blocks. + +1. During a full sync, where the node is trying to catch up to the most recent block, starting from an old block height. In this case, the node is able to download many blocks at once. +2. During normal operation, where the node is caught up to the most recent block, and is only downloading one block every few seconds. + +We'll cover both of these cases below. + +### Full Sync + +Full sync is the process by which a full node downloads and validates all of the blocks in the blockchain and catches up to the most recent block. Full sync is important, because it allows new nodes to validate that a blockchain is the heaviest -- and thus, the currently valid -- chain. It allows everyone to come to consensus on the current state, regardless of when they come online, or for how long they go offline. + +The method of full sync can vary between implementations, but the high level algorithm is the following: + +1. Connect to other peers on the network, by querying the DNS introducer, and crawling the network. +2. Check the current weight of the peak of the peers, and select a few peers to sync from. +3. Download and validate a weight proof, to ensure that the given peak has real work behind it. +4. Download and validate all blocks in the blockchain, in batches. + +Weight proofs are important, because they prevent other peers from lying to us about what the heaviest peak is. They also prevent us from downloading potentially useless data. Once the full node is caught up to the blockchain, it can properly farm, access the coin state, etc. + +### Normal Operation + +Normal operation is the process by which a full node continuously gossips and receives blocks with other peers, always following the heaviest peak. If our node is at weight 2000, and we see that a peer has a peak at weight 2100, then we fetch that block from the peer. Usually, this is done in two phases: + +1. The unfinished block is propagated across the network, along with all information up to the signage point, transactions, etc. +2. The finished block, which includes infusion point VDFs, is also propagated. This typically excludes the transactions, which were already sent in step 1. + +Normal operation is much less CPU-intensive than full sync, since there is only one block every 18 seconds, and one transaction block every 52 seconds, on average. Low-power machines like the Raspberry PI 4 should be able to easily continue normal operation. + +## Block Validation Steps + +The following sections list all of the required checks to ensure validity of a block. Please note that the official protocol and specification are defined by the `chia-blockchain` +[reference implementation](https://github.com/Chia-Network/chia-blockchain/tree/main/chia/consensus), and not by this documentation page. + +### Header Validation + +1. Check that the previous block exists in the blockchain, or that it is genesis. +2. Check finished slots that have been crossed since `prev_b`= the previous block in the chain. + - Check sub-slot challenge hash for genesis block. + - Check sub-slot challenge hash for non-genesis block. + - Check sub-slot challenge hash for empty slot. + - Validate that genesis block has no ICC=Infused challenge chain. + - Validate that there is not icc iff icc_challenge hash is None. + - Check infused challenge chain sub-slot VDF. + - Check infused challenge sub-slot hash in challenge chain, deficit 16. + - Check infused challenge sub-slot hash not included for other deficits. + - Check infused challenge sub-slot hash in reward sub-slot. + - If no icc, check that the cc=challenge chain doesn't include it. + - If no icc, check that the rc=reward chain doesn't include it. + - Check sub-epoch summary hash is None for empty slots. + - Check new difficulty and ssi if applicable. + - Check new difficulty and ssi are None if we don't finish epoch. + - Check challenge sub-slot hash in reward sub-slot. + - Check end of reward slot VDF. + - Check challenge chain sub-slot VDF. + - Check deficit (MIN_SUB.. deficit edge case for genesis block) + - If prev sb had deficit 0, resets deficit to MIN_BLOCK_PER_CHALLENGE_BLOCK + - Otherwise, deficit stays the same at the slot ends, cannot reset until 0 +3. Check sub-epoch summary + - Check that genesis block does not have sub-epoch summary + - Check that we finished a slot and we finished a sub-epoch + - Check the actual sub-epoch is correct + - Check that we don't have to include a sub-epoch summary +4. Check if the number of blocks is less than the max +5. Check proof of space +6. Check signage point index +7. Check required iters +8. check signage point index 0 has no cc sp and no rc sp +9. Check no overflows in the first sub-slot of a new epoch +10. Check total iters +11. Check reward chain sp proof +12. Check reward chain sp signature +13. Check cc sp vdf +14. Check cc sp sig +15. Check is_transaction_block +16. Check foliage block signature by plot key +17. Check foliage block signature by plot key +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 +21. Check extension data if applicable. None for mainnet. +22. Check if foliage block is present +23. Check foliage block hash +24. Check prev block hash for genesis and non-genesis +25. The filter hash in the Foliage Block must be the hash of the filter +26. The timestamp in Foliage Block must not be over 2 minutes in the future, and the timestamp must be greater than the previous transaction block timestamp. (This limit was 5 minutes until soft-fork 2 activated at block height 3886635, 2 Jul, 2023) +27. Check block height for genesis and non-genesis +28. Check block weight for genesis and non-genesis +29. Check challenge chain infusion point VDF +30. Check reward chain infusion point VDF +31. Check infused challenge chain infusion point VDF +32. Check reward block hash +33. Check reward block is_transaction_block + +### Body Validation + +1. For non transaction-blocs: foliage block, transaction filter, transactions info, and generator must + be empty. If it is a block but not a transaction block, there is no body to validate. Check that all fields are + None, and return. +2. For blocks, foliage block, transactions info must not be empty. +3. The transaction info hash in the Foliage block must match the transaction info. +4. The foliage block hash in the foliage block must match the foliage block. +5. The reward claims must be valid for the previous blocks, and current block fees. +6. No transactions before INITIAL_TRANSACTION_FREEZE timestamp (this check has been removed). +7. The generator root must be the hash of the serialized bytes of the generator for this block (or zeroes if no generator) +8. Check the transactions generator reference list: + - The generator_ref_list must be the hash of the serialized bytes of + - the generator ref list for this block (or 'one' bytes [0x01] if no generator) + - The generator ref list length must be less than or equal to MAX_GENERATOR_REF_LIST_SIZE entries + - The generator ref list must not point to a height >= this block's height + - If we have a generator reference list, we must have a generator + - Check that cost \<= MAX_BLOCK_COST_CLVM + - The CLVM program must not return any errors +9. Check that the correct cost is in the transactions info +10. Check additions for max coin amount (be careful to check for 64 bit overflows in other languages. This is the max 64 bit unsigned integer) +11. Validate addition and removal merkle set roots. +12. The additions and removals must result in the correct filter. +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). +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. +19. Check that the computed fees are equal to the fees in the block header. +20. Verify that removed coin puzzle_hashes match with calculated puzzle_hashes. +21. Verify CLVM conditions. +22. Verify aggregated signature. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/challenges.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/challenges.md new file mode 100644 index 00000000000..8edd33cb007 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/challenges.md @@ -0,0 +1,67 @@ +--- +title: Challenges +slug: /chia-blockchain/consensus/chains/challenges +--- + +The Chia consensus algorithm relies on timelords running VDFs for periods of time called _sub-slots_, which are adjusted periodically (and automatically) to take around 10 minutes. During every sub-slot, challenges are released by timelords, and a sort of mini lottery starts, where farmers check their plots for proofs of space. When farmers find a proof of space that qualifies, they broadcast it to the network. + +The difficulty adjusts automatically to target 32 winning proofs for the entire network in each sub-slot, or about one winner every 18.75 seconds on average (32 winners per 600 seconds). The winning proofs are infused into the VDF at different times within the sub-slot. + +:::info +A sub-slot is always targeted to last 10 minutes. There is also a period of time called a _slot_. Typically, a slot and a sub-slot are exactly the same thing. However, in order to prevent long-range attacks, slots are required to have at least 16 blocks (and sub-slots are not). If a sub-slot ends with fewer than 16 blocks having been created, the same slot must continue for another sub-slot. See the [Overflow Blocks and Weight page](/chia-blockchain/consensus/chains/overflow-blocks.md#minimum-block-requirement) (minimum block requirement) for more info. +::: + +The consensus requires farmers to follow the heaviest chain, which is the chain that has the highest accumulated difficulty (usually the chain with the most blocks). + +
+drawing
+Figure 4: Three sub-slots. The x axis represents time. Dotted lines represent VDF execution, advancing in time from left to right. Arrows represent hash dependencies (an object which points to another object includes the hash of the second object). +
+
+ +In figure 4, we can see three challenge points, c1, c2, and c3. At the these points timelords create challenges (256-bit hashes) which are provided as input to VDFs. Timelords take these hashes, and start computing a VDF on this challenge, for the specified number of iterations. In this example, each slot is 100,000,000 iterations. When the VDF is finished, the timelord publishes the new challenge and the proof of the VDF. An infusion of end-of-slot information happens at the end of each sub-slot. + +A challenge is always a 256-bit hash. The base info that is always included in this hash is the challenge chain VDF. However, the infused challenge chain, SubEpochSummary, difficulty, and sub slot iters might also be included, depending on where we are in the epoch cycle: + +```python +class ChallengeChainSubSlot(Streamable): + challenge_chain_end_of_slot_vdf: VDFInfo + infused_challenge_chain_sub_slot_hash: Optional[bytes32] # Only at the end of a slot + subepoch_summary_hash: Optional[bytes32] # Only once per sub-epoch, and one sub-epoch delayed + new_sub_slot_iters: Optional[uint64] # Only at the end of epoch, sub-epoch, and slot + new_difficulty: Optional[uint64] # Only at the end of epoch, sub-epoch, and slot +``` + +**Sub-slot**: a segment of a fixed number of VDF iterations, subject to periodic work difficulty adjustments, which automatically target a time of 10 minutes. + +**Sub-slot iterations**: determines how many VDF iterations each sub-slot must have. This number is periodically adjusted. + +**Challenge**: a sha256 output string. It is used as a proof-of-space challenge for farmers' plots. It is also used for the challenge chain VDF, and is sometimes referred to as a _challenge hash_. + +As you can see in Figure 4, there are three VDFs being executed concurrently, each of which serves a different purpose. They are explained in detail in the [Three VDF Chains page](/chia-blockchain/consensus/chains/three-vdf-chains.md). + +In the networking protocol, the three VDF proofs are usually passed around together, in what is called an _end of sub-slot bundle_. + +## Genesis Challenge + +The genesis challenge is the first challenge on a network that uses the Proof of Space and Time consensus. The timelords use this challenge to calculate and broadcast the very first signage point. Chia's mainnet, testnets and simulated networks each have their own unique genesis challenge. The timelords use this challenge to calculate and broadcast the very first signage point. Chia's mainnet, testnets and simulated networks each have their own unique _genesis challenge_. + +The genesis challenge is created arbitrarily, by hashing a preimage. In the case of Chia's mainnet, the preimage included the hash of Bitcoin block [675317](https://www.blockchain.com/explorer/blocks/btc/675317), which was mined shortly prior to the launch of Chia's network. It also included the following message from Bram: + +`"Operational error causes Fed payment system to crash" We stand on the shoulders of giants, now let's get farming!` + +The exact text of the preimage for Chia's mainnet is: + +``` +bitcoin_hash:0000000000000000000942b19f16b83a316acfa31e067c0b766c4dda034dc37f,bram_message:"Operational error causes Fed payment system to crash" We stand on the shoulders of giants, now let's get farming! +``` + +The SHA256 hash of this preimage is: + +``` +ccd5bb71183532bff220ba46c268991a3ff07eb358e8255a65c30a2dce0e5fbb +``` + +This hash is the genesis challenge for Chia's mainnet. The complete JSON data for the genesis challenge is located [here](https://download.chia.net/notify/mainnet_alert.txt). The first block on Chia's mainnet ([block 0](https://www.spacescan.io/block/0)) was created at signage point `2`; it points to the genesis challenge as its previous block. The prefarm was then distributed in [block 1](https://www.spacescan.io/block/1), at signage point `7`. + +The genesis challenge for other networks can be found opening `config.yaml` (located in `~/.chia/mainnet/config` for Chia's mainnet and testnets) and searching for `GENESIS_CHALLENGE:` in the section corresponding to the desired network. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/epoch-and-difficulty.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/epoch-and-difficulty.md new file mode 100644 index 00000000000..373e5fba3b4 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/epoch-and-difficulty.md @@ -0,0 +1,73 @@ +--- +title: Epoch and Difficulty +slug: /chia-blockchain/consensus/chains/epoch-and-difficulty +--- + +**Sub-epoch**: Sub-epoch N starts when sub-epoch N-1 ends (except for 0th sub-epoch), and it ends at the end of the first slot where 384 \* (N+1) blocks have been included since genesis. + +**Epoch**: Epoch N starts when epoch N-1 ends (except for 0th epoch), and it ends at the end of the first slot where 4608 \* (N + 1) blocks have been included since genesis. + +**Difficulty**: A constant that scales the number of iterations for a given proof of space. Iterations are computed as difficulty / quality. + +Every 4608 blocks, the difficulty adjustment is automatically performed. This modifies two parameters: The slot_iterations parameter, and the difficulty parameter. + +The sub_slot_iterations parameter is reset so a 600-second slot requires close to slot_iterations many iterations. The reset is done using the values from the last epoch to approximate the iterations-per-second ratio, concretely. + +We'll define `epoch$` as the period beginning with the last block that was infused _prior_ to the current epoch, and ending with the last block that was infused _in_ the current epoch. Thus, `epoch$` is a slightly shifted period that occurs for each epoch. + +The values `t1`,`i1` and `w1` denote the timestamp, iterations (since genesis), and weight (since genesis) at the beginning of `epoch$`. Along the same lines, `(t2,i2,w2)` are the values at the end of `epoch$`. + +Here's how we calculate iterations per second: + +```python +iterations per second = floor(num iterations in last epoch / duration of last epoch) + = floor((i2 - i1) / (t2 - t1)) +``` + +That is, the delta in total iterations from the start to the end of the epoch, divided by the delta in timestamps. + +Sub-slot iterations is the total number of iterations per ten-minute sub-slot. +Signage point interval iterations is sub-slot iterations divided by 64 (the number of signage points per sub-slot). + +```python +sub slot iterations = iterations per second * 600 +sp interval iterations = floor(sub slot iterations / 64) +``` + +Note that we don't take the iterations and time exactly at the end of an epoch, but at the last infusion point of a block in an epoch (aka `epoch$`), the reason being simply that we only have timestamps available when blocks are infused. + +```python +weight/sec of last epoch = (new weight - old weight) / duration of last epoch + = (w2 - w1) / (t2 - t1) + +new difficulty = (weight/sec * target seconds) / target number of blocks + = ((w2 - w1) / (t2 - t1) * (4608/64) * 600) / 4608 +``` + +This can be rearranged to use only one floor division: + +```python +new difficulty = floor(75 * (w2 - w1) / (16 * (t2 - t1))) +``` + +The sub-slot iterations are adjusted such that each slot lasts around 600 seconds. +The difficulty is adjusted such that every challenge gets 32 blocks on average with fewer iterations than slot_iterations. + +It is important to note that the VDF iterations per slot is not material to the weight. +That is, if there were two identical worlds where VDF speeds were equal and space was equal, but the sub-slot iterations parameter was twice as high in one world, then the blockchain with the higher sub-slot iterations would get twice as many blocks included per slot, but each slot would take twice as long. The weight per second added to the chain would be the same in both cases. + +Another way to look at it is that increasing sub-slot iterations increases the number of blocks per slot, but it also makes slots last longer, and thus has no effect on weight per second. + +## Sub Epochs + +As described in the [Three VDF Chains page](/chia-blockchain/consensus/chains/three-vdf-chains.md), the challenge chain is completely separate and does not refer to anything in the rewards chain. If these chains stayed separate forever, an attacker with a faster VDF would be able to look into the far future and predict challenges. The attacker could create one block per slot, with limited space, thus creating a whole challenge chain. This would allow them to create plots and instantly create proofs of space for these plots that will win in the future, and then delete the plots (a long range replotting attack). This would enable them to fill their reward chain and increase their weight. + +The solution to this is to periodically (every 384 blocks, which is an average of 2 hours) infuse the reward chain into the challenge chain. This means that the attacker can only perform the replotting attack for a few hours into the future. Plotting takes some time, but even if the attacker could replot instantly, the cost of a replotting attack will outweigh the benefits. This is because we do not infuse the _current_ reward chain output; instead we infuse the _previous_ sub-epoch's reward chain output (two hours in the past). + +The cost of creating a plot includes the electricity to calculate all of the tables, the RAM necessary while creating this plot, and the fixed infrastructure costs (space, power, cooling, etc). Assuming the worst case scenario of a super fast VDF, and instant ASIC plotting - the benefits would be equivalent to the benefits of storing that plot on a HDD for a few hours. Note that this would not guarantee a winning plot; it would be the equivalent of storing a normal plot. + +It is clear that this attack is not worthwhile, and that storing the plots is much cheaper. This is discussed in further detail in the [Attacks and Countermeasures page](/chia-blockchain/consensus/attacks-and-countermeasures#replotting). + +The above explains why the sub-epoch interval should be kept relatively low. But why can't we further reduce it to lower than 2 hours to further disincentivize replotting attacks? The reason is that whenever non-canonical data is infused into the challenge chain (which the reward chain contains, see the [Foliage page](/chia-blockchain/consensus/chains/foliage) for more info), an opportunity for grinding occurs. This means an attacker can possibly choose to include or exclude blocks to manipulate what the challenge will be 2 hours into the future. If this time is too short, they can gain a small space advantage by doing this more often. + +The second (and completely separate) purpose for sub-epochs is to act as checkpoints in a Flyclient-like protocol explained in the [Light Clients page](/chia-blockchain/architecture/light-clients.md), to increase the efficiency of light clients. 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 new file mode 100644 index 00000000000..49d3c13bb9d --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/foliage.md @@ -0,0 +1,81 @@ +--- +title: Foliage +slug: /chia-blockchain/consensus/chains/foliage +--- + +In the previous diagrams, there is no place for farmers to specify their rewards, since all blocks are canonical. +There is also no place to include transactions. Everything we have talked about so far is known as the _trunk_ of the blockchain. + +Farmers have no say in how their block is constructed in the trunk, since they must use the exact proof of space, VDFs, and signatures that are specified. +In order to include farming rewards, as well as transactions, in the system, we must introduce an additional component to the reward chain called _foliage_. + +**Trunk**: The component of blocks and the blockchain which includes VDFs, proofs of space, PoSpace signatures, challenges, and previous trunk blocks, and is completely canonical. The trunk includes each of the [three VDF chains](/chia-blockchain/consensus/chains/three-vdf-chains.md), but it never refers to the foliage. + +**Foliage**: An extension of the blocks produced in the reward chain. A block's foliage includes the specification of where rewards should go, which transactions should be included, and what the previous block's foliage is. + +:::info + +Foliage provides a separation between the transactions and the consensus. + +A given block's farmer decides what is included in the foliage, thereby allowing the farmer to grind on its contents. If the transactions and the consensus were not separated, a farmer could grind on the foliage in order to gain an unfair edge in the consensus, which would allow them to win more blocks. For this reason, the foliage is kept separate from the consensus, and it can never be used as input to the challenges. + +It is also important to note that in the implementation, when a farmer submits a block, the trunk and foliage are both submitted together -- the two pieces are not calculated and submitted at separate times. The reason we emphasize the separation of the transactions and the consensus is because the farmer may not modify a block's trunk, but retains total control over the foliage. + +::: + +**Re-org**: A re-org (or reorganization) is when a node's view of the peak changes, such that the old view contains a block that is not included in the new view (one or more blocks have either been removed, or have changed order). Both trunk and foliage re-orgs are possible, but should be rare in practice, and low in depth. + +In figure 11 below we can see that the foliage is added to the blocks formed in the reward chain. This foliage includes a hash of the previous foliage, a reward block hash, and a signature. These foliage pointers are separate from the trunk chain, and are not canonical. That is, farmers could theoretically create a foliage re-org where foliage is replaced, but the exact same trunk (proofs of space and time) are used. + +To prevent a foliage re-org, honest farmers only create one set of foliage per block. As soon as one honest farmer has added foliage to a block, the foliage becomes impossible to re-org beyond that height with the same PoSpace, since that farmer will not sign again with the same PoSpace. + +Furthermore, blocks like B3, which come parallel with the foliage of another block (B2), do not have to sign the previous block's foliage, since they do not necessarily have enough time to see it. + +:::info + +By "coming in parallel", we mean that the second block's signage point occurs before the first block's infusion point. + +::: + +The red arrows in the diagram represent a foliage pointer that is signed by the plot key for the proof of space in that block. The gray arrows represent a hash pointer which is not signed by the plot key (therefore the gray arrow in B3 can be replaced if B2 changes or is withheld). This prevents attacks where B2 modifies their block and forces B3 to re-org. + +Blocks which have red pointers are also eligible to create transactions, and are therefore called transaction blocks. + +**A block is a transaction block if and only if it is the first block whose signage point occurs after the infusion of the previous transaction block.** + +In the diagram, sp3 comes before B2, (a transaction block, and the previous block of B3), so B3 cannot be a transaction block. + +The red arrows provide security by burying foliage, but the gray arrows do not. The purpose of the gray arrows is to maintain a linked list in the foliage, and to reduce complexity in implementations. However, foliages with gray arrows pointing to them do get buried in the next-next block. + +
+drawing
+Figure 11: Foliage and trunk blocks. Blocks B1, B2, and B4 have transactions and have red pointers (pointers to last block). Note that the start of the sub-slot is also a signage point. +
+
+ +The block hash is a hash of the entire foliage and trunk block. Re-orgs work on block hashes. Even if we see a chain with the same proofs of space and time, as long as the foliages are different, the blocks will have different hashes. + +Note that the farmers of blocks B2 and B3 might both have a chance to create the block, so they must both provide the signed pointer and transactions. However, any transaction block can be included as a normal block as well, and since B2 and B3 are in parallel, only one of them can make a transaction block. + +While all blocks still choose the puzzle hashes of where their rewards go, those transactions do not get included into the blockchain until the next transaction block. + +### Transaction Block Time + +The average time between transaction blocks is 52 seconds. Several values are required to calculate this average: + +- 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](/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. +- The formal equation is (1/(e^(0.5)-1)+4)*9.375 or `(1/(e^(0.5)-1)+4)*9.375` which equals 51.95 seconds. + +The time between transaction blocks was deliberately chosen for a specific game-theoretic reason: If transaction blocks occurred at the same rate but there were no empty blocks between them, re-orgs and bribery attacks would be easier to pull off. + +Additionally, the fact that there are empty blocks between transaction blocks provides several benefits: + +- If blocks were created at the same rate and all of them contained transactions, low-power machines such as the Raspberry Pi wouldn't be able to keep up with the chain and therefore wouldn't be supported. +- Empty blocks can also help dampen the effect of the chain slowing down, for example during a dust storm. +- Finally, empty blocks help to smooth farmers' rewards. 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 new file mode 100644 index 00000000000..b7c3e6a1ef6 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/harvester-algorithm.md @@ -0,0 +1,30 @@ +--- +title: Harvester Algorithm +slug: /chia-blockchain/consensus/chains/harvester-algorithm +--- + +Approximately every 9.375 seconds, the full node sends a new signage point to the farmer, who sends it to each harvester. + +The exact protocol message sent for each signage point is the following: + +```python +class PoolDifficulty: + difficulty: uint64 + sub_slot_iters: uint64 + pool_contract_puzzle_hash: bytes32 + +class NewSignagePointHarvester: + challenge_hash: bytes32 + difficulty: uint64 + sub_slot_iters: uint64 + signage_point_index: uint8 + sp_hash: bytes32 + pool_difficulties: List[PoolDifficulty] +``` + +1. The harvester receives a signage point, and computes the plot filter: + +`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](/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 new file mode 100644 index 00000000000..1027c69e167 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/multiple-blocks.md @@ -0,0 +1,31 @@ +--- +title: Multiple Blocks +slug: /chia-blockchain/consensus/chains/multiple-blocks +--- + +
+drawing
+Figure 7: multiple blocks. Sp1 = signage point 1 +
+
+ +As you can see in Figure 7, multiple blocks can get infused into the same sub-slot. Chia's system targets one block every 18.75 seconds on average (32 blocks per sub-slot), and this is adjusted every 4608 blocks (around 24 hours) through the work difficulty algorithm. + +VDF proofs span: + +- from the previous infusion point before the current signage point to the current signage point, and +- from the previous infusion point to the current infusion point. + This means that the VDF proofs required for each block can overlap. + +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](/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. + +Finally, note that there can be multiple winners at the same signage point, all of which can be included into the blockchain. That would be the case in the diagram, if `sp2 == sp3`. The one which gets included first is the one with the lower `required_iters`, and thus earlier infusion point. + +You may be wondering what happens if a farmer makes a copy of a plot and the plot becomes eligible for infusion. Do the plots each win a block reward? No -- two blocks get created, but only one will be infused. The full nodes will only propagate the first copy of the block they see. The timelord node is ultimately connected to exactly one full node, so even if multiple identical blocks make it to that full node, they will not both be sent to the timelord for infusion. + +It is possible (albeit very unlikely) for two non-identical blocks to have the same infusion point, even though their hashes don't match. In this case, the full nodes will reject the second block they receive because each block must have total_iters > prev block total_iters. 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 new file mode 100644 index 00000000000..af75d2e564e --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/overflow-blocks.md @@ -0,0 +1,56 @@ +--- +title: Overflow Blocks and Weight +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](/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. + +**Current-slot challenge**: Any given block's current-slot challenges include all +challenges starting at the first challenge in the slot, and ending at the end of the slot (non-inclusive). +This is relevant because sometimes a slot spans multiple sub-slots, and thus multiple challenges. + +
+drawing
+Figure 9: B4 in this diagram is an overflow block, since the infusion is in the next sub-slot. + +B4 is not based on a current-slot challenge, and thus does not decrease the deficit or make a challenge block. + +
+
+ +Overflow blocks cannot exist in the first sub-slot of the epoch (since the sub-slot iterations change). + +Also, overflow blocks do not change the deficit unless they are based on a current-slot challenge, since overflow blocks are responses to the previous sub-slot's challenge. Overflow blocks are not challenge blocks unless they are based on a current-slot challenge. Note that it is rare for overflow blocks to decrease the deficit, since the deficit will almost always be decreased to zero, and a new slot will be started on every sub-slot. + +## Minimum Block Requirement + +A minimum of 16 current-slot challenge blocks must be infused into the rewards chain in order for a slot to be finished. (Recall that a sub-slot has no such requirement, so a slot could span multiple sub-slots.) + +The deficit is a number between 0 and 16 that is present at the start of a sub-slot, and is present for each finished block. This is defined as the number of reward chain blocks that we need to infuse in order to finish a slot. It is reset to 16 whenever we start a slot (so there must be at least 16 total blocks per challenge chain infusion). The deficit goes down for each reward chain infusion that is based on a current-slot challenge. + +The block with deficit 15 is a challenge block. + +The normal case is where the deficit starts at 16, and goes down to zero within the sub-slot, and resets back to 16 as we finish the slot and start a new one. In the case that we don't manage to reduce it to 0 within the end of the sub-slot, the challenge chain and infused challenge chain (if present) continue, and the deficit does not reset to 16. Blocks (including overflow blocks now), keep subtracting from the deficit until we reach 0. When we finish a sub-slot with a zero deficit, the infused challenge chain is included into the challenge chain, and the deficit is reset to 16. + +This requirement was added to discourage long-range attacks, and is described in detail in the [Attacks and Countermeasures page](/chia-blockchain/consensus/attacks-and-countermeasures#majority). The vast majority of sub-slots will have more than 16 blocks (recall that the average number is targeted to be 32), therefore the minimum-block requirement will not have much of an affect on normal operation. + +
+drawing
+Figure 10: c2 is the end of the sub-slot but not the end of the slot (we have yet to reach 0 deficit). c2 does NOT point to ic2, since the slot did not end at this sub-slot. +Deficit is 3 instead of resetting to 16, and the infused challenge chain continues. +
+
+ +## Weight + +The **weight** of a block is the sum of the difficulty of this block, plus all previous blocks that are ancestors of this block. Honest full nodes must choose the peak of the blockchain such that the peak is the block with the heaviest weight that they know of. This is a crucial requirement, and is identical to Bitcoin's heaviest chain rule. Due to this rule, an attacker with less than 50% of the space and no VDF advantage will have trouble earning more than their fair share, since they must get lucky and create more reward chain blocks than the honest chain. Furthermore, farmers only farm on the challenges that correspond to the heaviest chain. + +Both VDF speed and total amount of space are important for weight, and changes in these can trigger difficulty adjustments. If the amount of space increases, more than 32 blocks per slot will be created, so the difficulty has to be increased. If the network VDF speed increases, more than 32 blocks are created every 10 minutes, and thus the difficulty (and the sub-slot iterations) has to be increased. + +A farmer with exclusive access to a slightly faster VDF, however, cannot easily get more rewards than a farmer with the normal speed VDF. If an attacker tries to orphan one of the blocks on the chain, having a faster VDF will not help, since the attacker's chain will have fewer blocks (and thus a lower weight). Farmers must sign the block which they are building on top of, and they will only build on top of the highest weight chain. + +The VDF speed comes into play when the attacker wishes to launch a 51% attack, however. In this case, an attacking farmer can use the VDF to create a completely alternate chain with no honest blocks, and overtake the honest chain. This requires 42.7% of the total netspace, since the faster VDF chain can obtain weight at a faster rate than the honest chain. This attack is described in detail in the [Attacks and Countermeasures page](/chia-blockchain/consensus/attacks-and-countermeasures#faster-timelord). 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 new file mode 100644 index 00000000000..b72aa57628f --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/signage-and-infusion-points.md @@ -0,0 +1,137 @@ +--- +title: Signage and Infusion Points +slug: /chia-blockchain/consensus/chains/signage-and-infusion-points +--- + +Each sub-slot in both the challenge chain and the reward chain is divided into 64 smaller VDFs. Between each of these smaller VDFs is a point called a **signage point**. Timelords publish the VDF output and proof when they reach each signage point. + +:::info + +The challenge and reward chains both have signage points. The infused challenge chain, however, does not. + +::: + +The signage points occur every 9.375 seconds (64 signage points per 600-second sub-slot). The number of iterations between each signage point is **_sp_interval_iterations_**, which is equal to _sub-slot_iterations / 64_. + +The challenge at the start of the sub-slot is also a valid signage point. As each of the 64 signage points in the sub-slot is reached, those points are broadcast, starting from the fastest timelord's full node, and propagating to every other full node on the network. + +Farmers receive these signage points and compute a hash for each plot, at each signage point. If the hash starts with nine zeros, the plot passes the filter for that signage point, and can proceed. This disqualifies around 511/512 of all plot files in the network, for that signage point. The formula to compute the filter hash is: + +``` +plot filter bits = sha256(plot id + sub slot challenge + cc signage point) +``` + +The proof of space challenge is computed as the hash of the plot filter bits: + +``` +PoSpace challenge = sha256(plot filter bits) +``` + +Using this challenge, the farmers fetch quality strings for each plot that made it past the filter. Recall that this process requires around seven random disk seeks, which takes around 70 ms on a slow HDD. The quality string is a hash derived from part of the proof of space (but the whole proof of space has yet to be retrieved). + +:::info + +For both of our [previous example](/chia-blockchain/consensus/chains/challenges), as well as the next example, we'll use the following values: + +::: + +- _sub-slot_iterations = 100,000,000_ +- _sp_interval_iterations = sub-slot_iterations / 64 = 1,562,500_ + +The farmer computes the **_required_iterations_** for each proof of space. If the _required_iterations < sp_interval_iterations_, the proof of space is eligible for inclusion into the blockchain. At this point, the farmer fetches the entire proof of space from disk (which requires 64 disk seeks, or 640 ms on a slow HDD), creates an unfinished block, and broadcasts it to the network. + +:::info +For the vast majority of eligible plots, _required_iterations_ will be far too high, since on average 32 will qualify for the whole network for each 10-minute sub-slot. This is a random process so it's possible (though unlikely) for a large number of proofs to qualify. Any plot that does meet the _required_iterations_ for a signage point will qualify as there is no rivalry between winning plots. +::: + +The exact method for required_iterations is the following: + +```python +sp_quality_string = sha256(quality_string + cc_signage_point) +required_iterations = (difficulty + * difficulty_constant_factor + * int.from_bytes(sp_quality_string, "big", signed=False) + // (pow(2, 256) * expected_plot_size(size))) +``` + +The difficulty constant factor is based on the initial constants of the blockchain. For Chia, it is _2^67_. The difficulty varies per epoch, as explained in [Section 3.11](/chia-blockchain/consensus/chains/epoch-and-difficulty.md) 'Section 3.11: Epochs and Difficulty Adjustment'). As you can see, the `sp_quality_string` is converted into a random number between 0 and 1, by dividing it by _2^256_, and then multiplied by the plot size. + +For consensus purposes, the `expected_plot_size` is `((2 * k) + 1) * (2 ** (k - 1))`, where `k>=32<50`. The actual plot size is that value times a constant factor, in bytes. This is because each entry in the plot is around `k+0.5` bits, and there are around `2 ** k` entries. + +The _signage_point_iterations_ is the number of iterations from the start of the sub-slot to the signage point. + +The _infusion_iterations_ is the number of iterations from the start of the sub-slot at which the block with at least the required quality can be included into the blockchain. This is calculated as: + +``` +infusion_iterations = ( signage_point_iterations + 3 * sp_interval_iterations + required_iterations) % sub-slot_iterations +``` + +Therefore, _infusion_iterations_ will be between 3 and 4 signage points after the current signage point. Farmers must submit their proofs and blocks before the infusion point is reached. The modulus is there to allow overflows into the next sub-slot, if the signage point is near the end of the sub-slot. This is expanded on in [Section 3.9](/chia-blockchain/consensus/chains/overflow-blocks.md) 'Section 3.9: Overflow Blocks and Weight'). + +:::info +More information on infusion points is available in the [VDFs page](/chia-blockchain/consensus/proof-of-time#infusion). +::: + +
+drawing
+Figure 5: timelords create proofs for both the signage point and the infusion point. But they only infuse (change the VDF classgroup) for the latter. Squares symbolize infusions, where a new VDF is started. +
+
+ +Figure 5 shows the infusion point as a green square marked `b1`. The first and last blocks of the sub-slot are marked `r1` and `r2`, respectively. For this example, the farmer will create the block at the time of the signage point marked with a red arrow, which we'll call `b1'`. + +At `b1`, the farmer's block gets combined with the VDF output for that point. This creates a new input for the VDF from that point on, i.e. we infuse the farmer's block into the VDF. `b1` is only fully valid after two events have occurred: + +1. _infusion_iterations_ has been reached, and +2. Two VDF proofs have been included: one from `r1` to the signage point and one from `r1` to `b1`. (Actually it's more since there are three VDF chains, explained in [Section 3.8](/chia-blockchain/consensus/chains/three-vdf-chains.md) 'Section 3.8: Three VDF Chains')). + +In Figure 5, the farmer creates the block at the time of the signage point, `b1'`. However, `b1'` is not finished yet, since it needs the infusion point VDF. Once the _infusion_iterations_ VDF has been released, it is added to `b1'` to form the finished block at `b1`. + +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_. + +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. + +_infusion_iterations_ is then computed as: + +``` +infusion_iterations = signage_point_iterations + (3 \* sp_interval_iterations) + required_iterations +``` + +After realizing they have won (at the 20th infusion point), the farmer fetches the whole proof of space, makes a block (optionally including transactions), and broadcasts this to the network. The block has until _infusion_iterations_ (typically a few seconds) to reach timelords, who will infuse the block, creating the infusion point VDFs. With these VDFs, the block can be finished and added to the blockchain by full nodes. + +## Rationale for choosing 64 signage points + +Chia's original consensus, which was phased out before the launch of mainnet, used a single signage point per 10-minute subslot. This left the network vulnerable to short-range [replotting attacks](/chia-blockchain/consensus/attacks-and-countermeasures#replotting), where an attacker initiates a plot's creation after a signage point, and completes the plot before the next infusion point. The attacker could always choose a plot that passes the plot filter (because the signage point is hashed with the subslot challenge and the plot ID in calculating the filter) and then delete the plot after the infusion point. For a 512-filter, this would result in the attacker mimicking 512 plots (~51 TiB). In reality, under the original consensus, they would only need to own single computer capable of creating a plot in less than ten minutes. + +:::note +Technically this isn't an _attack_ because -- even if successful -- the "attacker" wouldn't gain an ability to cheat the network. However the "attacker" _would_ be using the network in an unintended way, effectively turning Chia into a Proof of Work system. Therefore, Chia's new consensus was intentionally designed to discourage this behavior. +::: + +The new consensus was introduced during Chia's beta phase. One of the modifications was to increase the number of signage points to 64 per 10-minute subslot, or one every 9.375 (600/64) seconds, on average. The Challenge Chain was also introduced (see the [Three VDF Chains page](/chia-blockchain/consensus/chains/three-vdf-chains.md) for more info). The maximum distance between a signage point and the next infusion point is now 4 signage points (see the _infusion_iterations_ formula, above), or 37.5 seconds. This is the maximum amount of time for the attack to be possible, but for it to be consistently applied, the minimum time of 28.125 seconds must be applied. Assuming a few extra seconds for network latency and other factors, the attack is now only possible if one can create a new plot in less than 25 seconds. + +:::note +Keep in mind that this "attack" is really mimicking the ownership of around 51 TiB of storage. Even when it does become possible to run the attack consistently, it will likely be much cheaper to use the network as intended, storing plots on non-volatile storage. +::: + +This begs the question: why not use even more signage points in the consensus? The simple answer is because as the signage points increase, it becomes more difficult for the timelords and nodes to keep up with the network. Sixty-four signage points per subslot was deemed enough to discourage the attack laid out above, while still allowing the timelords and nodes to perform as intended and to stay in sync. + +## Definitions + +**Quality string**: A small part of the proof of space, 2 _x values_ out of the total 64 _x values_, which can be retrieved efficiently from disk, and which values_to_fetch is determined by the signage point. + +**_sp_quality_string_**: A hash of the quality string concatenated with the challenge chain's signage point. This hash is what ultimately decides the "luck" of a certain proof, using the size of _required_iterations_ + +**_sp_interval_iterations_**: Defined as _floor(sub-slot_iterations / 64)_. + +**Signage points**: 64 intermediary points in time within a sub-slot in both the challenge and reward chains, for which VDFs are periodically released. At each signage point, a VDF output is created and broadcast through the network. The first signage point in the sub-slot is the challenge itself. Each block has a signage point such that the proof of space in the block must be eligible for that signage point. + +**_required_iterations_**: A number computed using the quality string, used to choose proofs of space which are eligible to make blocks. The vast majority of proofs of space will have _required_iterations_ which are too high, and thus not eligible for inclusion into the chain. This number is used to compute the infusion point. + +**Infusion point**: The point in time at _infusion_iterations_ from the challenge point, for a proof of space with a certain challenge and _infusion_iterations_. At this point, the farmer's block gets infused into the reward chain VDF. The infusion point of a block is always between 3 and 4 signage points after the signage point of that block. Computed as _signage_point_iterations + 3 \* sp_interval_iterations + required_iterations_. + +The delay between the signage point and infusion point has many benefits, including defense against orphaning and selfish farming, decreased forks, and no VDF pauses. This delay of around 28 seconds is given so that farmers have enough time to sign without delaying the slot VDF. Well-behaving farmers sign only one signage point with each proof of space, meaning that attackers cannot easily reorg the chain. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/three-vdf-chains.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/three-vdf-chains.md new file mode 100644 index 00000000000..eb7c75c6570 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/chains/three-vdf-chains.md @@ -0,0 +1,75 @@ +--- +title: Three VDF Chains +slug: /chia-blockchain/consensus/chains/three-vdf-chains +--- + +If we only used one VDF (for the reward chain), the inclusion or exclusion of blocks would allow control of the challenge for the next slot. This means that an attacker could try many different combinations of blocks, and choose the challenge that suits them best, to obtain more wins in the next slot. + +These types of attacks are called grinding attacks, and they are one of the main difficulties of changing from Proof of Work to Proof of Space or Proof of Stake. More detail is provided in the [Attacks and Countermeasures page](/chia-blockchain/consensus/attacks-and-countermeasures). + +To mitigate this, the challenges will be based only on the first block to be infused in a slot. + +
+drawing
+Figure 8: The three VDF chains for 1+ challenges. + +cc = challenge chain, ic = infused challenge chain, rc = reward chain, + +sp = signage point, B = block, c = challenge, r = reward + +An attacker can manipulate the reward chain results but this has no effect on c2, and therefore has no effect on the PoSpace lottery. + +
+
+ +There is a lot going on in this diagram! Let's break it down. + +There are 4 **blocks**: B1, B2, B3, and B4. Farmers create these blocks. The blocks have pointers (the arrows), and the data the pointers are pointing to is all contained within the blocks themselves. At least 16 blocks have been created in the diagram's sub-slot, but we don't draw all of them due to space constraints. + +The challenge chain and the reward chain each create 64 signage points, released every 9.375 seconds (on average) by timelords. Blocks must include the signage point VDFs (which mark the signage points) for both chains. + +The timelords send their VDF output to their full node, which adds it into an EndOfSubSlotBundle. This bundle includes the output from each chain (for example c1, ic1, and r1 in the diagram). The bundle is propagated to all other full nodes. Blocks must also include the infusion point VDFs for all three chains. + +The challenge chain broadcasts the challenges (c1 and c2). The same chain also executes the VDF from the start of the sub-slot to the end with nothing infused into it (the circles are VDF proofs but they do not interrupt the VDF). That is, in the challenge chain, the "lottery" is completely pre-determined, and not affected by blocks in the slot, until the end of the slot. + +The reward chain infuses every block that is included. + +The chain in the middle is called the **infused challenge chain**. It starts at the first infused block for each challenge, and goes on until the end of the slot. + +Recall that a **slot** must have at least 16 reward-chain blocks. A sub-slot doesn't have a minimum number of blocks (though it targets 32 blocks). Instead, a sub-slot always ends when sub-slot_iterations has been reached (this is targeted to take 10 minutes). + +Because a sub-slot is targeted to produce more than 16 blocks, a slot usually only needs one sub-slot to meet its minimum-block requirement, but that is not always the case. For example, we may have only 10 blocks in a sub-slot, and then 3 and then 7, which means those three sub-slots form one slot. The **deficit** is the number of blocks still necessary to end the slot: this is described in more detail in the [Overflow Blocks and Weight page](/chia-blockchain/consensus/chains/overflow-blocks.md#minimum-block-requirement). + +At the end of the slot, the challenge chain is combined with the infused challenge chain to generate the new challenge c2, which is used to start the challenge chain for the next sub-slot. + +The only block which affects the challenge chain (and thus the PoSpace lottery) is the first block in the slot, which here is B1. In fact, it's only a deterministic part of B1 called "cc B1", which only depends on challenge chain data. An attacker who wants to grind cannot change the challenge by withholding B2, B3, or any other block apart from the first one. + +An honest farmer who holds the first block (B1) will release it. If an attacker controls the first block (B1), they have two additional options: delay it or withhold it. + +- Delay it: In order to know whether the new challenge will benefit them, they will need to execute the VDF all the way up to c2. By that time, their chance to get included in the reward chain is gone, since honest farmers sign only one block per proof of space. +- Withhold it: This does not provide much benefit to the attacker, since they must release it before sp2 in order to get the farmers on their chain. Farmers will choose the heaviest chain, which is the one with the most (heaviest) reward chain blocks. + +Why do we commit to any blocks at all in the challenge chain? If we did not, an attacker with a faster VDF could look ahead, since they would not need the help of honest participants in order to compute the challenge chain into the future. The challenge chain would be totally deterministic. This would enable some advantage by replotting. Furthermore, the challenge chain can be used to probabilistically prove the weight of the reward chain to light clients, without sharing all reward chain blocks (since the challenge chain depends on the "best" block in the slot, you can calculate the number of reward chain blocks). + +For a block to be considered valid, it has to provide VDFs for the challenge chain and reward chain, and optionally for the infused challenge chain if it is present. Forcing all VDFs to be included means that all three chains are guaranteed to move forward at the same rate. + +## Definitions + +**Challenge chain**: The VDF chain based on each challenge for each sub-slot, which does not infuse anything in the middle of each sub-slot. The challenges are also used for the proofs of space. The signage points in this chain are used for the SP filter. + +**Reward chain**: The VDF chain that contains infusions of all blocks. This chain pulls in the challenge chain, and optionally, the infused challenge chain at the end of each sub-slot. + +**Infused challenge chain**: A VDF chain which starts at the first block infused in a slot (which is not based on the previous slot's challenge, this is called the challenge block) and ends at the end of the slot. +This increases security by preventing VDF lookahead attacks. + +**Sub-slot**: a period of time for which a timelord must run a VDF. The number of calculations the timelord must perform (sub-slot_iterations) to complete the sub-slot are adjusted periodically (and automatically) to take around 10 minutes. During this time, 64 signage points will be released and the entire network will submit an average of 32 valid proofs of space. + +**Slot**: one or more sub-slots. The important thing to remember is that a slot requires at least 16 reward-chain blocks. If these blocks are not produced in the first sub-slot, then another sub-slot will be required within the same slot. At the end of the slot, the infused challenge chain stops, the challenge chain pulls in the result of the infused challenge chain, and the deficit is reset to 16. + +**Block**: a block is a collection of data infused into the rewards chain which contains: a proof of space for a challenge hash with fewer iterations than the slot iterations, signage point and infusion point VDFs for both chains, optional infusion point VDF for the infused challenge chain, and a rewards address. Some blocks are also transaction blocks. There is a maximum of 128 blocks per slot. + +**Transaction Block**: A block that is eligible to create transactions, along with an associated list of transactions. + +**Challenge block**: The first block to be infused in each slot, which is not based on a previous slot's challenge. The challenge block always has a deficit of 15, and always starts off the infused challenge chain. + +**Peak**: The peak of the blockchain as seen by a node is the block with the greatest weight. Weight is the sum of the difficulty of a block and all its ancestors, which is similar to height, but a shorter chain can have heavier weight, due to difficulty adjustments. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/consensus-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/consensus-intro.md new file mode 100644 index 00000000000..d9b94ca0b2d --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/consensus-intro.md @@ -0,0 +1,25 @@ +--- +title: Consensus Introduction +slug: /chia-blockchain/consensus/consensus-intro +--- + +:::info + +This section is meant to provide a high level overview of Chia's consensus. If you are interested in implementing a new full node, we recommend that you review the [source code](https://github.com/Chia-Network/chia-blockchain/tree/main/chia/consensus) in order to understand in depth how the consensus is implemented. If you have further questions, feel free to reach out to us on [Discord](https://discord.gg/chia). + +::: + +Decentralized consensus algorithms require Sybil resistance, using a resource that is both cryptographically verifiable and scarce (not infinite). In previous blockchain systems, two different scarce resources have been used: computing power (Proof of Work) and staked money (Proof of Stake). + +Chia's Proof of Space and Time consensus uses storage capacity as the scarce resource. This comes much closer than previous systems to Satoshi's original ideal of "one CPU, one vote," where a _vote_ refers to a chance to win and validate a block, not an actual vote on-chain. For example, someone storing 500 GiB has 5 "votes," and someone storing 100 GiB has 1 "vote." + +One other cryptographic puzzle piece is used to secure Chia's system: a verifiable delay function (VDF), which is a cryptographic proof that real time has passed. + +A fair system can be created by combining proofs of space and time. In such a system, users store random-looking data on their hard drives. Their chance to win XCH is proportional to their allocated space. Furthermore, such a system scales to billions of participants in a similar way to the Proof of Work lottery. No funds, special hardware, registration, or permission is required to join, only a hard drive and an internet connection. The system is completely transparent and deterministic -- anyone can efficiently and objectively verify which chain is the canonical one, without relying on any trusted parties. + +Some notes to keep in mind as you continue reading: + +- Whenever the word _signature_ is used, it refers specifically to a deterministic BLS signature, following the IETF specification with the Augmented scheme. +- The private keys performing these digital signatures are controlled and stored by the farmers. +- A unique private key is used for each plot. +- The hash function used is SHA256, except for the proofs of space which also use CHACHA8 and BLAKE3. 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 new file mode 100644 index 00000000000..f09936cacfe --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/forks.md @@ -0,0 +1,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. + +| 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 | 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 new file mode 100644 index 00000000000..df3f6c0a587 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-1.0.md @@ -0,0 +1,70 @@ +--- +title: Proof of Space +slug: /chia-blockchain/consensus/proof-of-space-1.0 +--- + +A Proof of Space protocol is one in which: + +- A Verifier can send a challenge to a Prover. +- The Prover can demonstrate to the Verifier that the Prover is reserving a specific amount of storage space at that precise time. + +The Proof of Space protocol has three components: plotting, proving/farming, and verifying. For more info, see our [Details of the chiapos specification](https://www.chia.net/wp-content/uploads/2022/09/Chia_Proof_of_Space_Construction_v1.1.pdf), and [reference implementation](https://github.com/Chia-Network/chiapos). + +![chia-architecture](/img/pospace.png) + +## Plotting + +Plotting is the process by which a Prover, who we refer to as a _farmer_, initializes a certain amount of space. To become a farmer, one must have at least 101.4 GiB available to reserve on their computer (the minimum spec is a [Raspberry Pi 4](/reference-client/install-and-setup/installation#raspberry-pi)). There is no upper limit to the size of a Chia farm. Several farmers have multi-PiB farms. + +As of Chia 1.2.7, a k32 plot can be created in around five minutes with a high-end machine with 400 GiB of RAM, or six hours with a normal commodity machine, or 12 hours with a slow machine using one CPU core and a few GB of RAM. Opportunities still remain for huge speedups. Furthermore, each plot only needs to be created once; a farmer can farm with the same plots for many years. + +Plot sizes are determined by a k parameter, where `space = 780 * k * pow(2, k - 10)`, with a minimum k of 32 (101.4 GiB). The Proof of Space construction is based on [Beyond Hellman](https://eprint.iacr.org/2017/893.pdf "Beyond Hellman's Time-Memory Trade Offs with Applications to Proofs of Space"), but it is nested six times (thereby creating seven tables), and it contains other heuristics to make it practical. + +Each of the seven tables in a plot is filled with random-looking data that cannot be compressed. Each table has 2^k entries. Each entry in table i contains two pointers to table i-1 (the previous table). Finally, each table-1 entry contains a pair of integers between 0 and 2^k, called "x-values." A proof of space is a collection of 64 x-values that have a certain mathematical relationship. The actual on-disk structure and the algorithm required to generate it are quite [complicated](https://www.chia.net/assets/Chia_Proof_of_Space_Construction_v1.1.pdf), but this is the general idea. + +
+drawing
+Figure 2: Structure of a plot file. The 64 red x-values represent the proof, the 2 green x-values represent the quality. +
+
+ +Once the Prover has initialized 101.4 GiB, they are ready to receive a challenge and create a proof. One attractive property of this scheme is that it is non-interactive unless the farmer chooses [plot NFT style pooling](/chia-blockchain/architecture/pools): no registration or online connection is required to create a plot using the original plot format. Nothing hits the blockchain until a reward is won, similar to PoW. For pool portable plots, a farmer only needs a few mojos to create a plot NFT before plotting and then everything has the same characteristics from there. + +See the [Plotting FAQ page](/reference-client/troubleshooting/plotting-faq) for more info. + +## Farming + +Farming is the process by which a farmer receives a sequence of 256-bit challenges to prove that they have legitimately put aside a defined amount of storage. In response to each challenge, the farmer checks their plots, generates a proof, and submits any winning proofs to the network for verification. + +For each eligible plot (explained later), a farmer uses the following procedure to generate a full proof of space. Keep in mind that a plot consists of 7 tables (T1-T7) of approximately the same size, as well as 3 checkpoint tables (C1-C3), which are much smaller: + +1. The farmer receives a challenge from the VDF +2. For each eligible plot, extract a k-sized value from the challenge, where _k_ denotes the size of the plot (k32, k33, etc) +3. Look in the C2 table for a location at which to start scanning the C1 table +4. Scan the C1 table for the location at which to start scanning the C3 table +5. Read either one or two C3 parks. The number of parks to read depends on the index and value calculated from the C1 table. This requires an average of 5000 reads (the maximum is 10 000). These are sequential reads of 4 bytes (for an average total of 20 KiB) +6. Grab all the f7 entries matching the challenge value (which can be 0 or more), along with the index in the table at which they were found +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](/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. + +:::info +Throughout this website, we'll make a simple assumption that a single disk seek requires 10ms. In reality, this is typically 5-10ms, so we're using a conservative estimate. + +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](/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. + +Each plot file has its own unique private key called a _plot key_. The plot ID is generated by hashing the plot public key, the farmer public key, and either the pool public key (for OG plots) or the pool contract puzzle hash (for pooled plots). The requirements for signing a proof of space depend on the type of plots being used. See the [Plot Public Keys page](/chia-blockchain/keys/plot-public-keys) for details on the keys used for plot construction. + +In practice, the plot key is a 2/2 BLS aggregate public key between a local key stored in the plot and a key stored by the farmer software. For security and efficiency, a farmer may run on one server using this key and signature scheme. This server can then be connected to one or more harvester machines that store the actual plots. Farming requires the farmer key and the local key, but it does not require the pool key, since the pool's signature can be cached and reused for many blocks. + +## Verifying + +After the farmer has successfully created a proof of space, the proof can be verified by performing a few hashes and making comparisons between the x-values in the proof. Recall that the proof is a list of 64 x-values, where each x-value is k bits long. For a k32 this is 256 bytes (2048 bits), and is therefore very compact. Verification is very fast, but not quite fast enough to be verified in Solidity on Ethereum (something that would enable trustless transfers between chains), since this verification requires blake3 and chacha8 operations. 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 new file mode 100644 index 00000000000..6190ddb7ae3 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md @@ -0,0 +1,141 @@ +--- +sidebar_label: FAQ +title: FAQ +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +This information was updated on 5/20/2025. + +::: + +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 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)). + +### 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)). + +### 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? + +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). + +### 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) + +### 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. + +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. + +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. + +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. + +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. + +See our [farming requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements) for more detailed information. + +### What is the difficulty level in the new format? + +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. + +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.) + +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. + +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. + +### 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. + +### 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. + +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. + +### How many times will I have to replot? + +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. + +### 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. + +### 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. + +### 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. + +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. + +### 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. + +### When can I review the source code for plotting? + +The source code is located in the [pos2-chip](https://github.com/Chia-Network/pos2-chip) GitHub repository. + +### 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). + +### 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. + +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. + +### 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. + +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 new file mode 100644 index 00000000000..548642916cc --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md @@ -0,0 +1,40 @@ +--- +sidebar_label: Farming Requirements +title: Farming Requirements +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +This information was updated on 5/20/2025. + +::: + +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. + +:::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 + +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. + +| Plot Size | Full 5TiB Disk Activity | Full 20TiB Disk Activity | +| --------- | -------------------------------------- | ------------------------------------- | +| k28 | ~2.5% | ~10% | +| k30 | ~0.6% | ~2.4% | +| k32 | ~0.23% | ~0.9% | 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 new file mode 100644 index 00000000000..073d84cde05 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md @@ -0,0 +1,56 @@ +--- +sidebar_label: Introduction +title: Introduction +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +This information was updated on 5/20/2025. + +::: + +## 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. + +:::warning + +The documents in this section describe a technology that is still being developed. Everything you read here is subject to change. + +::: + +While the development of this technology is ongoing, we have put together several documents to answer all of your questions: + +## 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 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) + +:::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. +::: + +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: + +- A list of the expected [plotting requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements) +- A list of the expected [farming requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements) +- A [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline) of when we expect to reach each milestone +- A list of [frequently asked questions](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq) +- An [overview](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-overview) of the new format +- The [technical details](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-details/) of the new format + +## 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. 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 new file mode 100644 index 00000000000..24d06562354 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md @@ -0,0 +1,43 @@ +--- +sidebar_label: Plotting Requirements +title: Plotting Requirements +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +This information was updated on 5/20/2025. + +::: + +## 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. + +:::note +Subject to change pending final parameters. +::: + +| Plot Size | All RAM | +| :-------- | :------------------------------------------------- | +| k32 | ~10.6 GiB | +| k30 | ~4.2 GiB | +| k28 | ~1.6 GiB | + +## 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. + +:::note +Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day +::: + +| 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 | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-details.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-details.md new file mode 100644 index 00000000000..3bc4870dbe2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-details.md @@ -0,0 +1,15 @@ +--- +sidebar_label: Technical Details +title: Technical Details +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-details +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +This information was removed on 5/20/2025. While the CHIP for the specification is being finalized. +For the latest information, refer to [CHIP-48](https://github.com/Chia-Network/chips/pull/160) + +::: diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-overview.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-overview.md new file mode 100644 index 00000000000..599753058aa --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-overview.md @@ -0,0 +1,15 @@ +--- +sidebar_label: Technical Overview +title: Technical Overview +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-technical-overview +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +This information was removed on 5/20/2025. While the CHIP for the specification is being finalized. +For the latest information, refer to [CHIP-48](https://github.com/Chia-Network/chips/pull/160) + +::: 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 new file mode 100644 index 00000000000..eb96cccca66 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md @@ -0,0 +1,24 @@ +--- +sidebar_label: Timeline +title: Timeline +slug: /chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline +--- + +import Tabs from '@theme/Tabs'; +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 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 | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-time.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-time.md new file mode 100644 index 00000000000..b8d87968aa3 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/proof-of-time.md @@ -0,0 +1,38 @@ +--- +title: Proof of Time (VDFs) +sidebar_label: Proof of Time +slug: /chia-blockchain/consensus/proof-of-time +--- + +A Verifiable Delay Function, also referred to as a Proof of Time or VDF, is a proof that a sequential function was executed a certain number of times. + +**Verifiable**: This means that after performing the computation (which takes time), the Prover can create a very small proof in a very short time, and the Verifier can verify this proof without having to redo the whole computation. + +**Delay**: This means that the Prover actually spent a real amount of time (although we don't know exactly how much) to compute the function. + +**Function**: This means it's deterministic: computing a VDF on an input x _always_ yields the same result y. + +The key word here is "sequential", like hashing a number many times: hash(hash(hash(a))), etc. This means the prover cannot just add more machines to make the function execute faster. Therefore we can assume that computing a VDF requires real (wall-clock) time. The construction that we use is repeated squaring. The Prover must square a challenge x T times. This requires time ϴ(T). The Prover also must create a proof that this was performed properly. + +
+drawing
+Figure 3: The Verifier (blockchain) sends a challenge to the Prover (timelord) and the Prover computes the output and proof. +
+
+ +Although the following details are not very important for understanding the consensus algorithm, the choice of what VDF to use is relevant, because if an attacker succeeds in obtaining a much faster machine, some [attacks](/chia-blockchain/consensus/attacks-and-countermeasures) become possible. + +The VDF used by Chia is repeated squaring in a [class group of unknown order](https://github.com/Chia-Network/vdf-competition/blob/main/classgroups.pdf). There are two main ways to generate a large group that has an unknown order: + +1. Use an RSA modulus, and use the integers mod N as a group. The order of the group is unknown if you can generate your modulus with many participating parties using an MPC ceremony. +2. An easier approach is to use classgroups with a large prime discriminant, which are groups of unknown order. This does not require any complex or trusted setup, so we chose this option for Chia. + +To create one of these groups, one just needs a large, random, prime number. The drawbacks are that classgroup code is less tested in real life, and optimizations are less well-known than in RSA groups. We use the same initial element for the squaring (a=2, b=1 classgroup element), and instead use the challenge to generate a new random prime number for each VDF, which is used as the discriminant. The discriminant has a size of 1024 bits, which means the proof sizes are around 1024 bits. We use the [Wesolowski scheme](https://eprint.iacr.org/2018/623) split into n (1\<=n\<=64) phases so that creating the proofs is very fast. Since the n-wesolowski proofs can be large, we replace them with 1-wesolowski proofs as soon as they are available. These are smaller, but require more time to make. The proofs themselves are not committed to on-chain, so they are replaceable. + +### Infusion + +As a recap, VDFs take in an input, called a _challenge_, and produce an output, together with a proof that certifies that the function was evaluated correctly. + +A _value_, in this context, can be thought of as a block with a proof of space. The value is combined with an output of a VDF, to generate a new value, which is used as the input/challenge for the next VDF. This is known as an _infusion_ of a value into a VDF. + +Therefore, we are chaining VDFs, but committing to a new value in between. This is used so that we have a linear progression of blocks, alternating proofs of space with proofs of time. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/timelords.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/timelords.md new file mode 100644 index 00000000000..23b99100f07 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/consensus/timelords.md @@ -0,0 +1,24 @@ +--- +title: Timelord Algorithm +slug: /chia-blockchain/consensus/timelords +--- + +A timelord keeps track of the current peak, which includes an infused block at a certain height, and signage points from the peak onward. A timelord might receive new blocks to infuse, new peaks (blocks which are already infused), or new signage points. + +:::info +For more info, see the [Challenges page](/chia-blockchain/consensus/chains/challenges). +::: + +How does a timelord decide which challenges to create proofs of time on, given a limited number of available processors? It's important to emphasize that even though the fastest timelords are now ASICs, any user with a CPU can be a timelord, to provide fallbacks in the unlikely case that each of the ASIC timelords go down, or becomes malicious, etc. + +In general, timelords work on the heaviest chain. They create proofs of time at the signage points, and broadcast these to the network as they are reached. Timelords also infuse blocks as often as they can. When the timelord receives an infused block which has a greater weight than the current peak, they switch to it immediately. + +Timelords also run the [three VDF chains](/chia-blockchain/consensus/chains/three-vdf-chains.md) in parallel. Therefore, at least three fast CPU cores are necessary to advance the blockchain at an efficient rate. Extra CPU cores will be necessary to create proofs, but they do not have to be as fast. + +If the timelord receives a challenge with less weight than their current peak, they ignore it. If the timelord receives a challenge point later in the current chain, they do the safe thing: ignore it. The reason is that by switching to a point further in the future, the timelord might be skipping the infusion of blocks, and thus orphaning valid blocks. + +If the timelord receives a block for infusion which is late (we have already reached the challenge point at which the block should have been infused), the timelord ignores the block, since infusing to it would allow attackers to instigate a withholding attack, in an attempt to re-org or DoS the chain. + +Therefore, the main operation of the timelord involves keeping a cache of future blocks to infuse, broadcasting challenge points when they are reached, and infusing blocks when they reach their challenge points. + +If the timelord receives a challenge with the same weight as the current peak, they choose the unfinished block which they saw first (that is, the block that has not been infused yet), as opposed to choosing the infused block (peak) which they saw first. This also disincentivizes the withholding of blocks. 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 new file mode 100644 index 00000000000..9e20289ba8e --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/constants-variables-notation.md @@ -0,0 +1,48 @@ +--- +title: 常数、变量和符号 - Chia绿皮书 +sidebar_label: 0 - 常数、变量和符号 +slug: /chia-blockchain/green-paper/constants-variables-notation +--- + +# 0 - 常数、变量和符号 + +## 0.1 重要常数 + +| 常数 | Description | +| -------- | ------------------------------------------ | +| 10分钟 | target **duration of a sub-slot** | +| 32个区块 | target **number of blocks per sub-slot** | +| 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** | + +由上可得以下结论： + +| 隐含的常数 | 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个区块的目标 | +| $T\in {\mathbb N}$ | 时间参数（子时隙的VDF步数）。 每个纪元重新校准一次，以满足每个子时隙10分钟的目标 | + +## 0.3 提示 + +:::info Objective 0: +We will use blue boxes like this one to mention key objectives we want the design of Chia to satisfy +::: + +:::tip Design Choice 0: +Green boxes like this are used to highlight important design choices, which often will refer to objectives. +::: + +:::danger Security Notice 0: +A red box stresses some important aspects required for the security of Chia, and will typically refer to some design choice. +::: 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 new file mode 100644 index 00000000000..9f0a8084d3b --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-abstract.md @@ -0,0 +1,23 @@ +--- +title: 摘要 - Chia绿皮书 +sidebar_label: 摘要 +slug: /chia-blockchain/green-paper/green-paper-abstract +--- + +# 绿皮书 + +## 摘要 + +本文概述了 $\textrm{{\sf Chia}}$ 的共识层背后的基本设计思想和原理，$\textrm{{\sf Chia}}$ 是一种类似于比特币的最长链区块链。 它通过结合空间证明（Proofs of Space）和可验证延迟函数(Verifiable Delay Functions，VDF)实现了与比特币基于工作量证明(Proof of Work，PoW)的中本聪共识相当的安全性保障，同时实现了防止女巫攻击（Sybil resistance）。 This makes $\textrm{{\sf Chia}}$ much more [sustainable](https://chiapower.org/) and also more [decentralized](https://xch.farm/decentralization/) than a PoW based blockchain could be. + +我们概述了在用空间证明等高效证明系统替代工作量证明时必须解决的挑战，以及在 $\textrm{{\sf Chia}}$ 中如何解决这些挑战。 Here _efficient_ means that once the resource (like space or stake) is available, computing many proofs is basically as cheap as computing one. + +本文不是 $\textrm{{\sf Chia}}$ 的正式规范。 相反，它面向那些希望理解 $\textrm{{\sf Chia}}$ 共识设计选择的读者，以及对来自高效证明系统的无需许可的最长链区块链感兴趣的人。 + +[Green Paper PDF](https://docs.chia.net/files/ChiaGreenPaper_20241008.pdf) - updated October 8, 2024 + +--- + +### 先前版本共识绿皮书 + +In order to provide historical context, the Green Paper's previous version that discusses a precursor consensus which was never implemented is available here for viewing: [Precursor Green Paper](https://docs.chia.net/files/Precursor-ChiaGreenPaper.pdf). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-appendix.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-appendix.md new file mode 100644 index 00000000000..c4e208d8cd5 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-appendix.md @@ -0,0 +1,180 @@ +--- +title: Appendix - Chia Green Paper +sidebar_label: A - Appendix +slug: /chia-blockchain/green-paper/green-paper-appendix +--- + +# A - Building Blocks: PoSpace, VDFs and Signatures + +In this section we sketch the main building blocks used in the $\textsf{Chia}$ blockchain: unique digital signatures, proofs of space [DFKP15; AAC+17] and verifiable delay functions [Pie19b; BBBF18; Wes20]. The definitions are not fully general, but instead tailored to the particular constructions of PoSpace from [AAC+17] and the VDFs [Pie19b; BBBF18; Wes20] based on sequential squaring. + +## A.1 (Unique) Digital Signatures + +A digital signature scheme is specified by three algorithms; a (probabilistic) key-generation algorithm ${{\sf Sig.keygen}}$, a signing algorithm $\mu\gets {{\sf Sig.sign}}(sk,m)$ and a verification algorithm ${{\sf Sig.verify}}$. We assume the standard security notion (unforgeability under chosen message attacks) and perfect completeness, that is, a correctly generated signature will always verify: + +$$ +\begin{aligned} +\forall m,&& +\Pr[{{\sf Sig.verify}}(pk,m,\mu)={\sf accept}]=1\\ +\textrm{where}&&(pk,sk)\gets{{\sf Sig.keygen}}\ ;\ \mu\gets{{\sf Sig.sign}}(sk,m)~. +\end{aligned} +$$ + +$\textsf{Chia}$ uses signatures in the foliage (to chain foliage blocks and to bind them to the trunk) and also in the trunk (so only the farmer can compute the challenge). To avoid grinding attacks, the signatures used in the trunk must be unique, that is for every $pk$ (this includes maliciously generated public keys) and message $m$ there can be at most one accepting signature + +$$ +\forall pk,m,\ +({{\sf Sig.verify}}(pk,m,\mu)={\sf accept})\wedge +({{\sf Sig.verify}}(pk,m,\mu')={\sf accept})\Rightarrow (\mu=\mu')~. +$$ + +## A.2 (Unique) Proofs Of Space + +### A.2.1 Algorithms for PoSpace + +A proof of space is specified by the four algorithms given below + +##### $\textsf{PoSpace.init}$ + +> on input a space parameter $N\in{\cal N}$ (where ${\cal N}\subset \mathbb{Z}^+$ is some set of valid parameters) and a unique identifier $pk$ (we use $pk$ to denote the identifier as in $\textsf{Chia}$ it will be the public key of a signature scheme) outputs[^1]

$$S=(\ S.\Lambda\ ,\ S.N=N\ ,\ S.pk=pk)\gets {\sf PoSpace.init}(N,pk)$$

Here $S.\Lambda$ is the large file of size $\lvert S.\Lambda\ \rvert \approx N$ the prover needs to store. We also keep $N,pk$ as part of $S$ as it will be convenient. + +##### $\textsf{PoSpace.prove}$ + +> on input $S$ and a challenge $c\in \{0,1\}^w$ outputs a proof

$$\sigma=(\ \sigma.\pi\ , \sigma\ = \ \sigma.N=S.N\ ,\ \sigma.pk=S.pk\ ,\ \sigma.c=c\ )\ \gets {\sf PoSpace.prove}(S,c)$$

Here $\sigma.\pi$ is the actual proof, the other entries in $\sigma$ are just convenient to keep around. + +##### $\textsf{PoSpace.verify}$ + +> on input a proof $\sigma$ outputs ${\sf accept}$ or ${\sf reject}$

$${\sf PoSpace.verify}(\sigma)\in \{{\sf reject},{\sf accept}\}\ .$$

We assume perfect completeness

$$\begin{aligned}&&\forall N\in{\cal N},c\in\{0,1\}^w, \ \Pr[{{\sf PoSpace.verify}}(\sigma)={\sf accept}]=1\textrm{ where }\\&&S\gets{\sf PoSpace.init}(N,pk) \textrm{ and } \sigma\gets{{\sf PoSpace.prove}}(S,c)\end{aligned}$$ + +### A.2.2 Security of PoSpace + +We will not give the formal security definition for PoSpace here, but informally it states that an adversary who stores a file of size significantly less than $N$ bits should not be able to produce a valid proof for a random challenge unless he invests a significant amount of computation (ideally close to what it costs to run the full initialization ${\sf PoSpace.init}(N,pk)$). Moreover it must be impossible to amortize space, that is, initializing space for $m>1$ different identities must require $m$ times as much space. + +To prevent grinding attacks, we need our PoSpace to be unique as defined below. + +### A.2.3 Unique PoSpace + +A PoSpace is unique if for any identity $pk$ and any challenge $c$ there is exactly one proof, i.e., + +$$ +\begin{aligned} +&\forall N,pk,c,\\ +&\left|\{\sigma\ :\ \left({{\sf PoSpace.verify}}(\sigma)={\sf accept}\right)\wedge \left( (\sigma.N,\sigma.pk,\sigma.c)=(N,pk,c)\right)\}\right|= 1 +\end{aligned} +$$ + +We call a PoSpace _weakly_ unique if the _expected_ number of proofs is close to $1$, i.e., + +$$ +\begin{aligned} +&\forall N,pk,c,\\ +&{\mathrm E}_{c\gets \{0,1\}^w}\left[|\{\sigma : \left({{\sf PoSpace.verify}}(\sigma)={\sf accept}\} \right) +\wedge \left((\sigma.N,\sigma.pk,\sigma.c)=(N,pk,c)\right) +|\right]\\ +&\approx 1 +\end{aligned} +$$ + +For weakly unique PoSpace we assume that whenever there is more than one proof for a given challenge which passes verification, ${\sf PoSpace.prove}(S,c)$ outputs all of them. + +The [AAC+17] PoSpace used in $\textsf{Chia}$ is only _weakly unique_. To be able to focus on the main challenges, we will nonetheless assume a _unique_ PoSpace when analyzing $\textsf{Chia}$ but our analysis can be extended without major difficulties to handle weakly unique PoSpace, things just get a bit more messy. + +### A.2.4 The [AAC+17] PoSpace + +We give a very high level outline of the PoSpace from [AAC+17]. The space parameter is given implicitly by a value $\ell\in\mathbb{Z}^+$, the actual space required is approximately $N\approx \ell\cdot 2\cdot 2^{\ell}$ bits (e.g. for $\ell=40$ that's $10$ terabytes). Let $L:=\{0,1\}^\ell$ denote the set of $\ell$ bit strings. Below we denote with $X_{|\ell}$ the $\ell$ bit prefix of a string $X$. + +The identity $id:=pk$ together with a hash function ${\sf H}$ defines two functions $f: L\rightarrow L, g:L\times L\rightarrow L$ as + +$$ +f(x)={\sf H}(id,x)_{|\ell}\quad\textrm{and}\quad g(x,x')={\sf H}(id,x,x')_{|\ell} \ . +$$ + +Note that if we model ${\sf H}$ as a random function, then $f,g$ are also random functions. On a challenge $y\in L$ the prover must answer with a tuple + +$$ +id,(x,x')\qquad\textrm{ where }\qquad +x\neq x', f(x)=f(x'), g(x,x')=y +$$ + +if it exists. In this construction, for roughly a $(1-1/e)\approx 0.632$ fraction of the challenges $y\in L$ there will be at least one proof, and the expected number of proofs is $1$ (so it is a weakly unique PoSpace). + +The prover will generate and store two tables so they can efficiently generate proofs. They first compute and store a table with the values $(x,f(x))$ sorted by the 2nd entry. With this table, the prover can now efficiently enumerate all tuples $(x,x')$ where $x\neq x'$ and $f(x)=f(x')$ to generate a table containing all triples $(x,x',y=g(x,x'))$; the expected number of such triples is $|L|=2^\ell$. This table is then sorted by the thrid value. Now given a challenge $y$ one can efficiently look up proofs in the second table as it is sorted by the $y$ values. Storing the second table requires $\approx 3|L|\log(|L|)=2^{\ell+1}\ell$ bits, and this can be brought down to $\approx 2|L|\log(|L|)$ bits by encoding it in a more clever way. + +$\textsf{Chia}$ is based on this PoSpace, but to further minimize the effect of time/space trade-offs (where a malicious farmer tries to save on space at the cost of doing more computations), a nested version of this construction is used. We omit the details in this writeup. + +## A.3 Verifiable Delay Functions + +The definition of verifiable delay functions (VDFs) given below is not completely general, but makes some additional properties of VDF we'll need in $\textsf{Chia}$ explicit. In particular, we want a VDF where the sequential computation can start before we know the number of sequential steps for which it will run, while still being able to output proofs reasonably fast at any point during the sequential computation. This similar to the functionality provided by continuous VDFs [@Ephraim2020], which require that one can provide proofs for intermediate values almost immediately. We can allow some slack, and thus can use "normal" practical VDF constructions. We'll use the following notation to an (ongoing or finished) VDF computation $\tau$ + +$\tau.c \in \{0,1\}^\* \colon$ the challenge (usually one or more unpredictable values) used for this VDF + +$\tau.t \in \N \colon$ total number of sequential steps performed + +For $i\ :\ 0\ \le i \le \tau.t$ we let $\tau[i]$ denote the state of the VDF after $i$ sequential steps, and + +$\tau[i].x\in {\cal X}\colon$ denotes the value after $i$ steps. + +$\tau[i].\pi \colon$ is a proof certifying that $\tau[i].x$ is correctly computed. + +We'll denote the value and proof for the last value as + +$$ +\tau.y \stackrel{\scriptsize \sf def}{=}\tau[\tau.t].x\qquad \tau.\pi\stackrel{\scriptsize \sf def}{=}\tau[\tau.t].\pi +$$ + +The functions defining a VDF are + +##### $\textsf{VDF.sample}$ + +> on input a challenge $c\in\{0,1\}^\*$ samples the initial value $x$ and outputs a partial VDF value

$$\tau.{\sf t}:=0\ ,\ \tau[0].{\sf x}:=x\ ,\ \tau.{\sf c}:=c$$ + +##### $\textsf{VDF.next}$ + +> ${\cal X}\rightarrow {\cal X}$ the function doing one step of the sequential computation + +##### $\textsf{VDF.solve}$ + +> on input a challenge $c\in\{0,1\}^\*$ and time parameter $t\in\mathbb{Z}^+$ outputs a proof

$$\tau=(\ \tau.y\ ,\ \tau.\pi\ ,\ \tau.x\ ,\ \tau.c=c\ ,\ \tau.t=t\ )\gets {\sf VDF.solve}(c,t)$$

and runs in (not much more than) $t$ sequential steps (what a step is depends on the particular VDF). Here $\tau.y$ is the output and $\tau.\pi$ is a proof that $\tau.y$ has been correctly computed. For convenience we also keep $(c,t)$ as part of $\tau$. + +##### $\textsf{VDF.verify}$ + +> on input $\tau$ outputs ${\sf accept}$ or ${\sf reject}$.

$${\sf VDF.verify}(\tau)\in \{{\sf reject},{\sf accept}\}$$

Verifying must be possible in $\ll t$ steps, for existing VDFs verification just takes $\log(t)$ [Pie19b] or even constant [Wes20] time. + +We have perfect completeness + +$$ +\forall t,c\ :\ {{\sf VDF.verify}}({{\sf VDF.solve}}(c,t))={\sf accept} +$$ + +The two security properties we require are + +**uniqueness:** +It is hard to come up with any statement and an accepting proof for a wrong output. More precisely, it is computationally difficult to find any $\tau'$ where for $\tau\gets {\sf VDF.solve}(\tau'.c,\tau'.t)$ we have + +$$ +{\sf VDF.verify}(\tau')={\sf accept}\quad\textrm{ and }\quad\tau.y\neq \tau'.y\ . +$$ + +Note that we only need $\tau.y$ (but not $\tau.\pi$) to be unique, i.e., the proof $\tau.\pi$ showing that $\tau.y$ is the correct value can be malleable. This seems sufficient for all applications of VDFs, but let us mention that in the [Pie19b; Wes20] VDFs discussed below also $\tau.\pi$ is unique. + +**sequentiality:** +Informally, sequentiality states that for any $t$, an adversary ${\cal A}$ who makes less than $t$ sequential steps will not find an accepting proof on a random challenge. I.e., for some tiny $\epsilon$ + +$$ +\hspace{-1cm} + \Pr[{\sf VDF.verify}(\tau)={\sf accept}\ \wedge \ \tau.c=c\ \wedge\ \tau.t=t \ :\ c\stackrel{rand}{\gets}\{0,1\}^w,\tau\gets{\cal A}(c,t)]\le \epsilon +$$ + +Let us stress that ${\cal A}$ is only bounded by the number of _sequential_ steps, but they can use high parallelism. Thus the VDF output cannot be computed faster by adding parallelism beyond what can be used to speed up a single step of the VDF computation. + +### A.3.1 The [Pie19b, Wes20] VDFs + +The VDFs proposed in [Pie19b; Wes20] (see [BBBF18a] for an overview of those constructions) are both based on squaring in a group of unknown order, for concreteness let the group be $\mathbb{Z}_N^\*$ where $N=pq$ is the product of two large primes $p,q$. On input ${\sf VDF.solve}(c,t)$ one would first map the challenge $c$ on a group element, say as $x_c:= hash(c)\bmod N$, and the output is $(y,\pi)$ with $y=x_c^{2^t}\bmod N$. This $y$ can be computed by squaring $x_c$ sequentially $t$ times $x_c\rightarrow x_c^2\rightarrow x_c^{2^2}\rightarrow \cdots \rightarrow x_c^{2^t}$, and it is conjectured that there is no shortcut to this computation if one doesn't know the factorization of $N$. + +The VDFs from [Pie19b; Wes20] differ in how the proof $\pi$ that certifies that $y=x_c^{2^t}\bmod N$ is defined. The proof in [Pie19b] is shorter ($1$ vs. $\log(T)$ elements), but soundness of the proof requires an additional assumption (that taking random roots is hard). + +If one uses an RSA group as above, a trusted setup or a multiparty computation is needed to sample the modulus $N$ in a way that nobody learns its factorization. As this sampling is expensive, one would then think of $N$ as a public parameter to be used indefinitely. + +Wesolowski [Wes20] suggests using the class group of an imaginary quadratic field as the underlying group of unknown order. These groups can be obliviously sampled -- this means given random bits one can sample a group without learning its order -- and thus there is no need for a trusted setup. On the other hand, it's somewhat tricky to obliviously sample random group elements in class groups (here obliviously means in a way that does not reveal the discrete log of the element). Thus in the class group setting we can let ${\sf VDF}(c,t)$ sample a fresh group using the challenge $c$, and then exponentiate a fixed easy to find group element (concretely the element (a=2, b=1)). This is the approach taken in $\textsf{Chia}$. + +[^1]: The first constructions of PoSpace from [DFKP15] were based on depth-robust graphs. The initialization phase in these PoSpace was not just a function as it is here, but an interactive protocol. The definition we give here captures the [AAC+17] PoSpace (which was developed for $\textsf{Chia}$) where the initialization phase is non-interactive, this makes its use in a blockchain design much simpler. The Spacemint [PKF+18] proposal is using graph-based PoSpace and because of that must bootstrap the blockchain itself to make initialization non-interactive: farmers must post a commitment to their space to the blockchain via a special type of transaction before it can be used for farming. Without this, Spacemint would succumb to grinding attacks (on the message send to the verifier during the initialization phase). 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 new file mode 100644 index 00000000000..520f7934eaa --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-introduction.md @@ -0,0 +1,220 @@ +--- +title: Introduction - Chia Green Paper +sidebar_label: 1 - Introduction +slug: /chia-blockchain/green-paper/green-paper-introduction +--- + +# 1 - Introduction + +The **$\textsf{Chia}$ network** ([chia.net](https://chia.net/)) is a permissionless blockchain that was launched on March 19, 2021. $\textsf{Chia}$ is a "longest-chain" blockchain like Bitcoin, but uses disk-space instead of computation as the main resource to achieve consensus. This holds the promise of being much more ecologically and economically sustainable and more decentralized than a proof of work (PoW) based blockchain like Bitcoin could be. Figure 1 illustrates one slot of the $\textsf{Chia}$ blockchain. The main aim of this document is to explain the rationale for this rather complicated design. + +
+ Illustration of one slot of the Chia blockchain
Figure 1: Illustration of one slot (taking around 10 minutes) of the Chia blockchain. For illustration the slot has just 16 (instead 64) signage points and only 4 blocks (the actual chain has a target of 32).
+
+ +As mentioned, $\textsf{Chia}$ is basically what's called a _longest-chain_ protocol in the literature [BNPW19; BDK+19]. This notion captures blockchain protocols that borrow the main ideas from the Bitcoin blockchain: the parties (called miners in Bitcoin and farmers in Chia) that dedicate resources (hashing power in Bitcoin, disk space in Chia) towards securing the blockchain just need to + +1. listen to the (P2P) network to learn about progress of the chain and to collect transactions. + +2. locally use the resource (via proofs of work in Bitcoin or proofs of space in Chia) trying to create a block which extends the current chain. + +3. if a winning block is found, gossip the new block to the network. + +No other coordination or communication amongst the parties is required. In particular, as the miners in Bitcoin, the farmers in $\textsf{Chia}$ only need to speak up once they find a block and want it to be included in the chain. + +Constructing a secure permissionless blockchain using proofs of space is much more challenging than using proofs of work. In particular, a secure (under dynamic availability) longest-chain protocol based on proofs of space alone does not exist [BP22], so Chia's _proofs of space and time_ (PoST) consensus protocol, apart from farmers providing disk space, additionally relies on so called timelords who evaluate verifiable delay functions (VDFs). Figure 2 gives an overview of the formal security proofs and more informal arguments outlined in this document. + +
+ Diagram of Chia security and arguments
Figure 2: An illustration of the main security proofs and arguments for the Chia consensus layer.
+
+ +## 1.1 Security + +The Bitcoin blockchain is secure [GKL15] as long as the hashing power $hash_h$ (measured in hashes per second) contributed by honest parties is larger than the hashing power $hash_a$ available to an adversary, i.e., + +$$ +hash_h > hash_a +$$ + +
eq.(1)
+ +Similarly, the security of $\textsf{Chia}$ depends on the amount of space $space_h$ and $space_a$ controlled by the honest parties and the adversary, respectively. Additionally, the speed $vdf_h$ and $vdf_a$ (measured in steps per second) of the VDFs run by the fastest honest timelord and the adversary are relevant. With these definitions, + +$$ +\textrm{{\sf Chia}\ is provably secure if : } +space_h\cdot vdf_h > space_a \cdot vdf_a \cdot 1.47 +$$ + +
eq.(2)
+ +Let us stress that $\textsf{Chia}$ only requires a single timelord (which runs 3 VDFs) to be active at any time, in particular, $vdf_h$ in eq.(2) refers to the speed of the fastest VDFs controlled by an active and honest timelord, it doesn't matter if one or a billion timelords are active. In practice we'd still expect a small number – not just one – timelords to be available to have a backup should the currently fastest timelord become unavailable. + +On the other hand, we make no assumptions about the number of VDFs controlled by the adversary. Security as in eq.(2) holds even when assuming the adversary controls an unbounded number of VDFs of speed $vdf_a$. + +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$ + +$$ +\textrm{double spending in {\sf Chia}\ possible if : }space_h\cdot vdf_h < space_a \cdot vdf_a \cdot 1.34 +$$ + +
eq.(3)
+ +More concretely, if $vdf_h=vdf_a$, i.e., if the adversary has (an unbounded number of) VDFs of the same speed as the fastest honest timelord, then double spending is possible controlling $\frac{100\%}{1+1.34}\approx 43\%$ of the total space. + +A contribution of this writeup is a modular approach towards achieving secure longest-chain blockchains from efficient proof systems. In §2 we outline three attack vectors (illustrated in Figure 3) that emerge if we naïvely replace proof of work with an efficient proof systems. + +## 1.2 Network Delays + +In Bitcoin each block contains the hash of the previous block. If two blocks are found at roughly the same time, so there was no time for the block that was found first to propagate to the miner that found the second, they will refer to the same block, and only one can be added to the chain. The other will be "orphaned" and does not contribute towards securing the blockchain. The fraction of orphaned blocks depends on the network delay (the smaller the delay the fewer orphans) and the block-arrival time (fewer blocks per minute decrease the probability of orphans). Taking this into account, the security statement for Bitcoin from eq.(1) should be augmented to: + +$$ +hash_h \cdot \left(1-\frac{network\ delay}{block\ arrival\ time}\right)> hash_a +$$ + +
eq.(4)
+ +Even with its very slow 10 minutes block arrival time, Bitcoin's orphan rate was measured to be around $1.6\%$ [DW13]. As the $\textsf{Chia}$ chain is not a typical hash chain, but an ongoing VDF computation where blocks are infused, there's an elegant way to avoid orphans: the "infusion point" of a block is around $30$ seconds (more precisely, between $28.125$ and $37.5$ seconds) worth of VDF computations after the "signage point" it must refer to, and as long as the network delay is small enough so the block creating/gossiping process takes less than 30 seconds no orphans will occur. In particular, the bound from eq.(2) holds under this very weak network assumption independent of the block arrival time. + +The target block arrival time in $\textsf{Chia}$ is set to $18.75$ seconds (32 blocks per 10 Minutes slot), and while each of those blocks contributes to security, only a subset of these blocks actually carry transactions (roughly $36\%$, that's a block every $51.2$ seconds) in order to ensure that transaction blocks sequentially refer to each other. This prevents issues with inconsistent transactions, as each block producer knows the entire history. + +## 1.3 Game Theoretic Aspects + +Apart from proving security assuming the honest parties control a sufficient majority of the resources, to argue that a longest-chain protocol will be secure in the real world we need to justify why rational parties would behave honestly in the first place. In particular, it should not be possible to get more rewards by deviating from the honest mining/farming behavior. While Bitcoin is not fair in this sense due to selfish mining attacks [ES18], these attacks are not really practical and have not been observed in the wild for reasons we'll sketch below and discuss in more detail in §3. + +#### Fairness in $\textsf{Chia}$ + +Achieving fairness that is comparable to what Bitcoin achieves is a main design goal of $\textsf{Chia}$. While arguing about fairness directly is rather subtle, we identify two clean properties called "no slowdown" and "delayed gratification" a longest-chain can satisfy. Delayed gratification by itself already is a deterrent against selfish farming, and we show (Proposition 1 in §3) that these two properties jointly imply a chain-quality (i.e., fraction of honest blocks in the longest chain) no worse that what Bitcoin achieves. + +#### No-Slowdown + +The no-slowdown property was identified as a desirable property for longest-chain blockchains in [CP19]. It holds if (even an unbounded) adversary cannot slow down the growth of the chain by participating. We discuss the no-slowdown in $\textsf{Chia}$ and various other chains in §3.5. + +#### Delayed Gratification + +The $\textsf{Chia}$ design ensures that proof of space challenges are only revealed once they are needed, and once they're revealed they cannot be influenced any more. This then implies that it's impossible for a selfish farmer to create more blocks by deviating from honest farming, and thus – like in Bitcoin – the only thing a selfish farmer can do is prevent other farmers from adding their fair share of blocks in the current epoch (potentially even losing out on blocks themself). The reason a selfish farmer would do this is in order to enforce a lower difficulty, and thus more rewards for themselves, in the future \[ES18]. We denote chains with this property as having "delayed gratification".[^1] While delayed gratification doesn't prevent selfish mining, it severely limits the type of selfish mining possible, and we don't expect to observe selfish farming in $\textsf{Chia}$ for the same reasons we don't observe selfish mining in Bitcoin. As mentioned above, in combination with the no-slowdown property it even implies a chain-quality as in Bitcoin. + +## 1.4 Farmers and Timelords + +Constructing a secure blockchain based on proofs of space is significantly more challenging than with proof of work. So the $\textsf{Chia}$ design, as illustrated in Figure 1 is (arguably necessarily) more sophisticated than Bitcoin or other PoW based blockchains, which are basically just hash chains. Apart from proofs of space and standard cryptographic building blocks like hash functions and signature schemes, the security of $\textsf{Chia}$ crucially relies on verifiable delay functions (VDFs) [BBBF18; Pie19b; Wes20]. Informally, VDFs are functions whose computation is inherently sequential and verifiable and thus serve as a "proof of time". + +We will now shortly sketch how the $\textsf{Chia}$ blockchain is maintained by farmers and timelords. + +#### 耕种 + +Farmers are the analog of miners in Bitcoin, but instead of hashing power, farmers contribute disk-space towards securing the $\textsf{Chia}$ blockchain. As in Bitcoin, they are incentivized by block-rewards and transaction fees. As in Bitcoin, the block-rewards (i.e., some freshly minted coins that go to the block creator) decrease over time, but unlike in Bitcoin they will never go to zero for reasons outlined in [CKWN16]. + +To participate in farming a farmer must first initalize its disk-space, this process is called plotting and the files created and stored during this process are called plots. The smallest allowed plot in $\textsf{Chia}$ is slightly larger than 100GB, though for plotting one temporarily needs more than this. Once the plot(s) are in place, a farmer just listens to the network for proof of space challenges. There's a new challenge roughly every $9.375$ seconds and they are computed by a timelord as discussed below. For efficiency reasons there's a "plot filter" which for each plot dismisses all but (in expectation) one in 512 challenges immediately, so a plot is only accessed once every 80 minutes. The reason to not increase this time even further are so called replotting attacks which we'll discuss in §1.8.3. + +In $\textsf{Chia}$ only roughly $36\%$ of the blocks will carry transactions, but as a farmer doesn't know whether their block will be a transaction block when creating the block, farmers must always include transactions to the blocks they create. + +#### Timelords + +A timelord runs three VDFs, once every $9.375$ seconds they gossip a "signage point" that serves as a PoSpace challenge for the farmers. They also listen to the network for blocks created by farmers. If a valid block is received in time it gets "infused" into the chain (the infusion is always somewhere from $28.125$ to $37.5$ seconds after the signage point). + +The above only holds for the the timelord which runs the fastest VDFs. Timelords with slower VDFs can basically just recompute values that were already gossiped, so there's seemingly no point for them to participate. We still want a small number of timelords to participate (or at least be ready to take over) should the fastest timelord fail or misbehave. + +Unlike farmers, timelords do not receive any rewards in form of block-rewards or transaction fees. One reason is technical, unlike for farmers whose PoSpace contained in the blocks are linked to a signature public-key to which a reward can be given, the computation of the timelords is (and to prevent grinding attacks must be) canonical, they cannot attach a public-key to the values they computed. A second reason is the fact that it's not clear at all how such a reward would be distributed. If the fastest timelord gets the entire reward only they would be incentivized, but not the slower ones we'd like to have as back-ups. If also the slower ones get something then we'd get a PoW type lottery which we want to avoid in the first place. $\textsf{Chia}$ thus relies on a small number of timelords to run fast VDFs without being incentivised by on-chain rewards. + +## 1.5 Difficulty and Chain Selection Rule + +#### Difficulty + +In Bitcoin a difficulty parameter $D$ controls how many hashes are required in expectation to find a block. This parameter is re-calibrated every 2016 blocks (called an epoch and taking roughly 2 weeks) so blocks arrive roughly every 10 Minutes. + +$\textsf{Chia}$ has two parameters, a difficulty parameter $D$ and a time parameter $T$, these are re-calibrated once every $4608$ blocks (this epoch takes around 1 day). The time parameter $T$ is reset to fit the target time of 10 minutes per slot, while the difficulty is reset to target an average of 32 blocks per slot. + +For example if in an epoch the amount of space is $10\%$ higher than anticipated the difficulty for the next epoch would get up $D_{new}:=D_{old}\cdot 1.1$ while the time parameter remains unchanged $T_{new}:=T_{old}$. If the VDF speed in the epoch is $10\%$ higher than anticipated (i.e., the epoch only takes $24/1.1$ instead of $24$ hours) the time parameter goes up $T_{new}:=T_{old}\cdot 1.1$, and even though the space didn't change, the difficulty needs also to go up $D_{new}:=D_{old}\cdot 1.1$ account for the fact that now an epoch has more VDF steps. + +#### Chain Selection Rule + +Bitcoin has a very simple chain selection rule (aka. fork choice rule) which specifies which fork a miner should work on: a miner should always try to extend the "heaviest" chain they are aware of. The weight of a chain is the sum of the blocks, each multiplied by the difficulty parameter used while it was mined. Unless we consider forks which pass an epoch boundary, the heaviest chain is also the chain with the larger number of blocks, hence the name "longest chain" protocol. + +We can define the weight of a chain in $\textsf{Chia}$ analogously to Bitcoin, and currently the default $\textsf{Chia}$ farmer code follows basically the same "follow the heaviest chain" rule as Bitcoin miners. But let us stress that it's not clear whether for $\textsf{Chia}$ this simple rule is the best choice. For example, one could consider a rule for farmers where in case of a fork where both chains have the same weight they would work on both chains (note that in a PoW based chain this is not possible). While such a rule can slow down consensus, the observed fork could be due to an attack (double spending or selfish mining) trying to "split" the contribution of the honest space in two different chains, letting the farmers work on both forks would thwart this. + +In $\textsf{Chia}$ we also must specify a chain selection rule for the timelords. A timelord who does not control the fastest VDF will constantly fall behind and thus intuitively should just constantly adapt the chain with the most VDF steps in them. But if all timelords naïvely do this a malicious timelord controlling the fastest VDF could simply skip infusing any blocks they want, allowing for all kinds of attacks. Thus the rule for timelords has to be more nuanced, taking into account the chains they observe, and also blocks that were created by farmers but not infused in any of the chains. + +Determining the best rules for $\textsf{Chia}$ farmers and timelords is ongoing research. Fortunately, the rules for farmers and timelords are more of a social convention rather than a specification of the chain. As our understanding improves, new rules can be implemented in the code base and there's no need for a (soft) fork. + +## 1.6 Cryptographic Building Blocks + +The $\textsf{Chia}$ blockchain uses standard cryptographic building blocks, in particular hash functions and signature schemes. More interestingly, it relies on two (non-interactive) proof systems which were especially developed for constructing sustainable blockchains: proofs of space and verifiable delay functions. We shortly discuss the requirements $\textsf{Chia}$ has to these building blocks. + +#### Hash Functions. + +$\textsf{Chia}$ uses SHA256 for hashing, but any collision resistant hash function would do. For efficiency reasons, we also use the round function of CHACHA8 and BLAKE3 within the proof of space construction where we just need some scrambling but no cryptographic hardness (not even one-wayness). + +#### Signatures. + +$\textsf{Chia}$ uses deterministic BLS signatures for signing. In principle any signature scheme could be used as long as the signatures are unique, i.e., it's impossible (or at least computationally hard) to create two different valid signatures for the same message. Uniqueness will be crucial to prevent so called grinding attacks. + +#### Verifiable Delay Functions. + +A VDF is specified by some inherently sequential function, and a proof system for showing the output of the function is correct. The sequential function used in the VDF deployed in $\textsf{Chia}$ is repeated squaring in class groups of unknown order. The group is not fixed, but a fresh group is sampled every time a value is infused. The proof system is Wesolowski's [Wes20] proof of exponentiation which has proof of size only one group element. Only the VDF output, but not the proofs, are committed on-chain. This has the advantage that one can replace the proofs. In the current implementation one first computes a much larger but faster to compute proof of 64 group elements, which later is replaced by a normal (one element) Wesolowski proof. It also means one can easily replace Wesolowski's proof with another proof system should a weakness with this proof system (which relies on new number theoretic assumptions) be discovered. We discuss VDFs in detail in §A.3. + +#### Proofs of Space. + +The notion of proofs of space was introduced, and a first construction proposed, in \[DFKP15] (a security proof for their construction in the random oracle model was given in \[Pie19a]). This construction, which is combinatorial and based on pebbling lower bounds for particular graphs, has the major drawback that the initialization phase is _interactive_. A consequence of this is that if one wants to use this PoSpace in a blockchain, the farmers must first commit to their plots before they can be used for farming (say by recording this commitment on-chain via a special transaction as suggested in Spacemint \[PKF+18]). A new PoSpace with a _non-interactive_ initialization had to be developed for $\textsf{Chia}$ \[AAC+17]. This construction basically just specifies some function $f$, and then stores its function table $(x,f(x))$ sorted by the outputs $f(x)$. On challenge some value $y$, the prover looks up the entry $(x,y)$ (which is efficient as the list is sorted) and replies with the proof $x$, which can be easily verified checking that $y\stackrel{\tiny ?}{=}f(x)$. Unfortunately this simple construction miserably fails to be secure: the prover can store much less than the full function table, while still being able to efficiently find proofs. The reason are Hellman's time-memory trade-offs, a technique proposed in 1980 to break symmetric cryptographic schemes \[Hel80]. In \[AAC+17] it is shown how this simple construction can be "salvaged" to overcome any time-memory trade-offs.[^2] We'll discuss definition of a PoSpace, and the construction used in $\textsf{Chia}$ in particular, in §A.2. + +## 1.7 A High Level View of the Protocol + +The design and rationale of the $\textsf{Chia}$ blockchain is explained in the following sections, here we'll just give a very high level view of the chain as illustrated in Figure 1. The chain itself consists of four chains, one hash chain and three VDF chains. + +#### Hash and VDF chains + +While hash chains are a classical cryptographic construction, VDF chains were first used in $\textsf{Chia}$. A VDF chain alternates VDF computations with _infused_ values. It provides the security properties present in hash-chains, that is, the head of a chain commits its entire past (technically, given the head of a hash or VDF chain, it's computationally infeasible to come up with two different chains that end in that value). In addition, VDF chains come with a sequentiality property: the number of sequential steps to compute the VDF chain is the sum of the steps required for all the VDFs in that chain, i.e., the VDFs must be computed sequentially. Hash and VDF chains are discussed in more detail in §4. + +The four chains which constitute the $\textsf{Chia}$ blockchain are the (1) foliage chain ${\cal FC}$, which is a normal hash-chain and contains the transactions (2) the reward chain ${\cal RC}$ which records all blocks (3) the challenge chain ${\cal CC}$ used to create PoSpace challenges and (4) the infused challenge chain ${\sf i}{\cal CC}$ for some extra security properties. While ${\cal RC}$ and ${\cal CC}$ are normal VDF chains, ${\sf i}{\cal CC}$ is more of a sequence of forks from ${\cal CC}$. + +#### Blocks + +A block $\beta=\{\beta_F,\beta_T\}$ is made of two parts, the foliage block $\beta_F$, which contains the payload (transactions and a time-stamp) and the trunk block $\beta_T=\{\sigma,\mu_{{\sf rc\_sp}}\}$ which contains a PoSpace $\sigma$ and a signature $\mu_{{\sf rc\_sp}}$. + +#### Building the Chains + +- A timelord computes the ${\cal RC},{\cal CC},{\sf i}{\cal CC},{\cal FC}$ chains and broadcasts relevant values to the network. This includes signage points ${\sf rc\_sp}$ and ${\sf cc\_sp}$ which are the values of the ${\cal RC}$ and ${\cal CC}$ chains (together with a proof that these values are on the VDF chains) once every $9.375$ seconds. + +- A farmer who receives these _signage points_ ${\sf rc\_sp}$ and ${\sf cc\_sp}$ checks whether these points are of interest (i.e., on the heaviest known chain) and all the VDF proofs verify. Next, for each of their plots, they use ${\sf cc\_sp}$ as a challenge to compute a PoSpace $\sigma$. Then they check whether $\sigma$ satisfies a winning condition that allows to produce a block. + + If a winning PoSpace $\sigma$ is found, the farmer creates a signature $\mu_{\sf rc\_sp}$ of ${\sf rc\_sp}$ (that verifies under the $pk$ associated with $\sigma$) and a foliage block $\beta_F$ and then gossips the block $\beta=\{\beta_F,\beta_T=\{\sigma,\mu_{\sf rc\_sp}\}\}$. + +- When a timelord receives this block, they check whether the block satisfies all conditions to be infused into the chain. + + (${\cal RC}$) If yes, the trunk block $\beta_T$ is infused into ${\cal RC}$ once its _infusion point_ is reached, which is somewhere between 3 and 4 signage points (28.125 to 37.5 seconds worth of VDF computations) past the signage point of that block. + + (${\cal CC}$) If this happens to be the first block whose signage points are in the current slot, then $\mu_{\sf rc\_sp}$ (but not $\sigma$) is infused into the challenge chain ${\cal CC}$ at the end of the current slot. This way the challenge chain depends only on one block per slot. + + (${\sf i}{\cal CC}$) For some extra security, the timelord doesn't simply wait till the end of the slot to infuse the signature, but a third VDF is used to fork from ${\cal CC}$ at the infusion point by infusing $\mu_{\sf rc\_sp}$ into ${\cal CC}$, and this fork, called the infused challenge chain ${\sf i}{\cal CC}$, is then infused back to ${\cal CC}$ at the end of the slot. + + (${\cal FC}$) If the signage point of this block is later than the infusion point of the last _transaction block_, then this block is also a transaction block. Only in this case its foliage $\beta_F$ is appended to the foliage (hash) chain ${\cal FC}$, and this block becomes a "transaction block". + +## 1.8 Space Oddities + +When constructing a proof of stake or proof or a space based longest-chain protocol one faces similar challenges due to "nothing at stake" (aka. costless simulation) issues, we'll discuss these in §2. But there also aspects in which Space and Stake differ, and we'll shortly discuss three of them below. The first difference is the fact that space, unlike stake, is an unsized resource, which for example means that we can't have "certificates" [LR21]. The second difference is the fact that stake is an internal resource, while space is an external resource, one of the consequences of this is that a space based protocol can recover from malicious majority, while a stake based cannot. The third are replotting attacks against space which have no analogue in the stake setting. + +### 1.8.1 Sized vs. Unsized + +A key difference between stake and work is the fact that in a stake based chain we know the amount of the resource available for mining, while for an external resource like work or space this is no longer the case. Lewis-Pye and Roughgarden [Lew21; LR21] formalize this as the _sized_ vs. _unsized_ setting and prove some fundamental differences between them. The main result in [LR21] shows that _certificates_ which "provide incontrovertible proof of block confirmation", only exist in the sized setting, i.e., for PoStake but not PoWork blockchains. + +In their framework _space_ and also _space and time_ (i.e., the available space multiplied with the speed of the available VDFs) as used in $\textsf{Chia}$ are an unsized resource, so we can't hope to get certificates. + +### 1.8.2 Internal vs. External + +Work or space are actual resources and we can unambiguous talk about some party holding some amount of the resource at some given point in time. Stake on the other hand is an _internal_ resource defined relative to some chain on which it is recorded and "holding some stake" usually refers to the stake a party controls on the chain that currently is considered the valid one by honest parties. + +The main advantage on using stake to secure a longest-chain protocol is the fact that it's extremely sustainable as no external resource is required to secure the chain. But this comes at a price, one common argument against stake is that the chain is not really permissionless as participating in mining requires acquiring stake from the parties currently controlling it. Also from a security perspective an internal resource is delicate as keys controlling stake _not_ on the current chain can be used to attack the chain. A simple example would be an attack by which a party acquires keys that were valid at some block $B_i$ in the past, but which are no longer valid at the current block and thus are "cheap" (e.g., the party can lend a large amount of stake for a short time, or offer to buy outdated keys), and then uses these keys to fork at block $B_i$ and bootstrap a chain to the present. + +To prevent such attacks some chain require parties to delete old keys, but it's irrational for a party to delete old keys if they can be valuable in the future, say because one can sell them to an attacker (and this is rational if one holds just little stake, so not selling is unlikely to prevent the attack) or because there's a deep reorg and the old keys suddenly become valuable again. Combining stake with VDFs would make such attacks harder, but not prevent them as we'll discuss in §6 + +### 1.8.3 Replotting + +A subtle but important difference between stake and space is the fact that space allows for _replotting_ which has no analogue in the stake setting: Given a challenge $c$, a space farmer controlling a plot $S$ of size $N$ can _efficiently_ compute _one_ proof $\sigma \gets {\sf PoSpace.prove}(S,c)$. This is analogous to the stake based setting, but unlike in the stake setting, the farmer can _inefficiently_ compute _multiple_ proofs for challenge $c$ by repeatedly creating fresh plots and computing one proof with each of them. + +We refer to attacks exploiting this fact as _replotting attacks_. The most basic design choice to harden a chain against replotting attacks is to make sure that challenges arrive at a sufficiently high rate so that substantial replotting in-between two challenges is not feasible. Moreover the plot filter (which dictates what fraction of plots must be accessed with every challenge) cannot be chosen too aggressively as more aggressive filters makes potential replotting attacks easier. + +A fundamental fact about PoSpace that crucially relies on replotting is that _no PoSpace based longest-chain protocol secure under dynamic availability exists_ [BP22], we'll discuss their result in more detail in §6.2.3. $\textsf{Chia}$ overcomes this no-go theorem by using VDFs, we discuss security under dynamic availability and healing from malicious majority in the work, stake and space setting in §6. + +[^1]: According to Wikipedia, _delayed gratification_ is the resistance to the temptation of an immediate pleasure in the hope of obtaining a valuable and long-lasting reward in the long-term. + +[^2]: The crucial observation that makes this possible is the fact that Hellman's attack assumes that $f(.)$ can be efficiently computed in forward direction, while for a PoSpace we just require that the entire function table of $f(.)$ can be computed in time linear in the size of the table. 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 new file mode 100644 index 00000000000..73e36fe610a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/green-paper-references.md @@ -0,0 +1,41 @@ +--- +title: References - Chia Green Paper +sidebar_label: References +slug: /chia-blockchain/green-paper/green-paper-references +--- + +# References + +| 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. | +| 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. | +| 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. | +| 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. | +| 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. | +| 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. | +| 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. | +| 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. | + +## Additional Reading + +- [How to Store a Permutation Compactly](https://hackmd.io/@dabo/rkP8Pcf9t) by Bram Cohen and Dan Boneh 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 new file mode 100644 index 00000000000..781ed860a7a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/hash-and-vdf-chains.md @@ -0,0 +1,83 @@ +--- +title: Hash and VDF chains - Chia Green Paper +sidebar_label: 4 - Hash and VDF chains +slug: /chia-blockchain/green-paper/hash-and-vdf-chains +--- + +# 4 - Hash and VDF chains + +A key ingredient in longest-chain blockchains are hash-chains as discussed in §4.1 below. While $\textsf{Chia}$ also uses a hash-chain (for the foliage chain ${\cal FC}$), for $\textsf{Chia}$ we use a new chaining structure called a VDF chain defined in §4.2 below. + +## 4.1 Hash chains + +For this writeup, a _hash chain_ is a sequence $b_0,b_1,b_2\ldots$ of blocks, where each block $b_i=\{h_i,x_i\}$ contains some data value $x_i$ (possibly empty) and (with the exception of $b_0$) a hash value of the current data and the previous block. + +$$ +h_i:={\sf H}(b_{i-1},x_i) +$$ + +#### Security from hash chains. + +A hash chain is immutable in the following sense: + +--- + +**Proposition 2** (immutability of hash chains). _If ${\sf H}$ is a collision-resistant hash function, then it is computationally infeasible to find two distinct hash chains ${\cal H}=b_0,\ldots.b_i$ and ${\cal H'}=b'_0,\ldots,b'_j$ where $h_i=h'_j$ and no chain is a prefix of the other (which holds if they start with the same $x_0=x'_0$)._ + +--- + +## 4.2 VDF chains + +
+ Illustration of a VDF chain
Figure 6: Illustration of a VDF chain.
+
+ +A VDF chain is a sequence + +$$ +{\cal V}=z_0,\tau_1,z_1,\tau_2,z_2,\ldots,\tau_\ell +$$ + +
eq.(5)
+ +alternating data values $z_i\in\{0,1\}^\*$ and VDF values $\tau_i=(\tau_i.{\sf y},\tau_i.\pi,\tau_i.{\sf c},\tau_i.{\sf t})$ (as described in §A.3). The chain is valid if all VDF proofs are correct + +$$ +{\sf VDF.verify}(\tau_i)={\sf accept} +$$ + +and the challenge for the $i$th VDF is derived from the previous VDF output (except for $i=1$) and data value + +$$ +\tau_1.c := \mathsf{VDF.sample}(z_0) \quad \text{ and } \quad \forall i > 1 : \tau_i.\mathsf{c} := \mathsf{VDF.sample}(\tau_{i-1}.\mathsf{y}, z_{i-1}) +$$ + +where we use the convention that $\tau_0.{\sf y}$ is the empty string. + +### 4.2.1 Notation for VDF chains + +We naturally extend the notion for VDFs as described in §A.3 to VDF chains. The _total number of VDF steps in a VDF chain_ as in eq.(5) is simply the sum of the steps in its VDFs + +$$ +{\cal V}.{\sf t}\stackrel{\scriptsize \sf def}{=}\sum_{i=1}^\ell \tau_i.{\sf t} +$$ + +#### Security from VDF chains. + +VDF chains give two basic security guarantees, the first is immutability analogous to hash chains, but also sequentiality inherited from the underlying VDF, we discuss them shortly in more detail. + +--- + +**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 +\qquad +{\cal V}'=z'_0,\tau'_1,z'_1,\tau'_2,z'_2,\ldots,\tau'_{\ell'} +$$ + +where the last VDF outputs collide, i.e., $\tau_\ell.{\sf y}=\tau'_{\ell'}.{\sf y}$. Here different means that either they have different length $\ell\neq \ell'$ and neither is a prefix of the other. Or (if $\ell=\ell'$) there exists an $i$ s.t. either $z_i\neq z'_i$ or $\tau_i.{\sf y}\neq \tau'_i.{\sf y}$ or $\tau.{\sf t}\neq \tau'.{\sf t}$. Note that we ignore the proofs $\tau.\pi$ when comparing chains (we just use them to determine whether the chain is valid) as they must not be unique. Here different means that either they have different length $\ell\neq \ell'$ and neither is a prefix of the other. Or (if $\ell=\ell'$) there exists an $i$ s.t. either $z_i\neq z'_i$ or $\tau_i.{\sf y}\neq \tau'_i.{\sf y}$ or $\tau.{\sf t}\neq \tau'.{\sf t}$. Note that we ignore the proofs $\tau.\pi$ when comparing chains (we just use them to determine whether the chain is valid) as they must not be unique. + +Moreover a VDF chain is _sequential_, meaning that not only the individual VDFs must be computed sequentially (which follows from the security definition of VDFs), but also the VDFs in the chain were computed sequentially. I.e., computing a chain ${\cal V}$ as above requires $\sum_{i=1}^\ell \tau_i.{\sf t}$ sequential steps. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/longest-chain-protocols.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/longest-chain-protocols.md new file mode 100644 index 00000000000..da95a725123 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/longest-chain-protocols.md @@ -0,0 +1,47 @@ +--- +title: Longest-Chain Protocols from Efficient Proof Systems - Chia Green Paper +sidebar_label: 2 - Longest-Chain Protocols from Efficient Proof Systems +slug: /chia-blockchain/green-paper/longest-chain-protocols +--- + +# 2 - Longest-Chain Protocols from Efficient Proof Systems + +Before we can outline the specification of the $\textrm{{\sf Chia}}$ blockchain and its rationale in more detail, we first must understand the general challenges one faces when constructing a PoSpace based blockchain and some of the relevant literature on how to address these challenges. + +Ultimately, we want to argue security assuming only that sufficient fraction of the resource (space, fast VDFs) is controlled by _rational_ parties. Towards this, in this Section we first discuss how to achieve security assuming sufficiently many parties are _honest_, and then in §3 how _rational_ behavior is incentivized by ensuring that deviating from the protocol will not give any (or very little) extra reward to parties. + +
+ alt text
Figure 3: Illustration of the three main attack vectors that arise if we replace PoW with proofs of space (or any other efficient proof systems) in Bitcoin, and how they are addressed in Chia.
+
+ +As mentioned in the introduction, just replacing proofs of work in Bitcoin with proofs of space does not work. For one thing, there are syntactic differences between proofs of work and proofs of space. But more importantly, security breaks down if one replaces PoW with PoSpace in any straight forward way. The reason for this is the fact that for PoSpace (after plotting) it's extremely cheap to compute a proof for a given challenge. The analogue issue with proof of stake is sometimes called "nothing at stake". We'll refer to proof systems where proofs can be efficiently computed (like proofs of space or stake) as _efficient_, and describe three attack vectors that arise because of this issue: grinding, double-dipping and bootstrapping. Those are illustrated in Figure 3 and described below. In §5 we'll describe how those attacks are addressed in $\textrm{{\sf Chia}}$ in more detail. + +## 2.1 Grinding + +In longest-chain blockchains the challenge used to determine the miner/farmer who can add a block is derived from the chain itself. In Bitcoin, where the challenge for a block is simply the hash of the previous block, a miner can influence the PoW challenge by trying out different transaction sets or time stamps. While such "grinding" through different challenges gives no advantage in PoW based cryptocurrencies, it's a problem once we use an efficient proof system. + +To prevent such grinding we adopt an approach from Spacemint [PKF+18] and _split the chain_ in two parts which we'll call trunk and foliage. The trunk contains only canonical proofs, and the challenges depend only on values contained in the trunk. This way the only choice a farmer has to influence the challenge is by withholding a winning block. The foliage contains all the remaining "grindeable" content, in particular transactions and time-stamps. + +## 2.2 Double-Dipping + +Even once grinding is no longer an option, an adversary can in private create an entire "block-tree" by forking at each level. While each path in such a tree will have an exponentially small (in the depth) probability of overtaking the honest chain if the adversary controls less than half the resources, there's also an exponential number of paths, so it's not clear how much of an advantage this strategy gives. For constructions where each challenge depends on the previous block (as in Bitcoin), it was shown [CP19] that this strategy "boosts" the resource by a factor $e\approx 2.718$, in particular, with this strategy an adversary (having an unlimited number of VDFs whose speed matches the fastest honest time lord) can create a chain that is longer than the honest one with only a $1/(1+e)\approx 0.269$ fraction of the total space, and thus significantly less than the $0.5$ fraction (of hashing power) required in Bitcoin. + +To limit the impact of double-dipping an early version [CP19] of $\textrm{{\sf Chia}}$ consensus specified that also the honest parties do a very limited form of double-dipping and try to extend the best $3$ blocks they see at every depth, this rule was (by simulations) shown to increase the space required by an adversary from the $26.9\%$ mentioned above, to $38.5\%$. + +The deployed $\textrm{{\sf Chia}}$ protocol uses _correlated randomness_ to limit the impact of double dipping. This elegant idea was introduced in \[BDK+19], and basically suggest to only use every $k$th block to compute the challenges.[^1] The authors of \[BDK+19] determine the exact fraction of the _resource_ the adversary must control to break security as a function of $k$ (as mentioned, it's $2.718$ for $k=1$, and goes to $1$ as $k$ increases). $\textrm{{\sf Chia}}$ uses a variant where a challenge depends on one out of _at least_ (not exactly) $k=16$ blocks. Their analysis also applies to this setting, and with $k=16$ states that by double dipping the adversary can boost their resource by a factor of $1.47$, which means they must control at least a $\frac{1}{1+1.47}=0.405$ fraction of the resource for an attack. + +The resource considered in [BDK+19] is simply stake, while in $\textrm{{\sf Chia}}$ it's the product of space and VDF speed. Concerning VDFs, while for the honest parties the only thing that matters is the _speed_ of the three VDFs controlled by the fastest honest time lord, for an adversary the speed as well as the number of VDFs available to them matter. In the security analysis we can simply assume the adversary controls an unbounded number of VDFs, as that's when the analysis from [BDK+19] applies. This is how eq.(2) $space_h\cdot vdf_h > space_a \cdot vdf_a \cdot 1.47$ in §1.1 was derived. + +## 2.3 Bootstrapping + +A major issue with longest-chain blockchains based on efficient proof systems is bootstrapping (aka. costless simulation) by which an adversary can use its resource to create a chain at basically no cost. Such bootstrapping can be used for short range attacks like selfish mining, but also long range attacks where an adversary forks the chain at a point in the past and then "bootstraps" it into the present. Such long range attacks make it hard to achieve security under dynamic availability, where we assume that the honest parties control a majority of the resource at any point in time, but the total resource can vary over time. The amount of hashing power contributed towards securing Bitcoin has varied by many orders of magnitude in the past, and the same already happened to $\textrm{{\sf Chia}}$ in the first weeks after launch. + +
+ alt text
Figure 4: Illustration of the no slowdown and delayed gratification properties. A longest-chain blockchain satisfying these properties is no more susceptible to selfish mining than Bitcoin.
+
+ +Existing proposals to achieve security under such _dynamic availability_ include check-pointing, which is problematic as parties that join for the first time or have not followed the chain for a longer period need additional trust assumptions to decide which chain to follow. Unlike for grinding and double-dipping, the attacks that become possible due to bootstrapping are quite different for proofs of space and proofs of stake. In the latter one must consider old keys that hold no stake in the current chain, but still can be used to bootstrap from a past block. To address this it was suggested to have honest parties use key-evolution schemes [BGK+18] so the current keys cannot be used to create blocks in the past. Key-evolution is problematic as it's clearly not rational for honest parties to do; they could sell their keys or lose their stake in case of a deep reorg. + +The essence of the bootstrapping problem is the fact that one cannot ensure that time has passed in-between the creation of subsequent blocks. $\textrm{{\sf Chia}}$ solves this problem by combining proofs of space with _proofs of time_, concretely, verifiable delay functions (VDFs), which enforce that some inherently sequential computation (which requires time linear in the length of the computation) was performed in-between the creation of blocks. $\textrm{{\sf Chia}}$ combines those three countermeasures (splitting the chain, correlated randomness and proofs of time) into a single design which is secure if the resources controlled by the honest parties satisfy the bound from Eq. + +[^1]: Using the same challenge for $k>1$ blocks has already been suggested in [PKF+18], but this is a different requirement (as the challenge can still depend on all blocks) and adds much less security than correlated randomness for small $k$. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/rational-attackers.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/rational-attackers.md new file mode 100644 index 00000000000..2c216721797 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/rational-attackers.md @@ -0,0 +1,128 @@ +--- +title: Rational Attackers - Chia Green Paper +sidebar_label: 3 - Rational Attackers +slug: /chia-blockchain/green-paper/rational-attackers +--- + +# 3 - Rational Attackers + +In §2 we discussed how costless simulation opens attack vectors for double spending in longest-chain blockchains and how these are addressed in $\textrm{{\sf Chia}}$. To show security we assumed that a sufficient fraction of the resource is controlled by _honest_ parties who follow the protocol rules. In reality it's unrealistic to assume that parties will behave altruistically, instead we need to argue that it's _rational_ for parties to follow the protocol rules. Unfortunately costless simulation also makes this task much more challenging than in a PoW based system. + +In analogy to _selfish mining_ in Bitcoin, we refer to strategies by which a party gets more rewards than they would by following the protocol rules as _selfish farming_. To argue that rational parties will behave honestly it's necessary to bound the efficacy of selfish mining/farming strategies. + +In §3.1 below we first discuss selfish mining and why we don't observe it in Bitcoin even though it's possible in principle. As directly analyzing the security of a longest-chain protocol against selfish mining/farming is very challenging we take a modular approach. In §3.2 we first identify two properties – _no slowdown_ and _delayed gratification_ illustrated in Figure 5 – which are satisfied by Bitcoin, and then show in §3.3 that they imply robustness against selfish mining (through the notion of chain quality) of the level as achieved by Bitcoin. In §3.4 and §3.5 we then sketch how those notions are achieved in $\textrm{{\sf Chia}}$. + +## 3.1 Selfish Mining in Bitcoin + +While Bitcoin prevents double spending assuming a majority of the hashing power is controlled by miners who altruistically follow the protocol, it allows for _selfish mining_ \[ES18] by which a miner with a $\alpha<0.5$ fraction of the hashing power can create more than an $\alpha$ fraction of the blocks and thus gets an unfair share of the block rewards. In some settings this fraction can be as large as $\alpha/(1-\alpha)$ (e.g. a $0.33$ fraction for $\alpha=0.25$).[^1] Selfish mining has not been observed in Bitcoin, and there are various reasons why this is the case + +1. selfish mining requires either a fairly large fraction of the hashing power or very good control of the network (cf. Footnote [^1]) to be profitable + +2. the attack would be easily detected and + +3. delayed gratification as defined below. + +## 3.2 Delayed Gratification and No Slowdown + +The Bitcoin blockchain is split in epochs, each with a targeted duration of two weeks, and only at the end of an epoch the difficulty is reset to accommodate for the variation of the hashing power. Assuming the network is reliable, within an epoch, a selfish miner cannot create more blocks than they would get by honest mining. This follows from a crucial property of proofs of work: there's no way to find more proofs of a given difficulty (and thus blocks) in a given time window than simply following the protocol and always working on the known longest chain. The only thing selfish mining does in Bitcoin is to make honest parties waste their hashing power, so after the next difficulty reset (which only happens every 2 weeks) the difficulty is lower than it should be, and only at this point the selfish miner makes some extra profit. Another property of PoW based chains like Bitcoin is that an adversary cannot slow down chain growth. We capture these two desirable properties separately below. + +**Delayed Gratification:** A chain where an adversary cannot increase the number of blocks they find in expectation within an epoch of same difficulty by deviating from the honest strategy is said to have the _delayed gratification_ property. In $\textrm{{\sf Chia}}$, by "not deviating" we mean that the adversary simply runs an honest farmer using its available space, and additionally, should the adversary control VDFs that are faster than the fastest honest time lord, they are also assumed to run a time lord. Intuitively, delayed gratification is a good deterrent to selfish mining by itself as it limits selfish mining to adversaries who follow a "long term" agenda. + +**No Slowdown:** A chain where an adversary (no matter what fraction of the resource they control) cannot slow down the expected block arrival time by interacting with the chain is said to have the _no slowdown_ property. + +## 3.3 Chain Quality + +A longest-chain blockchain is said to have _chain quality_ $\rho$ if the fraction of blocks mined by honest miners is at least $\rho$ (with high probability and considering a sufficiently large number of blocks). Chain quality was introduced in [GKL15] as a metric to quantify how susceptible a chain is to selfish mining. Ideally, assuming an adversarial miner who controls an $\alpha$ fraction of the resource, the chain quality should be $\rho=1-\alpha$ as this means that the adversary cannot increase its fraction of blocks by deviating. + +By the Proposition below delayed gratification and the no slowdown property imply a bound on _chain quality_ which matches the bound proven for Bitcoin (when ignoring network delays). + +--- + +**Proposition 1** (Delayed Gratification and No Slowdown implies Chain Quality). _Consider a longest-chain protocol which has the delayed gratification and no slowdown property against an adversary who controls an $\alpha$ fraction of the global resource, then the chain quality is $1-\frac{\alpha}{1-\alpha}$ (compared to the ideal $1-\alpha$)._ + +_Proof._ Consider an adversarial miner ${\cal A}$ with an $\alpha$ fraction of the resource and let $\ell$ denote the (expected) number of blocks to be found if everyone would mine honestly. By the no slowdown property, no matter what ${\cal A}$ does the number of blocks found is at least $\ell'\ge (1-\alpha)\cdot\ell$. By delayed gratification, at most $\alpha\cdot\ell$ of those blocks were created by ${\cal A}$, we get a chain quality of + +$$ +\begin{aligned} +\textit{chain quality}&=\frac{\text{honest blocks}}{\text{total blocks}}\\ +&=\frac{\ell' - \alpha \cdot \ell}{\ell'}\\ +&=1-\frac{\alpha\cdot\ell}{\ell'}\\ +&\ge 1-\frac{\alpha\cdot\ell}{(1-\alpha)\cdot \ell}\\ +&=1-\frac{\alpha}{1-\alpha} +\hspace{10em}\square +\end{aligned} +$$ + +--- + +## 3.4 Delayed Gratification in Chia + +Having motivated why the no slowdown and delayed gratification properties are useful, in this and the next section we will sketch how they are achieved in Chia. Recall that delayed gratification means a selfish farmer cannot add more blocks into the chain than he could by honestly following the protocol. To achieve this in $\textrm{{\sf Chia}}$ we ensure that + +:::info Objective 1: Unpredictable and Immutable Challenges +(a) a challenge is revealed as late as possible. + +(b)) once it's revealed, it's almost certainly too late for a selfish farmer to influence it in any way. + +(c)) whether a plot can produce a block for a challenge only depends on the plot and the challenge (and not say, on what other plots exist). +::: + +These properties imply delayed gratification as a selfish farmer cannot do anything to influence challenges in a controlled way due to (a) & (b), and cannot do anything to increase its number of winning blocks for a given challenge due to (c). + +We will sketch how properties (a)-(c) are achieved in $\textsf{Chia}$ next. To follow the arguments the reader might want to recap the high level outline in §1.7 and illustration in Figure 1 + +**(a)** The only reason for the infused challenge chain ${\sf i}{\cal CC}$ is to make sure that the challenge becomes known as late as possible, in particular when considering an adversary with a faster VDF than the fastest honest time lord. + +**(b)** We infuse the _first_ block of each slot into the challenge chain ${\cal CC}$, this way making sure that this block is buried deep in the chain (by $31$ blocks on average) once revealed, and thus almost impossible to revert. + +**(c)** We use a variation on the correlated randomness technique from [BDK+19], where we let the challenge depend on every $k$th challenge on average, rather than exactly. This way only the challenge determines whether a plot can produce a winning block, irrespective of what other plots exist. + +## 3.5 No-Slowdown of Chia and other Constructions {#s:nschia} + +Recall that the no slowdown property requires that no adversary can slow down the block arrival time by participating. + +### 3.5.1 No-Slowdown in Bitcoin + +In Bitcoin no slowdown holds as whenever an honest miner finds a block, all the honest miners will switch to a heavier chain. An adversary can still kick out this block and replace it with one of his own (and that's what selfish mining is exploiting), but not slow down the growth. Of course here we assume a reliable network, a network level attacker who can increase the latency or even split the network can of course delay chain growth. + +### 3.5.2 A Non-Example, the G-Greedy-Rule + +One might assume that the no-slowdown property would be achieved by any "natural" longest-chain blockchain even if based on efficient proof systems. Unfortunately this intuition is wrong. A design for which no-slowdown fails to hold is the proof of stake based chain of Fan and Zhou \[FZ17]. Their chain mimics Bitcoin's Nakamoto consensus using proofs of stake, but to harden the design against (what in this writeup is called) double dipping attacks \[FZ17] suggest the miners not only extend the longest chain, but instead follow the "$g$-greedy rule": a miner should try to extend all forks they see which are at most $g$ blocks shorter than the longest chain they've seen so far. The rationale behind this rule is that by letting the honest miners do double-dipping to some extent, the advantage an adversary can get by double dipping shrinks.[^2] As shown in \[BDK+19], this design has some serious issues as an adversary with relatively small resources can with high probability prevent the chain reaching consensus by strategically releasing blocks and this way keep two forks alive for a long time. An illustration of their attack is in Figure 5. Interestingly (citing \[BDK+19]) _"..the efficacy (of the attack) is primarily achieved by slowing down the growth rate of the honest strategy."_ + +
+ alt text
Figure 5: Illustration of the balancing attack against [FZ17] taken from [BDK+19]
+
+ +### 3.5.3 Examples of No-Slowdown. + +The lesson from the example above is that the no-slowdown property is not easy to achieve in longest-chain protocols using efficient proof systems. Moreover the absence of this property can lead to various security issues, not just selfish mining opportunities, but even prevent consensus almost indefinitely as in the example above. Similar attacks were also proposed for BFT type protocol, most notably Ethereum [SNM+21]. + +#### Naïve Emulation of Bitcoin + +There are longest-chain blockchains from efficient proof systems which do have the no-slowdown property. The simplest is to just emulate Bitcoin by replacing PoW with PoSpace or PoStake. While satisfying no-slowdown, this basic construction has all the security issues discussed in §2. Fixing bootstrapping and grinding as outlined in §2 will preserve the no-slowdown property. The challenge is to find a good countermeasure to double-dipping without losing the no-slowdown property and introducing new attack vectors. + +#### $D$-Distance Greedy + +Bagaria et al. [BDK+19] not only prove that $g$-greedy does not have the no-slowdown property, but also suggest a different rule of a similar flavour they call "$D$-distance greedy", for which the no-slowdown property does hold [BDK+19 Lemma 12]. This rule reduces the double-dipping advantage factor towards $1$ as $D$ increases, but already for moderately large $D$ it becomes computationally infeasible for the miners to even determine which chain to follow. + +#### Old $\textsf{Chia}$ + +The first Chia greenpaper [CP19] has a very simple rule where honest farmers try to extend the first $k>1$ ($k=3$ was suggested) chain of any given length they become aware of. For this simple construction the advantage factor of double-dipping goes to $1$ as $k$ increases while it does achieve no-slowdown [CP19 Lemma 4]. + +#### $\textsf{Chia}$ + +While the deployed $\textsf{Chia}$ blockchain has many advantages over the old [CP19] proposal, the no-slowdown property is a much tricker issue in the new design. In particular, we do not yet have an analogue of [CP19 Lemma 4] which basically states that even an unbounded adversary (unlimited space, unlimited number of arbitrary fast VDFs) cannot slow down chain growth. + +When analyzing the no-slowdown property, it is useful to distinguish the specification of the chain (i.e., what constitutes a valid chain) and its chain selection rule (aka. fork choice rule), which tells the farmers and time lords on which chains to work should competing forks exist. + +For example the difference in the $g$-greedy and the $D$-distance greedy protocols discussed above (only the latter having the no-slowdown property) is only in the chain selection rule, the specification what constitutes an valid chain is the same. + +Unlike the chain specification, which can only be changed by a hard fork once the chain is deployed, the chain selection rule can easily be adapted by the farmers and/or time lords even after the launch. Finding a chain-selection rule for the $\textsf{Chia}$ chain which provably achieves no-slowdown is an interesting open problem. + +Under the additional assumption that an adversary does not control VDFs which are _faster_ than the fastest honest time lord, a very simple chain selection rule achieving no-slowdown exists: always follow the chain with accumulated most VDF steps. Of course this rule would be terrible in practice as security completely breaks if the adversary has an even slightly faster VDF than the fastest honest time lord. For example, such an adversary could create an "empty" chain by refusing to infuse any blocks. + +A more sensible rule is to simply follow the _heaviest_ fork like in Bitcoin. Unfortunately, unlike in Bitcoin, in $\textsf{Chia}$ the heaviest fork is not necessarily the fork which will be heaviest in the future assuming all honest parties adapt it: a fork $A$ might have one more block infused than some fork $B$, but if $B$ is way ahead in the VDF computation extending $B$ might give a better chain (in expectation) in the future. Thus, when using this rule, by releasing $B$ an adversary might slow down the chain. The currently deployed chain selection rule for farmers and time lords is basically to follow the heaviest fork, but with some heuristics to avoid clear cases where switching to a heavier chain is slowing down growth. + +[^1]: To achieve such a large fraction we must assume that (1) honest miners follow the (original Bitcoin) rule and in case they learn of two longest chains they always try to extend the one they saw first and (2) that once the selfish miner learns about a block mined by the honest miners, they can release a withheld block such that their block reaches most of the honest miners faster than this honest block. If either of these conditions is not met, selfish mining is much less profitable, and only becomes profitable at all for selfish miners who control a fairly large fraction of the resource [SSZ15]. + +[^2]: A similar proposal, where the honest parties try to extend the first $k$ blocks they see at every depth was proposed in an early proposal for $\textsf{Chia}$ (with $k=3$) [CP19]. This variant achieves the no-slowdown property. 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 new file mode 100644 index 00000000000..0a8ee8b0c99 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/green-paper/recovering-from-51-percent-attacks.md @@ -0,0 +1,178 @@ +--- +title: Recovering from 51% Attacks and Dynamic Availability - Chia Green Paper +sidebar_label: 6 - Recovering from 51% Attacks and Dynamic Availability +slug: /chia-blockchain/green-paper/recovering-from-51-percent-attacks +--- + +# 6 - Recovering from 51% Attacks and Dynamic Availability + +In this Section we have a look at two closely related security properties of longest-chain blockchains, namely recovery from malicious majority (aka. 51% attacks) and security under dynamic availability. We'll discuss proofs of work, stake and space, for the latter two also looking at how adding VDFs changes the picture. + +We discussed in §2 the main security issues of a PoSpace based longest-chain blockchain arise from the fact that PoSpace is an efficient proof system. PoSpace shares those security challenges with PoStake, and all three countermeasures summarized in Figure 3 (namely splitting the chain to prevent grinding, correlated randomness to prevent double-dipping and using VDFs to prevent bootstrapping) can readily be applied in the stake setting, correlated randomness was even originally proposed for stake [BDK+19]. But as we'll discuss below, when it comes to security under dynamic availability or 51% attacks there are fundamental differences between space and stake. In particular, using proofs of space in combination with VDFs one can handle both attacks basically as well as with proofs of work, while proofs of stake cannot, even in combination with VDFs. + +{' '} + +
+ ![](/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 + +A key difference between a PoW based longest-chain protocol and a longest- chain protocol based on an efficient proof system like PoStake or PoSpace is the fact that only the PoW based chains is guaranteed to recover security once an adversary that controls a sufficiently large fraction of the resource, even if it's just for a short period. This is sometimes called "a $51\%$ attack" referring to the fact that in bitcoin an adversary controlling $>50\%$ of the hashing power can break security in pretty much any way they like (they can double spend, get $100\%$ of the block rewards or censor). We'll stick with this expression even though the fraction of the resource required to control a chain can be lower than $50\%$ (as mentioned in §1.1, in ${\sf Chia}$ controlling $43\%$ of the space is sufficient). + +There's also a key difference between PoStake and PoSpace. By using VDFs in addition to PoSpace as in $\textsf{Chia}$ we get a chain that does have this self- healing property. While we can also augment a PoStake based chain with VDFs [DKT21], the resulting chain will not be self-healing. + +### 6.1.1 Recovering from PoW Majority in Bitcoin {#S:RBB} + +While Bitcoin provides no security if more than half of the hashrate is controlled by an adversary, it is "self-healing" in the sense that once the majority of the hashrate is again controlled by honest parties, Bitcoin regains (after some delay) all its security properties. + +A bit more formally, let ${\sf PoW}_h(t)$ and ${\sf PoW}_a(t)$ denote the hashing power of the honest and adversarial parties at clock time $t$, respectively. For $t_0eq.(11) + +If this holds the adversary can simply start at time $t_0$ to mine a chain in private, and release it at time $t_1$. By the first inequality the adversaries chain will be heavier than the honest one with probability at least $0.5$, and by the 2nd the honest block added at time $t$ will be buried by $k$ blocks with probability $0.5$, so both hold and we have a successful double spending attack with probability at least $\approx 0.5^2=0.25$ (it can actually be a bit less than that as the two events are negatively correlated). + +To be secure it's not sufficient that no $t_0,t_1$ as in eq.(11) exist, but one needs to be "sufficiently far" from this situation to guarantee that double spending can only happen with some tiny probability. From the standard Chernoff bound it follows that the probability that a fork starting at a block added at time $t_0$ and being released at time $t_1$ will be successful (i.e., have higher weight than the honest chain) is exponentially small in the number of expected honest blocks ${\sf PoW}_h(t_0,t_1)/D$ and the square of the honest to adversarial advantage, i.e., + +$$ +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoW}_h(t_0,t_1)}{D} \cdot\left( \frac{\mathsf{PoW}_h(t_0,t_1)}{\mathsf{PoW}_a(t_0,t_1)}-1 \right)^2\right) +\end{aligned} +$$ + +
eq.(12)
+ +### 6.1.2 Recovering from PoStake Majority + +This is in stark contrast to PoStake based longest-chain protocols, where once an adversary gets hold of keys controlling a sufficiently large amount of stake, security cannot be recovered by the honest parties without resorting on some external mechanism. The reason is bootstrapping as discussed in §2.3: an adversary who holds keys which at some point in the chain controlled stake $N$, can fork at that point and bootstrap a chain to the present that looks as if they had $N$ stake throughout. The issue is aggravated due to "stake-bleeding" [GKR18], which refers to the fact that the fork can amass additional stake through fees and block-rewards. + +### 6.1.3 Recovering from PoSpace Majority + +A longest-chain protocol using only PoSpace (like Spacemint [PKF+18]) is basically as bad as PoStake based protocols when it comes to healing after an adversary got control of a large amount of the resource. One difference is that in the PoStake case the bootstrapping is only possible while the adversary holds the space resource, while bootstrapping in PoStake just requires keys that were valid at some point in the past but can be worthless (i.e., not hold any stake in the chain currently considered by the honest parties) now. On the positive side, stake-bleeding is not an issues for PoSpace. + +### 6.1.4 Recovering from Space-Time Majority in $\textsf{Chia}$ {#S:RPOST} + +While a pure PoSpace based longest-chain protocol fails to heal from adversarial majority due to bootstrapping, by combining space with time as in Chia we prevent bootstrapping, and get a chain that naturally heals from adversarial majority. Though, what exactly constitutes the resource in a PoST protocol is less obvious than e.g. in the PoW or PoSpace setting. We already shortly touched this issue in §1.1. We'll now recap the notion for PoST resources introduced there, but in a more fine-grained manner using a time parameter to reflect that resources can change over time. Let + +| Term | Definition | +| ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| $space_h(t),space_a(t)$ | denote the disk space (more precisely, the space with initialised plots) available to the honest and adversarial parties at time $t$, respectively | +| $vdf_h(t)$ | denote the speed of the (three) VDFs available to the fastest honest and online time lord at time $t$ | +| $vdf_a(t)$ | denote the speed of the VDFs available to the adversary, the number of VDFs available to the adversary is unbounded. | + +:::danger Security Notice 2: Unlimited VDFs +$vdf_h$ only considers the fastest honest time lord, as only they matter for the growth of the honest chain. The adversary on the other hand is allowed an unlimited number of VDFs of speed $vdf_a$. Not putting any bound here makes the security statements stronger, but it might seem to give the adversary an unrealistic advantage. This is not really the case as most of the advantage an adversary can get by using many VDFs (trough double dipping) can already be achieved by using a fairly low amount of VDFs. So it would hardly make a quantitative difference if we put a cap on the number of VDFs, say 100, or simply put no cap at all. +::: + +Define the honest and adversarial resource at time time as the product of their space and VDF speed + +$$ +{\sf PoST}_h(t)=space_h(t)\cdot vdf_h(t)\quad,\quad +{\sf PoST}_a(t)=space_a(t)\cdot vdf_a(t) +$$ + +and analogously to the work setting let the cumulative space-time resource in a window from $t_0$ to $t_1$ be + +$$ +{\sf PoST}_h(t_0,t_1)= \int_{t_0}^{t_1}{\sf PoST}_h(t) \,dt +\quad , \quad +{\sf PoST}_a(t_0,t_1)= \int_{t_0}^{t_1} {\sf PoST}_a(t) \,dt +$$ + +With these definitions we now get a similar bound on the probability that an adversary can create a fork starting at $t_0$ and being released at time $t_1$ as we did for PoW in eq.(12) + +$$ +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoST}_h(t_0,t_1)}{D} \cdot\left( \frac{\mathsf{PoST}_h(t_0,t_1)}{1.47\cdot \mathsf{PoST}_a(t_0,t_1)}-1 \right)^2\right) +\end{aligned} +$$ + +
eq.(13)
+ +A difference to the PoW setting is the additional $1.47$ factor boosting the adversary's resource which is necessary to account for the fact that they can do some bounded double dipping. + +Analogously to the PoW case, a block added at time $t$ can be considered secure even in a setting where the adversary can get temporary majority as long as for all $t_0,t_1,t_01$ (that captures the advantage of the honest parties) and any time $t$ we have + +$$ +{\sf PoW}_a(t)\le f\cdot {\sf PoW}_h(t) +$$ + +
eq.(14)
+ +To see that Bitcoin is secure under dynamic availability we can reuse our inequality eq.(12) which using $\frac{{\sf PoW}_h(t_0,t_1)}{{\sf PoW}_a(t_0,t_1)}\ge f$ simplifies to (recall that $\frac{{\sf PoW}_h(t_0,t_1)}{D}$ is the expected number of honest blocks in the $t_0$ to $t_1$ window) + +$$ +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoW}_h(t_0,t_1)}{D} \cdot\left(f-1 \right)^2\right) +\end{aligned} +$$ + +
eq.(15)
+ +Which simply means that the probability that an adversary will be able to create any particular a fork decreases exponentially in the length of the fork. + +### 6.2.2 Dynamic Availability for PoST ($\textsf{Chia}$) + +Analogously to PoW just outlined, and using notation from §6.1.4 we can define dynamic availability for PoST as used in $\textsf{Chia}$ by requiring that at any time $t$ + +$$ +{\sf PoST}_a(t)\le f\cdot {\sf PoST}_h(t) +$$ + +
eq.(16)
+ +With this eq.(13) becomes + +$$ +\begin{aligned} +&\text{Pr}\left[\text{fork starting at } t_0 \text{ and released at } t_1 \text{ heavier than honest chain}\right] \\ +&\le -\exp\left(\frac{\mathsf{PoST}_h(t_0,t_1)}{D} \cdot\left( \frac{f}{1.47}-1 \right)^2\right) +\end{aligned} +$$ + +
eq.(17)
+ +Thus like in Bitcoin, in $\textsf{Chia}$ the probability of a successful fork decreases exponentially fast in the length of the fork. + +Unlike for PoW, to guarantee security it's not sufficient that $f>1$, but we need a more substantial gap in the resources of the honest parties and the adversary to account for double dipping, for parameters as in $\textsf{Chia}$ $f>1.47$ is sufficient. + +### 6.2.3 Dynamic Availability from PoSpace {#S:DAspace} + +While in $\textsf{Chia}$ we achieve security under dynamic availability by using space and time as a resource, it's an intriguing question whether a longest-chain blockchain based on proofs of space alone like Spacemint [PKF+18] could be secure under dynamic availability. + +Surprisingly, the answer is a resounding no as shown in [BP22]. They consider a setting where the chain progresses in steps, where a step happens every time a new challenge is picked. The adversary can change the amount of space available to the honest parties by a factor $1\pm\epsilon$ with every step, and the space available to them is always a factor $f>1$ smaller than what the honest parties have. Moreover the space can be replotted in $R$ steps. Their result states that no matter what chain selection rule is used, in this setting a PoSpace based blockchain can always be successfully forked by an adversary with a fork of length at most $R\cdot \epsilon/f^2$ steps. This bound is tight as a (albeit fairly complicated and thus not practical) chain selection rule achieving this bound exists. + +### 6.2.4 Dynamic Availability from PoStake + +The impossibility from [BP22] just discussed does not translate to proofs of stake based chain as there's no analogue for replotting in the stake setting. In fact, PoStake based longest-chain protocols secure under dynamic availability do exist [BGK+18]. The Ouroboros genesis chain selection rule from this paper works as follows: given two competing chains, one just compares the chains at a fairly short window right after the fork. Intuitively, the reason such a chain selection rule does not provide security under dynamic availability for space is because an adversary could use replotting to make this short window have large weight, thus create a winning chain even with much less space than the honest party. + +[^1]: If there's an epoch switch at some $t,t_0 + Challenge chain diagram
+ Figure 7: The reward, challenge and infused challenge chains. For illustration we only use 8 not 64 signage points per sub-slot. +
+ + +## 5.1 Additional Variables and Notation for this Section + +### 5.1.1 Variables + +| 变量 | Definition | +| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| $T_i$ | Time parameter of $i$-th slot (# of VDF steps per sub-slot). Recalibrated once per day for 10 minutes per sub-slot target. | +| $\mathsf{spi}_i$ | $$\mathsf{spi}_i \stackrel{\text{\tiny def}}{=} \frac{T_i}{64}$$ | +| $D_i$ | Difficulty parameter of $i$-th slot. Recalibrated once per day for 32 blocks per slot target | + +### 5.1.2 Step to Epoch + +$\kappa_i$ :Number of sub-slots in $i$th slot. Typically $\kappa_i=1$ but can be larger integer to enforce a $16$ block minimum. + +### 5.1.3 Notation for Points of Interest + +To describe the $\textsf{Chia}$ chains it will be convenient to introduce some extra notation. Recall that for a VDF $\tau$ or VDF chain ${\cal V}$ we denote with $\tau[t]$ or ${\cal V}[t]$ the point $t$ steps into the computation. $\tau.{\sf t},{\cal V}.{\sf t}$ is the total number of steps. Sometimes we overload notation and consider $\tau,{\cal V}$ to denote the point at the end of the computation rather than the entire VDF or VDF chain, i.e., $\tau=\tau[\tau.{\sf t}],{\cal V}={\cal V}[{\cal V}.{\sf t}]$. + +The VDF chains we'll consider (${\cal RC}$ and ${\cal CC}$) will be split into slots where the starting point of a new slot will always be an infusion point. For a point ${\sf point}={\cal V}[t]$ on such a chain we denote with + +| Point | Definition | +| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ${\sf point}.{\sf D}$ | the total depth, i.e., the number of steps of this point since genesis | +| ${\sf point}.{\sf d}$ | the depth of this point in the current slot | +| ${\sf point}.{\sf t}$ | the depth of this point in its VDF | +| ${\sf point}.{\sf x}$ | the value of the VDF chain at this point | +| ${\sf point}.\pi$ | a proof certifying the VDF computation up to this point | +| ${\sf point}^+$ | If ${\sf point}$ is an infusion point where some value $v$ gets infused, then we denote with ${\sf point}$ the point before infusion, and with $${\sf point}^+ = {\sf VDF.sample}({\sf point}.{\sf x},v)$$ the point after infusion | + +The following points on the $\textsf{Chia}$ VDF chains will be defined + +| Point | Definition | +| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | +| ${\sf cc\_sp}_{i,j}$ | The $j$th **challenge chain signage point** in the $i$th slot (eq.(6)) | +| ${\sf rc\_sp}_{i,j}$ | The $j$th **reward chain signage point** in the $i$th slot (eq.(9)) | +| ${\sf cc\_sp}(\beta)$ | he ${\sf cc\_sp}_{i,j}$ used as challenge to compute the PoSpace $\sigma$ in block $\beta$ | +| ${\sf rc\_sp}(\beta)$ | The ${\sf rc\_sp}_{i,j}$ whose signature $\mu_{{\sf rc\_sp}}$ is in $\beta$ | +| ${\sf rc\_ip}(\beta)$ | The infusion point of $\beta$ into ${\cal RC}$ (eq.(10) | + +The _signage point interval_ is the number of VDF steps between signage points, for the $i$th slot it's + +$$ +{\sf spi}_i \stackrel{\scriptsize \sf def}{=}T_i/64 +$$ + +so e.g., the depth of the $j$th signage point in the $i$th slot is $\mathsf{rc\_sp}_{i,j}.\mathsf{d} = \mathsf{cc\_sp}_{i,j}.\mathsf{d} = j \cdot \mathsf{spi}_i$. A block in the $i$th slot will be infused 3 to 4 signage point intervals past its signage point. + +$$ +3\cdot {\sf spi}_i\ <\ +{\sf rc\_ip}(\beta_T).{\sf d}\ -\ {\sf rc\_sp}(\beta_T).{\sf d}\ < \ 4\cdot {\sf spi}_i +$$ + +The first signage point in a slot is the last signage point after infusion + +$$ +{\sf rc\_sp}_{i+1,0}={\sf rc\_sp}_{i,\tau_i\cdot 64}^+ +$$ + +The $i$th slot starts at total depth + +$$ +{\sf rc\_sp}_{i,0}.{\sf D}=\sum_{j=1}^{i-1}T_j\cdot \kappa_j +$$ + +## 5.2 The Challenge Chain + +The challenge chain ${\cal CC}$ is a VDF chain whose data and VDF values we'll denote as + +$$ +{\cal CC}={\sf ic}_0, \tau^{{\cal CC}}_1,{\sf ic}_1,\tau^{\cal CC}_2,{\sf ic}_2,\ldots +$$ + +Here $\tau^{\cal CC}_i$ is the VDF computation for the $i$th slot. Usually its number of VDF steps is the current time parameter $T_i$ (and should take 10 minutes to compute), but in exceptional cases it can be an integer multiple $\kappa_i\in\mathbb{N}$ of that as we enforce a 16 block minimum per slot + +$$ +\tau^{\cal CC}_i.{\sf t} = \kappa_i\cdot T_i +\qquad\textrm{typically $\kappa_i=1$} +$$ + +The value ${\sf ic}_i$ infused at the beginning of slot $i+1$ depends on the first block in slot $i$, we'll explain how exactly in §5.5. + +As the VDF $\tau^{\cal CC}_i$ of the $i$th slot is computed by a time lord, they release equidistant points of this computation called the _challenge chain signage points_, one every ${\sf spi}_i=T_i/64$ VDF steps or around $9.375=600/64$ seconds + +$$ +{\sf cc\_sp}_{i,0},{\sf cc\_sp}_{i,1},\ldots,{\sf cc\_sp}_{i,\tau_i\cdot 64}\quad\textrm{where}\quad {\sf cc\_sp}_{i,j}\stackrel{\scriptsize \sf def}{=}\tau^{\cal CC}_i[j\cdot {\sf spi}_i] +$$ + +
eq.(6)
+ +The point ${\sf cc\_sp}_{i,\tau_i\cdot 64}$ at the end of the slot must also be broadcast as it's required to verify the VDF, but it's not used as a challenge as it's at the same depth as the first signage point ${\sf cc\_sp}_{i+1,0} \gets {\sf VDF.sample}({\sf cc\_sp}_{i,\tau_i\cdot 64},{\sf ic}_i)$ of the next slot. + +:::tip Design Choice 1: A Continuous Flow of Challenges +To get the security gains of correlated randomness, we let our PoSpace challenges depend on only one block (out of around 32) per slot, so there's a fresh challenge every 10 minutes. At the same time, we want a smooth continuous block arrival time (target is 18.75 seconds) and the challenge for each block should be revealed around 30 seconds before the block is infused (not much less to avoid orphan blocks, not much more to limit selfish mining and bribing opportunities). Deriving challenges ${\sf cc\_sp}_{i,1},{\sf cc\_sp}_{i,2},\ldots$ deterministically from one initial challenge ${\sf cc\_sp}_{i,0}$ using a delay function as outline above achieves exactly that. +::: + +The reward chain ${\cal RC}$ is a VDF chain that the time lords evaluate in parallel to ${\cal CC}$ and also has signage points at the same depth as ${\cal CC}$, i.e., ${\sf rc\_sp}_{i,j}.{\sf d}={\sf cc\_sp}_{i,j}.{\sf d}$. Before we can define ${\cal RC}$ we first need to explain the content of blocks. + +## 5.3 Trunk Blocks {#S:TB} + +Whenever a farmer receives new signage points ${\sf cc\_sp}_{i,j},{\sf rc\_sp}_{i,j}$ they first check whether this points lie on a heaviest chain (cf. the discussion in §1.5) and their VDF proofs verify. If the this is the case, the farmer checks they can create a winning PoSpace proof. This process will, for a subset of the plots, produce a PoSpace $\sigma$ and some additional value $\sigma.{\sf required\_iterations}$. Whether this PoSpace is a winning proof is now determined by the time parameter $T_i$ as + +$$ +\textrm{winning condition : } +\sigma.{\sf required\_iterations} < {\sf spi}_i\quad (=T_i/64) +$$ + +
eq.(7)
+ +:::tip Design Choice 2: Why 32 Blocks in Expectation and not Exactly? +With our winning condition we have 32 blocks per slot _in expectation_ depending on a challenge. We could have used a different design to enforce _exactly_ 32 challenges, but then it would be impossible to achieve our Objective 1.(c), which asks that whether a plot wins must depend solely on the challenge. +::: + +If a farmer has a winning PoSpace $\sigma$ they can produce a block $\beta=(\beta_T,\beta_F)$ which contains the foliage block $\beta_F$ and the trunk block $\beta_T$. The actual $\textsf{Chia}$ blocks are more sophisticated than our description below, but in this writeup we focus on the entries which are absolutely necessary for functionality and security of the chain and ignore entries which are there for efficiency like weight proofs for light clients or pooling. They key entries in a valid trunk block + +$$ +\beta_T=(\sigma,\mu_{{{\sf rc\_sp}}}) +$$ + +are + +$\sigma\gets {\sf PoSpace.prove}(S,{\sf cc\_sp}_{i,j})$, a proof of space for some plot $S$ on challenge ${\sf cc\_sp}_{i,j}$ where the proof $\sigma$ satisfies the winning condition from eq.(7). + +$\mu_{\sf rc\_sp}\gets {{\sf Sig.sign}}(S.sk,{\sf rc\_sp}_{i,j})$, a signature using the secret key of the plot $S$ (so it verifies under the public-key $\sigma.pk$ in the PoSpace) of the signage point in the rewards chain discussed in the next section. + +## 5.4 The Reward Chain + +The reward chain ${\cal RC}$ is a VDF chain that time lords compute in parallel to ${\cal CC}$. Like ${\cal CC}$, ${\cal RC}$ can be spilt in a sequence of slots. + +$$ +{\cal RC}={\cal RC}_1,{\cal RC}_2,\ldots +$$ + +While in ${\cal CC}$ the $i$th slot just contains a VDF $\tau^{\cal CC}_i$ and the value ${\sf ic}_i$ infused at the end, each slot ${\cal RC}_i$ of the ${\cal RC}$ chain + +$$ +{\cal RC}_i=\tau^{\cal RC}_{i,1},\beta_1,\tau^{\cal RC}_{i,2},\beta_2\ldots, \beta_{b_i} \tau^{\cal RC}_{i,b_i+1},({\sf ic}_i,\tau^{\cal CC}_{i}.{\sf y}) +$$ + +
eq.(8)
+ +is a VDF chain with typically around $33$ infused values: around 32 blocks $b_i$ and at the end of the slot also the ${\cal CC}$ and ${\sf i}{\cal CC}$ points at the same depth. The ${\cal RC}$ signage points are + +$$ +{\sf rc\_sp}_{i,j}\stackrel{\scriptsize \sf def}{=}{\cal RC}_i[j\cdot {\sf spi}_i] +$$ + +
eq.(9)
+ +#### Where do Blocks get Infused. + +Let $\beta_T=(\sigma,\mu_{{{\sf rc\_sp}}})$ be some valid block for challenge ${\sf cc\_sp}(\beta_T)$, its reward chain infusion point ${\sf rc\_ip}(\beta_T)$ is then at depth + +$$ +{\sf rc\_ip}(\beta_T).{\sf d}={\sf rc\_sp}(\beta_T).{\sf d}+3\cdot {\sf spi}_i+\sigma.{\sf required\_iterations} +$$ + +
eq.(10)
+ +As $\sigma.{\sf required\_iterations}$ is at most ${\sf spi}_i$ the infusion point is somewhere between 3 and 4 signage points past the signage point it refers to. That means we have somewhere from 28.125 to 37.5 seconds for a round trip from the time lord who gossips the signage point, to a farmer who computes and gossips a block, back to the time lord who then infuses the block. + +## 5.5 The Infused Challenge Chain + +Recall that the challenge chain ${\cal CC}$ is used to create PoSpace challenges, and we want these challenges to only depend on one block per slot. For this, at the end of the $i$th slot we infuse the PoSpace $\sigma$ from the first trunk block $\beta_T$ whose signage point is in the $i$th slot into ${\cal CC}$. We don't simply infuse $\sigma$, but to delay revealing the challenge for as long as possible and make sure it's buried deep in the chain when revealed, we run a VDF on top of $\sigma$ to get the infused challenge value ${\sf ic}_i$ to be infused as defined in §5.2. + +Concretely, the infused challenge of the $i$th slot is the output of a VDF computation + +$$ +{\sf ic}_i\stackrel{\scriptsize \sf def}{=}\tau.{\sf y}\qquad \tau={\sf VDF.solve}(x,t) +$$ + +on some challenge $x$ and time $t$ which are defined as follows. + +Let $\beta_T=(\sigma,\mu_{{{\sf rc\_sp}}})$ be the first trunk block infused into the $i$th slot ${\cal RC}_i$ past the 3rd signage point, using notion as in eq.(10) + +$$ +\beta_T=\beta_j \textrm{ where }j=\min\{k\ :\ \beta_k.{\sf d}>3\cdot {\sf spi}\} +$$ + +now the challenge $x$ is derived from the PoSpace in this block and the value of ${\cal CC}$ at the depth of its infusion point + +$$ +\quad +x\gets {\sf VDF.sample}(\sigma,{\cal CC}[{\sf rc\_ip}(\beta_T).{\sf D}].{\sf y}) +$$ + +the number of steps $t$ is the the remaining number of VDF steps in the slot, so the value ${\sf ic}_i$ will be available at the end of the slot when it's required, but not earlier + +$$ +t={\sf cc\_ip}_{i,0}.{\sf D}- {\sf rc\_ip}(\beta).{\sf D} +$$ + +:::danger Security Notice 1: Why iCC depends only on σ +We only use $\sigma$, not the entire trunk block $\beta_T=(\sigma,\mu_{{{\sf rc\_sp}}})$, to compute the infused challenge ${\sf ic}_i$. This is crucial to ensure that the challenges depend only on a single challenge per slot. Had we infused the entire $\beta_T$ (as we do into ${\cal RC}$), the challenges would depend on all blocks (as $\mu_{{\sf rc\_sp}}$ depends on ${\cal RC}$ which infuses all blocks) and we would not get security against double dipping. +::: + +:::tip Design Choice 3: Why Infusing the First Block? +Recall that by our Objective 1.(a) we want challenges to be only revealed when necessary and (b) to be immutable once revealed. + +While (b) suggest to infuse the first possible block so it's buried once revealed, for (a) it would be better to use the latest possible block. We go with the first block to achieve (b), and by running a VDF on top of the block we also achieve objective (a). +::: + +:::tip Design Choice 4: Upper and Lower Bounds on Blocks per Slot +The target number of blocks per slot is 32, and there's an upper bound of 64 and lower bound of 16. These bounds make some attacks more difficult. In normal deployment the number of blocks will be close to its expectation, so these bounds should basically never be reached. The lower bound is required to bound the efficacy of double-dipping as sketched in §2.2, while the upper bound is necessary to prevent replotting attacks as explained in §1.8.3. +::: + +:::info Objective 2: The Trunk is (almost) Ungrindeable +To prevent grinding, the only decision that influences the trunk should be whether to add a block or not. We need one exception to this rule: the time-stamps (in blocks in the foliage) are used to recalibrate the time parameter which determines the numbers of VDFs steps per slot in the trunk. This gives a minor grinding opportunity, to further limit the usability of this for attacks, the window used to calibrate the time parameter is not simply the previous epoch, but shifted $XXX$ back so the relevant time-stamp is already buried deep in the chain. +::: + +:::info Objective 3: ${\cal CC}$ (almost) only Depends on the First Block +To limit the impact of double-dipping we use correlated randomness [BDK+19]). For this the challenge chain ${\cal CC}$ should only depend on the first block in every slot. If this was the case, this would allow for long-range replotting attacks. For this reason, once every sub-epoch (approx 2h) the rewards chain is infused to the challenge chain. +::: + +## 5.6 The Foliage + +Whenever a farmer finds a winning PoSpace they can create a block $\beta=\{\beta_F,\beta_T\}$ which contains the trunk block $\beta_T$ as discussed above, and a foliage block + +$$ +\beta_F=\{{\sf data},\mu_F\} +$$ + +which contains the payload of the block ${\sf data}$ (transactions, a time-stamp) and a signature (using the key $S.sk$ as for $mu_{\sf rc\_sp}$, cf.§5.3}) + +$$ +\mu_F \gets {{\sf Sig.sign}}(S.sk,(\beta_T,\beta'_F)) +$$ + +that links this foliage block to the chain. It signs the (hashes of the) current trunk block $\beta_T$ as well as the foliage block $\beta'_F$ from the last transaction block as discussed below. + +While _every_ valid trunk block will typically be infused into ${\cal RC}$ (unless the time lord is malicious, the block arrives too late to be infused or the slot is already at its 64 block upper limit), only a subset of the foliage blocks are included in the foliage chain ${\cal FC}$ for reasons outlined below: + +:::info Objective 4: Block Arrival vs. Creation Time +We want blocks to arrive at a rather high frequency ($9.375$ seconds on average) to achieve fast confirmation. At the same time we want to give sufficient time ($28.125$ to $37.5$ seconds between signage and infusion points of a block) for block creation to prevent oprhan blocks. +::: + +:::info Objective 5: Sequential Transaction Blocks +Every block of transactions added must refer to the previous block of transactions. This way we avoid having to deal with transactions that are invalid due to previous transactions that were added but were not known to the creator of the current transaction block. +::: + +:::tip Design Choice 5: Foliage +To achieve the above objectives, we let farmers who found a winning PoSpace and can create a block always create a foliage block referring to the last transaction block before the signage point of their block. The time lord will add the foliage of a block – and thus make this block a _transaction block_ – if no other transaction block was infused between the signage and infusion point of that block. +::: + +## 5.7 Fraction of Transaction Blocks + +With the above rule, we expect one transaction block every $\left(\frac{1}{e^{0.5}-1}+4\right)\approx 5.54$ slots, that's one every $51.95$ seconds and corresponds to $36\%$ of all blocks. + +For the interested reader, let us shortly outline how the above is determined. The signage points of consecutive transactions blocks must be at least 4 points apart as a block with signage point ${\sf rc\_sp}_i$ is infused somewhere between ${\sf rc\_sp}_{i+3}$ and ${\sf rc\_sp}_{i+4}$. The gap can be bigger than $4$ points if no block is found in response to ${\sf rc\_sp}_{i+4}$ and potentially more points after that. The expected number of blocks found for each slot is $0.5$ (32 block target for 64 points). The number of blocks found for each slot is Poisson distributed with expectation $0.5$ ($32$ block target for $64$ points). With this distribution, the expected number of consecutive points with no blocks is $\frac{1}{e^{0.5}-1}$. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/introduction.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/introduction.md new file mode 100644 index 00000000000..9f72ef8f1b8 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/introduction.md @@ -0,0 +1,57 @@ +--- +sidebar_label: Intro to Chia +title: Introduction +slug: /chia-blockchain/introduction +--- + +# Chia简介 + +Chia是一种具有智能交易能力的加密货币和区块链。 它从头开始设计，旨在使加密货币比现金更易于使用，更难于丢失。 + +Its [Proof of Space and Time](/chia-blockchain/consensus/consensus-intro) is the only Nakamoto consensus algorithm since Proof of Work, while also having a [much lower energy consumption](https://chiapower.org). Chia 的愿景之一是改善区块链行业的碳足迹。 + +Chia的主网于2021年3月19日推出。 Development of its ecosystem is ongoing, with primitives released for [CATs](https://chialisp.com/cats), [NFTs](https://chialisp.com/nfts), [Offers](https://chialisp.com/offers), and [DIDs](https://chialisp.com/dids). + +This page will give a brief overview of Chia and its various components. If you are interested in becoming a Chia farmer, feel free to skip ahead to the [Beginner's Guide to Farming](/reference-client/getting-started/farming-guide). + +## 时空证明（Proof of Space and Time） + +Chia uses a consensus algorithm referred to as [Proof of Space and Time](https://www.chia.net/green-paper). 这使得任何拥有互联网连接和一些可用磁盘空间的人都能参与网络的安全性维护。 + +Because of this process of farming (analogous to mining), Chia has become the most decentralized blockchain in the world, with [over 100,000 nodes](https://dashboard.chia.net/d/em15uQ47k/peer-info) securing the system. 每个节点都存储区块链的历史记录副本，并在网络中传播新的交易。 + +## 硬币模型（Coin Set Model） + +Chia使用硬币模型来跟踪网络的状态。 在这个模型中，硬币（coin）是区块链上的最重要（first-class）对象。 Each coin is locked with a serialized [CLVM](https://chialisp.com/clvm) program called a **puzzle**, which is then hashed to create a **puzzle hash** (which can be converted to an address). 硬币的ID是其父硬币ID、 硬币puzzlehash和硬币金额的哈希值。 + +在Chia中，每笔交易必须包含至少一个硬币的支出。 为了花费一个硬币，必须提供原始的puzzle，以及一个有效的解决方案（solution）和一个可选的聚合签名（aggregated signature）。 Multiple coins can require each other be spent in the same transaction by using **announcements**. + +:::info +For more information, check out the [Coin Set Intro page](/chia-blockchain/coin-set-model/intro) and the [Chialisp.com](https://chialisp.com) website. +::: + +## 矿池（Pooling） + +与许多其他区块链一样，Chia允许连接矿池来确保小规模的农民能够平滑的获得奖励。 然而，Chia的矿池协议具有三个独特的特点。 + +首先，区块是由农民来创建，而不是其所属的矿池。 这个设计决策是与 Chia 的去中心化目标相结合的。 In other blockchains such as Bitcoin, four or five pools control over 51% of the global hashrate on any given day (Sources: [blockchain.com](https://www.blockchain.com/pools), [blockchair.com](https://blockchair.com/bitcoin/charts/hashrate-distribution)). 可以说，攻击比特币最简单的方法就是贿赂这些矿池的运营商。 在Chia中，矿池运营商只负责分发奖励。 他们不能修改区块链。 因此，Chia的矿池协议不会导致中心化。 + +当赢得一个区块时，农民获得奖励的1/8，矿池运营商获得其余的7/8。 这样设计是为了阻止矿池运营商通过在竞争池上进行挖矿（耕种，farming），然后在找到证明时不创建区块来损害竞争对手（独自耕种的农民在创建区块时会获得全部奖励）。 + +加入矿池无需权限，因此农民无需注册即可加入。 只需在区块链上进行一笔小交易，仅需1个mojo和交易手续费。 + +:::info +For more information, check out the [Pool Protocol page](/chia-blockchain/protocol/pool/pool-protocol). +::: + +## 其他亮点 + +Chia 还有许多其他创新，其中一些包括： + +- **BLS signatures**, which allow aggregating all of a block's signatures together. +- **Scalability and performance** improvements, which allow running a Chia node on a Raspberry Pi. +- **Weight proofs and light clients**, which enable fast syncing from a mobile device. For more info, see [light clients](/chia-blockchain/architecture/light-clients). +- **Chia Asset Tokens** (CATs) are fungible tokens that can be minted from standard XCH. 拥有无限可能！ [Read more on CATs](https://chialisp.com/cats) or watch a [CATs video intro](https://www.youtube.com/watch?v=yxagP_VC8BE). Additionally, a community member has created [TAIL Database](https://www.taildatabase.com/ "TAIL database"), which contains a list of CATs in the wild. +- **Offer files** enable the peer-to-peer exchange of assets, including standard XCH, as well as CATs. [Read more on Offers](https://chialisp.com/offers) or watch a [brief intro video](https://youtu.be/Z2FoZSNtttM "Offers intro on YouTube"). +- **NFTs** enable and drive real-world applications of digital ownership through true marketplace independence, consistent provenance, and digital permanence. We laid out our [vision for NFTs on Chia](https://www.chia.net/2022/05/11/our-vision-for-chia-nfts.en.html) and launched our [NFT1 standard](https://www.chia.net/2022/06/29/1.4.0-introducing-the-chia-nft1-standard.en.html) in June 2022. +- 本文档将向技术受众解释Chia系统不同组件的动机和实现，并深入解释了所有内容的工作原理。 If you would like to skip to how to make dApps (decentralized apps) on Chia, please visit the [Chialisp](https://chialisp.com) website. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/architecture.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/architecture.md new file mode 100644 index 00000000000..790d323b1c1 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/architecture.md @@ -0,0 +1,34 @@ +--- +title: Architecture +slug: /chia-blockchain/keys/architecture +--- + +:::info + +This page details the architecture of keys. For a more general overview of other components, refer to the [Architecture Overview page](/chia-blockchain/architecture/architecture-overview). + +::: + +The following image assumes an architecture where the farmer decides to keep all keys separate. + +- a wallet key that can potentially be cold storage +- local keys within the harvester machine, which are separated from the farmer +- a separate pool key + +Note that in the simplest configuration, a user can run all of the services (wallet, node, harvester, farmer, pool) in the same machine, and thus the same master key is used for all keys. + +
+drawing +
+ +In this configuration, harvesters only store plot files, and provide the farmer with signatures by the local sk whenever necessary. + +The farmer machine has its own key, which is used to create signatures of new blocks, and combines them with the local sk signatures. The farmer machine can configure a different wallet address to send the funds to, so the user can keep their spending keys in cold storage. + +Furthermore, the communication channel between the farmer and harvester is authenticated with TLS certificates, which allows the harvester to know if the farmer is trusted. + +The farmer can also communicate with a pool, through the pooling protocol. In this case, the farmer would send periodic messages to the pool, to prove space. Recall from the [Pool Architecture page](/chia-blockchain/architecture/pools) that each block is eligible to create two coinbase reward coins: the pool reward, which is 7/8, and the farmer reward, which is 1/8 + transaction fees. + +After farming a block, the 7/8 coin is absorbed by the pool, and later distributed to pool members. Chia's pool architecture is decentralized, because the farmers run their own node, and pooling does not lead to central control of the system. + +If using a pool contract puzzle hash, the pool signature is not included in the block. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/keys-and-signatures.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/keys-and-signatures.md new file mode 100644 index 00000000000..39d3ac92e0c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/keys-and-signatures.md @@ -0,0 +1,92 @@ +--- +title: Keys and Signatures +slug: /chia-blockchain/keys/keys-and-signatures +--- + +This section will explain the different types of keys in the Chia network. It will also cover how the keys are generated, stored, and used. These systems are designed to be flexible enough to support many different configurations and pooling setups and to be resilient to various attacks. + +All Chia keys are [BLS-12-381](https://github.com/supranational/blst/) private keys, following the [IETF specification](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/), the [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333) specification for key derivation and [BIP 44 registered](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). Private keys are 32 bytes, public keys 48 bytes, and signatures 96 bytes (public keys are points in G1, signatures are points in G2.) + +:::warning +There is a slight difference between Chia's implementation and EIP-2333, as described in the next section. +::: + +BLS signatures allow for many features and optimizations, such as non-interactive m/n thresholds, aggregation of all signatures in a block, and tricks like combining two coins into the same transaction. Private keys can be generated by using a 24-word mnemonic phrase, which users can use to back up and restore their wallets. + +A 24-word mnemonic phrase is used as entropy in order to generate a private BLS key. The recommended method of key backup is to store the 24-word phrase offline. Recovery can then be performed by entering the 24-word phrase. The private key is not required for recovery. + +In theory, wallet recovery could also be performed from the master private key alone. However, there are some caveats: + +- Chia Network Inc has not attempted this, and has no plans to attempt it. In fact, as far as we know, nobody has attempted it, so it is not guaranteed to work. It is not supported, and likely never will be supported. Use at your own risk +- Because this is not supported, you would need to create your own wallet in order to perform this recovery +- Even after a successful wallet recovery, you would not be able to recover your 24-word mnemonic phrase. The phrase is used as entropy to generate a private key; a phrase _cannot_ be generated _from_ a private key + +The BLS master private key is stored in the OS keychain, which usually requires password authentication and is encrypted. + +:::note +In theory, wallet recovery should be possible on a new system by copying the keychain from a system on which the wallet has already been installed. However, this is not supported. The only supported method of wallet recovery is with the 24-word seed phrase. +::: + +The master private key can be used to derive child keys, which can further be used to derive child keys, etc. The number of levels can be infinite. BLS public keys can be combined to form a new public key, which can be used to validate aggregate signatures. + +Each time the wallet generates a new address to receive funds, it creates a new BLS private key. The farmer and pool only use the first key in the current codebase, but they can be updated to generate a new key every time a block is won, for additional privacy. + +When it comes to getting paid, a program is created that uses one of the wallet BLS public keys. This program, called a _puzzle_, is hashed to generate a puzzle hash. The puzzle hash is then converted to an address in bech32m format, for easy error correction and usability. + +So an address is analogous to a wallet child BLS public key, the private key of which can be derived from the master seed. + +
+drawing +
+ +## Difference between Chia and EIP-2333 + +Chia's plot format uses keys compliant with the [IRTF CFRG BLS standard](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/). After Chia had already committed to this standard, a new optional change was introduced to the salt format. + +Chia uses the following salt: + +`"BLS-SIG-KEYGEN-SALT-" (i.e., an ASCII string comprising 20 octets)` + +Whereas the optional change uses a slightly different salt: + +`H("BLS-SIG-KEYGEN-SALT-") (i.e., the hash of an ASCII string comprising 20 octets)` + +Both of these salts are described in the [BLS signature specification](https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html), which states: + +`For compatibility with prior versions of this document, implementations SHOULD allow applications to choose the salt value.` + +Therefore, the salt Chia uses is compatible with this specification. + +For your reference, here is the change that was introduced after Chia's plot format had been finalized: + +``` + Procedure: + 1. salt = "BLS-SIG-KEYGEN-SALT-" + 2. SK = 0 + 3. while SK == 0: + 4. salt = H(salt) + 5. PRK = HKDF-Extract(salt, IKM || I2OSP(0, 1)) + 6. OKM = HKDF-Expand(PRK, key_info || I2OSP(L, 2), L) + 7. SK = OS2IP(OKM) mod r + 8. return SK + + KeyGen is the RECOMMENDED way of generating secret keys, but its use + is not required for compatibility, and implementations MAY use a + different KeyGen procedure. For security, such an alternative KeyGen + procedure MUST output SK that is statistically close to uniformly + random in the range 1 <= SK < r. +``` + +## Non-Observer vs Observer Keys + +There are two ways in which child keys can be derived from parent keys: non-observer and observer (also called hardened and unhardened). + +Non-observer keys are the default, and only supported, method in the EIP-2333 spec. They are secure, since each key is cryptographically separated -- revealing one key has no impact on the security of its ancestors or siblings. However, non-observer keys are limited in functionality, because they can only be derived through private derivation. That is, a parent _private_ key can be used to derive a child _private_ key, but a parent _public_ key cannot be used to derive a child _public_ key. + +Observer keys do allow public derivation. This enables view-only wallets that support viewing _all_ of your public keys, using only the root (master) public key. This is what is usually done for Bitcoin Hierarchical Deterministic (HD) view-only wallets. It enables more privacy when compared to systems like Ethereum, which reuse the same address for all transactions. + +One advantage of observer keys is tax calculation: if you use a different address for each transaction, you only need to give your accountant your parent public key, who can use it to derive all of your child addresses. This would not be possible with non-observer keys. + +The main security drawback of observer keys is that if you accidentally reveal a single child private key, along with the parent public key, then your parent private key and all sibling keys can be calculated as well. + +At the time of Chia's mainnet launch in March and May 2021, only non-observer keys were used. Beginning with the Light Wallet Beta release (December 2021), observer keys are supported -- and preferred -- for view only-wallet support. The first full release with built-in support for observer keys is 1.3 (February 2022). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/plot-ids.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/plot-ids.md new file mode 100644 index 00000000000..5f208d680ab --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/plot-ids.md @@ -0,0 +1,22 @@ +--- +title: Plot IDs +slug: /chia-blockchain/keys/plot-ids +--- + +A plot ID is a 32-byte value that is used as a deterministic seed to create an entire plot. In other words, two plots with the same plot ID will create byte-identical plot files. Plot IDs are public values that get put into Proof of Space objects. + +A plot ID can be generated in one of two ways, depending on the desired farming method of the plot. + +
+drawing +
+ +1. Farm to pool public key. This method of farming is desirable if solo farming (no pools). To farm a plot like this, we hash together the pool public key and the plot public key (explained later). When successfully farming a block, the pool private key must sign the reward address. The drawback of this method is that if using a pool, the pool cannot be changed, and the plot is tied to the pool forever. + +2. Farm to pool contract address. This method of farming is suitable for users who want to farm to a pool, and to be able to change pools in the future. Most farmers will likely use this method. + +Instead of requiring a signature by the pool, rewards go straight into the puzzle hash (or address), that is encoded into the plot. This address is a smart contract controlled by the user, which specifies the user's current pool. The user can switch pools, with a timeout delay that the pool operator may customize (typically 30 minutes). + +This approach requires creating a blockchain transaction of at least one mojo before farming. Farmers can get 100 mojos for free from the official [faucet](https://faucet.chia.net). + +The plot public key is explained in the next section. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/plot-public-keys.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/plot-public-keys.md new file mode 100644 index 00000000000..c5aaccb926c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/keys/plot-public-keys.md @@ -0,0 +1,48 @@ +--- +title: Plot Public Keys +slug: /chia-blockchain/keys/plot-public-keys +--- + +So, what is the plot public key shown in the previous section? The plot public key can technically be any BLS public key. As long as the correct signatures are included in the block, full nodes will allow it. However, BLS allows us to combine many public keys into one, which allows native N-of-N signatures without full nodes noticing that a multi-signature is used. In the current versions of `chia-blockchain`, we use this to our advantage to increase security. Please note that these schemes are not consensus critical, and therefore some farmers might use different strategies for generating their public keys. + +The plot public key is usually generated in one of two ways, the first for OG Plots, and the second for pooled plots. + +## OG Plots + +- The plot public key is a 2/2 BLS aggregate public key, which is generated by combining the farmer public key with the local public key. +- The local public key is a random key that is created for each plot, and put into the plot. They are not children of any BLS keys, and therefore are totally independent between plots. +- The farmer key is a key that the farmer machine stores. + +## Pooled Plots + +For plots which are generated for use with the Plot NFT pooling protocol, an additional "taproot" secret key is used, making the aggregate key a 3-of-3. This 3rd key can be derived from public information of the other 2 keys, and it ensures that an attacker cannot create two new keys k1 and k2 such that they both add up to the original aggregate key. + +The taproot private key is defined as: + +```python +taproot_sk = BLSKeyGen(sha256(bytes(local_pk + farmer_pk) + bytes(local_pk) + bytes(farmer_pk))) +``` + +Each block requires a signature from the plot key. This means that we need to combine two (or three) signatures: + +1. from the local secret key (generated by the harvester) +2. from the farmer secret key (generated by the farmer) +3. (optional) from the taproot key (generated by the farmer) + +The farmer combines all the signatures to generate the plot signature, which will look like a normal 1-of-1 BLS signature to the rest of the network. + +Note that signatures from both the local secret key and the farmer secret key are required for the block to be valid. A pool operator cannot derive the farmer secret key if they gain access to the local secret key. + +## Plot format + +The plot format depends on whether "farm to public key" or "farm to contract address" is being used. If farming to a contract address, the puzzle hash (address) is directly encoded into the plot. Otherwise, the pool public key is directly encoded into the plot. + +:::note +This is not the exact plot format, there are a few more details that are left out here. +::: + +The important thing is that the harvester is only storing their local key in the plot, but no other keys are required from the harvester. This key alone is not enough to do anything, since it must be combined with the farmer's key. Therefore, compromising the harvester does not allow an attacker to redirect rewards. + +
+drawing +
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/harvester-protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/harvester-protocol.md new file mode 100644 index 00000000000..140ec947b96 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/harvester-protocol.md @@ -0,0 +1,134 @@ +--- +title: Harvester Protocol +slug: /chia-blockchain/protocol/harvester-protocol +--- + +[Harvester protocol source](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/harvester_protocol.py) + +The harvester protocol defines the messages sent between a farmer service and a harvester service. These tend to +be on the same machine for small farmers, but for medium or large farmers they can be in multiple machines. + +## harvester_handshake + +The handshake between farmer and harvester. +A farmer sends this message to harvesters, to initialize them and tell them which +pool public keys and farmer public keys are acceptable to use. + +A farmer can be connected to multiple harvesters, but a harvester should only have one farmer connection. +The harvester can start using plots which have these keys associated with them. + +```python +class HarvesterHandshake(Streamable): + farmer_public_keys: List[G1Element] + pool_public_keys: List[G1Element] +``` + +## new_signage_point_harvester + +This message is a notification from the farmer to the harvester of a new challenge. +The harvester first checks which plots pass the plot filter (see the [Harvester Algorithm page](/chia-blockchain/consensus/chains/harvester-algorithm)), and for those that do, fetches the quality. +This requires around 7-9 random reads (and thus disk seeks) for each quality. +Each plot is expected to have one proof of space (and therefore one quality) on average, so for 50 plots, a harvester would have around 50 qualities. +For those qualities that are sufficiently good to win a block or a pool partial, the whole proof is fetched (64 random reads in the plot), +and then `new_proof_of_space` is sent to the farmer. + +```python +class NewSignagePointHarvester(Streamable): + challenge_hash: bytes32 # The challenge hash for the sub slot in which the signage point lies + difficulty: uint64 # The current blockchain difficulty + sub_slot_iters: uint64 # The current blockchain sub-slot iters + signage_point_index: uint8 # The signage point's index, from 0 to 63. 0 for an end of sub slot signage point + sp_hash: bytes32 # The hash of the signage point, this is == challenge_hash iff the index is 0 + pool_difficulties: List[PoolDifficulty] # List of each pool the farmer is in, and what the difficulty is for that pool + + +class PoolDifficulty(Streamable): + difficulty: uint64 # The current difficulty that is set for plots belonging to this pool contract + sub_slot_iters: uint64 # The pool sub slot iters, which is static for each network (mainnet, testnet) + pool_contract_puzzle_hash: bytes32 # The pool contract puzzle hash which can be in many plots +``` + +## new_proof_of_space + +A successful proof of space that is sent to the farmer. The `challenge_hash`, `sp_hash`, and `signage_point_index` +correspond to the ones sent in `new_signage_point_harvester`. Many proofs can be submitted for each signage point. + +The plot is a string chosen by the harvester to represent the winning plot (and proof index) in future communications +between the farmer and harvester. This can be, for example, the filename of the plot with an additional byte for the index. +This is relevant, because a certain plot can potentially have more than one proof for each signage point, and we want +communications for each proof to be separate and not conflict (specifically to fetch signatures from the harvester). + +```python +class NewProofOfSpace(Streamable): + challenge_hash: bytes32 + sp_hash: bytes32 + plot_identifier: str + proof: ProofOfSpace # The actual proof of space which contains more data, shown below + signage_point_index: uint8 + +class ProofOfSpace(Streamable): + challenge: bytes32 # This is the challenge for the pospace, explained in the Signage and Infusion Points page + pool_public_key: Optional[G1Element] # Only one of these two should be present + pool_contract_puzzle_hash: Optional[bytes32] # Present only for pooled plots + plot_public_key: G1Element # Explained in the keys section + size: uint8 # k size, usually 32 but can vary + proof: bytes # proof bytes, 64 k bit values, total size 8k bytes +``` + +## request_signatures + +This is a request from the farmer to the harvester for a signature from the plot key, for a specific plot (using the +plot identifier from `new_proof_of_space`). The farmer can request signatures from multiple messages. + +```python +class RequestSignatures(Streamable): + plot_identifier: str + challenge_hash: bytes32 + sp_hash: bytes32 + messages: List[bytes32] +``` + +## respond_signatures + +This is a response to `request_signatures`. The local public key is the public key corresponding to the secret key +in the plot. To see more about the keys for plots, look at the [BLS Keys page](/chia-blockchain/keys/keys-and-signatures). + +```python +class RespondSignatures(Streamable): + plot_identifier: str + challenge_hash: bytes32 + sp_hash: bytes32 + local_pk: G1Element # Key in the plot + farmer_pk: G1Element # Key controlled by farmer + message_signatures: List[Tuple[bytes32, G2Element]] +``` + +## request_plots + +A request from the farmer to the harvester for the list of all plots being farmed by the harvester. + +```python +class RequestPlots(Streamable): + pass +``` + +## respond_plots + +A response to `request_plots` request. This message is also sent whenever a new plot is loaded. + +```python +class RespondPlots(Streamable): + plots: List[Plot] + failed_to_open_filenames: List[str] # Filenames for files which cannot be opened + no_key_filenames: List[str] # Filenames for files which cannot be farmed by this farmer + +class Plot(Streamable): + filename: str + size: uint8 + plot_id: bytes32 + pool_public_key: Optional[G1Element] + pool_contract_puzzle_hash: Optional[bytes32] + plot_public_key: G1Element + file_size: uint64 + time_modified: uint64 +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/networking-protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/networking-protocol.md new file mode 100644 index 00000000000..92423414649 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/networking-protocol.md @@ -0,0 +1,102 @@ +--- +title: Networking Protocol +slug: /chia-blockchain/protocol/networking-protocol +--- + +[Shared networking protocol source](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/shared_protocol.py) + +The Chia protocol is asynchronous and peer-to-peer. It runs on top of WebSockets on port 8444 (or other ports for farmers and timelords). All nodes act as both clients and servers, and can maintain long-term connections with other peers. + +Every message in the Chia protocol is composed of bytes, using the Streamable format, and sent as a WebSocket message. Each message is composed of three parts: + +1. A field spanning 1 byte, representing the type of message being transmitted, and how to decode the data. +2. Second, an optional 2-byte ID, which is used per connection to keep track of requests and responses. +3. The data, which is a Streamable encoded representation of one of the protocol messages. + +```python +class Message(Streamable): + # one of ProtocolMessageTypes + type: uint8 + # message id + id: Optional[uint16] + # Message data for that type + data: bytes + +``` + +Chia protocol messages have a max length of `(4 + 2^32 - 1) = 4294967299` bytes, or around 4 GB. + +## Handshake + +All peers in the Chia protocol (whether they are farmers, full nodes, timelords, etc.) act as both servers and clients (peers). As soon as a connection is initiated between two peers, both peers send a Handshake message, and a HandshakeAck message to complete the handshake. A peer's node_id is the SHA-256 hash of their [x.509](https://en.wikipedia.org/wiki/X.509) [DER](https://wiki.openssl.org/index.php/DER) certificate. + +```python +class Handshake(Streamable): + network_id: str # Network id, ex. mainnet, testnet11, simulator0 + protocol_version: str # Protocol version to determine which messages the peer supports + software_version: str # Version of the software, to debug and determine feature support + server_port: uint16 # Which port the server is listening on + node_type: uint8 # NodeType (full node, wallet, farmer, etc.) + capabilities: List[Tuple[uint16, str]] # Key value dict to signal support for additional capabilities/features + +``` + +After the handshake is completed, both peers can send Chia protocol messages, and disconnect at any time by closing the WebSocket. + +## Heartbeat + +Heartbeat messages are sent periodically by the WebSocket libraries. Peers that are unresponsive will therefore be disconnected. + +If a node does not receive any message from a peer for a certain period of time, even if heartbeats are being received, then the node will disconnect and remove the peer from the active peer list. + +## Introducer + +Please refer to the [chia seeder documentation](https://docs.chia.net/guides/seeder-user-guide/) for more information on setting up you own chia seeder / introducer and how to have it included in the default chia config.yaml. + +When a new node joins the network, it randomly connects to existing nodes on the network. + +To facilitate this process, a number of introducer nodes will temporarily be run by Chia and other users, which will crawl the network and support one protocol message: get_peers_introducer. The introducer will then return a random subset of known recent peers that the calling node will attempt to connect to. + +DNS introducers are also available at different names, which return random reliable peers to connect to. + +For example: `dig dns-introducer.chia.net`. + +More DNS introducers will be recruited in the future; check the [chia-blockchain repository](https://github.com/Chia-Network/chia-blockchain) for updates. The introducer is only contacted at initial launch of the application, or if the peer database has no good peers. + +## RPC + +Aside from the Chia protocols described in the next page, there is also a local RPC protocol to allow simple control over a node or wallet through HTTPS. All requests and responses for the RPC protocol are in JSON, to simplify the interface. This allows doing things like getting the tips of the chain, getting a specific block, adding connections, stopping the node, etc. The full node UI connects to the full node using the RPC. + +The RPC APIs are provided in both WebSocket and HTTPS format. + +## Incoming and Outgoing Connections + +The Chia software has multiple rules and checks to make sure a node is connected to several good peers. + +For example, outgoing connections (connections which our node makes to external nodes) are ranked higher than incoming ones. This is because we cannot verify whether incoming peers are part of an attack or not. + +Each node will try to connect to 8 (implementation-dependent) external peers. As long as a node is connected to at least one fast and non-malicious peer, the node should be able to keep up with, and maintain, consensus with the heaviest blockchain. + +## Bans + +If a peer appears to be acting dishonestly, it can be disconnected and temporarily banned from reconnecting. Reasons for banning include (but are not limited to) exceeding the limits provided for each type of protocol message, sending invalid information, and making the node throw an exception when handling a message. + +The duration of the ban depends on the severity of the issue. Care should be taken to not ban honest peers by accident. Different implementations might have larger or different rate limits as well. + +## Certificates + +All connections between nodes are encrypted and signed with X.509 signed certificates. Each node generates an X.509 certificate and signs it with the Chia CA (Valid To: January 21, 2031, Serial Number: 5c8a71239328650eb9fef85cec32bf779ca6a0c5) for node connections on port 8444. Node IDs are derived by hashing the public key of the certificate, so each node can have a consistent node ID to use for authentication. Each node will also generate and have its own private CA and self-sign certificates for local connections to services like farmer and harvester. + +## Peer gossiping + +Peers are broadcasted within the network with `request_peers` and `respond_peers` messages. The `respond_peers` message contains up to 1000 peers, each having its IP address, its port and an estimate of its last active timestamp. + +Data received from `respond_peers` messages or from the introducers are stored in peer tables, similar to Bitcoin's. The tables will be used to randomly select peers in order to establish the outgoing connections. If we've successfully connected with the peer at least once, it is stored in the "tried" table. Otherwise, it is stored in the "new" table. The tried table protects the node from attacks (i.e. eclipse attacks), as an attacker won't be able to easily alter it (all peers initially go into the new table). Periodically, feeler connections are made in order to increase the number of entries in the tried table: we select a peer from the new table and if it's reachable, we move it to the tried table and then we disconnect it. Additionally, peer tables are stored on disk (in the `peers.dat` file) every 15 to 30 minutes, and then loaded every time the node restarts. + +Both new and tried tables optimize for the network groups of the entries to be as diverse as possible (/8 for ipv4 and /16 for ipv6). The rules of storing the bucket and the bucket position for a given peer depend on hashing the peer's network group, peer's port, sender's network group (peer that sent the "respond_peers" message containing our current peer), and a secret 32 byte key. This way, an attacker won't be able to predict the bucket and the bucket position where a peer will be stored, and only one entry will be stored within the similar network groups (as the bucket and the bucket position calculations will be identical for similar network group peers). + +When a new inbound peer connects to us, we relay its address to one peer we're connected to by sending a `respond_peers` message. Similarly, when we receive a `respond_peers` message containing only one peer, we relay its address to two peers we're connected to. This ensures when a new peer connects to the network, its address will be eventually known by everyone else. The relay peers are chosen deterministically by our key, the current day and their IP and port, by choosing the smallest value after hashing those values (while being deterministic, they also change every day). Additionally, our node sends its address once every 24 hours to all the peers it is connected to, to point that we're still online. + +All the above update the timestamps of the peers. Additionally, we update the timestamp of our outbound connections, at most once every 20 minutes, after they send us a message. + +Beside picking our outgoing connections, the peer tables are also used to respond to `request_peers` messages. We pick random peers from both new and the tried table, assuming their timestamp is not too old and we don't have too many failed connections with them. Every time peer A connects to peer B, peer A will send peer B a `request_peers` message. The answer will be a `respond_peers` message that will help peer A bootstrap further. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/peer-protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/peer-protocol.md new file mode 100644 index 00000000000..f836eeb3bab --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/peer-protocol.md @@ -0,0 +1,298 @@ +--- +title: Peer Protocol +slug: /chia-blockchain/protocol/peer-protocol +--- + +[Peer protocol source](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/full_node_protocol.py) + +This protocol is a bidirectional protocol for communication between full nodes in the Chia system. +The sender is the full node sending the message, and the recipient is the full node that is receiving the message. + +## new_peak + +Sent to peers whenever our node's peak weight advances (whenever the blockchain moves forward). +The fork point allows peers to detect how deep of a reorg happened, and fetch the correct blocks. +The unfinished reward block hash allows the receiving peer to use their cache for unfinished blocks, +since they most likely already have the unfinished +version of the same block, and therefore don't need to re-request the block transactions generator. + +Usually, during normal operation, peers will ask for just the latest block, or +ignore this message if they have already received it from another peer. If we are a few blocks behind, blocks are +fetched one by one in reverse order up to the fork. + +If we are far behind this peak, we will start a batch sync (download a few tens of blocks in batches) or a long sync, +where we download a weight proof and then download many blocks in batches. + +```python +class NewPeak(Streamable): + header_hash: bytes32 # header_hash of new block + height: uint32 # height of new block + weight: uint128 # weight of new block + fork_point_with_previous_peak: uint32 + unfinished_reward_block_hash: bytes32 +``` + +## new_transaction + +Sent to peers when a new spend bundle has been added to the mempool. The receiving peer can then choose to ignore +it, or request the whole transaction. + +```python +class NewTransaction(Streamable): + transaction_id: bytes32 # hash of the spend bundle + cost: uint64 # cost of the transaction, used to see if fees are sufficient for mempool inclusion + fees: uint64 # fees in mojo of transaction, used to see if fees are sufficient for mempool inclusion +``` + +## request_transaction + +Request for a full transaction (spend bundle) from a peer by its id. If a peer does not respond, other peers are contacted +for the same transaction. + +```python +class RequestTransaction(Streamable): + transaction_id: bytes32 # hash of the spendbundle +``` + +## respond_transaction + +Response for a `request_transaction` message. Sends a spend bundle to a peer. To see the contents of a `SpendBundle`, see the [Spend Bundles page](/chia-blockchain/coin-set-model/spend-bundles). + +```python +class RespondTransaction(Streamable): + transaction: SpendBundle +``` + +## request_proof_of_weight + +Request a weight proof from a peer. This is done right before starting a long sync. The weight proof allows our +node to validate whether a `new_peak` that we received from a peer corresponds to an actual valid blockchain. It is +proof that a certain amount of "weight", or space and time, has been used on that blockchain. + +```python +class RequestProofOfWeight(Streamable): + total_number_of_blocks: uint32 # Height of the peak block + tip: bytes32 # The header_hash of the peak block +``` + +## respond_proof_of_weight + +Response to a `request_proof_of_weight` message. Note that weight proofs can be quite large, in the tens of MB range. +If the chain VDFs are compressed (aka blueboxed), then they weight proofs will be smaller. +This is the V1 version of weight proofs, more efficient versions might be added in the future. + +```python +class RespondProofOfWeight(Streamable): + wp: WeightProof + tip: bytes32 +``` + +## request_block + +Request for a block at a certain height from a peer. Called after receiving a `new_peak` message. + +```python +class RequestBlock(Streamable): + height: uint32 # Height of the block to request + include_transaction_block: bool # Whether to include transaction data +``` + +## respond_block + +Response to a `request_block` message. + +```python +class RespondBlock(Streamable): + block: FullBlock +``` + +## reject_block + +Rejection to a `request_block` message. + +```python +class RejectBlock(Streamable): + height: uint32 +``` + +## request_blocks + +Request multiple blocks at once from a peer. + +```python +class RequestBlocks(Streamable): + start_height: uint32 + end_height: uint32 # Inclusive + include_transaction_block: bool # Whether to include transaction data +``` + +## respond_blocks + +Response to a `request_blocks` message. + +```python +class RespondBlocks(Streamable): + start_height: uint32 + end_height: uint32 + blocks: List[FullBlock] +``` + +## reject_blocks + +Rejection to a `request_blocks` message. + +```python +class RejectBlocks(Streamable): + start_height: uint32 + end_height: uint32 +``` + +## new_unfinished_block + +Notification to another peer that a new unfinished block was added to the cache. These unfinished blocks are kept +around temporarily, until the infusion point VDF is released, and the block can be "finished" and added to the blockchain. + +```python +class NewUnfinishedBlock(Streamable): + unfinished_reward_hash: bytes32 +``` + +## request_unfinished_block + +Request for an unfinished block from a peer. + +```python +class RequestUnfinishedBlock(Streamable): + unfinished_reward_hash: bytes32 +``` + +## respond_unfinished_block + +Response to a `request_unfinished_block` message. + +```python +class RespondUnfinishedBlock(Streamable): + unfinished_block: UnfinishedBlock +``` + +## new_signage_point_or_end_of_sub_slot + +Sent when the node adds a new signage point or a new end of sub slot to the full node store. The receiver can choose +to request the object, or potentially request the previous sub slot, if they are far behind. For example, recently +synced up to the peak of the blockchain. + +```python +class NewSignagePointOrEndOfSubSlot(Streamable): + prev_challenge_hash: Optional[bytes32] # Challenge hash at the start of the previous sub slot, if present + challenge_hash: bytes32 # Challenge hash at the start of the sub slot + index_from_challenge: uint8 # Index from the start, 0 for end of sub slot + last_rc_infusion: bytes32 # Last reward chain infusion hash +``` + +## request_signage_point_or_end_of_sub_slot + +Request for a signage point or end of slot. + +```python +class RequestSignagePointOrEndOfSubSlot(Streamable): + challenge_hash: bytes32 + index_from_challenge: uint8 + last_rc_infusion: bytes32 +``` + +## respond_signage_point + +Response for `request_signage_point_or_end_of_sub_slot`. After receiving this message, the recipient will check that +all VDFs are correct, and forward it to other full nodes and potentially farmers. + +```python +class RespondSignagePoint(Streamable): + index_from_challenge: uint8 # Which index out of the 64 signage points, cannot be 0 since that is the EOS + challenge_chain_vdf: VDFInfo + challenge_chain_proof: VDFProof + reward_chain_vdf: VDFInfo + reward_chain_proof: VDFProof +``` + +## respond_end_of_sub_slot + +Another response for `request_signage_point_or_end_of_sub_slot` in the case where `index_from_challenge` is zero. +This is also verified and forwarded by the full node, similar to signage points. + +```python +class RespondEndOfSubSlot(Streamable): + end_of_slot_bundle: EndOfSubSlotBundle +``` + +## request_mempool_transactions + +This is a request for transactions in the mempool. The filter corresponds to a BIP158 Compact Block Filter, which +allows the recipient to see what transactions the sender already has (with some small chance for false positives), +without sending all transaction IDs. The recipient can then respond using `respond_transaction` directly, but should +not send a very large number of transactions, to not overwhelm the original sending peer. + +```python +class RequestMempoolTransactions(Streamable): + filter: bytes +``` + +## new_compact_vdf + +A notification to a peer that a new compact VDF has been added to the blockchain. Compact VDFs +are smaller versions of VDF proofs present in blocks. They do not change the block itself, they just +compress the block data to keep the DB smaller and sync time lower. The actual proof + +```python +class NewCompactVDF(Streamable): + height: uint32 # Height of the block which has a new VDF + header_hash: bytes32 # Header hash of that block + field_vdf: uint8 # Which VDF in that block was updated (blocks have multiple VDFs) + vdf_info: VDFInfo # Info of the VDF that was updated +``` + +## request_compact_vdf + +A request to a peer for a compact VDf. + +```python +class RequestCompactVDF(Streamable): + height: uint32 + header_hash: bytes32 + field_vdf: uint8 + vdf_info: VDFInfo +``` + +## respond_compact_vdf + +A response to a peer that requested a compact VDF. + +```python +class RespondCompactVDF(Streamable): + height: uint32 + header_hash: bytes32 + field_vdf: uint8 + vdf_info: VDFInfo + vdf_proof: VDFProof +``` + +## request_peers + +Request a list of peers. There is no body in this message. This is usually sent when connecting +to a peer. + +```python +class RequestPeers(Streamable): + """ + Return full list of peers + """ +``` + +## respond_peers + +A response to `request_peers`, containing a list of ip and port for each peer. Must be no larger than 1000. +The timestamp corresponds to the last time this peer's record was updated, based on the peer DB update rules. + +```python +class RespondPeers(Streamable): + peer_list: List[TimestampedPeerInfo] +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/pool/pool-protocol-specification.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/pool/pool-protocol-specification.md new file mode 100644 index 00000000000..f1bf4eb0ca4 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/pool/pool-protocol-specification.md @@ -0,0 +1,529 @@ +--- +title: Pool Protocol 1.0 Specification +slug: /chia-blockchain/protocol/pool/pool-protocol-specification +--- + +# 11.2 Chia Pool Protocol 1.0 Specification + +This is the initial version of the Chia Pool Protocol. It is designed to be simple, and to be extended later. It relies on farmers having smart coins (referred to as plot NFTs in GUI + CLI) which allow them to switch between pools by making transactions on the blockchain. Furthermore, it decreases the reliance on pools for block production, since the protocol only handles distribution of rewards, and it protects against pools or farmers acting maliciously. + +## Security considerations + +The pool must ensure that partials arrive quickly, faster than the 28-second time limit of inclusion into the blockchain. This allows farmers that have slow setups to detect issues. + +The Pool server must check that the `pool_contract_puzzle_hash` a.k.a. `p2_singleton_puzzle_hash` matches the +puzzle that they expect. Otherwise, the pool has no guarantee that users will not attempt to claim block rewards +for themselves, and immediately leave the pool, something that the provided smart contract prevents. + +The Chia client must only connect to the pool configuration URL via HTTPS over TLS >= 1.2. This is to +prevent session hijacking, leading to user funds being stolen. + +## Parties + +The parties involved in the pool protocol are the pool operator and farmers. Each farmer is running +a farmer process, and any number of harvester processes connected to that farmer process. The full node can either be +run by the farmer (the default in the Chia GUI application), or run by the pool operator. If the farmer does not want +to run a full node, they can configure their node to connect to a remote full node. + +A pool operator can support any number of farmers. + +## Farmer identification + +A farmer can be uniquely identified by the identifier of the farmer's singleton on the blockchain, this is what +`launcher_id` refers to. The `launcher_id` can be used as a primary key in a database. The pool must periodically check +the singleton's state on the blockchain to validate that it's farming to the pool, and not leaving or farming to another +pool. + +## Farmer authentication + +For the farmer to authenticate to the pool the following time based authentication token scheme must be added to the +signing messages of some endpoints. + +``` +authentication_token = current_utc_minutes / authentication_token_timeout +``` + +Where `authentication_token_timeout` is a configuration parameter of the pool which is also included in the +[GET /pool_info](#get-pool_info) response that must be respected by the farmer. Whereas `current_utc_minutes` is the +local UTC timestamp in **minutes** at the moment of signing. The local clock should ideally be in sync with a time +synchronization protocol e.g., NTP. The authentication token is usually included in a signed payload. + +## HTTPS Endpoints Summary + +The pool protocol consists of several HTTPS endpoints which return JSON responses. The HTTPS server can run on any port, +but must be running with TLS enabled (using a CA approved certificate), and with pipelining enabled. +All bytes values are encoded as hex with optional 0x in front. Clients are also expected to run with pipelining. + +## Error codes + +A failed endpoint will always return a JSON object with an error code and an +english error message as shown below: + +```json +{ "error_code": 0, "error_message": "" } +``` + +The following errors may occur: + +| Error code | Description | +| ---------- | -------------------------------------------- | +| 0x01 | The provided signage point has been reverted | +| 0x02 | Received partial too late | +| 0x03 | Not found | +| 0x04 | Proof of space invalid | +| 0x05 | Proof of space not good enough | +| 0x06 | Invalid difficulty | +| 0x07 | Invalid signature | +| 0x08 | Web-Server raised an exception | +| 0x09 | Invalid puzzle hash | +| 0x0A | Farmer not known | +| 0x0B | Farmer already known | +| 0x0C | Invalid authentication public key | +| 0x0D | Invalid payout instructions | +| 0x0E | Invalid singleton | +| 0x0F | Delay time too short | +| 0x10 | Request failed | + +## Signature validation + +Most of the endpoints require signature validation. The validation requires serialization of the endpoints payloads +to calculate the message hash which is done like: + +``` +message_hash = sha256(serialized_payload) +``` + +The serialized payload must follow the format defined in the [`Streamable` class](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/util/streamable.py). + +## Pool URL + +The pool URL is the url that farmers use to connect to the pool. The subdomains, port, and path are optional. The client +will use 443 if there is no port. Note that the trailing slash must NOT be present. Everything must be lower case. + +``` +https://subdomain.domain.tld:port/path +``` + +## GET /pool_info + +This takes no arguments, and allows clients to fetch information about a pool. It is called right before joining a pool, +when the farmer enters the pool URL into the client. This allows the farmer to see information about the pool, and +decide whether or not to join. It also allows the farmer to set the correct parameters in their singleton on the +blockchain. Warning to client implementers: if displaying any of this information, make sure to account for malicious +scripts and JS injections. It returns a JSON response with the following data: + +```json +{ + "description": "(example) The Reference Pool allows you to pool with low fees, paying out daily using Chia.", + "fee": 0.01, + "logo_url": "https://www.chia.net/img/chia_logo.svg", + "minimum_difficulty": 10, + "name": "The Reference Pool", + "protocol_version": 1, + "relative_lock_height": 100, + "target_puzzle_hash": "0x344587cf06a39db471d2cc027504e8688a0a67cce961253500c956c73603fd58", + "authentication_token_timeout": 5 +} +``` + +#### description + +The description is a short paragraph that can be displayed in GUIs when the farmer enters a pool URL. + +#### fee + +The fee that the pool charges by default, a number between 0.0 (0.0%) and 1.0 (100.0%). This does not include blockchain +transaction fees. + +#### logo_url + +A URL for a pool logo that the client can display in the UI. This is optional for v1.0. + +#### minimum_difficulty + +The minimum difficulty that the pool supports. This will also be the default that farmers start sending proofs for. + +#### name + +Name of the pool, this is only for display purposes and does not go on the blockchain. + +#### protocol_version + +The pool protocol version supported by the pool. + +#### relative_lock_height + +The number of blocks (confirmations) that a user must wait between the point when they start escaping a pool, and the +point at which they can finalize their pool switch. Must be less than 4608 (approximately 24 hours). + +#### target_puzzle_hash + +This is the target of where rewards will be sent to from the singleton. Controlled by the pool. + +#### authentication_token_timeout + +The time in **minutes** for an `authentication_token` to be valid, see [Farmer authentication](#farmer-authentication). + +## GET /farmer + +Get the latest information for a farmer. + +Request parameter: + +``` +- launcher_id +- authentication_token +- signature +``` + +Example request: + +``` +https://poolurl.com/farmer/launcher_id=:launcher_id&authentication_token=:token&signature=:signature +``` + +Successful response: + +```json +{ + "authentication_public_key": "0x970e181ae45435ae696508a78012dc80548c334cf29676ea6ade7049eb9d2b9579cc30cb44c3fd68d35a250cfbc69e29", + "payout_instructions": "0xc2b08e41d766da4116e388357ed957d04ad754623a915f3fd65188a8746cf3e8", + "current_difficulty": 10, + "current_points": 10 +} +``` + +### Parameter + +#### launcher_id + +The unique identifier of the farmer's singleton, see [Farmer identification](#farmer-identification). + +#### authentication_token + +See [Farmer authentication](#farmer-authentication) for the specification of +`authentication_token`. + +#### signature + +This is a BLS signature of the hashed serialization of the following data in the given order: + +| Element | Type | +| ------------------------------------------------------------ | ------- | +| method_name | string | +| launcher_id | bytes32 | +| target_puzzle_hash | bytes32 | +| authentication_token | uint64 | + +where `method_name` must be the serialized string `"get_farmer"`, the parameters must be serialized and hashed +according to [Signature validation](#signature-validation) and the signature must be signed by the private key of the +`authentication_public_key` using the Augmented Scheme in the BLS IETF spec. + +where the parameter must be serialized and hashed according to [Signature validation](#signature-validation) and the +signature must be signed by the private key of the `authentication_public_key` using the Augmented Scheme in the BLS +IETF spec. + +Note: The pool MUST return the current points balance, which is the total number of points found since the last +payout for that user. + +## POST /farmer + +Register a farmer with the pool. This is required once before submitting the first partial. + +Request: + +```json +{ + "payload": { + "launcher_id": "0xae4ef3b9bfe68949691281a015a9c16630fc8f66d48c19ca548fb80768791afa", + "authentication_token": 27062279, + "authentication_public_key": "0x970e181ae45435ae696508a78012dc80548c334cf29676ea6ade7049eb9d2b9579cc30cb44c3fd68d35a250cfbc69e29", + "payout_instructions": "0xc2b08e41d766da4116e388357ed957d04ad754623a915f3fd65188a8746cf3e8", + "suggested_difficulty": 10 + }, + "signature": "0xa078dc1462bbcdec7cd651c5c3d7584ac6c6a142e049c7790f3b0ee8768ed6326e3a639f949b2293469be561adfa1c57130f64334994f53c1bd12e59579e27127fbabadc5e8793a2ef194a5a22ac832e92dcb6ad9a0d33bd264726f6e8df6aad" +} +``` + +Successful response: + +```json +{ "welcome_message": "Welcome to the reference pool. Happy farming." } +``` + +A successful response must always contain a welcome message which must be defined by the pool. + +#### payload + +#### payload.launcher_id + +The unique identifier of the farmer's singleton, see [Farmer identification](#farmer-identification). + +#### payload.authentication_token + +See [Farmer authentication](#farmer-authentication) for the specification of +`authentication_token`. + +#### payload.authentication_public_key + +The public key of the authentication key, which is a temporary key used by the farmer to sign requests +to the pool. It is authorized by the `owner_key`, so that the owner key can be kept more secure. The pool should reject +requests made with outdated `authentication_keys`. These key can be changed using `PUT /farmer`, which is signed with +the owner key. + +#### payload.payout_instructions + +These are the instructions for how the farmer wants to get paid. By default this will be an XCH address, but it can +be set to any string with a size of less than 1024 characters, so it can represent another blockchain or payment +system identifier. + +#### payload.suggested_difficulty + +A request from the farmer to update the difficulty. Can be ignored or respected by the pool. However, this should only +be respected if the authentication public key is the most recent one seen for this farmer. + +See [Difficulty](#difficulty) for more details about the impact of the difficulty. + +#### signature + +This is a BLS signature of the hashed serialization of the payload: + +``` +sha256(PostFarmerPayload) +``` + +signed by the private key of the `owner_public_key` using the Augmented Scheme in the BLS IETF spec. + +See the [streamable](#signature-validation) class `PostFarmerPayload` in the +[pool protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/pool_protocol.py) +and [Farmer authentication](#farmer-authentication) for the specification of `authentication_token`. + +## PUT /farmer + +Allows farmers to update their information on the pool. + +Request: + +```json +{ + "payload": { + "launcher_id": "0xae4ef3b9bfe68949691281a015a9c16630fc8f66d48c19ca548fb80768791afa", + "authentication_token": 27062279, + "authentication_public_key": "0x970e181ae45435ae696508a78012dc80548c334cf29676ea6ade7049eb9d2b9579cc30cb44c3fd68d35a250cfbc69e29", + "payout_instructions": "0xc2b08e41d766da4116e388357ed957d04ad754623a915f3fd65188a8746cf3e8", + "suggested_difficulty": 10 + }, + "signature": "0xa078dc1462bbcdec7cd651c5c3d7584ac6c6a142e049c7790f3b0ee8768ed6326e3a639f949b2293469be561adfa1c57130f64334994f53c1bd12e59579e27127fbabadc5e8793a2ef194a5a22ac832e92dcb6ad9a0d33bd264726f6e8df6aad" +} +``` + +For a description of the request body entries see the corresponding keys in [POST /farmer](#post-farmer). The values +provided with the key/value pairs are used to update the existing values on the server. All entries, except +`launcher_id`, are optional but there must be at least one of them. + +See the [streamable](#signature-validation) class `PutFarmerPayload` in the +[pool protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/pool_protocol.py) for details +and [Farmer authentication](#farmer-authentication) for the specification of +`authentication_token`. + +Successful response: + +```json +{ + "authentication_public_key": true, + "payout_instructions": true, + "suggested_difficulty": true +} +``` + +A successful response must always contain one key/value pair for each entry provided in the request body. The value +must be `true` if the entry has been updated or `false` if the value was the same as the current value. + +See below for an example body to only update the authentication key: + +Example to update `authentication_public_key`: + +```json +{ + "payload": { + "launcher_id": "0xae4ef3b9bfe68949691281a015a9c16630fc8f66d48c19ca548fb80768791afa", + "authentication_public_key": "0x970e181ae45435ae696508a78012dc80548c334cf29676ea6ade7049eb9d2b9579cc30cb44c3fd68d35a250cfbc69e29" + }, + "signature": "0xa078dc1462bbcdec7cd651c5c3d7584ac6c6a142e049c7790f3b0ee8768ed6326e3a639f949b2293469be561adfa1c57130f64334994f53c1bd12e59579e27127fbabadc5e8793a2ef194a5a22ac832e92dcb6ad9a0d33bd264726f6e8df6aad" +} +``` + +## POST /partial + +This is a partial submission from the farmer to the pool operator. + +Request: + +```json +{ + "payload": { + "launcher_id": "0xae4ef3b9bfe68949691281a015a9c16630fc8f66d48c19ca548fb80768791afa", + "authentication_token": 27062279, + "proof_of_space": { + "challenge": "0xe0e55d45eef8d53a6b68220abeec8f14f57baaa80dbd7b37430e42f9ac6e2c0e", + "pool_contract_puzzle_hash": "0x9e3e9b37b54cf6c7467e277b6e4ca9ab6bdea53cdc1d79c000dc95b6a3908a3b", + "plot_public_key": "0xa7ad70989cc8f18e555e9b698d197cdfc32465e0b99fd6cf5fdbac8aa2da04b0704ba04d2d50d852402f9dd6eec47a4d", + "size": 32, + "proof": "0xb2cd6374c8db249ad3b638199dbb6eb9eaefe55042cef66c43cf1e31161f4a1280455d8b53c2823c747fd4f8823c44de3a52cc85332431630857c359935660c3403ae3a92728d003dd66ef5966317cd49894d265a3e4c43f0530a1192874ed327e6f35862a25dfb67c5d0d573d078b4b8ba9bfb1cce52fd17939ae9d7033d3aa09d6c449e392ba2472a1fecf992abcc51c3bf5d56a72fef9900e79b8dba88a5afc39e04993325a0cd6b67757355b836f" + }, + "sp_hash": "0x4c52796ca4ff775fbcdac90140c12270d26a37724ad77988535d58b376332533", + "end_of_sub_slot": false, + "harvester_id": "0xb9d8de98ec5c026f1167b0b587715d7137f43b6d1d40b81d9aac6dc8355fde28" + }, + "aggregate_signature": "0xa078dc1462bbcdec7cd651c5c3d7584ac6c6a142e049c7790f3b0ee8768ed6326e3a639f949b2293469be561adfa1c57130f64334994f53c1bd12e59579e27127fbabadc5e8793a2ef194a5a22ac832e92dcb6ad9a0d33bd264726f6e8df6aad" +} +``` + +Successful response: + +```json +{ "new_difficulty": 10 } +``` + +A successful response must always contain the new difficulty which must be respected by the farmer. + +#### payload + +This is the main payload of the partial, which is signed by two keys: `authentication_key` and `plot_key`. + +#### payload.launcher_id + +The unique identifier of the farmer's singleton, see [Farmer identification](#farmer-identification). + +#### payload.authentication_token + +See [Farmer authentication](#farmer-authentication) for the specification of `authentication_token`. + +#### payload.proof_of_space + +The proof of space in chia-blockchain format. + +#### payload.proof_of_space.challenge + +The challenge of the proof of space, computed from the signage point or end of subslot. + +#### payload.proof_of_space.pool_contract_puzzle_hash + +The puzzle hash that is encoded in the plots, equivalent to the `p2_singleton_puzzle_hash`. This is the first address +that the 7/8 rewards get paid out to in the blockchain, if this proof wins. This value can be derived from the +`launcher_id`, and must be valid for all partials. + +#### payload.proof_of_space.plot_public_key + +Public key associated with the plot. (Can be a 2/2 BLS between plot local key and farmer, but not necessarily). + +#### payload.proof_of_space.size + +K size, must be at least 32. + +#### payload.proof_of_space.proof + +64 x values encoding the actual proof of space, must be valid corresponding to the `sp_hash`. + +#### payload.sp_hash + +This is either the hash of the output for the signage point, or the challenge_hash for the sub slot, if it's an end +of sub slot challenge. This must be a valid signage point on the blockchain that has not been reverted. The pool must +check a few minutes after processing the partial, that it has not been reverted on the blockchain. + +#### payload.end_of_sub_slot + +If true, the sp_hash encodes the challenge_hash of the sub slot. + +#### aggregate_signature + +This is a 2/2 BLS signature of the hashed serialization of the payload: + +``` +sha256(PostPartialPayload) +``` + +signed by the private keys of the following keys using the Augmented Scheme in the BLS IETF spec: + +1. `plot_public_key` +2. `authentication_public_key` + +See the [streamable](#signature-validation) class `PostPartialPayload` in the +[pool protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/pool_protocol.py) for details +and [Farmer authentication](#farmer-authentication) for the specification of +`authentication_token`. + +A partial must be completely rejected if the BLS signature does not validate. + +## GET /login + +This allows the user to log in to a web interface if the pool supports it, see service flags in +[GET /pool_info](#get-pool_info). The farmer software must offer a way to generate and display a login link or provide +a button which generates the link and then just opens it in the default browser. The link follows the specification +below. + +Note that there is no explicit account creation. A farmer can log in after making their self known at the pool with +[POST /farmer](#post-farmer). + +Request parameters: + +``` +- launcher_id +- authentication_token +- signature +``` + +Example request: + +``` +https://poolurl.com/login?launcher_id=:launcher_id&authentication_token=:token&signature=:signature +``` + +#### launcher_id + +The unique identifier of the farmer's singleton, see [Farmer identification](#farmer-identification). + +#### authentication_token + +See [Farmer authentication](#farmer-authentication) for the specification of +`authentication_token`. + +#### signature + +This is a BLS signature of the hashed serialization of the following data in the given order: + +| Element | Type | +| ------------------------------------------------------------ | ------- | +| method_name | string | +| launcher_id | bytes32 | +| target_puzzle_hash | bytes32 | +| authentication_token | uint64 | + +where `method_name` must be the serialized string `"get_login"` and `target_puzzle_hash` +is pool's target puzzle hash (see [GET /pool_info](#get-pool_info)). The parameters must be serialized and hashed +according to [Signature validation](#signature-validation) and the signature must be signed by the private key of the +`authentication_public_key` using the Augmented Scheme in the BLS IETF spec. + +where the parameter must be serialized and hashed according to [Signature validation](#signature-validation) and the +signature must be signed by the private key of the `authentication_public_key` using the Augmented Scheme in the BLS +IETF spec. + +## Difficulty + +The difficulty allows the pool operator to control how many partials per day they are receiving from each farmer. +The difficulty can be adjusted separately for each farmer. A reasonable target would be 300 partials per day, +to ensure frequent feedback to the farmer, and low variability. +A difficulty of 1 results in approximately 10 partials per day per k32 plot. This is the minimum difficulty that +the V1 of the protocol supports is 1. However, a pool may set a higher minimum difficulty for efficiency. When +calculating whether a proof is high quality enough for being awarded points, the pool should use +`sub_slot_iters=37600000000`. +If the farmer submits a proof that is not good enough for the current difficulty, the pool should respond by setting +the `current_difficulty` in the response. + +## Points + +X points are awarded for submitting a partial with difficulty X, which means that points scale linearly with difficulty. +For example, 100 TiB of space should yield approximately 10,000 points per day, whether the difficulty is set to +100 or 200. It should not matter what difficulty is set for a farmer, as long as they are consistently submitting partials. +The specification does not require pools to pay out proportionally by points, but the payout scheme should be clear to +farmers, and points should be acknowledged and accumulated points returned in the response. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/pool/pool-protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/pool/pool-protocol.md new file mode 100644 index 00000000000..0338bd79e18 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/pool/pool-protocol.md @@ -0,0 +1,136 @@ +--- +title: Summary +slug: /chia-blockchain/protocol/pool/pool-protocol +--- + +The Chia pool protocol has been designed for security and decentralization. It does not rely on any 3rd party, closed code, or trusted behavior. + +Some of the protocol's highlights: + +- The farmer can never steal from the pool by double farming. +- The farmer does not need collateral to join a pool. They only need a wallet with one mojo (and potentially a transaction fee) to create a singleton. +- The farmer can easily and securely change pools. +- The farmer can run a full node (increasing decentralization) on low-end hardware, such as a Raspberry Pi 4. +- The farmer can start a new full node, using only their 24-word seed phrase to log in to Chia's software, and the pooling configuration is detected, without requiring a central server. +- The farmer chooses which transactions to include from their full node and creates transaction blocks in a decentralized way. + +### Customization + +Several things can be customized by pool operators, while still adhering to the protocol. These include: + +- How long the timeout is for leaving the pool +- How difficulty adjustment happens +- Fees to take, and how much to pay in blockchain fees +- How farmers' points are counted when paying ([PPS, PPLNS,](https://en.bitcoin.it/wiki/Comparison_of_mining_pools) etc) +- How farmers receive payouts (XCH, BTC, ETH, etc), and how often +- What store (DB) is used - by default it's an SQLite db. Users can use their own store implementations, based on + `AbstractPoolStore`, by supplying them to `pool_server.start_pool_server` +- What happens (in terms of response) after a successful login +- The backend architecture of the pool + +However, some things cannot be changed. These are described in our [pool specification](https://github.com/Chia-Network/pool-reference/blob/main/SPECIFICATION.md), and mostly relate to validation, protocol, and the singleton format for smart coins. + +### Pool Protocol Summary + +When not pooling, farmers receive signage points from full nodes every 9 seconds, and send these signage points to the harvester. + +:::info +See the [Signage and Infusion Points page](/chia-blockchain/consensus/chains/signage-and-infusion-points) for more details. +::: + +Each signage point is sent along with the `sub_slot_iters` and `difficulty`, two network-wide parameters which are adjusted every 4608 blocks (~24 hours). The `sub_slot_iters` is the number of VDF iterations performed in 10 minutes for the fastest VDF in the network. This increases if the fastest timelord's speed increases. The difficulty is similarly affected by timelord speed (it goes up when timelord speed increases, since blocks come faster), but it's also affected by the total amount of space in the network. These two parameters determine how difficult it is to "win" a block and find a proof. + +:::info +See the [Challenges page](/chia-blockchain/consensus/chains/challenges) for more details. +::: + +Since only about one farmer worldwide finds a proof every 18.75 seconds (two signage points), this means the chances of finding one are tiny, with the default `difficulty` and `sub_slot_iters`. For pooling, we increase the `sub_slot_iters` to a constant, but very high number: 37,600,000,000 (37.6 billion), and then we decrease the difficulty to an artificially lower one, so that proofs can be found more frequently. + +The farmer communicates with one or several pools through an HTTPS protocol, and sets their own local difficulty for each pool. Then, when sending signage points to the harvester, the pool `difficulty` and `sub_slot_iters` are used. This means that the farmer can find proofs very often, perhaps every 10 minutes, even for small farms. + +These "partial" proofs, however, are not sent to the full node to create a block. They are instead only sent to the pool. This means that the other full nodes in the network do not have to see and validate everyone else's proofs, and the network can scale to millions of farmers, as long as the pool scales properly. Only one of a given pool's farmers needs to win a block for the entire pool to be rewarded proportionally to their space. + +The pool then keeps track of how many proofs (partials) each farmer sends, weighing them by difficulty. Occasionally (for example every three days), the pool can perform a payout to farmers based on how many partials they submitted. Farmers with more space, and thus more points, will get linearly more rewards. + +Instead of farmers using a `pool_public_key` when plotting, they now use a puzzle hash, referred to as the `p2_singleton_puzzle_hash`, also known as the `pool_contract_address`. These values go into the plot itself, and cannot be changed after creating the plot, since they are hashed into the `plot_id`. The pool contract address is the address of a chialisp contract called a _singleton_ or plot NFT. The farmer must first create a singleton on the blockchain, which stores the pool information of the pool that that singleton is assigned to. When making a plot, the address of that singleton is used, and therefore that plot is tied to that singleton forever. + +When a block is found by the farmer, 7/8 of the block reward (the pool portion) go into the singleton. When the farmer claims these funds they are sent directly to the pool's target address. The other 1/8 of the reward, plus transaction fees, are sent directly to the farmer. + +:::info +The block reward's payout amount will change according to the halving cycle, detailed in the [Block Rewards page](/chia-blockchain/consensus/block-validation/block-rewards#halvings). However, the 7/8 - 1/8 ratio will always remain the same. +::: + +The farmer can also configure their payout instructions, so that the pool knows where to send the occasional rewards to. Optionally a farmer can opt out of a pool by updating the singleton and then claiming future rewards for themselves. + +### Receiving partials + +A _partial_ is a proof of space with some additional metadata and authentication info from the farmer, which meets certain minimum difficulty requirements. Partials must be real proofs of space responding to blockchain signage points, and they must be submitted within the blockchain time window (~28 seconds after the signage point). + +The pool server: + +1. receives partials from the users +2. validates that the partials are correct and correspond to a valid signage point on the blockchain +3. Adds the partials to a queue. + +A few minutes later, the pool pulls from the queue, and checks that the signage point for that partial is still in the blockchain. If everything is good, the partial is counted as valid, and the points are added for that farmer. + +### Collecting pool rewards + +
+ drawing +
+ +The pool periodically searches the blockchain for new pool rewards (according to the [rewards schedule](/chia-blockchain/consensus/block-validation/block-rewards)) that go to the various `p2_singleton_puzzle_hashes` of each of the farmers. These coins are locked, and can only be spent along with the singleton that they correspond to. The singleton is also locked to a `target_puzzle_hash`. Anyone can spend the singleton and the `p2_singleton_puzzle_hash` coin, as long as it's a block reward, and all conditions are met. Some of these conditions require that the singleton always create exactly one new child singleton with the same launcher ID, and that the coinbase funds are sent to the `target_puzzle_hash`. + +### Calculating farmer rewards + +Periodically (for example once a day), the pool executes a payment loop, going through the recent partials that have been submitted by farmers, and making payouts to some, or all farmers. The exact method for computing balance and payout logic can be customized by the pool operator. + +### 1/8 vs 7/8 + +Note that the coinbase rewards in Chia are divided into two coins: the farmer coin and the pool coin. The farmer coin (1/8 of the reward, plus transaction fees) only goes to the puzzle hash signed by the farmer private key, while the pool coin (7/8 of the reward) goes to the pool. This split of 7/8 - 1/8 exists to deter attacks where one pool tries to destroy another by farming partials, but never submitting winning blocks. + +If a farmer is not a member of a pool, the farmer coin and the pool coin are both sent directly to the farmer. + +### Difficulty + +The difficulty allows the pool operator to control how many partials per day they are receiving from each farmer. The difficulty can be adjusted separately for each farmer. A reasonable target would be 300 partials per day, to ensure frequent feedback to the farmer, and low variability. + +A difficulty of 1 results in approximately 10 partials per day per k32 plot. This is the minimum difficulty that V1 of the protocol supports. However, a pool may set a higher minimum difficulty for efficiency. + +When calculating whether a proof is high-quality enough for being awarded points, the pool should use `sub_slot_iters=37600000000`. If the farmer submits a proof that is not good enough for the current difficulty, the pool should respond by setting +the `current_difficulty` in the response. + +### Points + +X points are awarded for submitting a partial with difficulty X, which means that points scale linearly with difficulty. + +For example, 100 TiB of space should yield approximately 10,000 points per day, whether the difficulty is set to 100 or 200. It should not matter what difficulty is set for a farmer, as long as they are consistently submitting partials. The specification does not require pools to pay out proportionally by points, but the payout scheme should be clear to farmers, and points should be acknowledged and accumulated points returned in the response. + +### Difficulty adjustment algorithm + +The following is a simple difficulty adjustment algorithm executed by the pool, provided in the reference implementation: + +- Obtain the last successful partial for this launcher id +- If > 6 hours, divide difficulty by 5 +- If > 45 minutes < 6 hours, divide difficulty by 1.5 +- If < 45 minutes: + - If have < 300 partials at this difficulty, maintain same difficulty + - Else, multiply the difficulty by (24 \* 3600 / (time taken for 300 partials)) + +Notes: + +- 6 hours is used to handle rare cases where a farmer's storage drops dramatically. +- The 45 minutes is similar, but for less extreme cases. +- Finally, the last case of < 45 minutes should properly handle users with increasing space, or slightly decreasing space. + +This algorithm targets 300 partials per day, but different numbers can be used based on +performance and user preference. + +The pool can also improve this algorithm or change it however they wish. + +For example the farmer can provide their own `suggested_difficulty`, and the pool can decide whether to update that farmer's difficulty. The pool should be careful to only accept the latest authentication_public_key when setting difficulty or pool payout info. The initial reference client and pool do not use the `suggested_difficulty`. + +### Making payments + +Note that the payout info can be changed through `PUT /farmer`. The user can choose where rewards are paid out to, and this does not have to be an XCH address. The pool should ONLY update the payout info for successful partials with the latest seen authentication key for that launcher_id. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/protocol.md new file mode 100644 index 00000000000..5aa43f86b39 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/protocol.md @@ -0,0 +1,23 @@ +--- +title: Chia Protocol +slug: /chia-blockchain/protocol/protocol +--- + +The Chia protocol is composed of a few different sub-protocols. All protocol messages are sent encoded in Streamable format, using the networking protocol defined in the [Networking page](/chia-blockchain/protocol/networking-protocol). The following documents go into depth into the messages sent by each type of service/node, and how they should be interpreted. + +The protocol is asynchronous and bidirectional, that is, each end of the connection can send messages, and receive a response, multiple responses, or no response for each message. + +1. [Harvester protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/harvester_protocol.py) (harvester \<-> farmer) +2. [Farmer protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/farmer_protocol.py) (farmer \<-> full node) +3. [Timelord protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/timelord_protocol.py) (timelord \<-> full node) +4. [Peer protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/full_node_protocol.py) (full node \<-> full node) +5. [Pool protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/pool_protocol.py) (pool \<-> farmer) +6. [Wallet protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/wallet_protocol.py) (wallet/light client \<-> full node) +7. [Introducer protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/introducer_protocol.py) (introducer \<-> full node) + +In addition to the sub-protocols that are specific to services, a few protocols are shared across all or most services. + +1. [Shared networking protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/shared_protocol.py) +2. [Timing protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/protocol_timing.py) +3. [Message types protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/protocol_message_types.py) +4. [State machine protocol](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/protocol_state_machine.py) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/serialization-protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/serialization-protocol.md new file mode 100644 index 00000000000..3bd63cc4bb8 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/serialization-protocol.md @@ -0,0 +1,80 @@ +--- +title: Serialization Protocol +slug: /chia-blockchain/protocol/serialization-protocol +--- + +Serialization in Chia refers to how objects are converted into bytes for uses such as transmitting to other nodes, storing on disk, or hashing objects. + +For example, a header_hash refers to the sha256 hash of the header of a block, but +sha256 takes in bytes, so we need a consistent way to convert objects into bytes. + +## Streamable Format + +To prevent consensus issues, the streamable format was designed to be deterministic and easy to implement. All objects in the Chia protocol are transmitted using the streamable format. Furthermore, some database tables use streamable representation as well. + +The primitives are: + +- Sized ints serialized in big endian format, i.e uint64 +- Sized bytes serialized in big endian format, i.e bytes32 +- BLS public keys serialized in bls format (48 bytes) +- BLS signatures serialized in bls format (96 bytes) +- bool serialized into 1 byte (0x01 or 0x00) +- bytes serialized as a 4 byte size prefix and then the bytes. +- ConditionOpcode is serialized as a 1 byte value. +- str serialized as a 4 byte size prefix and then the utf-8 representation in bytes. + +An item is one of: + +- primitive +- Tuple[item1, .. itemx] +- List[item1, .. itemx] +- Optional[item] +- Custom item + +A streamable must be a Tuple at the root level. Iters are serialized in the following way: + +1. A tuple of x items is serialized by appending the serialization of each item. +2. A List is serialized into a 4-byte prefix (number of items) in big endian followed by the serialization of each item. +3. An Optional is serialized into a 1-byte prefix of 0x00 or 0x01, and if it's one, it's followed by the serialization of the item. +4. A Custom item is serialized by calling the .parse method, passing in the stream of bytes into it. An example is a CLVM program, which has its own serialization format. + +This format can be implemented very easily, and allows us to hash objects like headers and proofs of space, without complex serialization logic. + +Note that in the python implementation, we don't use a Tuple at the root level, but instead just use a dataclass with ordered type fields for ease of use. However, it is streamed as a Tuple. + +## Examples + +The streamable specification has been designed to work well with Python using the @streamable decorator available in `chia-blockchain`, but it can work just as well with other programming languages. A class with the @streamable decorator becomes immutable, and has the `__bytes__()` and `.from_bytes(b)` methods. + +### ProofOfSpace type definition + +```python +@streamable +class ProofOfSpace(Streamable): + challenge: bytes32 + pool_public_key: Optional[G1Element] + pool_contract_puzzle_hash: Optional[bytes32] + plot_public_key: G1Element + size: uint8 + proof: bytes +``` + +### Creating and serializing a proof of space + +```python +from chia.types.blockchain_format.proof_of_space import ProofOfSpace +from blspy import G1Element +from chia.types.sized_bytes import bytes32 +from chia.util.ints import uint8, uint32 +pospace = ProofOfSpace(bytes([0xaa]*32), None, bytes32([0xbb]*32), G1Element.generator(), uint8(33), bytes([0xcc]*264)) +print(bytes(pospace)) +``` + +### Output + +As you can see, each one of the fields is serialized in order, according to the above specification. The G1 Generator value +is serialized in BLS format as: ``. + +``` +aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0001bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb97f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb2100000108cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/wallet-protocol.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/wallet-protocol.md new file mode 100644 index 00000000000..3ae267bee62 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/protocol/wallet-protocol.md @@ -0,0 +1,573 @@ +--- +title: Wallet Protocol +slug: /chia-blockchain/protocol/wallet-protocol +--- + +[Wallet protocol source](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/wallet_protocol.py) + +This protocol is a bidirectional protocol for communication between full nodes and wallets in the Chia system. +This is also sometimes referred to as the light client protocol. + +The wallet protocol contains two sub protocols by which a wallet can sync transaction from a node. + +## Privacy Protocol + +The first is the privacy protocol, where the wallet downloads each header and checks the filter for transactions. It is more private, +but much slower. + +## Fast Sync Protocol (recommended) + +The second is the fast sync protocol, where the wallet directly asks the node to look for certain coin ids or puzzle +hashes. It has less privacy but is much faster. The following is the flow for syncing for a wallet that any wallet +developer should follow. It is important to connect to several random nodes to increase security. This sync protocol +should be very fast for users who don't have many transactions. + +1. Perform a DNS lookup to obtain random node IPS: `dig dns-introducer.chia.net`. +2. Connect to a few nodes, to ensure the server does not omit transactions. The nodes will send a `new_peak_wallet` message with their claimed peaks. +3. Download a weight proof from one of the nodes (or several) with the heaviest peak +4. Verify the weight proof to make sure the claimed peak is correct +5. Subscribe to first 100 puzzle hashes for our key (both observer and non-observer) +6. Validate the puzzle hash subscription state returned from the full node. This requires making sure the block in which these coins are included is part of the chain of SubEpochSummaries. Only the block hashes have to be checked here. Furthermore, a few block headers (around 30-50) should be validated after this block to make sure it is properly buried. +7. From step 5, we obtain all coin IDs which we are interested in, and we restore any CAT wallets for coins which have our puzzle hash in the hint. +8. Subscribe to interesting coin IDs +9. Validate the coin subscription returned from the full node, similar to how it's done in step 5 + +# Protocol Messages + +## request_puzzle_solution + +A request from the wallet to the full node for the puzzle and solution of a certain spent coin ID. + +```python +class RequestPuzzleSolution(Streamable): + coin_name: bytes32 # ID of the spent coin + height: uint32 # Spent height +``` + +## respond_puzzle_solution + +A response to a `request_puzzle_solution` request. + +```python + +class RespondPuzzleSolution(Streamable): + response: PuzzleSolutionResponse + +class PuzzleSolutionResponse(Streamable): + coin_name: bytes32 + height: uint32 + puzzle: Program + solution: Program +``` + +## reject_puzzle_solution + +A rejection to a `request_puzzle_solution` request. + +```python +class RejectPuzzleSolution(Streamable): + coin_name: bytes32 + height: uint32 +``` + +## send_transaction + +A message by which a wallet can send a transaction to the mempool and broadcast it to the network. The full node +will attempt to include it into the mempool. + +```python +class SendTransaction(Streamable): + transaction: SpendBundle +``` + +## transaction_ack + +A response to a `send_transaction` message. After attempting to include the transaction, the mempool inclusion status +is returned, with an optional english error string in case it did not succeed. + +```python +class MempoolInclusionStatus(IntEnum): + SUCCESS = 1 # Transaction added to mempool + PENDING = 2 # Transaction not yet added to mempool + FAILED = 3 # Transaction was invalid and dropped + +class TransactionAck(Streamable): + txid: bytes32 + status: uint8 # MempoolInclusionStatus + error: Optional[str] +``` + +## new_peak_wallet + +A notification from the full node to the wallet that the blockchain's peak has changed. + +```python +class NewPeakWallet(Streamable): + header_hash: bytes32 # New peak of the blockchain + height: uint32 # New peak's height + weight: uint128 # New peak's weight + fork_point_with_previous_peak: uint32 +``` + +## request_block_header + +A request from the wallet to the full node for a HeaderBlock at a specific height. + +```python +class RequestBlockHeader(Streamable): + height: uint32 # Height of the header block +``` + +## respond_block_header + +A response to a `request_block_header` request. + +```python +class RespondBlockHeader(Streamable): + header_block: HeaderBlock +``` + +## request_block_headers + +A request from the wallet to the full node for a HeaderBlock at a specific height.\ +NOTE: this message deprecates and replaces `request_header_blocks` (flip block and header). + +```python +class RequestBlockHeaders(Streamable): + height: uint32 # Height of the header block +``` + +## respond_block_headers + +A response to a `request_block_headers` request.\ +NOTE: this message deprecates and replaces `respond_header_blocks` (flip block and header). + +```python +class RespondBlockHeaders(Streamable): + header_block: HeaderBlock +``` + +## reject_block_headers + +A rejection to a `request_block_headers` request.\ +NOTE: this message deprecates and replaces `reject_header_blocks` (flip block and header). + +```python +class RejectBlockHeaders(Streamable): + start_height: uint32 + end_height: uint32 +``` + +## reject_header_request + +A rejection to a `request_block_header` request. + +```python +class RejectHeaderRequest(Streamable): + height: uint32 +``` + +## request_removals + +A request from the wallet to the full node for the removals (removed coins) of a certain block. If `coin_names` is None, +we are requesting all removals in the block. Otherwise, we are requesting only these specific removal coin IDs. + +```python +class RequestRemovals(Streamable): + height: uint32 # Height of the block + header_hash: bytes32 # Header hash of the block + coin_names: Optional[List[bytes32]] +``` + +## respond_removals + +A response to a `request_removals` request. If `coin_names` is None, all removals are returned, and `proofs` is set +to None. Otherwise, only the requested coins are returned, (id to coin tuples) and a proof is returned for each +coin id (id to proof tuples). The proofs are merkle set inclusion proofs. See `merkle_set.py` in chia-blockchain +for more info on how to verify these proofs. + +```python +class RespondRemovals(Streamable): + height: uint32 + header_hash: bytes32 + coins: List[Tuple[bytes32, Optional[Coin]]] + proofs: Optional[List[Tuple[bytes32, bytes]]] +``` + +## reject_removals_request + +A rejection to a `request_removals` request. + +```python +class RejectRemovalsRequest(Streamable): + height: uint32 + header_hash: bytes32 +``` + +## request_additions + +A request from the wallet to the full node for the additions (added coins) of a certain block. If `puzzle_hashes` is +None, we are requesting all additions in the block. Otherwise, we are requesting only additions which have this puzzle hash. + +```python +class RequestAdditions(Streamable): + height: uint32 + header_hash: Optional[bytes32] + puzzle_hashes: Optional[List[bytes32]] +``` + +## respond_additions + +A response to a `request_additions` request. If `puzzle_hashes` is None, all additions are returned, and `proofs` is set +to None. Otherwise, only the requested coins are returned, (puzzle_hash to list of coin tuples, since multiple coins +can have the same puzzle hash) and a proof is returned for each +coin (puzzle_hash, proof, proof2 tuples). The proofs are merkle set inclusion proofs. See `merkle_set.py` in chia-blockchain +for more info on how to verify these proofs. `proof` refers to a proof of the puzzle hash in the merkle set, and +`proof2` is the merkle proof of `sha256(concatenation of coin ids)` for each puzzle hash, in the merkle set. Both are +included as elements in the merkle set for each block. + +```python +class RespondAdditions(Streamable): + height: uint32 + header_hash: bytes32 + coins: List[Tuple[bytes32, List[Coin]]] # puzzle hash => List[Coin] with that puzzle hash + proofs: Optional[List[Tuple[bytes32, bytes, Optional[bytes]]]] # Puzzle hash. proof, proof2 +``` + +## reject_additions_request + +A rejection to a `request_additions` request + +```python +class RejectAdditionsRequest(Streamable): + height: uint32 + header_hash: bytes32 +``` + +## request_header_blocks + +DEPRECATED: this message has been deprecated and replaced with `request_block_headers` (flip block and header).\ +A request from the wallet to the full node for a list of consecutive header blocks, inclusive. + +```python +class RequestHeaderBlocks(Streamable): + start_height: uint32 + end_height: uint32 +``` + +## reject_header_blocks + +DEPRECATED: this message has been deprecated and replaced with `reject_block_headers` (flip block and header).\ +A rejection for a `request_header_blocks` request. + +```python +class RejectHeaderBlocks(Streamable): + start_height: uint32 + end_height: uint32 +``` + +## respond_header_blocks + +DEPRECATED: this message has been deprecated and replaced with `respond_block_headers` (flip block and header).\ +A response to a `request_header_blocks` request. + +```python +class RespondHeaderBlocks(Streamable): + start_height: uint32 + end_height: uint32 + header_blocks: List[HeaderBlock] +``` + +## register_for_ph_updates + +A request from the wallet to the full node to register for updates to a puzzle hash. This is part of the fast sync +protocol. Whenever a new coin with one of these puzzle hashes (or hint) is created or spent, the full node will send a notification +to the wallet (`coin_state_update`). Also, a one time notification is sent back with all the updates (`respond_to_ph_updates`). + +```python +class RegisterForPhUpdates(Streamable): + puzzle_hashes: List[bytes32] + min_height: uint32 +``` + +## respond_to_ph_updates + +A one-time response to `register_for_ph_updates` with all the confirmation or spent heights, and all the CoinStates. +CoinState is an object that shows a change in a coin. if `spent_height` is not None, that means the coin was spent. +If `created_height` is not None, that means the coin was created but not spent. If both are None, it means the +coin was reverted (reorged out of the chain) and no longer exists. + +```python +class RespondToPhUpdates(Streamable): + puzzle_hashes: List[bytes32] + min_height: uint32 + coin_states: List[CoinState] + +class CoinState(Streamable): + coin: Coin + spent_height: Optional[uint32] + created_height: Optional[uint32] +` +``` + +## register_for_coin_updates + +A request from the wallet to the full node to register for updates to a coin ID. This is part of the fast sync +protocol. Whenever a new coin with one of these coin IDs is created or spent, the full node will send a notification +to the wallet (`coin_state_update`). Also, a one time notification is sent back with all the updates (`respond_to_coin_updates`). + +```python +class RegisterForCoinUpdates(Streamable): + coin_ids: List[bytes32] + min_height: uint32 +``` + +## respond_to_coin_updates + +A one-time response to `register_for_coin_updates` with all the confirmation or spent heights, and all the CoinStates. + +```python +class RespondToCoinUpdates(Streamable): + coin_ids: List[bytes32] + min_height: uint32 + coin_states: List[CoinState] +``` + +## coin_state_update + +This is an update but not in response to a request. The full node will send the update whenever a new block +is confirmed which contains removals or additions that are interesting to the wallet. + +```python +class CoinStateUpdate(Streamable): + height: uint32 + fork_height: uint32 + peak_hash: bytes32 + items: List[CoinState] +``` + +## request_children + +A request from the wallet to the node for the children of a certain (spent) coin ID. + +```python +class RequestChildren(Streamable): + coin_name: bytes32 +``` + +## respond_children + +A response to a `request_children` request. + +```python +class RespondChildren(Streamable): + coin_states: List[CoinState] +``` + +## request_ses_info + +A request from the wallet to the full node for SubEpochSummary heights. This is used for the fast sync protocol, +to know where sub epochs start and end. + +```python +class RequestSESInfo(Streamable): + start_height: uint32 + end_height: uint32 +``` + +## respond_ses_info + +A response to a `request_ses_info` request. + +```python +class RespondSESInfo(Streamable): + reward_chain_hash: List[bytes32] + heights: List[List[uint32]] +``` + +:::note +The below messages have been added via [Chip 26](https://github.com/Chia-Network/chips/blob/8a597d06988eb308aa13488c5916ec041f39bc74/CHIPs/chip-0026.md). +These have been added to the reference [node codebase](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/protocols/wallet_protocol.py) but have not been implemented in the reference wallet as of January 2025. +::: + +## request_remove_puzzle_subscriptions + +Removes puzzle hashes from the subscription list (or all of them if None). + +```python +class RequestRemovePuzzleSubscriptions: + puzzle_hashes: Optional[List[bytes32]] +``` + +## respond_remove_puzzle_subscriptions + +Returns the hashes that were actually removed. + +```python +class RespondRemovePuzzleSubscriptions: + puzzle_hashes: List[bytes32] +``` + +## request_remove_coin_subscriptions + +Removes coin ids from the subscription list (or all of them if None) + +```python +class RequestRemoveCoinSubscriptions: + coin_ids: Optional[List[bytes32]] +``` + +## respond_remove_coin_subscriptions + +Returns the ids that were actually removed. + +```python +class RespondRemoveCoinSubscriptions: + coin_ids: List[bytes32] +``` + +## request_puzzle_state + +Requests coin states that match the given puzzle hashes (or hints).\ +When subscribe is set to True, it will add and return as many coin ids to the subscriptions list as possible.\ +When subscribe is set to True and mempool updates are enabled (can be done during the handshake) mempool update messages will be sent (including an initial MempoolItemsAdded message when you subscribe for the first time). +Filter out spent, unspent, or hinted coins, as well as coins below a minimum amount. + +```python +class RequestPuzzleState: + puzzle_hashes: List[bytes32] + previous_height: Optional[uint32] + header_hash: bytes32 + filters: CoinStateFilters + subscribe_when_finished: bool + +class CoinStateFilters: + include_spent: bool + include_unspent: bool + include_hinted: bool + min_amount: uint64 +``` + +## respond_puzzle_state + +Responds with coin states that match the given puzzle hashes (or hints). + +```python +class RespondPuzzleState: + puzzle_hashes: List[bytes32] + height: uint32 + header_hash: bytes32 + is_finished: bool + coin_states: List[CoinState] +``` + +## reject_puzzle_state + +Reject request_puzzle_state in the event that a reorg is detected by a node, this is the only scenario it will be rejected like this. + +```python +class RejectPuzzleState: + reason: uint8 # RejectStateReason + + +class RejectStateReason(IntEnum): + REORG = 0 + EXCEEDED_SUBSCRIPTION_LIMIT = 1 +``` + +## request_coin_state + +Request coin states that match the given coin ids.\ +When subscribe is set to True, it will add and return as many coin ids to the subscriptions list as possible.\ +When subscribe is set to True and mempool updates are enabled (can be done during the handshake) mempool update messages will be sent (including an initial MempoolItemsAdded message when you subscribe for the first time). + +```python +class RequestCoinState: + coin_ids: List[bytes32] + previous_height: Optional[uint32] + header_hash: bytes32 + subscribe: bool +``` + +## respond_coin_state + +Respond with coin states that match the given coin ids.\ +This does not implement batching for simplicity. The order is also not guaranteed. However, you can still specify the previous_height and header_hash to start. + +```python +class RespondCoinState: + coin_ids: List[bytes32] + coin_states: List[CoinState] +``` + +## reject_coin_state + +Reject request_coin_state in the event that a reorg is detected by a node, this is the only scenario it will be rejected like this. + +```python +class RejectCoinState: + reason: uint8 # RejectStateReason + +class RejectStateReason(IntEnum): + REORG = 0 + EXCEEDED_SUBSCRIPTION_LIMIT = 1 +``` + +## mempool_items_added + +The below mempool update messages (including an initial MempoolItemsAdded message when you subscribe for the first time) are received when: + +- `request_coin_state` or `request_puzzle_state` messages are sent, +- AND subscribe is set to True in the request, +- AND mempool updates are enabled (can be done during the handshake). + +```python +class MempoolItemsAdded: + transaction_ids: List[bytes32] +``` + +## mempool_items_removed + +The below mempool update messages (including an initial MempoolItemsAdded message when you subscribe for the first time) are received when: + +- `request_coin_state` or `request_puzzle_state` messages are sent, +- AND subscribe is set to True in the request, +- AND mempool updates are enabled (can be done during the handshake). + +```python +class MempoolItemsRemoved: + removed_items: List[RemovedMempoolItem] + +class RemovedMempoolItem: + transaction_id: bytes32 + reason: uint8 # MempoolRemoveReason + +class MempoolRemoveReason(Enum): + CONFLICT = 1 + BLOCK_INCLUSION = 2 + POOL_FULL = 3 + EXPIRED = 4 +``` + +## request_cost_info + +Request various information about the costs of transactions, blocks, and the mempool. + +```python +class RequestCostInfo: + pass +``` + +## respond_cost_info + +Respond with various information about the costs of transactions, blocks, and the mempool. + +```python +class RespondCostInfo: + max_transaction_cost: uint64 + max_block_cost: uint64 + max_mempool_cost: uint64 + mempool_cost: uint64 + mempool_fee: uint64 + bump_fee_per_cost: uint8 +``` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/chia-farming-workload.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/chia-farming-workload.md new file mode 100644 index 00000000000..aa4e3a7f34a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/chia-farming-workload.md @@ -0,0 +1,184 @@ +--- +title: Storage - Chia Farming Workload Analysis +slug: /chia-blockchain/resources/chia-farming-workload +--- + +Jonmichael Hands, VP Storage, Chia Network. For comments and questions reach out to @LebanonJon on [Discord](https://discorg.gg/chia), or [@LebanonJon](https://twitter.com/LebanonJon) on Twitter + +[Model](https://docs.google.com/spreadsheets/d/1AJP8j673qfbxxju87SjGs174DMVFpzjS/edit?usp=sharing&ouid=108662600751303250659&rtpof=true&sd=true) in Excel + +## 摘要 + +Chia uses a consensus called proof of space and time, in which participants prove to the network that they are storing a certain amount of data through a process called farming. + +Farmers respond to network challenges to earn rewards for securing the Chia network, which involves generating proofs of space from stored data. The protocol for farming and harvesting was designed for quick and efficient verification of proofs of space while minimizing disk io (input/output). A harvester service checks plot files for partial proofs of space when a challenge is received. There is a plot filter designed to significantly reduce the amount of disk io required by requiring that a hash of the plot id and challenge contains a certain amount of zeros. We will explore the theoretical disk io requirements based on the protocols, and look at measured disk utilization during a real farming workload. The Chia farming workload differs from traditional enterprise or consumer storage use cases since the data stored in plot files contains no user data. The Chia farming workload is read-only, completely random distribution, and a low amount of data transferred between the device and host. Data durability (defined as the probability of not losing user data) and error rate requirements for Chia are significantly reduced compared to storing user data and may constitute a new class of storage media and promote used hardware that otherwise would not be suitable. + +## Proof of space verification + +The proof of space construction and the [Proof of Space page](/chia-blockchain/consensus/proof-of-space-1.0) contains the details on the format for plot files. A plot file size is determined by a k value where each plot is made up of 7 tables each with 2^k entries. When a challenge arrives the plot filter is applied to reduce the disk io by the value of the plot filter constant, which is currently set to 512. The probability of a plot being accessed each challenge, which happens on the signage point interval time, is 1/512. The probability of an individual disk being accessed can be found with the binomial distribution function cumulative probability with a probability per plot, n trials equal to the number of plots on the disk (probability of X successes ≥ 1) per signage point. The amount of IOPS (input/output operations per second) can be estimated by determining the mean of the plot filter passes per day and multiplying by the number of seeks required for a proof quality check. In the pooling protocol a pool operator requests several partial proofs of space per day per drive to verify that the pool participant is indeed storing as much data as they claim. The bandwidth and amount of data transferred can be estimated by looking at the average blocksize of the read requests multiplied by the IOPS. + +**Constants in proof of space that were chosen for Chia** + +- Signage point time (seconds): 9.375 +- Plot filter: 512 +- K value minimum: 32 +- IO Proof quality check: 9 read requests +- IO Full proof of space (and partial request from pool): 64 read requests +- Partials per day: set by pool operators, estimated at 300 for reference +- Average IO size per request (kB): 14 + +## Storage workload profile + +We can estimate the storage workload on a given drive capacity (measured in TB, terabytes) by knowing the k size selected and n number of plots that fit on the drive. + +| Drive size (TB) | 4 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | +| ---------------------------------- | -: | -: | -: | --: | --: | --: | --: | --: | +| k value | 32 | 32 | 32 | 32 | 32 | 32 | 32 | 32 | +| Number of plots | 36 | 73 | 91 | 110 | 128 | 146 | 165 | 183 | +| k value | 34 | 34 | 34 | 34 | 34 | 34 | 34 | 34 | +| Number of plots | 8 | 17 | 21 | 25 | 30 | 34 | 38 | 43 | + +Events per day, plots passing filter = signage points per day ✕ n plots / filter constant +number of reads =(Events per day, plots passing filter ✕ IO Proof quality check) +(IO Full proof of space ✕ Partials per day\ +IOPS average =number of reads per day / 86400 seconds +MB read per day = Number of reads ✕ average IO size per request (kB) / 1000\ +Bandwidth = IOPS \* Block Size + +### Average IO Size per request + +An IO kernel trace was taken on a sample of drives to determine the block size requests on the block layer (commands sent directly to the drive over the SATA interface), and found that the majority of the IO commands sent were 12 and 16kB transfers. This will likely change very slightly with different storage hardware, operating systems, storage devices, drivers, and filesystems. + +![iosize_hist](images/iosize_hist.png "iosize_hist") + +Measured data from ext4 filesystem in Linux resulted in an average blocksize of +13.9kB with n=44 drives of capacity 18TB +14.5kB with n=94 drives capacity ranging from 8-18TB + +### Calculated data read and disk bandwidth + +Chia Farming Total Amount of data read per day per drive capacity + +![data_per_day](images/data_per_day.png "data_per_day") + +Bandwidth and amount of data read are all directly proportional to the number of io requests required for the proof quality checks and partial proof of space generation. K=32 with a difficulty of 1 is the theoretical maximum bandwidth for Chia farming. It is typical for a pool operator to automatically adjust the difficulty to target enough partials per day to get an accurate estimate of the farming capacity, without a significant increase in io on the device. + +![bw_drive](images/bw_drive.png "bw_drive") + +As expected, bandwidth per drive scales with the number of plots per drive (which is increased when a higher capacity disk is used) and increases with difficulty. K=34 offers a reduction in io requirements by reducing the number of plots per disk. + +![prob_access](images/prob_access.png "prob_access") + +### Hard drive rated workloads + +Hard disk drive reliability is rated at a specified amount of data read and written per year, expressed in TB/year. Common 3.5in HDDs used in Chia farming are rated at 200-550TB per year workload depending on the drive model and recommended use case. The amount of data written for Chia is often just the size of the drive, because plots are generated on ephemeral storage and then sequentially copied over to the drive. The amount of data read can be calculated by looking at the bandwidth of the drive and multiplying it by time. In the worst case, with the largest hard drive on the market today at 20TB, full of k=32 plots, at difficulty 1 pooling would read an average of 2.1GB per day, or 750 GB per year. This is 0.37% of the rated workload assuming a 200TB/year - Chia is an extremely light workload compared to typical end-user workloads (e.g. NAS, file or object storage, video streaming). + +## Measured data + +Data was collected across a sample size of drives of varying capacity, as detailed in the system configuration. The duration of the measured data was 48 hours with a scraping period of 5s. + +| capacity | Sample Size | bandwidth (kB/s) | IOPS | blocksize (kB) | latency (ms) | +| -------- | ----------- | ----------------------------------- | -------------------- | --------------------------------- | ------------------------------- | +| 8 | 3 | 3.45 | 0.23 | 14.76 | 5.18 | +| 10 | 2 | 4.17 | 0.28 | 14.72 | 7.04 | +| 12 | 16 | 5.03 | 0.34 | 14.69 | 7.11 | +| 14 | 2 | 6.02 | 0.41 | 14.72 | 5.21 | +| 16 | 27 | 6.20 | 0.44 | 14.14 | 6.27 | +| 18 | 44 | 7.46 | 0.51 | 14.57 | 5.53 | +| Total | 94 | 6.46 | 0.45 | 14.48 | 6.02 | + +We compare the modeled metrics of an 18TB drive to the measure data collected + +| Metric | Estimated/Modeled | Measured | +| --------------------------------------------- | ------------------------- | ------------------------- | +| Bandwidth per drive (kB/s) | 4.59 kB/s | 7.46 kB/s | +| IOPS | 0.33 | 0.51 | +| Disk busy time | 0.136% | 0.24% | +| Latency per request (ms) | 4.3 | 6.02 | + +Disk IOPS + +![IOPS](images/iops.png "IOPS") + +Disk bandwidth + +![bw](images/bw.png "bw") + +Latency + +![latency](images/latency.png "latency") + +Disk Utilization + +![disk_busy](images/disk_busy.png "disk_busy") + +CPU Busy Time + +![cpu busy time](images/cpu1.png "cpu") + +System CPU Utilization + +![system utilization](images/cpu.png "cpu") + +Network Traffic (Chia harvester only) + +![network](images/net.png "network traffic") + +### Measurement tools + +- [Grafana](https://grafana.com/) +- [Node Exporter](https://prometheus.io/docs/guides/node-exporter/) +- [Prometheus](https://prometheus.io/) +- [Standalone Linux IO Tracer](https://github.com/Open-CAS/standalone-linux-io-tracer) +- dstat, iostat (sysstat) + +### System configuration + +Measured data collected from the following system + +``` +Motherboard: Intel R1208WFTYS +Intel Xeon Gold 6140 CPU, 128GB DDR4 @ 2400MT/s +HBA: LSI 9300-8e +JBOD: Supermicro 90 Bay, SuperChassis 946ED-R2KJBOD +Drive Models: +Seagate Exos x16 16TB, Firmware SN03 +WD HC550 18TB, Firmware: PCGNW232WDC +WD WD120EDAZ: 8, 10, 12, 14TB, Firmware: 81.00A81 +``` + +## Data durability, uncorrectable bit error rate, and Chia farming + +UBER is defined as "A metric for the rate of occurrence of data errors, equal to the number of data errors per bits read." +In HDD and SSD, UBER is generally reflected in lifetime values for an entire population, but the actual rates of error and rate of increase are dependent on many factors including time, temperature, and amount of wear on the storage media. In SSDs this is adjusted for and measured per the JESD218B specification which defines UBER for SSDs using "The +numerator is the total count of data errors detected over the full TBW rating for the population of SSDs, or the sample of SSDs in the endurance verification." + +### UBER of standard storage devices + +Consumer HDDs are rated for less than 1 error per 1014 (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 | +| -------------- | ------- | ------------------- | +| Consumer HDD | 10\-14 | 800 TB | +| Enterprise HDD | 10\-15 | 8 PB | +| SSD | 10\-17 | 800 PB | + +### UBER in Chia + +In a storage system containing user data, an uncorrectable read error on a single storage device is handled by redundancy or parity, generally through RAID, erasure code, mirror, or backup of the data. Plot files contain random cryptographic hashes. If a device containing plots fails, no useful data is lost. Therefore, the best practice for Chia is not to include any data protection. If there is a single uncorrectable read error somewhere on the storage device, we could therefore calculate the probability of reading that LBA (logical block address) by using the estimated amount of data read per day in the Chia farming workload - because the reads are perfectly random, each read request coming from the harvester service will have an equal probability of being accessed. + +Using the UBER and the estimated amount of data read per day with Chia farming, we can approximate the number of years it would take to encounter an error while farming Chia. + +![UBER](images/uber.png "UBER") + +### What happens when an error occurs? + +Each k=32 plot file contains around 4.3 billion proofs. Depending on where the error occurs, in metadata, table 1, etc. there are a certain amount of proofs within a plot file that will be corrupted. In the absolute worst case that an entire plot file gets corrupted. A more likely case would just be that a certain percentage of proofs are corrupt, and the likelihood of reading those given the amount of data read per day in the Chia farming workload is extremely low. If the uncorrectable read error collides with a lookup for a partial proof of space, the farmer would fail that single request for a partial proof of space or proof quality check. This would lower the user's estimated capacity for a short duration, but then revert to the mean. In other words, an error in Chia farming is not catastrophic. Chia farming workload is a very good fit for a storage device with a higher error rate, potentially even with an UBER of greater than 10-13 . + +## Summary + +Chia is a light workload for a hard drive, 309 times lower disk busy time than an example hyperscale data center workload[2]. Plot files contain random cryptographic hashes that can easily be created and no user data, removing data durability requirements for data storage in Chia farming. Proof of space is a novel use case for hard drives and can accept storage media with a high UBER compared to typical consumer and enterprise workloads. Chia farming will constitute a new class of storage that is optimized for high capacity, write once / read many, low power, and high error rate. Chia farming is a great fit for hard drive technology optimized for sequential write only, such as SMR (Shingled Magnetic Recording), and in the future NVMe ZNS (Zoned Name Spaces) paired with high capacity storage of a lower media grade. Chia farming would be an ideal use case for used storage, given the storage media is high enough capacity to maintain a competitive TCO compared to new more power-efficient disks. + +## Resources + +1. [JEDEC ](https://www.jedec.org/standards-documents/jesd218b01)JESD218B.01 SOLID STATE DRIVE (SSD) REQUIREMENTS AND ENDURANCE TEST METHOD +2. [Facebook's Tectonic Filesystem: Efficiency from Exascale](https://www.usenix.org/system/files/fast21-pan.pdf) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/community-projects/bridge-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/community-projects/bridge-guide.md new file mode 100644 index 00000000000..3b980d5e47a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/community-projects/bridge-guide.md @@ -0,0 +1,300 @@ +--- +title: XCH Bridge Guide +slug: /chia-blockchain/resources/community-projects/bridge-guide +--- + +## Intro + +A _cryptocurrency bridge_ is a powerful tool that enables seamless transfers of digital assets between different blockchain networks, breaking down the barriers of blockchain interoperability. The first Chia blockchain bridge by Warp.Green is now available, paving the way for anyone to access XCH. + +As the first of many bridges to come, Warp.Green marks an exciting milestone in our journey toward greater access to chia (XCH). To help you get started, here's a introductory guide on how to use the Warp.Green bridge. + +## The Warp.green Bridge + +The [Warp.green bridge](https://www.warp.green/) is a messaging protocol that enables bridging assets between Chia and other blockchains. It is an open-source project located on [GitHub](https://github.com/warpdotgreen). It was developed by Warp.green, which is not affiliated with Chia Network Inc. + +This guide will show you how to send ETH from the [Base](https://www.base.org/) blockchain (an Ethereum L2) to the Chia blockchain. The transfer will take a total of 15-20 minutes, though the initial setup could take considerably longer if you are not familiar with the technologies involved. + +:::info + +It is also possible to bridge assets from Ethereum to Chia, but we chose the Base chain for this guide because it tends to have lower fees. + +In addition, it is possible to bridge assets in the other direction: from Chia to Ethereum/Base. This guide doesn't demonstrate this functionality, but the basic technique is quite similar. + +Finally, note that the bridge is set up to allow for bridging _any_ Chia or Ethereum asset. However, only a limited number of assets are currently supported. A list of supported assets is maintained at [warp.green/bridge/assets](https://www.warp.green/bridge/assets). + +::: + +## Set up MetaMask + +[MetaMask](https://metamask.io/) is one of the most popular wallets for storing digital assets such as ETH, and it supports the Base blockchain. We will use MetaMask for this guide, so if you want to follow along, you will need to install it as a web browser extension. But don't worry – if you want to use a different Base wallet, the instructions will likely be similar. + +After you have installed MetaMask, click the browser extension button ("1" in the following image), then click the dropdown to change blockchains ("2"): + +

+ bridge +


+ +By default, Ethereum's mainnet will be selected. The Warp.green bridge _will_ work with this network, but for this guide, we will use Base instead. Click `+ Add network`: + +

+ bridge +


+ +Several supported networks will be displayed. Locate `Base Mainnet` and click `Add`: + +

+ bridge +


+ +Verify that you are adding the correct network. The Chain ID for the Base mainnet is `8453`. Make sure this number is shown, and click `Approve`: + +

+ bridge +


+ +The network should be added successfully. Click `Switch to Base Mainnet`: + +

+ bridge +


+ +You will be given some important info about this network. Read this info carefully, then click `Got it`: + +

+ bridge +


+ +In order to use this wallet for the bridge, you will need to add funds. In this example, the MetaMask wallet was funded with 0.0057 ETH on the Base blockchain: + +

+ bridge +


+ +After your Ethereum wallet has been funded, you can set up a Chia wallet. + +## Set up a Chia wallet + +While several Chia wallets exist, currently the bridge only supports wallets that use WalletConnect, as well as [Goby](https://www.goby.app/). For this example, we will use the Chia reference wallet. See our [wallet guide](/reference-client/getting-started/wallet-guide/#use-the-chia-wallet) for instructions on setting up this wallet. + +You will need to add some XCH to the reference wallet in order to pay fees. In the image below, the wallet contains 0.001 XCH. Typically, this amount will be sufficient. + +We're going to send a wrapped form of ETH to the Chia reference wallet. If you are using Chia 2.3.1 or later, your wallet will automatically recognize the wrapped ETH, but it's still a good idea to add this asset manually. + +:::info + +Regardless of which blockchain you are using, when you receive a bridged token, it will be a "wrapped" version of the native token. The Warp.green bridge calls its tokens "warped" instead of "wrapped". There is no material difference between these two terms; they can be used interchangeably. + +::: + +Click `MANAGE TOKEN LIST`: + +

+ bridge +


+ +Locate `Base Warped milliETH` and click the slider to enable this asset. Feel free to double-check that the asset's ID matches the one from the [asset list](https://www.warp.green/bridge/assets) on Warp.green's website: + +

+ bridge +


+ +Your wallet will add `Base Warped milliETH`: + +

+ bridge +


+ +:::info + +One `Base Warped milliETH` is the equivalent to 1/1000 of one ETH. This denomination was chosen due to the differences in decimals on Chia and Ethereum. + +::: + +## Connect your wallets to the bridge + +Using the same browser where you installed MetaMask, browse to [warp.green/bridge](https://www.warp.green/bridge). In order to use the bridge, you will need to connect both of your wallets. + +### Connect your ETH wallet + +Click `Connect ETH Wallet`: + +

+ bridge +


+ +Click `MetaMask` (or whichever wallet you used on the Ethereum side): + +

+ bridge +


+ +Select the account(s) you want to connect to the bridge. If you just installed MetaMask, there will only be one account. Click `Next`: + +

+ bridge +


+ +Click `Connect` to connect your MetaMask wallet to the bridge: + +

+ bridge +


+ +Your MetaMask wallet is now connected to the bridge. + +### Connect your Chia wallet + +Click `Connect Wallet`: + +

+ bridge +


+ +Click `Wallet Connect` if you are using the Chia reference wallet: + +

+ bridge +


+ +You will be shown a QR code (not shown here). In this example, we'll click the `Copy Link` button. + +Next, open your reference wallet, click the WalletConnect icon ("1" in the image below), then click `ADD CONNECTION` ("2"): + +

+ bridge +


+ +Paste the link you previously copied, and click `CONTINUE`: + +

+ bridge +


+ +Your Chia reference wallet will now be connected to the bridge. Click `CLOSE`: + +

+ bridge +


+ +The bridge will request an address from your wallet. It may perform other requests as well. Click `CONFIRM` for each request: + +

+ bridge +


+ +Return to your web browser. You should see `Connected` displayed under `Wallet Connect`. If so, you can close this dialog: + +

+ bridge +


+ +## Initiate the transfer + +The bridge will ask you to enter an amount to transfer. By default, the asset to transfer will be USDC. However, in this example, we will transfer ETH: + +

+ bridge +


+ +Enter the amount to transfer. Also, verify that the `From` and `To` chains are accurate. For this example, we will transfer 0.001 ETH from Base to Chia. + +:::info + +The Base blockchain will charge a fee, so you will not be able to send the full amount in your MetaMask wallet. In this example, 0.00000465 ETH was the required fee. This fee will vary, depending on which blockchain you are using, and how busy the network is. + +::: + +After you have verified this info, click `Bridge`: + +

+ bridge +


+ +In Step 1 of the transfer, you will be given one more chance to verify the accuracy of everything you have entered. + +:::warning caution + +Be sure to read this dialog carefully, and verify that all information contained within is accurate. + +::: + +:::note note on fees + +Several fees may apply when using the bridge: + +Each blockchain charges a fee to use its network. The size of each fee depends on how busy the network is, as well as how long you are willing to wait for your transaction to be confirmed. Generally speaking, the fees on Base are significantly lower than those on Ethereum. On Chia, the network is often not busy enough to require any fees. + +In addition, a "toll" is automatically deducted for using the bridge. The toll is a small charge (either 0.001 XCH or 0.00001 ETH, depending on the chain where the transaction originated), collected solely to prevent network spam. This money does not go to the bridge or to its operators. Instead, it is redirected to the farmer/miner of the block which includes your transaction. + +Finally, the bridge itself charges a 0.3% tip for using the protocol. This tip is split among the bridge validators and helps to cover the costs associated with maintaining the bridge. + +For more information, see [warp.green's documentation](https://docs.warp.green/). + +::: + +If everything looks good, click `Initiate Bridging`: + +

+ bridge +


+ +MetaMask will pop up, and you will be shown the details of your transfer. This includes the current blockchain fee amount. Click `Confirm` to accept the fee and initiate the transfer: + +

+ bridge +


+ +You will now be taken to Step 2 of the transfer. Before completing the transfer, you will need to wait around 10-15 minutes; the exact time can vary a bit. The reason for this delay is to avoid funds being lost in blockchain reorgs: + +

+ bridge +


+ +Leave this browser window open, and return to it after 15 minutes. + +### Complete the transfer + +After waiting for around 15 minutes, the transfer will reach Step 3. Click `Generate Offer via Wallet`: + +

+ bridge +


+ +Change to your Chia reference wallet. You may see a dialog asking for permission to execute `getWallets`. If so, Click `CONFIRM`: + +

+ bridge +


+ +You may need to grant permission to execute one or more additional methods. Click `CONFIRM` on these dialogs. Eventually, you will see a dialog with a `SHOW OFFER DETAILS` button. Click this button: + +

+ bridge +


+ +You will be shown the details of the transfer from the bridge to your wallet. By default, no blockchain fee will be used. However, if you have available funds (the small circle in the image below), we recommend that you add a fee in order to expedite the transfer. Either way, leave the `In exchange for` side of the dialog blank. Click `CLOSE` when you are finished reviewing this dialog: + +

+ bridge +


+ +If you added a blockchain fee, it will now appear in the `Confirmation Request` dialog. Click `CONFIRM`: + +

+ bridge +


+ +Return to your web browser. The transfer will now be in progress. This should be completed in 1-5 minutes, depending on how busy the Chia network is, along with the size of your fee: + +

+ bridge +


+ +After the transfer has completed, return to the reference wallet. It should now contain the `Base Warped milliETH`. In this example, the bridge charged a 0.3% fee, so 0.997 wmilliETH.b was transferred. Recall that this amount is worth 0.000997 ETH: + +

+ bridge +


+ +Congratulations! You have successfully transferred ETH from the Base chain to Chia. If you would like to exchange the wmilliETH.b for another asset, you could head to a decentralized exchange such as [dexie.space](https://dexie.space/), or an AMM such as [tibetswap.io](https://v2.tibetswap.io/). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/cryptocurrency-intro.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/cryptocurrency-intro.md new file mode 100644 index 00000000000..b3b8e32e72a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/cryptocurrency-intro.md @@ -0,0 +1,123 @@ +--- +title: Intro to Cryptocurrencies +slug: /chia-blockchain/resources/cryptocurrency-intro +--- + +## What is a Cryptocurrency? + +A cryptocurrency system can be thought of as a payments and financial infrastructure that is not controlled by any single entity, such as a bank, company, or government. Prior to the introduction of cryptocurrencies, there had always been an operator that had control of transaction inclusion and monetary policy. This operator represented a centralized point of both power and failure. + +The financial world was fundamentally changed with the introduction of Bitcoin on January 3, 2009. In the years that have followed, many other cryptocurrencies have been created to solve various problems in the legacy financial realm. + +Cryptocurrencies use clever cryptography, mathematics, and monetary incentives to create a system where people called farmers or miners get paid to run the system, and there is no central point of control that can be taken down by malicious actors. + +This brings many benefits, some of which are: + +- **No requirements to participate**: Anyone with an internet connection can participate in the new crypto economy, regardless of nationality, wealth status, religion, etc. +- **Censorship resistance**: Censorship is difficult or impossible. Anyone is allowed to transact, and to send any amount or run any program at any time. +- **Independent monetary policy**: New currencies can be created that do not depend on decisions made by one group or one country, and instead can be based on algorithms or have a fixed supply. +- **Unstoppable applications**: A program developed for, and run on, a secure blockchain can never be changed or stopped. The program itself can own funds and perform financial transactions. Code can run autonomously, without depending on a human operator. Some blockchain applications include: tokenization of other assets, non-fungible tokens (NFTs), loans, remittances, identity wallets, etc. +- **Global standards**: Through crypto, different countries and regions can interact and transact on one shared standard that is clearly documented, fully open source, and available for free. Different parties can come together to use a neutral platform, which reduces costs for those who build on top of the cryptocurrency. +- **Security**: There are many forms of potential attacks on any financial infrastructure, including virtual and physical hacks, bribery, network issues, etc. A system with a million nodes is much more difficult to attack than the aforementioned single point of failure. + +## How do Cryptocurrencies Work? + +To understand the basics of how a cryptocurrency like Bitcoin or Chia works, we first need to look at how one would design a cryptocurrency from scratch. This section is targeted toward those new to the blockchain industry; others can skip it. + +:::info + +For a deeper introduction we recommend the book [Bitcoin and Cryptocurrency Technologies](https://bitcoinbook.cs.princeton.edu/) which also has a freely available pre-print and video lectures. + +::: + +We could rely on a central server with a public API to send transactions (which takes in a username and password) and a public API for reading data. However, this is not decentralized, and it does not bring most of the benefits above. This is the way in which many financial systems worked before Bitcoin. + +How would we design a transaction system which does not depend on any one party? + +
+ drawing +
+ +### Authentication + +First, we need a secure way to send transactions to many servers. Let's assume that there are 1000 servers across the world, instead of just one, and that these servers send transaction information of users to each other. + +These servers are assumed to be run by different entities (companies, people, etc). Usernames and passwords would not work in this decentralized model, because every server would need to know the password in order to verify that a transaction is valid. This would be extremely insecure. + +
+ drawing +
+ +Instead, we can use public key cryptography, invented by Hellman, Merkle, and Diffie. + +For example, a user named Alice maintains a secret key (also called a private key) `sk_a`, and a public key `pk_a`. The public key is posted in a transaction next to her balance, let's say 1 BTC. In order to spend that 1 BTC, she needs to provide a digital signature with her private key. The signature can be verified with the public key and message only, and is specific to the data that is being signed. + +Each server running in this decentralized system can accept a transaction, which includes the ID of the coin that is being sent, the recipient information, and the signature. + +Digital signatures are fundamental building blocks for cryptocurrencies. + +
+ drawing +
+ +### Double Spending + +However, signatures are not enough, because of an issue called the "double spend problem." Of the 1000 servers, let's say 500 are in Asia and 500 are in America. An attacker, Bob, sends two transactions that spend the same coin, to two servers, at the same time: one in Asia and one in America. Those transactions send the money to different recipients, which should not be allowed. + +In this case, the two servers need to come to agreement as to which transaction came first. Otherwise, they will have diverging state, and the system will not have global consensus. To solve this issue, we need a consensus algorithm, or a way for all computers in the system to quickly come to unambiguous agreement on the ordering and content of transactions. + +Since we are trying to create a globally decentralized and secure system, why not allow each person one vote, and add up votes for deciding transaction ordering? This would be great if it were possible, but it unfortunately requires some type of central party, first to decide who is a "person," and then to create these identities. This would make the system centralized. + +We could instead base the system on "one computer, one vote," counting each IP address as a "computer." However, it is trivial to buy new IP addresses, or to change addresses using a VPN or a proxy server. An attacker could even create millions of fake IP addresses. The attacker would gain control of the network once they own 51% of the addresses. At this point, they could decide transaction ordering and content. Again, the system becomes centralized, and possibly compromised. + +The key issue that makes it difficult to solve the double-spend problem is the Sybil attack. A Sybil attack is when an attacker creates a large amount of fake identities at a low cost. Most "Proof of X" blockchains are not secure because if an attacker creates multiple identities, this will give the attacker an advantage. + +The genius of Satoshi Nakamoto was to solve the double-spend problem by requiring real-world work in order to obtain "votes," and to decide consensus. This "Proof of Work" is cryptographically verifiable. The only requirements for participation are a computer and an internet connection. + +In Proof of Work networks, each computer that is participating repeatedly generates cryptographic hashes using random input. This functions as a global lottery, where hashes are generated until one computer generates a winner -- a hash with a certain number of leading zeros. This is known as a _proof of work_ because there are no shortcuts. Computers must put in the required amount of computational "work" by generating hashes. + +When a winning proof is found, the computer that discovered it earns the right to generate a new "block" in the blockchain. This block contains a pointer to the previous block, a list of valid transactions, and the winning hash. All nodes are required to accept the heaviest chain (the one which required the most work). Therefore, all nodes will accept the new block, and the proof-of-work lottery begins anew. + +In Bitcoin's consensus algorithm, each proof takes an average of 10 minutes to generate. As more computers join the network, the average amount of time to generate a proof will naturally decrease. This brings us to another of Satoshi's simple and elegant ideas: the difficulty adjustment. Every 2016 blocks (two weeks, on average) the proof-of-work algorithm automatically adjusts how difficult it is to find a proof. It accomplishes this by increasing or decreasing the required number of leading zeros in a generated hash. The result is that the average time required to find a proof will always be 10 minutes, no matter how many computers start or stop participating in the proof-of-work lottery. + +With this consensus mechanism in place, attacking the network becomes very difficult. If an attacker wants to "rewrite history" by creating an alternative blockchain, they'll need to create new blocks faster than the honest actors in the system. Because of the proof of work that is required to create each block, the attacker will need to generate hashes faster than all other computers in the network, combined. This is known as a "51% attack" and is discussed in greater detail later in the [Consensus Attacks page](/chia-blockchain/consensus/attacks-and-countermeasures). + +Proof of Work solves the double-spend problem -- only one computer can create a block at any one time. It also solves the Sybil problem -- not only does creating a block require a real-world investment in hardware, but it also gives no advantage to someone who creates multiple identities. This person has the same probability of winning, whether they're using one identity or a million. + +
+ drawing +
+ +### Blockchain + +Each node in the network maintains active connections with a few other random nodes. If a user wants to make a transaction, they send it to any node in the network, which automatically broadcasts it to their peers. Because each node is connected to a unique set of peers, the transaction quickly gets propagated to every node in the network. The nodes then save the transaction, including all other pending transactions, locally in memory. This is called the _mempool_. + +:::info +For more info on Chia's mempool, see the [Mempool page](/chia-blockchain/architecture/mempool). +::: + +In order for each node to search for a proof, it must assemble a block to hash against. It does this by including transactions from the mempool, and it will most likely choose the pending transactions that pay the highest fee. A transaction fee market is thus created, where the supply is the total transactions per second (TPS) that the system supports, and the demand is based on the number of transactions in the mempool. A transaction is said to be "confirmed" once it is included inside a block which has the required proof of work. + +Blockchain transactions can also include scripts or programs, which allow controlling funds directly with code. This code can require a certain number of signatures to release the funds, or have any arbitrary logic. + +:::info +Keep in mind that blockchain programs are expensive to run, since every node in the system must download and run the program. Just because it _can_ be run on a blockchain, doesn't mean that is _should_ be run on one. +::: + +Each block also has a hash pointer to the previous block. This means that the hash of the contents of the previous block are included in the current block. If an attacker could find an alternative valid proof for a historical block, the proof would then change that block's hash, which would invalidate the next block. If the attacker wanted to change a block that occurred 10 blocks in the past, they would therefore need to re-do the proof of work for at least 10 blocks. The rest of the network would continue to create legitimate blocks, however, so in reality, the attacker would likely have to create many more than just 10 blocks. In fact, as long as the rest of the network, combined, could create blocks at the same rate or faster, the attacker would _never_ be able to create a chain longer than the legitimate chain. + +The Bitcoin network performs around 170 quintillion (170,000,000,000,000,000,000) hashes per second; the attacker would have to control at least that much hashpower to make a 51% attack feasible. + +
+ drawing +
+ +### Beyond Proof of Work + +Over a decade has passed since the creation of Bitcoin and Proof of Work blockchains. While Proof of Work is quite secure, that security comes at a cost: a tremendous expenditure of energy is required to generate those 170 quintillion hashes per second. On top of that, specialized hardware is required to run nodes on these systems, which has led to a high degree of centralization among the top miners. + +Perhaps most troubling of all are the pools. On a given day, the hashrate of the top four or five Bitcoin pools constitutes over half of the overall hashrate. Arguably, the easiest attack against the Bitcoin network would be for the pool operators to collude (either willingly or under threat), putting a 51% attack well within reach. + +These issues have prompted people to develop alternative Sybil-resistant consensus models. Proof of Stake (voting with blockchain assets) is one of the most popular approaches, and within this category there are many types of algorithms. These systems tend to compromise on decentralization (and thus, security) to varying degrees. + +Chia takes an alternate approach called _Proofs of Space and Time_ (PoST), which we think is likely to be more decentralized and accessible than Proof of Stake. In this model, full nodes store files full of millions of hashes (akin to lottery tickets, as described above) on hard drives. This model maintains the security properties of Nakamoto's Proof of Work, while remaining accessible to normal users without any special hardware. 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 new file mode 100644 index 00000000000..24921f90be2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/faq.md @@ -0,0 +1,1698 @@ +--- +title: FAQ +slug: /chia-blockchain/resources/faq +--- + +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'; + +## General + +### What are harvesters, farmers, full nodes, and timelords? + +You can read about each of them and the architecture in the [Architecture Overview page](/chia-blockchain/architecture/architecture-overview). The [Consensus Intro page](/chia-blockchain/consensus/consensus-intro) is the most current documentation, however. + +### What is a proof of space? + +A _proof of space_ is a proof that a farmer has allocated a portion of their storage in a way that is very difficult to create in real-time but efficient to pre-compute and store on a hard drive. The [Chia Proof of Space Construction document](https://www.chia.net/wp-content/uploads/2022/09/Chia_Proof_of_Space_Construction_v1.1.pdf) goes deeply into the math and implementation considerations to mitigate [Hellman's Time - Memory tradeoff](https://pdfs.semanticscholar.org/f0ba/66072ac10d9898b8a79171ec726d45ec804b.pdf) problem. A plot is a large set of proofs of space. A harvester can harvest multiple plots on the same machine. A farmer can then control [multiple harvesters across many machines](/reference-client/farming/farming-many-machines) to manage the whole "farm". + +Farming uses substantially less electricity than Proof of Work for the same unit of security. You can learn more at [chiapower.org](https://chiapower.org). + +### What is a VDF/proof of time? + +A Verifiable Delay Function (VDF), also known as a proof of time, is a sequential operation that takes a prescribed amount of time to compute (and which cannot be accelerated by parallelism) and which produces an accompanying proof whose result may be quickly verified. This must be done in a group, for which Chia uses ideal class groups. You can learn about them in our [class group document](https://github.com/Chia-Network/oldvdf-competition/blob/master/classgroups.pdf). [Timelords](/chia-blockchain/consensus/timelords) usually run three VDFs at a time for the three internal blockchains of the Chia blockchain. They run as `vdf_client` processes. + +### What is a genesis challenge? + +A genesis challenge is the first VDF challenge on a network that uses the Proof of Space and Time consensus. For more info about the genesis challenge for Chia's mainnet, see the consensus section of this website. For more info about the genesis challenge for Chia's mainnet, see the [consensus section](/chia-blockchain/consensus/chains/challenges#genesis-challenge) of this website. + +### 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](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 + +- **Chia** - uppercase Chia depending on context, this can refer to Chia Network the company, the Chia software (Chia client), or the Chia blockchain. +- **XCH** - refers to the Chia token, XCH. +- **mojo** - a trillionth of an XCH. +- **chia** - lowercase chia refers to the Chia token, XCH. Similarly, mojos are lowercase. + +### How do I sign up for the Chia email newsletter? + +You can sign up for the Chia email newsletter by following [this link](http://eepurl.com/hQDvIn). + +You can select either General Chia News or Developers News or both to receive emails about those topics. + +### What are the rules and guidelines around using Chia's trademarks and copyrighted materials on my own site or project? + +Chia, like all companies, has an obligation to protect and enforce its Trademarks and Copyrights in the relevant jurisdictions. We do this both to ensure that we properly maintain our own responsible use of them, as well as to prevent bad actors from attempting to leverage Chia’s property in an effort to scam the ecosystem or cause other harm. That said, we do want to make it possible for people to talk about Chia, and build tools and platforms that support it’s growth openly. To this effect we have [several guidelines](https://www.chia.net/ip-trademarks/) that we hope will help you better understand some “Do’s and Don’ts” as you go about this. (And if you are ever unsure, you are always welcome to email us at [hello@chia.net](mailto:hello@chia.net) with questions about this subject!) + +### How do I contact Chia with more questions? + +You can email us at [hello@chia.net](mailto:hello@chia.net) or join us on [Discord](https://discord.gg/chia). + +Please note that for support with Chia, we do not offer 1:1 direct support. All support is provided via our discord #support channel. All support is provided via our discord #support channel. + +### Will the average person be able to use Chia as a payment instrument? + +Our hope is that, over time, Chia will be supported by point of sale systems and consumer payment apps all over the world. For example, if you pay for a coffee at Tully’s in England with your GrabPay app from Thailand, it should “just work” without you needing to know it was paid in Chia. For example, if you pay for a coffee at Tully’s in England with your GrabPay app from Thailand, it should “just work” without you needing to know it was paid in Chia. + +Or, for example, if services like Venmo or Cash App aren’t available where you live, using Chia will be far less of a hassle than executing a slow and expensive wire transfer. Using legacy banking to send and convert cash across borders is cumbersome, slow and expensive, and while alternative money transfer services might be faster, they’re not cheap: Western Union can charge upwards of 10% in transfer fees. Using legacy banking to send and convert cash across borders is cumbersome, slow and expensive, and while alternative money transfer services might be faster, they’re not cheap: Western Union can charge upwards of 10% in transfer fees. + +The technology is completely open source and accessible, and anyone can build a new wallet without our permission or assistance. The technology is completely open source and accessible, and anyone can build a new wallet without our permission or assistance. However, we intend to help wallet, exchange, and merchant processing partners with support and integration services, joint marketing and lending for liquidity. + +### Why are you named Chia? + +We’re green money! Our founder Bram Cohen started the company knowing he wanted to reduce the energy dependence of blockchains through a “green” option. The concept of farming seemed to be the best metaphor for filling unused disk space and monitoring it for winning sprouts. This led us to look for a grain that had the properties we wanted to embody with our new Network. The team wanted a name that would be short and impactful. Everyone was amused that it was also a grain associated with a whimsical meme. Chia Network was born. + +### Is the value of Chia going to be as volatile as other cryptocurrencies? + +We believe that Chia coins will be less volatile than other cryptocurrencies due to the planned nature of our planned public company status which will allow financial institutions to hedge and leverage coins and equity. Initially, we expect Chia Network to largely be valued based upon the valuation of the chia that the Company will hold on its balance sheet. Movements in the price of chia on digital exchanges are likely to be mirrored by price movements in the price of our stock on a stock exchange. There will be more ways to get exposure to the success of chia than traditional blockchain projects. This will also allow the usual options and derivatives to our stock to be used as something like a synthetic derivative for the price of chia coins. Additionally, our ability to use the Chia Strategic Reserve may reduce some volatility of chia in the market. + +### Why does Chia run competitions? + +We believe that more eyes on our code will only make it better. For example, the [results](https://www.chia.net/2019/07/18/chia-vdf-competition-round-2-results-and-announcements/) of our [VDF Competition](https://github.com/Chia-Network/vdf-competition) produced a VDF implementation whose runtime was 80% faster than our original implementation. + +### Where has Chia advanced the state of the art in applied cryptography? + +Chia has created three new core inventions and advanced the interest in, and adoption of, a fourth. Firstly, Chia created the first intended for production [BLS Signatures library](https://github.com/Chia-Network/bls-signatures). Second, Chia is the first production use of Verifiable Delay Functions, or VDFs. Third, Chia created [Proof of Space and Time for Nakamoto consensus](https://docs.chia.net/chia-blockchain/green-paper/green-paper-abstract). + +Finally, Chia is the first production use of [class groups](https://github.com/Chia-Network/vdf-competition/blob/master/classgroups.pdf) of unknown order which has spawned significant new research into their applicability to cryptography. + +### Does Chia use Bitcoin's code? + +No. Chia is written entirely from scratch with a custom form of Lisp called [Chialisp](https://chialisp.com/). + +Chia also advanced applied cryptography as described above. + +### Isn't Bitcoin good enough? + +When Bitcoin was developed, it was not foreseen that specialized hardware could vastly outperform the computers that everyone owns. What was intended to be a decentralized network is now controlled by a small number of miners with access to chip fabrication plants and wholesale electricity purchasing (or worse). The miners who currently control the Bitcoin Network feel they have a competitive advantage as is and oppose changing the protocol even when it’s clear that it should be changed. Chia has had ten years to study the new digital money ecosystem and believes we can make cryptocurrency more decentralized, more secure, and easier to use. What was intended to be a decentralized network is now controlled by a small number of miners with access to chip fabrication plants and wholesale electricity purchasing (or worse). The miners who currently control the Bitcoin Network feel they have a competitive advantage as is and oppose changing the protocol even when it’s clear that it should be changed. Chia has had ten years to study the new digital money ecosystem and believes we can make cryptocurrency more decentralized, more secure, and easier to use. + +### What is Chia's inflation? + +After the Chia pre-farm, Chia offers farming rewards of 64 chia every 10 minutes. Over the first 12 years the farming rewards will be halved at the end of each 3rd year. From year 13 to infinity, the rewards will remain constant at 4 chia every 10 minutes leading to ever decreasing inflation rates. Chia’s inflation falls through the 0.50% rate 22 years after mainnet launch. More information can be found in our halving schedule Over the first 12 years the farming rewards will be halved at the end of each 3rd year. From year 13 to infinity, the rewards will remain constant at 4 chia every 10 minutes leading to ever decreasing inflation rates. Chia’s inflation falls through the 0.50% rate 22 years after mainnet launch. More information can be found in our [halving schedule](/chia-blockchain/consensus/block-validation/block-rewards/#halvings) + +### Where is the Chia source code? + +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 | + +### When did Chia launch mainnet? + +Chia launched mainnet on March 19, 2021. You can follow along with code updates across our many repositories outlined [here](/chia-blockchain/resources/faq#where-is-the-chia-source-code) + +### What is the Chia Strategic Reserve? + +Chia has a novel business model to both, lower volatility of the coin and increase adoption. By loaning Chia and managing the interest rates of those loans as well as other tools like buying our stock with chia coins, we hope to lower the quarter to quarter volatility of the coin. To drive adoption, we intend to loan Chia to Global 5000 companies who will use it to pay their international vendors quickly, less expensively, and more securely. We also intend to use the strategic reserve to aid development and adoption. We plan to do things like invest in promising startups in the Chia ecosystem, potentially increase farming rewards during limited periods of time to spur additional farming, and fund corporations paying 105% of the value of their international payables in Chia instead of fiat currency. + +Chia Network Inc created 21 million chia at mainnet launch. This is known as the Strategic Reserve. For details on the Company’s plans for the Strategic Reserve, see page 20 of the Business Whitepaper. This is known as the Strategic Reserve. For details on the Company’s plans for the Strategic Reserve, see page 20 of the [Business Whitepaper](https://www.chia.net/whitepaper/). + +### Did Chia have an ICO? + +No. No. Chia did not have and is not planning an ICO. Instead, our goal is to take the company’s equity public on an American stock exchange. This way, shareholders can share risk and return with management with transparency and disclosure while we use well understood corporate controls to make binding statements about how Chia Network intends to use the Strategic Reserve. The chia coin (XCH) is meant to be a useful payment instrument and not an investment opportunity. Chia intends to complete a fully compliant SEC registered equity IPO and will come to market as market-timing is amenable. Instead, our goal is to take the company’s equity public on an American stock exchange. This way, shareholders can share risk and return with management with transparency and disclosure while we use well understood corporate controls to make binding statements about how Chia Network intends to use the [Strategic Reserve](/chia-blockchain/resources/faq#what-is-the-chia-strategic-reserve). The chia coin (XCH) is meant to be a useful payment instrument and not an investment opportunity. Chia intends to complete a fully compliant SEC registered equity IPO and will come to market as market-timing is amenable. + +### Why do I want to farm Chia? + +You can farm Chia on the unused storage of your laptop, desktop, or corporate network and, in return, you have the chance to receive rewards in chia for helping secure the blockchain. Our software allows you to allocate a certain amount of unused disk space to create plots. Since the only resource intensive step is the initial plotting, once you download the Chia node software, your drives will be plotted in the background. Once plotting is complete, your computer will begin farming on your behalf and the software does all the work and tracks your rewards for you. Ongoing farming uses very little network bandwidth and almost no resources other than storage. By making the farming process available to anyone with unused disk space, we are moving towards our goal of a truly decentralized blockchain that will also serve as a cross subsidy to the storage and cloud industry. Visit our Farming Basics doc to get started. Our software allows you to allocate a certain amount of unused disk space to create plots. Since the only resource intensive step is the initial plotting, once you download the Chia node software, your drives will be plotted in the background. Once plotting is complete, your computer will begin farming on your behalf and the software does all the work and tracks your rewards for you. Ongoing farming uses very little network bandwidth and almost no resources other than storage. By making the farming process available to anyone with unused disk space, we are moving towards our goal of a truly decentralized blockchain that will also serve as a cross subsidy to the storage and cloud industry. Visit our [Farming Basics](/reference-client/farming/farming-basics) doc to get started. + +### What is the Chia Network Strategy? + +It is our belief that the blockchain industry is still led by developers. We intend to be the superior chain for deploying new applications and services as well as being the only serious and secure choice for applications like sovereign backed stable coins. The Chia Network business will be the first for profit company that manages a pre-farm and we intend to be the first publicly tradable “near ETF” cryptocurrency. We believe that - as Redhat and MySQL AB were necessary to drive corporate adoption of linux and mysql - we will be the source for support and training as sovereigns, financial institutions, and corporations look to use cryptocurrency in daily commerce. Finally, we believe that we will be able to leverage the storage ecosystem to drive adoption at corporations and end users as hard drive manufacturers and storage server sellers are likely to bundle space farming into their offerings. + +Our [Business Whitepaper](https://www.chia.net/whitepaper/) is the definitive document on our strategy and approach. + +### Where can I learn more about the technical details of your consensus algorithm? + +Details can be found on the [Consensus](/chia-blockchain/consensus/consensus-intro) page of our docs site. + +Additionally, we maintain a list of academic papers and presentations about Chia on our [references page](/chia-blockchain/resources/references#chias-technical-specs). + +### What is the difference between mining and farming? + +Mining requires expensive single use hardware that consumes exorbitant amounts of electricity. We are mitigating this problem through a fair, eco-friendly, and better blockchain that uses farming to leverage existing empty hard disk space distributed on nodes around the globe. Farming remains decentralized because anyone that has installed our software and has plots can win the next block. Mining requires expensive custom single use hardware and access to electricity at wholesale or better prices which only purpose built corporations can afford to mine. Farming is more decentralized because it relies on empty hard disk space and anyone with a mobile phone, laptop, or corporate network tends to have extra space not currently being used. Unlike mining, once you’re done farming your storage you can repurpose it to, for example, store your family photos. + +For more information we have this [blog article](https://www.chia.net/2023/01/18/mining-vs-farming/), or you can refer to our [Farming](/reference-client/farming/farming-basics) and [Plotting](/reference-client/plotting/plotting-basics) docs. + +### Where can I learn more about Chialisp? + +Documentation can be found at [Chialisp.com](https://chialisp.com/). + +### Why is Chia better? + +Chia has a new innovative Nakamoto consensus algorithm, [Proof of Space and Time](https://docs.chia.net/chia-blockchain/green-paper/green-paper-abstract), that removes the energy demands of Proof of Work from the system. Compared to other cryptocurrencies, Chia has significantly better security due to its more decentralized blockchain by Nakamoto Coefficient. [Chialisp](https://chialisp.com/) is Chia’s new smart transaction programming language that is powerful, easy to audit, and secure and will unlock the security, transparency, and ease of use that cryptocurrencies promise. Chia is also adopting more modern cryptographic tools to enable richer smart transaction capabilities. Chia is taking a new and superior approach to funding, building, and supporting a blockchain via an eventually public, for-profit, open source development company that holds a pre-farm. Chia will use its [Strategic Reserve](/chia-blockchain/resources/faq#what-is-the-chia-strategic-reserve) to ease the volatility of the coin to mitigate bubbles and crashes and to drive adoption of chia. + +### What is Proof of Space and Time? + +Chia developed a new innovative Nakamoto consensus algorithm, [Proof of Space and Time](https://docs.chia.net/chia-blockchain/green-paper/green-paper-abstract), that eliminates the energy demands of Proof of Work while maintaining and in some cases enhancing security. + +Proof of Space is a cryptographic technique where provers show that they allocate unused hard drive space for storage space. In order to be used as a consensus method, Proof of Space must be tied to Proof of Time. PoT ensures that block times have consistency in the time between them and increases the overall security of the blockchain. In order to be used as a consensus method, Proof of Space must be tied to Proof of Time. PoT ensures that block times have consistency in the time between them and increases the overall security of the blockchain. + +### What is Chialisp? + +Chia has a newly developed, innovative blockchain programming language called [Chialisp.com](https://chialisp.com/), which is powerful, easy to audit, and secure. Chialisp is a superior on-chain smart transaction development environment that will unlock the security, transparency, and ease of use that cryptocurrencies promise. + +### How does Proof of Space and Proof of Time work? + +Proof of space can be thought of as a way to prove that you are keeping some storage unused on your hard-disk drive. Users of the Chia blockchain will “seed” unused space on their hard-disk drive by installing software which stores a collection of cryptographic numbers on the disk into “plots.” These users are called “farmers.” When the blockchain broadcasts a challenge for the next block, farmers can scan their plots to see if they have the hash that is closest to the challenge. A farmer’s probability of winning a block is the percentage of the total space that a farmer has compared to the entire network. + +Proof of time requires a small period of time to pass between blocks. Proof of time is implemented by a Verifiable Delay Function that takes a certain amount of time to compute, but is very fast to verify. The key idea of a VDF is that they require sequential computation, and since having many parallel machines does not yield any benefit, electricity waste is minimized. There will likely be relatively few VDF servers (“Timelords”), as the fastest one will always finish first and it takes only one fast and fair Timelord on the network to complete a block and move the chain forward. + +More information can be found in the [Green Paper](https://docs.chia.net/chia-blockchain/green-paper/green-paper-abstract). + +### Where can I get answers to questions about running Chia? + +You should first read through the [Chia Introduction](https://docs.chia.net/chia-blockchain/introduction) and [docs FAQ](/chia-blockchain/resources/faq), check out the wealth of information on our [docs site](https://docs.chia.net/) and join us on [discord](https://discord.gg/chia) in the #support or #general channels. We have also created a good summary of the basics of [creating plots](https://www.chia.net/2021/02/22/plotting-basics/) for Chia. + +### What is Chia? + +Chia was incorporated in August of 2017 to develop an improved blockchain and smart transaction platform. We are building the Chia Network to improve the global financial and payments systems. Chia is the first enterprise-grade digital money. Chia was incorporated in August of 2017 to develop an improved blockchain and smart transaction platform. We are building the Chia Network to improve the global financial and payments systems. Chia is the first enterprise-grade digital money. Chia is using the first new Nakamoto consensus algorithm since Bitcoin. Called Proof of Space and Time, it was created by Bram Cohen, the best network protocol engineer alive and the inventor of BitTorrent. Chialisp is Chia’s new smart transaction programming language that is powerful, easy to audit, and secure. Reference smart transactions currently available are: atomic swaps, authorized payees, recoverable wallets, multisig wallets, and rate-limited wallets. Called Proof of Space and Time, it was created by Bram Cohen, the best network protocol engineer alive and the inventor of BitTorrent. Chialisp is Chia’s new smart transaction programming language that is powerful, easy to audit, and secure. Reference smart transactions currently available are: atomic swaps, authorized payees, recoverable wallets, multisig wallets, and rate-limited wallets. + +### What is the official Chia Network DID used for NFTs? + +From time to time, Chia Network may release NFTs for a variety of reasons, such as our inaugural Chia Friends collection. Any NFTs minted by Chia Network will use our official DID: did:chia:19qf3g9876t0rkq7tfdkc28cxfy424yzanea29rkzylq89kped9hq3q7wd2. Always check the provenance of an NFT purportedly to be official from us by looking for this DID as the minter. Fortunately, the majority of 3rd party platforms are designed to automatically show the Chia Network name and/or logo with these NFTs, but it never hurts to double check! Any NFTs minted by Chia Network will use our official DID: `did:chia:19qf3g9876t0rkq7tfdkc28cxfy424yzanea29rkzylq89kped9hq3q7wd2`. Always check the provenance of an NFT purportedly to be official from us by looking for this DID as the minter. Fortunately, the majority of 3rd party platforms are designed to automatically show the Chia Network name and/or logo with these NFTs, but it never hurts to double check! + +What makes Chia different from proof of work blockchains? + +One core difference is the consensus algorithm called proof of space and proof of time. One core difference is the consensus algorithm called proof of space and proof of time. Basically as after the farmer creates a proof of space and a block, other computers called timelords add proofs of time to the block, which is a cryptographic proof that says that a certain amount of time (like 30 seconds) has passed. So instead of the whole world mining at the same time, only a few computers are "mining" for each proof of space that won. Since these are all cryptographic proofs, they cannot be forged or broken, making the consensus extremely secure. So instead of the whole world mining at the same time, only a few computers are "mining" for each proof of space that won. Since these are all cryptographic proofs, they cannot be forged or broken, making the consensus extremely secure. + +In Chia, the only electricity required is the electricity to create the plots, and to run the hard drives, which is on the order of 10 watts to power, plus CPU power required to run a full node (which is very light). In comparison Blockchains like Bitcoin and Ethereum rely on huge farms of GPUs ( 300W each GPU), or ASICs (hundreds or thousands of watts per machine) to secure the blockchain. You can think of proof of work, as millions of computers "making" lottery tickets by using electricity, but each ticket can only be used once. Chia will use vastly less electricity as each plot will last over 5 years, and the only electricity required is the initial setup (plotting) and 10W for farming a drive. + +For more information on the power utilization of Chia please read through the [Chia power site](https://chiapower.org/). + +### What is Chia's burn address? + +#### Mainnet Burn Address + +``` +xch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ks6e8mvy +``` + +#### Testnet Burn Address + +``` +txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh +``` + +#### The Burn Address Explained + +[Chia addresses](https://docs.chia.net/chia-blockchain/coin-set-model/addresses) are puzzle hashes encoded into the "xch" prefix address format using the [bech32m encoding scheme](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki). + +A traditional bech32m puzzle hash for a burn address is all zeros ending in "dead": `0x000000000000000000000000000000000000000000000000000000000000dead` + +Converting this to an address, you end up with the burn address for mainnet: `xch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ks6e8mvy` + +The testnet burn address is different: `txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh` + +You can use a puzzle hash converter to verify these burn addresses for yourself. + +#### What is a burn address? + +A burn address is an address whose private key (24 words) is unobtainable. There's no feasible way to determine the key for the above burn addresses. This means anything sent to a burn address is inaccessible forever, aka "burned." There's no feasible way to determine the key for the above burn addresses. This means anything sent to a burn address is inaccessible forever, aka "burned." + +Thank you to [r/chia](https://www.reddit.com/r/chia/) member [juraj](https://www.reddit.com/r/chia/comments/q88yi8/does_chia_have_a_dead_address/hqolhgn/) for this information. + +### How does the transactions_generator work? + +Some important changes went into the `transactions_generator` code with the 2.1.0 hard fork. These changes are detailed in the [Block Format](/chia-blockchain/consensus/block-validation/block-format#transactions_generator-update) page. + +## Plotting + +### What is k? + +"k" is the space parameter that controls the size of plots. It is an integer for the following equation: `plot_size_bytes = C1 * 2^k(k + C2)` where C1 is constant 1 and C2 is constant 2. In practice this means that final size is roughly `((2 * k) + 1) * (2 ** (k - 1)) * 0.78005` though that constant is estimated. You can examine the [Space Required section](https://www.chia.net/wp-content/uploads/2022/09/Chia_Proof_of_Space_Construction_v1.1.pdf#page=15) of the [Chia Proof of Space Construction document](https://www.chia.net/wp-content/uploads/2022/09/Chia_Proof_of_Space_Construction_v1.1.pdf) for the calculation of how much space is required for a given k. + +:::note + +Prior to Chia 2.0, the estimated space constant factor of 0.762 slightly incorrect. This led to a netspace calculation that was lower than the actual netspace. To correct this, we have [updated the constant factor](https://github.com/Chia-Network/chia-blockchain/pull/15771) to 0.78005. + +::: + +### How big are plot sizes (k)? + +You can see some example plot sizes, times to plot, and working space needed based on various k's in these [k size tables](/chia-blockchain/resources/k-sizes). Current working space needed for the default plotting options of a k=32 is 239 GiB and the final file is approximately 101.4 GiB. There is small natural variation in temp space needed and the final file size of each plot. Note that 239 GiB is 256.6 GB. + +### What k-size should you plot? + +The minimum plot size is k=32. There is only one reason why you might want to plot larger than k=32: to maximize the total utilization of a given drive or space. A couple of k=33 plots with a majority of k=32 plots can reduce the amount of leftover unused space on a drive. + +The reason k=32 was chosen as the minimum plot size was to prevent a short-range replotting attack, which is detailed in our [consensus doc](/chia-blockchain/consensus/consensus-intro). The gist of the attack is that if someone can create a plot in less than ~30 seconds, they could create a new plot that passes the filter for each signage point, and then delete the new plot immediately afterward. This would effectively emulate storing 512 plots, thus turning Chia into PoW. + +- Note that this attack does not create a winning plot; it only creates a plot that passes the filter. + +This attack won't be economically feasible for some time, if ever. Two potential mitigation techniques are to lower the plot filter (thus reducing the benefit of the attack), or to increase the minimum plot size (thus making the attack more difficult to perform). + +k=32 is expected to be the minimum plot size until at least 2026. If and when that size is increased, you will be given ample notice to replot before the change is made effective. + +### What is recommended for plotting? + +We think you will want to use used Data Center grade NVMe SSD drives to create your plots. Regular consumer NVMe SSD generally has too low of a [TBW](https://www.enterprisestorageforum.com/storage-hardware/ssd-lifespan.html) rating. One of our community members keeps this handy [SSD Endurance page](/reference-client/plotting/ssd-endurance) up to date so you can compare various SSDs. You should never use your root/OS SSD to plot as it can lead to drive failure and loss of booting. You can plot directly to hard drives and get good results, especially if you plot in parallel to different drives. You can use non-root SSD over Thunderbolt 3 and migrate your plots off to whatever storage you want to keep them on long term. You could even load them on a Raspberry Pi 4 with outdated USB 2.0 drives attached and they will harvest and farm just fine. PC World offers this great [background on current storage technologies](https://www.pcworld.com/article/2899351/everything-you-need-to-know-about-nvme.html) but this graph gives you a quick view of why we recommend NVMe SSD: +![NVMe SSD vs SATA](/img/plotting-nvme-ssd.png "NVMe SSD is 5.5 times faster than SATA SSD") + +### Can I plot more than one plot at a time? + +Yes, using either the GUI or CLI. Over the short run you have a bit more control of plotting using the CLI. You can read the [Installation page](/reference-client/install-and-setup/installation) to learn more. You may have better results if you stagger the start time of parallel plotting processes depending on your hardware setup. + +### Can I make plots on one machine and move it to another machine? + +是的。 The [Moving Plots page](/reference-client/plotting/moving-plots) gives you the details. You may also want to consider running a [remote harvester](/reference-client/farming/farming-many-machines). You can also use the same private key set to plot on more than one machine at a time but be aware of the [uPnP issues](/chia-blockchain/resources/faq#why-should-i-not-run-more-than-one-node-on-a-home-network-and-whats-this-about-upnp). + +### What is the secondary temp directory `-2`, and how should I set it? + +`-2` is in use during phase 3 and 4. It is the file being built into the resulting .plot file. As it is done compressing tables during phase 3, it will move them into the `.plot.2.tmp` file (`-2`), and phase 4 will scan through the entire `.plot.2.tmp` (`-2`) file, and write table headers for easy access by the harvester. When phase 4 is done, if `-2` = `-d`, it will simply rename the `.plot.2.tmp` to `.plot`. If `-2` != `-d`, it will copy the file into place, then rename, and finally remove the `-2` file. The amount of writing is about 110% of the resulting `.plot` file size. It is a setup dependent option - is your setup faster at moving the compressed tables into the `.plot.2.tmp` file, and then scan through the entire file, and write table headers during phase 4 - and then copy to `-d` (`-2` = `-t`) - or is it faster to send the compressed tables directly into the `-d` (`-2` = `-d`) directory, and then in phase 4, scan through the entire file, and write table headers inside `-d` (`-2` = `-d`) thereby skipping the final copy into place. The `-2` directory can be set in the Advanced Options for Step 3 in the GUI. + +### My plotting attempt got "Caught plotting error: Not enough memory..."? + +If you see something like `Caught plotting error: Not enough memory for sort in memory. Need to sort X.XXGiB` then you need to either select more memory buffer or more buckets. More buckets require less memory but will create more temp files and more sporadic disk writing. You will almost always want to use 128 buckets and you should try increasing the RAM max usage/`-b` to 4608MiB. + +### My plotting attempt ended with "RuntimeError: bad allocation"? + +This is a RAM problem with your machine. It can be how your swap file is configured. It is often your overclock, or XMP settings and even can be a faulty RAM stick. Chia plotting is better than memtest at surfacing broken or mis-configured RAM. + +### Can I resume plotting if my computer or drive reboots or enters power save mode while plotting? ? ? + +Unfortunately, resuming a plot is not supported. We suggest that you disable power saving mode - especially for external drives - and try to limit other possible causes of interruptions. Plotting a k=32 could take multiple hours, depending on your hardware, so these interruptions can be painful. They are also a part of why we don't recommend plotting plots larger than k=32 as each increment in k generally doubles the time to complete a single plot. + +### Do I have to be connected to the internet or synced to plot? + +No. Plotting can be done entirely offline and needs nothing from the blockchain to complete. The only time you have to be online and synced is when you're farming so that you receive new challenges for the next blocks and transactions to include in a transaction block if you're lucky enough to win one of them and get the transaction fees. Note that one farmer winning is independent of other farmers winning at the same time. All farmers can "win" at nearly the same time. That is why sometimes there are 10 blocks in one minute, and sometimes there is only 1 block per minute, etc. + +### Is there any advantage in plotting larger k sizes? + +No. As long as you plot at least k=32, those plots will be eligible to win on mainnet. In a decade or more, k=32 may become too small, but that's speculative. Usually the only reason to plot larger than k=32 is to optimize using all of the space on a given drive. For example, it may make sense to have two k=33's and the rest k=32 so that you only leave 10 GB free on a given drive. + +### Is the final size of the plotted space the only variable in how often I can win block rewards? + +是的。 + +### How do I know if my plots are OK? + +Run `chia plots check -n 30` to try 30 sample challenges for each plot. Each of your plots should return a number around 30, which means it found around 100% of the attempted proofs of space. If you're still worried try `-n 100` as more random attempts will give you a more valid assessment that the plots is fine. It really is ok if your plot is within 80%-120%. If some of your plots are missing for some reason you may need to add the directory they are in to your config.yaml file. That can be done in the GUI with the MANAGE PLOT DIRECTORIES button or on the command line with `chia plots add -d [directory]`. + +### 我可以使用连接到SSD/NVME的USB 3.0电缆来运行临时文件吗？ + +On Windows, it has not worked well since the communication speed is not fast enough, sometimes the usb turns off, then the plot is not valid. It's possible to run 1 plot, but limiting when trying to process multiple plots. Most are installing PCIe adapters to SSC/NVME and that solves the issue. The mac has very fast communication to do the first plot, many others are saying that they can do 2 plots but process time increases dramatically. Technology is constantly changing so continue to do research and ask in the chat rooms. + +## Full Node + +### What is this UPnP Error? + +[UPnP](https://www.homenethowto.com/ports-and-nat/upnp-automatic-port-forward/) is an optional setting that allows users to open a port in their router and therefore allow other nodes to connect to them. This is not required, since your node can still make outgoing connections without UPnP. + +For some routers, UPnP is enabled automatically, but for others, you might have to go into your router settings and enable UPnP manually. Sometimes restarting the router is also necessary. + +Another option is port forwarding, where you tell your router/NAT to forward requests on port 8444 or 58444 for testnet to your machine. + +### Why should I not run more than one node on a home network and what's this about UPnP? + +First, running more than one node with the same private keys on your home network is wasting bandwidth by syncing two copies of the blockchain over your download link. You can get the same results by running one node and [using multiple harvesters](/reference-client/farming/farming-many-machines) on multiple computers. Second, if you have [uPnP](https://www.homenethowto.com/ports-and-nat/upnp-automatic-port-forward/) enabled on both nodes and your home router supports uPnP (and most do) it will cause both of your nodes to not sync the blockchain. You need to disable uPnP on all or all but one node behind a uPnP enabled router. The CLI command `chia configure --enable-upnp false` will turn uPnP off on a node. It requires a restart of the node to take effect. If you disable UPnP on all but one of your nodes then your local router will forward inbound 8444 traffic to the one node and the rest will now be able to connect to the network but just will not accept inbound connections from the network. + +### Why does my node have no connections? How can I get more connections? + +Step 1. Make sure you are running the most recent version of the Chia software. Check out the [Installation page](/reference-client/install-and-setup/installation). + +Step 2. If your node has no connections, it could be one of many reasons. The most likely reason is that there are no users with space to have new connections, so you cannot connect to them. To solve this, you should try opening port 8444 on your router so other peers can connect to you. Follow the steps in the [Node Syncing page](/reference-client/troubleshooting/node-syncing). + +Port 8444 is the port 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 can quickly talk to other PCs, link up, and start downloading and syncing with the Chia blockchain. + +The network is undergoing rapid growth and expansion. Many of the newly arrived Chia peers (computers) do not open up port 8444. It makes it very hard for the network. So please port forward on port 8444! + +Use this link to check if your router's port 8444 is closed: [https://portchecker.co/](https://portchecker.co/) + +Step 3: You might need to disable UPnP in the config file (~/.chia/mainnet/config/config.yaml) or by using the cli command `chia configure -upnp false`. You might have multiple nodes running on the same machine, or in the same wifi network. Make sure to close all Chia applications on your computer. Also check your firewall or antivirus software, which might be blocking connections. + +Step 4: Try deleting your peer DB which is located at `~/.chia/mainnet/db/peer_table_node.sqlite`. Close then restart Chia. + +Step 5: Edit `~/.chia/mainnet/config/config.yaml`, search for `weight_proof_timeout` and increase it from 180 to 400. If that value is not there, you can add it under the `full_node` section. + +It can take a few minutes to start receiving peers and several hours to completely sync. + +### I am seeing blocks and connections but my node says "Not Synced" + +This is usually a system clock issue, which is causing the display of "Not synced", even though you are. Your clock must be set to the exact time, and cannot be more than 5 minutes off. Check your phone and your computer and ensure the time is the same. + +### What is the new database? + +Chia began using version 2 of its blockchain database in 2022. Version 1 has since reached its end-of-life. + +#### About version 2 + +Version 2 of the database is still written in SQLite, but it has undergone a series of optimizations from version 1, such as storing hashes in binary, rather than human-readable hex format. It also is more compressed than version 1. These two factors combined have resulted in an approximately 45% reduction in the size of the database, as well as a slight improvement in its performance. + +When you install a brand new full node, version 2 of the database will be created when you run `chia init`. + +If you are upgrading from Chia 1.x to 2.1 or later (which is required due to the [hard fork](/chia-blockchain/consensus/forks/)), you will no longer be able run with version 1 of the database. In this case, your options are to download a [database checkpoint](https://www.chia.net/downloads/#database-checkpoint) or to upgrade to version 2 manually, as described below. + +#### About the upgrade process + +If you still have a copy of version 1 of the database, you can upgrade it to version 2. This upgrade will not happen automatically. The command to perform the upgrade is `chia db upgrade`. This is documented in detail in our [CLI reference](/reference-client/cli-reference/cli/#upgrade). Be sure you have enough free space on the disk that contains your database file to write the new file. + +The upgrade could take several hours. After it has completed, run `chia start farmer -r` to restart your farmer and switch to the new database. + +Note that the new database will have the same peak as version 1 at the time you _initiated_ the upgrade. Your node will still need to run a short sync to fetch the remaining blocks that had gotten added while the upgrade was being performed. + +Because the upgrade from version 1 to 2 of the database is time-consuming, most users will likely only perform it on one of their systems and copy the new database file to their other systems afterward. If you choose this option, be sure to either copy the file _before_ running `chia start farmer -r`, or stop Chia altogether if it is already using the new database. Once the database is swapped from v1 to v2, you also need to update your `config.yaml` to reflect the new v2 database change. Under the `full_node:` section set `database_path: db/blockchain_v1_CHALLENGE.sqlite` to `database_path: db/blockchain_v2_CHALLENGE.sqlite` + +:::warning +If you copy your database file to another computer while Chia is currently using it, you'll risk corrupting it, which will necessitate a full sync from genesis. +::: + +#### Technical details + +If you're interested in learning more technical details of the new database, see the first Github Pull Request that introduced the changes: + +- https://github.com/Chia-Network/chia-blockchain/pull/9442 + +And there were two follow-up Pull Requests with additional improvements, along with some benchmarks. + +- https://github.com/Chia-Network/chia-blockchain/pull/9454 +- https://github.com/Chia-Network/chia-blockchain/pull/9455 + +Finally, here is the Pull Request that added the upgrade functionality: + +- https://github.com/Chia-Network/chia-blockchain/pull/9613 + +### What is the difference between Wallet Mode and Farming Mode? + +When you load Chia's client GUI for the first time, you'll be asked to choose whether to run in Wallet Mode or Farming Mode. Here are the main features of each mode: + +Wallet Mode: + +- This mode runs a Chia wallet, but not a full node. +- The wallet will sync by connecting to external peers. +- You'll be able to send and receive Chia and/or CATs. +- Farming will be disabled. + +Farming Mode: + +- This mode runs a full node, so farming will be enabled. +- The wallet will also sync by connecting to external peers, unless specific conditions are met (see below). +- You'll be able to send and receive Chia and/or CATs, just as while running in Wallet Mode. + +To switch between Wallet Mode and Farming Mode, click the gear icon on the upper-right side of your client. The settings menu will appear. Click the desired mode. + +Note that in both modes, the light wallet protocol is always used. This protocol will sync your wallet by only downloading information from a subset of the blocks. The more transactions your wallet has had, the longer this process will require. + +The following are situations when your wallet will NOT connect to external peers: + +- `connect_to_unknown_peers = false` is set in config.yaml, under `wallet:`. +- Your wallet is connected to a trusted node (typically this is your local host) AND that node is fully synced. + +For example, let's say you're running Chia for the first time and you have not modified `connect_to_unknown_peers`. Here is one potential workflow: + +1. Start the GUI and select Wallet Mode. +2. Your wallet will sync by downloading relevant information from external peers. +3. Change to Farmer Mode. Your full node will be started. Your wallet will continue to download relevant information from external peers. +4. After your full node has synced, your wallet will automatically connect to your full node in order to stay synced. It will terminate its connections with external peers. +5. Change to Wallet Mode. Your full node will continue to run in the background, and your wallet will remain connected to your full node in order to stay synced. +6. Stop and restart Chia. You will return to Wallet Mode, and your full node will no longer be running. Your Chia client is now in state 2. + +Depending on how you are using your Chia client, we recommend the following: + +- Casual users who are not farming or running a business such as a DEX can use Wallet Mode. +- Farmers need to run in Farming Mode. +- Anyone running a business, as well as anyone who frequently trades XCH or CATs, should do one of the following: + - Run in Farming Mode. Only transact when your node is fully synced. + - Set `connect_to_unknown_peers = false`. Run in either Wallet Mode or Farming Mode. + +### What are trusted peers and how do I add them? + +There are two types of peer nodes -- trusted/known and untrusted/unknown. By default, your local node is your only trusted node. It is possible to add other nodes to the trusted list, for example if you personally run more than one full node. One reason to add a trusted node is to speed up the sync time of your light wallet. + +The light wallet protocol has two techniques to sync: + +1. If you have access to at least one trusted node that is fully synced, then your wallet will sync by downloading blocks only from your trusted node(s) +2. Otherwise, your wallet will sync by connecting to, and downloading from, multiple untrusted nodes, and verifying that the information downloaded from each node is the same + +Typically, it is much faster to sync a wallet by connecting to a trusted node. Therefore, if you have access to a synced node that you trust, you may want to add that node to your trusted peers list. _We recommend that you only add your own full nodes to this list_. + +### How can I connect to a community node instead of farming with my own full node? + +Unfortunately, connecting to a community node is not secure, and we therefore never recommend doing so. See our [node syncing guide](https://docs.chia.net/reference-client/troubleshooting/node-syncing/#community-nodes) for more info. + +#### 先决条件 + +1. Chia needs to be version 1.3.0 or later on all computers +2. Have a full node running on version 1.3.0 or later + +#### Steps to add a trusted node (peer) + +1. You'll need your trusted node's ID. From your trusted node, run `chia show -s`. Copy the value of `Node ID`, which will appear near the beginning of the output. For example: + +```bash +~$chia show -s +Network: mainnet Port: 8444 Rpc Port: 8555 +Node ID: 0ThisisanexampleNodeID7ff9d60f1c3fa270c213c0ad0cb89c01274634a7c3cb9 +``` + +2. Edit config.yaml. This file is located in `~/.chia/mainnet/config` on Linux and MacOS, and `C:\Users\\.chia\mainnet\config` on Windows. + +Search for the `wallet:` section. It should be near the end of the file. Edit the following values from within this section: + +- `connect_to_unknown_peers` - Default is `true`; change it to `false` +- `target_peer_count` - Default is `3`; change it to `1` (assuming you only have one trusted full node) +- `trusted_peers` + - Default is `0ThisisanexampleNodeID7ff9d60f1c3fa270c213c0ad0cb89c01274634a7c3cb9: Does_not_matter` + - Change to `: Does_not_matter` + - Note 1: Replace `` with the actual Node ID you obtained above + - Note 2: It doesn't matter what you enter on the right side of the colon. The argument will be ignored. Just make sure to enter something + +Optional (this setting ensures the node is automatically used while starting the client) + +- `full_node_peers:` the default `host:` is `localhost`. full_node_peer: the default host: is localhost. Change this to the IP address of the trusted full node (local IP if the node is on the same LAN and public IP if it is not). + - Note 3: The IP address can be found by reviewing your full nodes network connection information (local IP) or by searching "What's my IP" in your favorite search engine. + +3. Restart Chia on the computer you are connecting to the trusted node to pick up the changes. + +- Note 4: If you did not add the full node peer in the optional step you will need to run `chia peer wallet -a :8444` to manually connect to the node peer. + +4. To verify that the changes are working, run `chia wallet show`. The last line of the output should contain `-Trusted: True` + +### How does light wallet syncing work? + +This response will give a non-technical overview of Chia's light wallet syncing process. For technical info, see [our docs site](/chia-blockchain/architecture/light-clients), as well as the [FlyClient White Paper](https://eprint.iacr.org/2019/226.pdf), which details the process from which Chia's light client is based. + +First, a bit about addresses in Chia. A single Chia wallet can use up to four billion (2^32) addresses. Hopefully, you won't need more than that! Using multiple addresses can help provide anonymity. Rather than having to sign up for a new account each time you want to receive money, you can simply click "NEW ADDRESS" and _presto_ -- a new address appears. Additionally, each time you receive change from sending money, a new address is automatically generated. Your wallet keeps track of each of the addresses that have been used. As long as your wallet is synced, it always knows how much money you have. + +One important thing to remember is that your wallet addresses will always be generated _in the same order_. When you generate a "new" address, you're actually calculating the _next_ address in the sequence. Your wallet doesn't know what the next address will be until it's generated, but the sequence will always be the same. For example, if you generate 50 new addresses (and write them down), and then install Chia on a new computer and import the same wallet, the first 50 addresses you generate will _exactly_ match those from your original computer. + +Next, we'll introduce a setting called `initial_num_public_keys`. This setting is part of `config.yaml`, located in `~/.chia/mainnet/config` on Linux and MacOS, and `C:\Users\\.chia\mainnet\config` on Windows. The default value of this setting is 100. The majority of users should _not_ change it. + +You can think of `initial_num_public_keys` as the number of future addresses to examine. It's a window that expands with time (and never contracts). Here's how it works: + +The first time you run Chia's software, your wallet will attempt to sync. It does this by checking the first address in the sequence. If that address has ever received money, your wallet will account for that transaction history and examine the next address, and so on. It would take a _very_ long time to examine all four billion addresses, so your wallet will stop looking at some point. This is where `initial_num_public_keys` comes in. + +By default, your wallet will stop after it has examined 100 straight addresses that have never received money. If it examines 50 empty addresses and then finds a transaction on the 51st address, the number left to examine is reset back to 100. Because the addresses always appear in the same sequence, it will be rare to have even a single address without any transaction history. But there is one exception: if you click "NEW ADDRESS" twice, then one address will remain unused. If you click "NEW ADDRESS" 101 times without receiving money at any of those addresses, then you'll have 100 consecutive unused addresses in the sequence. Let's say you receive money at the 101st address. When your wallet attempts to sync, it will stop looking after the 100th blank address. Transactions from subsequent addresses will remain undiscovered, and your balance will be incorrect. + +The default setting for `initial_num_public_keys` is quite conservative -- it should be rare for anyone to click "NEW ADDRESS" more than 100 times without actually using any of those addresses. That said, you might have a legitimate reason to do this, for example if you're running an exchange. In that case, feel free to set `initial_num_public_keys` to a higher number, stop your wallet, delete your wallet database, and start your wallet again to begin a fresh sync. + +Why not set `initial_num_public_keys` to a higher number by default? Because it would take longer for your wallet to sync. Why not set it lower? If the default setting were 2, most wallets would likely still show the correct balance and the sync time would be faster. However, we set the default to 100 to prioritize showing the correct balance over syncing as fast as possible. + +How does your wallet know it has the correct info for each address? It polls one or more of its peers. These peers can be either trusted or untrusted, as explained in the [previous question](#what-are-trusted-peers-and-how-do-i-add-them). By default, your own node is the only one you trust. If your node is fully synced, then your wallet only needs to query your node to determine your transaction history for each address. If your node is not fully synced, then your wallet will query a number of peers about this info. If any of them lie, omit info, or disconnect in the middle of a query, your wallet will know because the responses won't all match. + +If you believe your balance is incorrect, changing `initial_num_public_keys` is unlikely to fix the problem. If at all possible, you should sync a full node, stop Chia, delete your wallet database, and start Chia again. This time, Chia will sync based on your own node alone. If this is not an option, then resyncing from untrustred nodes might fix the problem as well. + +### Where is the Chia blockchain database located? + +The Chia database (db) is located in the `db/` directory inside the `.chia/mainnet/` directory. The `.chia/` directory will be found in your user's home directory. You will find the testnet database in the same `db/` directory if you are using testnet. + +- mainnet database filename: `blockchain_v2_mainnet.sqlite` +- testnet database filename: `blockchain_v2_testnet11.sqlite` + +#### Windows Systems + +:::info + +To show hidden files on Windows file explorer click View \ Show \ Hidden items + +::: + +``` +C:\Users\ +└─ .chia/ + └── mainnet/ + └─ db/ +``` + +#### macOS and Linux Systems + +:::info + +To show hidden files on Mac finder click "COMMAND"+"SHIFT"+"." (period), on linux GNOME explorer click the carrot (small down arrow in top right) then select Show Hidden Files + +::: + +``` +/Users/ +└─ .chia/ + └── mainnet/ + └─ db/ +``` + +### How do I use the Official Chia Blockchain snapshot torrent? + +1. Download the torrent file from https://www.chia.net/downloads/#database-checkpoint +2. Use a torrent client to download the full db. Bittorrent is recommended but any torrent client will work. +3. Unpack/reassemble the torrent file that was downloaded (on windows I used 7zip, Mac and linux have built in tools that work for this) +4. Move the db to the correct folder (~\.chia\mainnet\db\) and update the name to "blockchain_v2_mainnet.sqlite" (removing the date information in the name) +5. Verify the config file (~\.chia\mainnet\config\config.yaml) has the correct value under the full_node section for `database_path: db/blockchain_v2_CHALLENGE.sqlite` (should only need to change the v1 to v2) +6. Launch chia and wait for a bit (the height to hash and peers files need to be built so this can take upwards of 30 minutes) + +### How do I move the Chia blockchain database to another drive? + +The Chia blockchain database will continue to grow as new blocks are farmed creating the ever-growing need for additional space. In some cases this requires users to move their database to a different drive. In some cases this requires users to move their database to a different drive. + +:::warning + +We strongly urge using a fast ssd to store the blockchain database. Using a slow drive can create issues with maintaining sync with the network. Using a slow drive can create issues with maintaining sync with the network. + +::: + +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.\ + **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 | + +**Note:** This information has been adapted from the [Spacefarmers guide](https://wiki.spacefarmers.io/guides/farming/movedb). + +:::info + +Chia versions 2.1.0 and newer no longer support the version 1 (v1) blockchain database. +Please refer to the [upgrade instructions](/chia-blockchain/resources/faq#how-do-i-upgrade-my-version-1-blockchain-database-to-version-2) if your database is version 1. + +::: + +### How do I upgrade my version 1 blockchain database to version 2? + +Chia versions 2.1.0 and newer no longer support the version 1 (v1) blockchain database. There are two method for updating the database to version 2, either using the upgrade cli command or downloading the [official database snapshot torrent](https://www.chia.net/downloads/#database-checkpoint). + +#### CLI command: + +1. Stop the chia client (this can be done while chia is running but stopping the client saves from any potential issues). +2. Run the command `chia db upgrade` (you do not need the input or output paths if these are still default). [Upgrade command context](https://docs.chia.net/cli#upgrade). + - This process will take some time and requires additional space as the v1 db is compacted into the v2 db which leaves the v1 db intact. + - Remove any `-wal` or `-shm` files that are present in the directory (these are temporary files that should only be removed when all chia processes are stopped). +3. Verify the config file (~\.chia\mainnet\config\config.yaml) has the correct value under the full_node section for `database_path: db/blockchain_v2_CHALLENGE.sqlite` (should only need to change the v1 to v2) +4. After the above completes start the chia client. +5. If all loads up properly (might take ~5-10 minutes to load) then you can safely delete the v1 db found here `~\.chia\mainnet\db\blockchain_v1_mainnet.sqlite`. + +#### Official torrent: + +1. Download the torrent file from the [official database snapshot torrent](https://www.chia.net/downloads/#database-checkpoint). +2. Use a torrent client to download the full db. Bittorrent is recommended but any torrent client will work. [Bittorrent](https://www.bittorrent.com/) is recommended but any torrent client will work. +3. Unpack/reassemble the torrent file that was downloaded (on windows one can use [7zip](https://7-zip.org/), Mac and linux have built in tools that work for this). +4. Stop all chia processes if you have not already. +5. Move the db to the correct folder `~\.chia\mainnet\db\` and update the name to `blockchain_v2_mainnet.sqlite` (removing the date information in the name). + - Remove any `-wal` or `-shm` files that are present in the directory (these are temporary files that should only be removed when all chia processes are stopped). +6. Verify the config file (~\.chia\mainnet\config\config.yaml) has the correct value under the full_node section for `database_path: db/blockchain_v2_CHALLENGE.sqlite` (should only need to change the v1 to v2). +7. Launch chia and wait for a bit (the height to hash, sub-epoch, and peers files need to be built so this can take 5-10 minutes). + +### Why does my node have no connections? How can I get more connections? + +:::info + +This functionality was first made available in Chia version 2.2.0, in [PR #17369](https://github.com/Chia-Network/chia-blockchain/pull/17369). Special thanks to [Felix Brucker](https://github.com/felixbrucker) for creating it! + +::: + +By default, when you start a Chia full node, it will attempt to connect to a random set of peers. This is normally fine, but there are some cases in which you might want to connect to the same peer(s) every time, such as if: + +- You are a pool operator who wants to establish consistent groups of nodes to support your pool +- You are running a small, private testnet where all peers are known +- You are connecting to a larger testnet which nonetheless has an insufficient number of nodes to locate your first peer immediately upon starting a full node + +Steps to connect to the same full node peers: + +1. Edit your config file; the default location is `~/.chia/mainnet/config/config.yaml` +2. In the `full_node:` section, you should see the following line: `full_node_peers: []` + - If you do not see this line, you can either add it manually, or rename your config file and run `chia init` to create a new copy, which will contain this line. +3. Remove the square brackets (`[]`) and add add new lines with `- host` and `port`. Be sure to indent `port`, even though it does not have a hyphen. For example, to add two mainnet peers, use the following syntax: + ```yaml + full_node_peers: + - host: + port: + - host: + port: + ``` + - Typically, `` will be either 8444 (for mainnet) or 58444 (for most testnets). + +:::note + +These are not trusted peers (for more info, see the [question on connecting to trusted peers](#what-are-trusted-peers-and-how-do-i-add-them)). Instead, these are normal peers that you happen to want to connect to on an ongoing basis. If you lose your connection to one of these peers, your node will automatically attempt to reestablish the connection. + +::: + +## Farming + +### What is the difference between a Farmer and a Harvester? + +可以将收割机视为是农民的一个扩展节点。 收割机检查地块并将结果报告给农民，然后农民将结果提交给区块链。 If setting up harvesters it is important to review the proper way to [farm on many machines](/reference-client/farming/farming-many-machines) + +### How do I tell if I'm farming correctly? + +If you see plots in the Plots section of the Farm page in the GUI - your plots are being farmed. You will see challenges and proof attempts as they come through in the Last Attempted Proof section however you usually will not have a proof worth sending to the network due to the [plot filter](/chia-blockchain/resources/faq#what-is-the-plot-filter-and-why-didnt-my-plot-pass-it). You can additionally see the Total Size of Plots on the Farm view and it will tell you how much unique space is being farmed and statistically how long it should take - on average - to win a block. +Also, your node needs to be synced for you to farm properly. In the GUI, check the Full Node page. On the cli, do `chia show -s -c`. + +### Does it matter how fast my internet connection is? + +No. You have 30 seconds to respond to challenges. + +### I have only 10 TB, will I ever win XCH? + +[ChiaCalculator.com](https://chiacalculator.com "Chia Calculator") does a good job at running the numbers. + +First, the bad news. Statistically, it would take multiple years to win a reward with a 10-TB farm. ("So you're saying there's a chance...") + +Now, the good news. You can join a pool and collect regular rewards, no matter your farm's size! See the [Pool Farming page](/reference-client/farming/pool-farming) for more info. + +### What is the plot filter and why didn't my plot pass it? + +Farmers compute a plot filter based on the signage point, their plot id, and the sub-slot challenge - which are hashed together to create the plot filter bits. If the plot filter bits start with 9 zeroes, that plot passes the filter for that signage point, and can proceed. This disqualifies around 511/512 of all proofs of space on the network, for each signage point. There are 4608 \* 2 or 9216 signage points per day so the average plot should pass the filter 18 times per 24 hours on average. Once a plot passes the plot filter it then competes for the best proof of space with every other plot that also passed that plot filter for that signage point. For reasons that aren't super simple to intuit, the only thing each plot is competing on is to have the best proof of space and thus the chances of getting a reward depend on total size of plots on the farm - even with the plot filter in place. + +As long as the plot passes the filter, and do not have any internal file errors, the plot will always be eligible to compete for the best proof of space. Moving the plot to another directory or server will not change its eligibility. + +Please note that the speed of your lookups when passing the plot filter should be below 5 and preferably below 2 seconds. When you actually win a reward, your drive will have to do more lookups than these, so it's important that the the lookups are happening fast. + +### Why does my Chia farm say `Missing signage points`? + +This means that your harvester did not respond to one or more signage points in time to be eligible to win a reward. However, if you miss fewer than 100 signage points per day, it is not a serious issue. However, if you miss fewer than 100 signage points per day, it is not a serious issue. + +On average there are 9216 signage points per day, or one every 9.375 seconds. On average there are 9216 signage points per day, or one every 9.375 seconds. If your harvester misses 9 signage points per day, then your farm was operational 99.9% of the time. This would be considered normal, even for a farm with a stable internet connection. If you are consistently missing more than 1% of the signage points, or around 100 per day, then it is probably worth investigating the cause. This would be considered normal, even for a farm with a stable internet connection. If you are consistently missing more than 1% of the signage points, or around 100 per day, then it is probably worth investigating the cause. + +Some reasons your harvester might miss more than 100 signage points per day: + +- Your harvester can't handle its required compute load -- typically this will happen if you are farming with compressed plots. However, even with uncompressed plots, if your harvester sometimes requires more than five seconds to perform its lookups, it may miss some signage points. See our plotting documentation for more info on how determine the maximum number of plots your harvesters can handle. However, even with uncompressed plots, if your harvester sometimes requires more than five seconds to perform its lookups, it may miss some signage points. See our [plotting documentation](/reference-client/plotting/plotting-compression) for more info on how determine the maximum number of plots your harvesters can handle. +- Lost connections to peers -- check your peer count by clicking the `FULL NODE` icon in the upper right corner of your farmer GUI. If you only have a few peers, your local network might have a [UPNP issue](#what-is-this-upnp-error). See our question on [obtaining more peer connections](#why-does-my-node-have-no-connections-how-can-i-get-more-connections). +- Changed external IP address -- some ISPs will change the IP address of their customers frequently and without warning. This may be happening to your home network. Your ISP might be able to provide you with more info. Unfortunately, if this is happening, often the only recourse is to pay for a dedicated IP address. This may be happening to your home network. Your ISP might be able to provide you with more info. Unfortunately, if this is happening, often the only recourse is to pay for a dedicated IP address. +- Changed internal IP address -- your home network might also have changed the IP address of your harvester(s). Your router's settings might provide you with more info. Your router's settings might provide you with more info. +- Temporary loss of internet -- you don't need a fast internet connection to run a Chia node. But you do need a stable one. If your local network loses internet connectivity for a few seconds, you might miss a signage point. But you do need a stable one. If your local network loses internet connectivity for a few seconds, you might miss a signage point. +- Bad wifi connection -- we recommend that you run your farmer with a wired internet connection. If you need to use wifi, try to keep your farmer as close to your router as possible. Bad wifi connection -- we recommend that you run your farmer with a wired internet connection. If you need to use wifi, try to keep your farmer as close to your router as possible. While wifi tends to be consistent enough to run a Chia farm, if your farmer is in a different room than your router, you might occasionally miss a signage point. + +### Can I join a farming pool? + +Yes you can. Please check the [Pool Farming page](/reference-client/farming/pool-farming). + +### I have heard that it's recommended that a winning plot be deleted on mainnet? + +This was our advice in 2020, long before the launch of mainnet. However, we no longer advise anyone to delete their winning plots. + +Some background: The consensus Chia originally used during the testnet phase contained the possibility of an [attack](https://docs.chia.net/chia-blockchain/consensus/attacks-and-countermeasures#bribe-trunk) where an attacker who could co-ordinate N deep from the tip of the chain could try to coerce a winning farmer to re-write a historical transaction block. However, before the launch of mainnet, the consensus was updated; this attack is no longer viable. See the link for more details. + +### Do my plots "wear out" or "go bad"/"go stale" over time? Will I have to regularly re-plot? + +No, your plots are virtually unaffected by the passage of time, aside from hardware errors. Even in the presence of bit flips due to aging hardware, plots remain mostly effective. The only cases where you would need to re-plot are: 1. if you are using solo plots (not NFT plots) and wish to join a pool (please see note below) or 2. if hardware speeds advance to the point of a certain k value becoming obsolete (e.g., `k=32` becomes too fast to plot and we ban them, forcing you to replace them with `k≧33` plots). For case 1., you are free to have any mix of solo plots and pool plots if you do not want to re-plot. For case 2., `k=32` is not expected to become outdated until sometime between 2026-2031. + +- Note on case 1: + We have added a Pooling Protocol that replaces the hard-coded "Pool Public Key" of a plot, with a plotNFT's "Pool Contract Address" - more on this subject can be read here: https://docs.chia.net/reference-client/farming/pool-farming/#pooling-faq + +### Is it possible to have a proof but not get a reward? + +It is unlikely, but it is possible. There are multiple reasons why this might be the case. The most common is that due to network delay, or drive speed delay (for example using a slow NAS), you missed the time for inclusion into the blockchain, which is 28 seconds. This time is from when the timelords create the signage points, to when the timelords infuse your block. Check to make sure that you are connected and synced to multiple peers, and that your quality lookup are fast (\<2 seconds, definitely less than 5). Another reason might be that the signage point where you won did not get included into the blockchain. This can sometimes happen, since timelords may publish signage points that don't end up on chain. + +## Wallet + +### How do I use the Chia faucet? + +To use the [chia faucet](https://faucet.chia.net/) or [testnet11 faucet](https://testnet11-faucet.chia.net/) you will need to identify your **Master Public Key** (also referred to as the **Public Key**). +You can use either the GUI or CLI to identify the Master Public Key by following these steps: + +#### GUI + +:::warning +Never share your private / secret keys or mnemonics with anyone. These give access to spend funds from your wallet. +::: + +1. In the top right corner select logout: + +
+ Logout of the Chia wallet +

+ +2. Using the desired keys menu, select details: + +
+ Select Details for a Chia keyset +

+ +3. View and copy the **Public Key** to the field on the Faucet page: + +
+ Chia keys detail screen, Public Key highlighted +

+ +#### CLI + +:::warning +**NEVER** share your private / secret keys or mnemonics with anyone. These give access to spend funds from your wallet. +::: + +In order to view your keys from the cli, run `chia keys show`, optionally including the `-f ` flag to show only the info for the key you just generated: + +1. From terminal (mac/linux) or powershell (windows) run `chia keys show`: + +```bash +chia keys show +``` + +2. View and copy the **Master Public Key** to the field on the faucet page: + +```bash +Showing all public keys derived from your master seed and private key: + +Label: Demo Wallet +Fingerprint: 2281896037 +Master public key (m): 96ce91d974daa0990e6681ac2de3e3f49142f6b655a081817832265c143e658a6e60a5dec856f292f45fe2d04c7856f6** +Farmer public key (m/12381/8444/0/0): a9e366b26f155491af9a903c0ed9717bfd09a71cbe283eeda825128fd7c6b9ac60e1608f9f008adcfbf66e233d5b4ce8 +Pool public key (m/12381/8444/1/0): 9566fa434f342dd5f9380a6bfc59dd7d1abd22869a425a8ca09cf27200eaa6aad5bc8fc00db90af832eb8028b0c6e3f0 +First wallet address: xch1kr3zf7dqw5q953ex6zt33lndj90q0zlh68404tsntnljthnwqs2qvjmwrg +``` + +:::note +For more security best practices please review the [Securing Your Chia – How to Be a Hard Target](https://www.chia.net/2021/05/28/securing-your-chia-how-to-be-a-hard-target/) blog article. +::: + +### How do I send or receive a transaction? + +The Wallets page in the GUI will display your receive address and provide an interface for you to spend your chia funds. You can also obtain a new wallet receive address any time you would like and those funds will all come to the same place as they are based on [HD Keys](https://www.investopedia.com/terms/h/hd-wallet-hierarchical-deterministic-wallet.asp). + +There is growing wallet functionality available on the command line. Try `chia wallet -h`. Wallet software also provides features related to [CAT's](https://www.chia.net/2021/11/15/the-CATs-out-of-the-bag.en.html), and trade offers. You can get a receive address on the cli with `chia keys show`. + +### What is the Coin model? + +The coin (or [UTXO](https://river.com/learn/bitcoins-utxo-model/)) model is a Bitcoin-style transaction model which is also used in Chia. Your wallet keeps track of a set of coins, where each coin can be any amount of XCH. When spending a coin (making a transaction), you have to spend the entire amount, and split that coin into multiple outputs, called coin additions. One addition is to the recipient of the transaction, and the other one is to you, as change. The change usually goes to a new address, so you will not see it in your normal address on Chia explorer, but your wallet will keep track of it and include it in the balance. Each block in Chia is a list of removals (coins spent) and additions (coins created). There are no transactions in the blockchain, which is why you cannot lookup transactions in the block explorers. + +### What are HD Keys? + +HD or Hierarchical Deterministic keys are a type of public key/private key scheme where one private key can have a nearly infinite number of different public keys (and therefor wallet receive addresses) that will all ultimately come back to and be spendable by a single private key. + +### How many confirmations do I need to trust that a chia transaction is final? + +Small reorgs in Chia are possible, though rare. In order to be confident that your transaction won't be reorged, you should wait around six blocks, or two minutes, after the first confirmation. More details are available in [our consensus documentation](/chia-blockchain/consensus/analysis#safety "Safety analysis of Chia's consensus"). + +### Why is my wallet not synced? Why can I not connect to wallet from the GUI? + +Try the following options: + +1. GUI may not be fully refreshed. Try the "force reload" option under View to force the GUI to refresh. +2. It's possible the wallet DB may be corrupted. Deleting the wallet DB will resolve this, but will also cause you to lose any Offer history and you will need to setup your CAT wallets again. + +To delete your wallet DB follow these steps: + +1. Shut down Chia and all Chia processes, check the task manager to see if they are all shut down. _Note that this will cancel running plots_, so be careful. +2. Restart your computer (if there are still running processes and you can't get those processes to quit) +3. Delete the `~/.chia/mainnet/wallet/db` folder +4. Restart Chia + +### Why do I have a negative balance? Why is my pending transaction not confirming? + +Your pending transaction can take a few minutes if blocks are full. If it's not confirmed after a while, your pending transaction might be stuck. Try the following steps: + +1. Shut down your wallet and node +2. Delete your wallet db files: located at `~/.chia/mainnet/wallet/db`. This will require syncing up your wallet, but not your node. And then you can resubmit the transaction. +3. Make sure you have upgraded to the latest version +4. Start the application and wait for the wallet to sync up +5. After your wallet is fully synced to the same height as the Full Node, your Wallet Balance will be correct. + +Known problem: After your wallet is resynced, any previous outgoing transaction will appear as incoming transaction at the block height you made the outgoing transaction. + +### Where can I buy Chia? + +Visit [chia.net/buy-xch](https://chia.net/buy-xch) for instructions on buying Chia. Visit [offers](https://chialisp.com/offers) to learn more about peer-to-peer trading on Chia. + +There are several exchanges that offer XCH, you can see a list of exchanges supporting XCH on [chialinks](https://chialinks.com/exchanges/) a community created website. This list is for informational purposes only. It is up to the reader to do their own research on the best exchange for their needs. + +### I was running the light wallet beta app and I upgraded to the latest beta and my offer history disappeared. How do I get that back? + +If you were running the light wallet beta app (v1.2.11 dev 265) and you've upgraded to the latest beta (v1.2.12+), you can get your offer history and your CAT wallets back by following these instructions: + +1. Close the Chia app +2. Check the following directory: `~/.chia/mainnet/wallet/db` if it's not empty, then be sure to delete all the .sqlite files that match the key (e.g., `blockchain_wallet_v2_mainnet_1123456789.sqlite`) +3. copy the file(s) from `~/.chia/standalone_wallet/wallet/db/blockchain_wallet_v1_mainnet_123456789.sqlite_new` to `~/.chia/mainnet/wallet/db` +4. rename the file `~/.chia/mainnet/wallet/db/blockchain_wallet_v1_mainnet_123456789.sqlite_new` to `blockchain_wallet_v2_mainnet_123456789.sqlite` +5. launch the Chia app + +### Why does the wallet tab tell me that it's synced, but when I look at the full node tab, it still shows that I'm syncing? + +This is because of the newly integrated light wallet client sync. The wallet will sync through the light wallet sync while the full node syncs up in the background. Once the full node is synced up, then the wallet will sync primarily through the local trusted full node. + +### I lost my offer history, and I have open offers. How do I cancel those offers since I can't access the open offers through the wallet? + +If you've lost your offer history and want to cancel those offers but can't access them, then the only way to cancel the offer would be to send yourself a transaction with the CAT tokens that were part of the offer. + +### Why don't new CAT tokens automatically show up in my wallet anymore? + +The wallet no longer automatically adds unknown CATs wallets for CATs that may have been airdropped to your wallet. This is to help ensure that syncing doesn't slow down with all the additional CATs that could suddenly show up. It is recommended that you use a tail database to look up and add. We understand that this will add some extra work to know which CATs to add wallets for and set them up manually. We do hope to improve upon this experience Soon™ + +### How can I make a coin that may only be spent until a certain timestamp or block height? + +This capability is available by using the `ASSERT_BEFORE_*` conditions, originally added in [CHIP-14](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0014.md). In order to prevent the possibility of bricking a coin, you are recommended to use these conditions only in a coin's _solution_ and not in its _puzzle_. See [our documentation](https://chialisp.com/conditions#assert-before-seconds-relative) for more info. + +### Where is the executable file to start the reference wallet GUI located on Windows? + +If you only installed Chia for the current user, the exe will be installed to the following location (be sure to replace `` with your actual user ID): + +``` +C:\Users\\AppData\Local\Programs\Chia\Chia.exe +``` + +If you installed Chia for all users, then this is the location of the exe: + +``` +C:\Program Files\Chia\Chia.exe +``` + +### What is the dust filter? + +In crypto parlance, "dust" refers to coins that have almost no value. In Chia, the smallest denomination is 1 mojo, or 1-trillionth of an XCH. Unsolicited coins of this value certainly count as dust, but even much larger coins, for example 1 million mojos, are still worth a fraction of a penny. + +Chia experienced its first "dust storm" in late 2021. The "duster" spammed the blockchain with millions of tiny coins, likely in an attempt to stress-test the network. Chia's blockchain is robust, so it continued without issue. However, many people ended up with thousands of dust coins in their wallets. This proved problematic. + +In version 1.2.x, wallets that had received tens of thousands of dust coins were unable to sync. The task of optimizing our wallet was a difficult one, but by version 1.3 we had made significant improvements, and these wallets could finally sync. + +However, sync times for dusted wallets were still measured in days, which was unacceptable. We continued making optimizations, and by version 1.5.1, a wallet with over 100,000 coins could sync within a few minutes. But we wanted to reduce those sync times even more. + +The dust filter is a new feature, added in version 1.6.0. It is activated whenever there are at least a certain number of unspent dust coins in the wallet. While activated, the filter ignores any coins considered "dust". + +Two new settings have been added to `~/.chia/mainnet/config/config.yaml` in the `wallet` section: + +- `spam_filter_after_n_txs: 200` +- `xch_spam_amount: 1000000` + +If you are upgrading an existing Chia installation, these settings won't be added automatically. In this case, you will need to either add them manually or delete `config.yaml` and run `chia init` to generate a new copy. + +The default settings essentially say, "If my wallet contains more than 200 coins, ignore all coins after the first 200 that are worth less than 1 million mojos." Note that the filter is not applied for CATs or NFTs. + +You can modify these default values to support different functionality. For example: + +- Disable the filter by setting `xch_spam_amount` to `0` (nothing is dust) +- Enable the filter regardless of your wallet's status by setting `spam_filter_after_n_txs` to `0` +- Consider coins to be "dust" only if they are smaller than 100 mojos by setting `xch_spam_amount` to `100` + +However, we believe the default settings will be sufficient for most users. + +Note that if the number of unspent coins in your wallet falls to 200 (by default) or lower, then the dust filter will be deactivated. This could happen if you spend or consolidate some of your coins. + +### Why is my wallet's balance inconsistent? + +If you have more than two hundred unspent coins (by default) in your wallet, the dust filter will be activated. Depending on which mode your wallet is using, your balance could show slight differences each time you sync. This is because the coins will not necessarily show up in the same order while syncing. + +The maximum difference in your balance is `spam_filter_after_n_txs * xch_spam_amount`. However, the actual difference will rarely be more than a few thousand mojos. + +There are three potential scenarios: + +1. Light wallet only (untrusted mode) -- Your wallet is syncing from multiple remote full nodes. Each time your wallet syncs, it will connect to a new set of nodes, so the coins might not show up in the same order. Different coins could be filtered, so your balance may be slightly different each time you sync. + +2. Synced full node (trusted mode) on multiple computers -- If you load the same wallet on different full nodes, the databases will be slightly different due to network latency. Even though the coins themselves all exist, they might not show up in the same order, so different coins could be filtered. In this case, your balance might be slightly different between the two computers. + +3. Synced full node (trusted mode) with one computer -- Your trusted database will be the same each time you sync, so the wallet balance will also be the same. + +### Why does my wallet say `Error Can't send more than xxxxxxxx mojos in a single transaction`? + +This error can occur when attempting to send XCH, CATs, or NFTs. Unfortunately, the error is vague, so there is a bit of guesswork in determining the cause. In the future, we plan to make this error -- along with the recommended way to fix it -- more specific. + +Some of the potential causes include: + +1. You don't have enough money in your wallet. Double check your wallet's `Total Balance`. +2. You have enough money, but one or more of your coins are locked. Chia uses the [coin set model](#what-is-the-coin-model) of accounting, where everything is a coin. If some of your coins are part of either a pending transaction or an [Offer](#offers), they have been temporarily locked. In this case, your `Spendable Balance` is less than your `Total Balance`. In order to unlock these coins, cancel any pending offers and click `Actions` --> `Delete Unconfirmed Transactions` in your wallet's `Summary` panel. +3. The CLVM cost of your transaction is greater than the maximum cost allowed. In order to add a Chia transaction to the blockchain, a certain amount of processing power is required. This is the transaction's _cost_. When sending a single coin or NFT to another wallet, the cost is low. However, if you are attempting to send hundreds of coins or dozens of NFTs in a single transaction, the total cost could be prohibitively high, thus triggering the error. One way to fix this is to break your large transaction into multiple smaller ones -- try sending only the amount indicated in the error message. Another fix is to [combine your coins](/reference-client/cli-reference/wallet-cli#combine) by opening a command prompt or terminal window and running `chia wallet coins combine`. + +### Is there an RPC to list wallet names? + +Unfortunately, no. However, to obtain the user-specified wallet names programmatically, you can use the `chia keys label show` CLI command. + +Another way to obtain this info is by connecting to the daemon over a websocket by using `wscat`: + +```bash +wscat -n --cert ~/.chia/mainnet/config/ssl/daemon/private_daemon.crt --key ~/.chia/mainnet/config/ssl/daemon/private_daemon.key -c wss://localhost:55400 +``` + +From there, you can use the `get_keys` command, similar to the following example (the `request_id` can be any string): + +```json +{ + "ack": false, + "command": "get_keys", + "data": {}, + "destination": "daemon", + "origin": "client", + "request_id": "43dc226cef76963ddd56c7068972947f373918c24b0fdf5bfa767a1340271da6" +} +``` + +This command will return a payload with all of the pubkeys/fingerprints/labels -- private keys omitted. + +If you want the private keys included, pass `"include_secrets":true` in the data object. For example: + +```json +{ + "ack": false, + "command": "get_keys", + "data": { "include_secrets": true }, + "destination": "daemon", + "origin": "client", + "request_id": "43dc226cef76963ddd56c7068972947f373918c24b0fdf5bfa767a1340271da6" +} +``` + +### How do I disable the dust filter? + +1. Edit `~/.chia/mainnet/config/config.yaml` +2. If `xch_spam_amount` doesn't exist, add it +3. Set the value for `xch_spam_amount` to `0` (nothing is dust) +4. Restart Chia + +### Can I import a 12-word mnemonic seed phrase from another wallet? + +Starting in version 1.7.0, Chia's reference wallet will accept both 12- and 24-word mnemonics. This allows you to import a mnemonic from another wallet. Simply click `IMPORT FROM 12 WORD MNEMONIC` when importing your wallet. However, do keep in mind: + +- Chia's reference wallet only allows you to _import_ a 12-word mnemonic. It does not allow you to create a new 12-word mnemonic. +- Certain wallets use 12-word mnemonics that are not compatible with Chia's reference wallet. As far as we know, this only applies to the Pawket wallet, but there may be others as well. In the case of Pawket, you need to export a 24-word mnemonic from their app in order to use Chia's reference wallet. More info can be found on their [FAQ page](https://info.pawket.app/faq/). + +### How can I configure Chia to reuse the same receive address? + +By default, Chia will update your receive address for every new transaction. This is done for privacy reasons -- it is more difficult to associate multiple transactions with the same wallet if each transaction uses a different address. + +However, there are some downsides to using multiple addresses: + +- It can be more difficult to track the history of your own transactions. For example, block explorers cannot associate multiple addresses with the same wallet. (Note, however, that the reference wallet _will_ show you a complete history.) +- Some wallets only search a limited number of addresses for a given key, so they may not display your full balance. +- Wallet performance can degrade after a large number of addresses have been used. This is because the wallet must search for transactions for each address in the derivation index. + +Starting in version 1.7.1, Chia's reference wallet will allow you to keep the same receive address with each transaction. If you change this setting, each of the above issues will be mitigated, at the expense of reduced privacy. + +To set up your wallet to reuse the same receive address: + +1. Edit `~/.chia/mainnet/config/config.yaml` +2. Search for `reuse_public_key_for_change:` + +If this parameter doesn't exist, you can add it manually. Under `wallet:` add the following two lines: + +```bash +reuse_public_key_for_change: + '2999502625': false +``` + +3. `2999502625` is a dummy fingerprint that is added by default. You will need to obtain your wallet's fingerprint actual by running `chia keys show`. For example, + +```bash +$ chia keys show +Showing all public keys derived from your master seed and private key: + +Label: Testnet1 +Fingerprint: 2104826454 +``` + +4. Change the dummy fingerprint to your wallet's actual fingerprint, and update the value to `true`. For example, + +``` +reuse_public_key_for_change: + '2104826454': true +``` + +5. If you wish to specify the behavior for more than one fingerprint, you can add additional fingerprints to new lines. If a fingerprint is not listed, the default value of `false` will be used. +6. Restart Chia for the changes to take effect. Your wallet will now reuse the same receive address for every transaction. + +To verify that the same address is being reused: + +1. Run `chia wallet get_address -f `. + - Replace `` with the fingerprint you would like to test + - This command will give you the latest address for that fingerprint +2. Run `chia wallet send -f -t
-a 0.000000000001 -m 0.000000000001 --override`. Some notes: + - Replace `` with fingerprint you used in step 1 + - Replace `
` with the address you retrieved from step 1 + - This command will send 1 mojo to your latest address, and attach a 1 mojo fee. Feel free to adjust these amounts accordingly. (You can also send money from the GUI.) + - The `--override` flag is needed because the amounts to send are considered unusual +3. After the transaction has completed, run `chia wallet get_address -f `. You should receive the same address as you received in step 1. If you received a different address, `reuse_public_key_for_change` was not set to `true` for the specified fingerprint. + +### What is identical spend aggregation? + +Identical spend aggregation is a mempool feature that allows multiple different spend bundles to spend the same coin. It is being introduced in version 1.8.2. It is being introduced in version 1.8.2. + +There are two requirements for identical spend aggregation to be successful: + +1. The puzzle of the coin being spent must not contain any `AGG_SIG_ME` or `AGG_SIG_UNSAFE` conditions +2. Each of the spend bundles that spend the coin must have identical solutions for spending that particular coin + +In cases where both of these requirements are met, when a farmer creates a block, it will choose one of the identical spends from the mempool as the "winner", based on which transaction pays the highest fee-per-cost. The remaining copies of that spend will then be deduplicated against the winner (they will be aggregated into a single spend). Any announcements the coin makes will then be available for any other spend to assert within the same block. The remaining copies of that spend will then be deduplicated against the winner (they will be aggregated into a single spend). Any announcements the coin makes will then be available for any other spend to assert within the same block. + +### Which mempool feature does identical spend aggregation introduce? + +In Chia versions prior to 1.8.2, two key features were not supported by the mempool: + +1. The ability of a transaction to spend the output of another mempool item (i.e. inter-transaction ephemeral spends) +2. The ability to assert an announcement made by another mempool item (i.e. inter-transaction announcements) + +These features both would necessitate the creation of dependency graphs, which a farmer would need to solve (and ideally optimize) when creating a block. + +Regarding feature 1, the only ephemeral spends that are currently supported must come from the same spend bundle. Inter-transaction ephemeral spends are not yet supported as of version 1.8.2. _Inter-transaction_ ephemeral spends are not yet supported as of version 1.8.2. + +Chia version 1.8.2 introduces identical spend aggregation, which addresses some of the use cases of Feature 2. Spends that make use of this feature are still restricted by the lack of `AGG_SIG_*` conditions, which means that anyone who needs to assert an announcement from an aggregated spend could also have spent the coin. However, this version brings Chia one step closer to offering full support for inter-transaction announcements. + +### Why do I see `INVALID_FEE_TOO_CLOSE_TO_ZERO` in my log file? + +This error message occurs when you submit a transaction that does not include a high enough fee, for example when the network is quite busy. Try submitting the transaction again with a higher fee (100 million mojos will generally suffice for standard transactions). For more details, see our [mempool documentation](/chia-blockchain/architecture/mempool#fee-required-for-inclusion). + +--- + +## Cloud Wallet + +See our dedicated page for [Cloud Wallet FAQs](/cloud-wallet/faq). + +--- + +## Offers + +### What are Chia Offers? + +Chia Offers enable a decentralized, peer-to-peer trading of assets on the Chia blockchain. For more information, see our: + +- [Technical reference document](https://chialisp.com/offers) +- [GUI (graphical user interface) tutorial](/reference-client/getting-started/wallet-guide) +- [Video - Offers GUI Demo](https://youtu.be/Z2FoZSNtttM) +- [CLI (command line interface) tutorial](/guides/offers-cli-tutorial) + +### After creating an offer file, why does my spendable balance differ more than the amount specific in the offer? + +When you create an offer, [coins are reserved](https://chialisp.com/offers#offer-states) to ensure that when the offer has been accepted and written on to the blockchain, the transaction can be completed. Chia's wallet will reserve the largest coin to fulfill an offer, and when that coin is reserved, it will lower the spendable balance by the total coin amount. + +### I plan on making many offers and I want to ensure that my coins aren't locked up? + +To create smaller coins, send money to your own wallet in smaller denominations. For more info, see our [reference doc](https://docs.chia.net/reference-client/cli-reference/wallet-cli/). + +### When canceling an offer, when should I check the "cancel on blockchain" checkbox? + +You should use this option if the offer file has left your computer. If you don't use this option, someone who sees your offer could still accept it. See our [reference doc](https://chialisp.com/offers#cancellation) for more info. + +### If I cancel my offer on the blockchain, will other people be able to fulfill it? + +No, canceling on the blockchain ensures that your offer can no longer be fulfilled. + +### I'm accepting an offer, but it shows a Unknown CAT, what should I do? + +You should always check the ID of the asset(s) being offered before accepting any offers. First make sure you have a CAT wallet set up for the assets that you are trading for and are getting that information from a reputable source. Second, when you view the offer in the wallet, ensure the amounts and the CATs match up to what you are expecting. For more info, see our [GUI tutorial](https://chialisp.com/offers-gui-tutorial#taker-accepts-an-unknown-cat-offer). + +### Where can I share my offers? + +Once you've created the offer, you'll need to find someone who will take the other side of it. You can share your offers through the following methods: + +- Send your offer file directly to another user +- [Offerpool.io](https://offerpool.io/) - an open-sourced, decentralized offers database built on top of OrbitDB and IPFS +- [dexie.space](https://dexie.space/markets) - a decentralized exchange for Chia offers supporting Chia tokens (CATs) and NFTs + +### Why don't I see the offers option in my wallet? + +You are probably running a very old version before it was integrated into both the Full Node and Light Wallet options. You should download and install the [latest version](https://www.chia.net/downloads) of the reference software. Now you can farm and use all the new features of the wallet. + +### How do I know if I'm getting the right exchange value for an offer? + +Prices in cryptocurrencies fluctuate all the time. You can review any of the existing decentralized exchanges like Dexie, HashgreenSwap, Offerpool, or TibetSwap to see what trading pairs are trading for in the open market. Alternatively you can find a reputable centralized exchange website that will give you the valuation in local currencies. + +### Will my Offers sync across different Chia wallets on different machines? + +No, Offers are created and stored locally on each machine. Any accepted offers will only be seen by other computers through the transaction history list. + +### Can my coin be spent on another computer with a wallet that uses the same keys, even if I am running two wallets on two different computers and I have an open Offer on one computer? + +Yes, the coin can be spent from another computer. Coins are reserved locally on the computer where the offer was created. If that coin is spent from another computer, then the offer will be canceled. In general, it is recommended that you don't use two machines to access the same wallet that offers are being made from. + +### Why do I see `Error 6` when attempting to accept an Offer? + +Version 1.7.0 of the reference wallet uses a slightly different Offer format than previous versions. If your version of the reference wallet is older than 1.7.0, and the offer was created on version 1.7.0 or later, you will see `Error 6`. + +![Error 6](/img/error_6.png) + +To fix this, download and install the [latest version](https://www.chia.net/downloads) of the reference wallet and accept the same offer. You should no longer see the error. + +--- + +## NFTs + +### What are NFTs? + +Non-Fungible Tokens have become extremely popular in the last few years. [This site](https://www.simplilearn.com/tutorials/blockchain-tutorial/what-is-nft "Basic NFT Explanation") gives a beginner-friendly explanation of what NFTs are. + +### How do I buy NFTs? + +Chia NFTs make use of a unique feature: [Offers](https://chialisp.com/offers). You may already have used Offers to trade XCH and CATs, but to summarize, they enable the trustless, peer-to-peer exchange of assets on Chia's ecosystem, with no involvement from central parties or intermediaries. And now you can use them to buy and sell NFTs, as well. Simply click the Offers button in your Electron wallet, then click "Create an Offer" and "NFT Offer". We'll have a more detailed guide that includes all of the options soon. + +### How can I make an NFT offer using the CLI? + +The CLI commands for NFT offers are almost the same as [those for CAT offers](https://chialisp.com/offers-cli-tutorial#create-a-single-token-offer). The main difference is that you have to include the NFT singleton's value after the NFT ID (typically this is `:1`). For example, to make an offer, you can run: + +```bash +chia wallet make_offer -o 1:0.1 -r nft1g5gzj3hl9gdyrq83zveepf8wmeet8mxl8zutfyahs0wfkg9mcs9qepc4w5:1 -p test.offer -m 0.001 +``` + +The result is: + +``` +Creating Offer +-------------- + +OFFERING: + - 0.1 XCH (100000000000 mojos) +REQUESTING: + - 1 nft1g5gzj3hl9gdyrq83zveepf8wmeet8mxl8zutfyahs0wfkg9mcs9qepc4w5 (1 mojos) +Offers for NFTs will have royalties automatically added. Are you sure you would like to continue? (y/n): y +Confirm (y/n): y +Created offer with ID 55314ee65db39c173de05873138440c48525eac39fd4a622fd766b3bb4ab02ff +Use chia wallet get_offers --id 55314ee65db39c173de05873138440c48525eac39fd4a622fd766b3bb4ab02ff -f 2118200991 to view status +``` + +To view your new offer, run the `get_offers` command that was output upon the offer's creation. Using the above example: + +```bash +chia wallet get_offers --id 55314ee65db39c173de05873138440c48525eac39fd4a622fd766b3bb4ab02ff -f 2118200991 +``` + +The result is: + +``` +Record with id: 55314ee65db39c173de05873138440c48525eac39fd4a622fd766b3bb4ab02ff +--------------- +Created at: 2022-07-12 11:27:17 +Confirmed at: 0 +Accepted at: N/A +Status: PENDING_ACCEPT +--------------- +``` + +### How can I take an NFT offer using the CLI? + +Continuing with the previous example, we can run the `take_offer` command from the wallet that owns the NFT: + +``` +chia wallet take_offer test.offer +Summary: + OFFERED: + - XCH (Wallet ID: 1): 0.1 (100000000000 mojos) + REQUESTED: + - 45102946ff2a1a4180f1133390a4eede72b3ecdf38b8b493b783dc9b20bbc40a: 0.001 (1 mojo) +Included Fees: 0.001 +Would you like to take this offer? (y/n): y +Accepted offer with ID 11abdc8b7bb241303d2f0c909860785e0e09a842fb6178bdf6527c99e37f3d35 +Use chia wallet get_offers --id 11abdc8b7bb241303d2f0c909860785e0e09a842fb6178bdf6527c99e37f3d35 -f 757927417 to view its status +``` + +Use the suggested command to view the offer's status: + +``` +chia wallet get_offers --id 11abdc8b7bb241303d2f0c909860785e0e09a842fb6178bdf6527c99e37f3d35 -f 757927417 + +Record with id: 11abdc8b7bb241303d2f0c909860785e0e09a842fb6178bdf6527c99e37f3d35 +--------------- +Created at: 2022-07-12 11:41:50 +Confirmed at: 1241919 +Accepted at: 2022-07-12 11:41:50 +Status: CONFIRMED +``` + +### Can I send an NFT to an XCH address? + +是的。 Just as with XCH and CATs, you can send NFTs to an XCH address. If the recipient doesn't have an NFT wallet, one will be created automatically. + +### How do I sell my NFTs? + +As with buying NFTs, you can also sell them using Offers. Simply create an Offer in your Electron wallet, then send it wherever you want, including to our community galleries and marketplaces such as [MintGarden](https://mintgarden.io/), [Dexie](https://dexie.space/markets), and [SpaceScan](https://www.spacescan.io/). If an Offer file is modified, then that copy is no longer valid. This means that you can share your Offers with confidence -- the only thing a "thief" can do with your Offer is accept it. + +### Is there any limitation to which assets I can offer? + +As of version 1.6.1, you can use the Offer Builder to construct an offer of any asset(s) for any other asset(s). This includes offering XCH, CATs, and NFTs on both sides of the offer. + +### What is the difference between a transfer and a sale? + +A sale involves using an offer, which in turn requires an NFT to be exchanged for one or more assets. Any time you want to buy or sell an NFT, you will create or accept an Offer. Royalties are built into the NFT, so they will automatically be accounted for when the offer is created/accepted. + +A transfer is where you move an NFT from one address to another. No money is exchanged, and there are no royalties. The two main use cases for transferring an NFT are + +- Moving an NFT to another wallet that you own +- Giving an NFT away for free + +### Do I need a new wallet address in order to receive NFTs? + +No. You can send and receive NFTs from the same address you have used in the past. One caveat is that if you send an NFT to an address that is currently running on a pre-1.4 wallet, your wallet won't _recognize_ the NFT. However, the NFT will be safely kept inside your wallet, and it will become accessible after you upgrade to version 1.4 or greater. + +### How do I mint an NFT? + +If you are comfortable using a command line interface (CLI), then you can follow our [dev guide](/guides/nft-intro) to mint an NFT. If you prefer a browser-based minting tool, options include [MintGarden](https://mintgarden.io/mint) and [Omakasea ChiaNFT](https://github.com/OmakaseaNFT/chia-nft-util). Other community-developed marketplaces are listed on [ChiaLinks.com](https://chialinks.com/nfts/). + +### Can I mint an NFT with a URL that includes a comma? + +Yes, but you need to use an RPC. If you use the CLI command, the comma will be interpreted as a delimiter -- two separate URLs will be created. However, even though URLs that include commas are generally not recommended, they should work with the RPC command. You don't even need to escape the comma or use extra quotes. But, as with all things NFT-related, you should test this functionality on the testnet before attempting it on mainnet. + +### What does it mean to self-custody an NFT? + +On other blockchains, NFTs are typically custodied in a marketplace. This is akin to having an account with a company. The marketplace has a reputational motivation to keep your NFT safe and secure, but your NFT is still in their hands. + +_Self custody_ means that you have control over your own assets. The same mantra of "Not your keys, not your coins" also applies to NFTs. When you self-custody your Chia NFTs, it means that they are controlled by _your_ keys, and therefore they are _your_ assets. + +### Where does my NFT live? + +There are two components of a Chia NFT: on-chain and off-chain. + +**On-Chain:** An NFT is a special type of coin called a "singleton". It contains three lists of URIs, which link to: + +1. The NFT's data. This is typically an image file. +2. The NFT's metadata. This is typically a JSON file containing information about the NFT. +3. The NFT's license. This is typically a text file the spells out what rights the NFT's owner has. + +The URI lists can only be prepended to; existing URIs cannot be modified or deleted. + +For security purposes, each NFT contains a hash of the data represented by each of the corresponding URIs. The hashes can never be modified after minting. + +**Off-Chain:** The actual NFT image lives in at least one location online. It can be stored under any number of URI protocols, including (but not limited to) http, https, ftp and ipfs. + +Because Chia NFTs use a _list_ of URIs (as opposed to a single one), the image can be stored in multiple locations. This is important for preserving an NFT's permanence because a single link could break. + +For high-end NFTs, you may even want to store the image offline. Why would you do this? Let's say each of the online links is broken. As long as you (or anyone else) has a copy of the image, you can upload it and add a new link to the NFT. As long as the image's hash matches the hash that's built into the NFT, the new image is guaranteed to be identical to the original, and therefore valid. It is for these reasons that we believe NFTs on Chia will have stronger permanence than on any other blockchain. + +The same rules apply for the metadata and license information. They can exist in multiple locations, but their hashes may not be modified after the initial minting. This prevents future owners from modifying this information, even though they can add new links. + +The metadata URI can provide a wide variety of information about the NFT, including its title, properties (eg - year created, attributes, colors used, etc), rankings (eg - power: 25 out of 100, etc), collection name, as well as series number (eg - 1 of 100). The NFT's minter is free to include whatever information they want at the time of minting. The NFT1 spec allows different metadata formats to be developed. At the time of this writing, almost all NFTs use [CHIP-7](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0007.md), which allows marketplaces to parse the metadata more easily. + +The license URI can provide any relevant information concerning the NFT's license, such as who owns the Intellectual Property. + +### Can I add new links? + +You can add new URIs to the data, metadata and license URI lists of any NFT you own. The new URIs will always be prepended to the list (added to the front of the list). + +### After the NFT has been minted, is there a limit to how many links I can add at a time? + +Yes -- you can only add one link at a time. After the transaction has been processed, you can add another link. + +### Is there a limit to the total data size of the metadata? + +No. (Well, you can't have infinite data, but Chia doesn't enforce any limits.) + +### Is there a limit to the number of links? + +Chia doesn't enforce a limit. However, because the links are contained within the NFT, as you add links, the size of the NFT also grows. If you were to add thousands of links, the NFT would eventually grow so large, it wouldn't fit inside a block and would no longer be spendable. If you only wanted to add a few dozen links, you would not run into this limitation. + +### Are all the links posted on every spend, or only when adding them? + +On Chia's blockchain, everything is a coin. This includes XCH, CATs, and NFTs. Whenever any coin is spent, the original puzzle is revealed. Therefore, with NFTs, every link is posted on every spend. + +### Can I modify links? + +You cannot modify or remove any existing URIs, or their corresponding hashes. This was a design decision to keep NFTs from being arbitrarily modified after their minting. + +### Does an NFT transaction take longer than an XCH (or CAT) transaction? + +In Chia, all transactions within a single block are processed simultaneously. As long as your NFT makes it into a block, it will take the same amount of time as any other transaction to process. The only caveat is that NFTs have a higher CLVM cost than XCH transactions. Therefore, if the mempool is full, a higher fee will be required in order for an NFT to be included in a block. However, if the mempool is not full, then this caveat does not apply. + +### How much is the fee for minting/selling an NFT? + +If the mempool is not full, then no fee is needed. If the mempool is full, then in order for your transaction to be included into the next block, you'll need to add a fee of at least 5 mojos per cost. The recommended minimum fee in this scenario is: + +- Minting an NFT with a DID: 615 million mojos +- Transferring/selling an NFT: 335 million mojos + +For other scenarios, see [our NFT developer documentation](/guides/nft-intro). + +### What happens if exactly the same `nft mint` command is executed twice? + +Then two separate NFTs will be created. They will have different IDs, but everything else will be identical. + +### How do royalties work? + +An NFT's royalty percentage and receive address may optionally be included in an NFT upon its minting. After the NFT has been minted, the royalty may never be modified. If an NFT includes a royalty, then every time the NFT is sold, the appropriate percentage of the sale will be paid to the royalty's receive address (typically the address of the original artist). The amount paid both to the new owner, as well as the royalty address, will be clearly displayed within the Offer. + +On other blockchains, royalties are paid at the discretion of the marketplace on which the NFT is custodied. On Chia, however, the royalties are built directly into the NFT. While under-the-table transfers could still circumvent royalties, they would also introduce counterparty risk for both the buyer and seller. In order to transfer a Chia NFT in a trustless manner, royalties must be paid. + +### Are there any royalties when exchanging an NFT for another NFT? + +No -- there would be no fair way to assess royalties for NFT-for-NFT offers, so these are treated as swaps with no royalties being calculated. + +### How are royalties calculated in offers that involve multiple assets? + +This depends on what assets are included in the offer. A few rules to keep in mind: + +1. If more than one NFT is being traded, the royalties will be divided by the number of NFTs. For example: + - If 4 NFTs are being traded for 1 XCH, then each NFT will have an assumed price of 0.25 XCH + - If the royalty for each NFT is 10%, then each NFT will receive a 0.025 XCH royalty, for a total royalty of 0.1 + - If the royalties are 10%, 8%, 5%, and 3%, then the NFTs will receive 0.025 XCH, 0.02 XCH, 0.0125 XCH, and 0.0075 XCH, for a total royalty of 0.65 XCH +2. If the NFTs are being traded for more than one fungible asset, then the royalties will be calculated for each asset individually + - For example, if 1 NFT is being traded for both 1 XCH and 1000 SBX and it carries a 10% royalty, then the royalties shall be 0.1 XCH and 100 SBX for this sale +3. If multiple NFTs are being traded for multiple fungible assets, then rules 1. and 2. will both be applied +4. When NFTs are traded for other NFTs, no royalties are exchanged + +### Can I use more than one royalty address? + +An NFT can include a maximum of one royalty address. However, because the royalty address can be any XCH address, the address can correspond to a smart coin that splits all royalties between multiple recipient addresses. See [CHIP-8](https://github.com/Chia-Network/chips/pull/30) for one potential implementation of split royalties. + +### Are royalties paid upon transferring an NFT? + +No. Transfers are conducted without any royalties being paid. + +### What is the Chia Friends project? + +Chia Friends was an airdrop of 10,000 NFTs. While Chia Network Inc gave these NFTs to 10,000 lucky recipients for free, they currently can be bought or sold just like any other NFT. All sales include a 3% royalty, which goes to the Marmot Recovery Foundation (here's their [wallet address](https://www.spacescan.io/xch/address/xch120ywvwahucfptkeuzzdpdz5v0nnarq5vgw94g247jd5vswkn7rls35y2gc)). For more information, see the [Chia Friends website](https://www.chiafriends.xyz/). + +### Is Chia Friends the same as the Holiday 21 token? + +No, these are two completely different projects. + +Chia Friends was an airdrop of 10,000 NFTs. While Chia Network Inc gave these NFTs to 10,000 lucky recipients for free, they currently can be bought or sold just like any other NFT. All sales include a 3% royalty, which goes to the Marmot Recovery Foundation (here's their [wallet address](https://www.spacescan.io/xch/address/xch120ywvwahucfptkeuzzdpdz5v0nnarq5vgw94g247jd5vswkn7rls35y2gc)). For more information, see the [Chia Friends website](https://www.chiafriends.xyz/). + +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 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. + +### Why do I have a Profile in my wallet? + +The Profile in your wallet is a Decentralized Identifier (DID). These can be used for tracking an NFT's provenance (history). Each NFT can be assigned to one DID. Though not strictly required, most NFTs will use DIDs for their added provenance. You can create a new DID by clicking the Settings button (the gear icon) in the lower left corner of Chia's Electron wallet. + +### Do I need to have a Profile to own/trade an NFT? + +No. NFTs can be left unassigned to a Profile. + +### How do I use the CLI for creating and using DIDs and NFTs? + +Our [dev guide](/guides/nft-cli) will walk you through creating DID and NFT wallets, minting an NFT, adding links and transferring your NFT, all using the CLI. In addition to the dev guide, we have a complete reference with all CLI commands for using [DIDs](/reference-client/cli-reference/did-cli) and [NFTs](/reference-client/cli-reference/nft-cli). + +### What RPC functionality is available for DIDs and NFTs? + +We also have a [dev guide geared at using RPCs](/guides/nft-rpc). For more details about each of our individual RPCs, see our reference for [DIDs](/reference-client/rpc-reference/did-rpc) and [NFTs](/reference-client/rpc-reference/nft-rpc). + +### What limitations, if any, are there for NFTs on Chia's blockchain? + +Chia's [bulk minting tool](/guides/nft-bulk-mint) allows you to mint 25 NFTs per block. If you attempt to mint more than this, you run the risk of your spend bundle sitting in the mempool for a long time. Additionally, if you don't use the bulk minting tool (or a similar tool), you can only mint one NFT per block. + +### Are there any security concerns I should consider? + +Unfortunately, fraud and outright theft are common in this space. If you take a few basic precautions, you'll have a much better chance of keeping your NFTs safe: + +- Never give away your wallet's seed phrase. If anyone asks for it, they are attempting to scam you. +- When viewing an offer for an NFT, always check its provenance. The links to do this are located below the image when viewing it in an offer. An NFT's provenance is a complete record of its ownership history. This helps to verify that the NFT is authentic. +- Avoid directly sending someone money in exchange for an NFT. Use offers whenever possible. Occasionally, legitimate projects may require you to send them a token in exchange for an NFT, but the most secure way to buy and sell NFTs is with offers. + +### What recovery options are available if my NFT gets stolen? + +If your NFT is stolen, then unfortunately there's not much you can do, other than offer to buy it back from the thief or the current owner. This is why you should be extra diligent in avoiding theft in the first place, beginning with following the above tips. + +### What is the stance on NSFW NFTs being created? + +Chia Network Inc has no ability to censor content on the Chia blockchain. However, the metadata schema that most NFTs use includes a `"sensitive_content"` object, with a default value of `false`. This flag will indicate to wallets and marketplaces whether the NFT contains any sensitive content, which they can then use in deciding whether to display the NFT. + +### How do I configure my system to send and receive notifications? + +Starting in version 1.6.1, you can send and receive notifications to a specified puzzle hash. This will eventually enable us to support sending an offer to an NFT's owner without having to go through an exchange. + +This functionality is disabled by default. It includes two settings in the `wallet:` section of `~/.chia/mainnet/config/config.yaml`: + +- `accept_notifications` - a boolean to specify whether you want to allow notifications to be received. If this setting is missing, it will automatically be set to `false`. Set to `true` to receive notifications +- `required_notification_amount` - the amount (in mojos) you require to be sent with a notification in order to receive it. If this setting is not specified, the default of `10000000` (10 million) will be used + +In order to enable notifications, you can either add these settings manually, or rename `config.yaml` and run `chia init`. A new copy of `config.yaml` will be created which contains the new settings. + +Finally, you need to restart Chia for these settings to be picked up. + +Note that for version 1.6.1, messages are sent and received via an RPC only. This is a primitive that will be added to the GUI in a future release. For more information on sending and receiving messages, see our [RPC documentation](/reference-client/rpc-reference/wallet-rpc#send_notification). + +### How can I use the CLI to send an Offer notification to the owner of an NFT? + +This process is documented under `Example 2` of the [send_notification](/reference-client/rpc-reference/wallet-rpc#send_notification) RPC doc. + +### How can I sign and verify a message with an NFT? + +From the CLI, you can use the `chia wallet nft sign_message` command. See [our CLI documentation](/reference-client/cli-reference/nft-cli#sign_message) for more details. + +From the GUI, you can sign and verify messages from the `ADVANCED` tab in the `Settings` section. Note that as of February 2023, this has not been included in an official build yet. It is only available in the `main` branch of the [chia-blockchain-gui](https://github.com/Chia-Network/chia-blockchain-gui/) repository. Eventually this will be added to an official build, but for now you can use it at your own risk. + +1. Click `Settings`, click on the `ADVANCED` tab, and click `CREATE SIGNATURE`: + +![ADVANCED tab](/img/verify_signature/1_advanced_tab.png) + +2. Click `NFT`, enter the message you want to sign, and click `SIGN`: + +![Sign a message](/img/verify_signature/2_sign_nft_message.png) + +3. The message details will appear. Copy these details to the clipboard or save them to a file: + +![Show the signed message](/img/verify_signature/3_show_message.png) + +4. To verify a signature, click `VERIFY SIGNATURE` from the `ADVANCED` tab and enter the signature's details: + +![Verify the message](/img/verify_signature/4_verify_message.png) + +5. If the signature is valid for the details you entered, you will receive a `Valid` message: + +![Message verified](/img/verify_signature/5_signature_verified.png) + +--- + +## Support/Miscellaneous + +### What are the minimum officially supported OS versions? + +- MacOS 13.0 Ventura +- Windows 10 +- Ubuntu 18.04 (20.04 highly recommended) +- Raspberry Pi OS 64 or Ubuntu 20.04 for Pi/ARM64 (Not recommended for plotting or timelord) +- An SSD for storing the blockchain's database. A 512 GB or larger model with 520 MB/s read/write speeds will work just fine and is available for around $30 USD (do not use an SD card as they are not fast enough) + +### What versions of Python are supported? + +- Chia supports all versions of Python that have not reached their end-of-life. Starting with Chia version 2.0.0, the minimum version of Python supported is 3.8. See the official Python version list for more info. Starting with Chia version 2.0.0, the minimum version of Python supported is 3.9. See the [official Python version list](https://devguide.python.org/versions/) for more info. + +### How do I verify file checksum? + +Use the instructions below to verify Chia download integrity in a command line. Windows – Verify Checksum +Windows – Verify Checksum + +Run the following command: + +``` +certutil -hashfile [location of file] SHA256 +``` + +For example: + +``` +certutil -hashfile C:\Users\%USERNAME%\Downloads\Setup-Win64.exe SHA256 +``` + +macOS – Verify Checksum + +Run the following command: + +``` +shasum -a 256 [location of file] +``` + +For example: + +``` +shasum -a 256 ~/Downloads/Setup-MacOS.dmg +``` + +Linux – Verify Checksum + +Run the following command: + +``` +shasum -a 256 [location of file] +``` + +For example: + +``` +shasum -a 256 ~/Downloads/chia-blockchain_1.1.7_amd64.deb +``` + +### Can I use a fast SAS HDD for storing the blockchain's database? + +A very high-end HDD will not be fast enough, so we recommend a $30 SSD, as stated above. It can be an external SSD, connected via USB, but a dedicated internal connection is preferred. The database is always growing, but 512 GB should be sufficient until at least 1H 2027. + +### Can I run this on a Raspberry Pi 3 or 4? + +Raspberry Pi 4 is supported, but Pi 3 is not. Here are the [instructions](/reference-client/install-and-setup/installation#raspberry-pi). This project requires a 64-bit OS. One can install and run harvesters, farmers, and full nodes on the Pi. Plotting on a Pi is feasible now with Chacha8 instead of AES, but the Pi isn't quick. Modern desktops and laptops plot in the 0.07 - 0.10 GiB/minute range and the Pi 4 plots at 0.025 GiB/minute. Pi is also not a candidate for Timelords or VDF clients... + +### How do I upgrade and keep my keys and plots? + +If you use the GUI, it will migrate from release to release for you. For both the GUI and the command line, your keys are stored on OS specific keychains. If running services from the command line only, `chia init` will migrate your config.yaml and dbs - if appropriate - to the new version. Keys and plots made before Beta 8 are deprecated and useless. + +### Where is the executable file to start Chia's reference wallet on Windows? + +Windows users can run `C:\Users\\AppData\Local\Programs\Chia\Chia.exe` (be sure to replace `` with the actual ID) to start the reference wallet GUI. This will also start a full node if that features has been enabled. + +### I installed Chia with the packaged installer. How do I run CLI commands? + +For power users, it is possible to [install Chia from source](/reference-client/install-and-setup/installation#from-source). In this case, you will run Chia from a virtual environment on the command line. + +However, most users will prefer to download a packaged installer from Chia's official [download site](https://www.chia.net/downloads/). + +After installing with the packaged installer, you can run Chia from the command line by invoking the executable file. The easiest way to set this up is by running the `alias` command. The exact command needed depends on your OS: + +:::info Chia setup + + + +(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: + +```powershell +Set-Alias -Name chia "C:\Program Files\Chia\resources\app.asar.unpacked\daemon\chia.exe" +``` + + + + +Alias command is not needed, but you should still run the following: + +```bash +chia init --fix-ssl-permissions +``` + + + + +```bash +alias chia='/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/chia' +chia init --fix-ssl-permissions +``` + + + + +::: + +To test your setup, run `chia version`. You should be shown the correct version. For example: + +```powershell +chia version +1.6.1 +``` + +### Where are the config and log files stored? + +Linux & macOS + +``` +Chia config: ~/.chia/mainnet/config/config.yaml +Chia logs: ~/.chia/mainnet/log/ +``` + +Windows + +``` +Chia config: C:\Users\%USERNAME%\.chia\mainnet\config\config.yaml +Chia logs: C:\Users\%USERNAME%\.chia\mainnet\log\ +``` + +### How do I change the log level to show more detail? + +CLI + +You can use the CLI command chia configure --set-log-level INFO to set your log level to the useful INFO setting. Be sure to restart Chia after making settings changes. Config File Be sure to restart Chia after making settings changes. +Config File + +In `config.yaml` you can set the level of detail for your logs. + +Look for this section in `config.yaml`. It’s useful to change the logger setting `log_level` from `WARNING` to `INFO` to get the detail needed to troubleshoot. + +``` +logging:&id001 +log_filename: log/debug.log +log_level: INFO +log_stdout:false +``` + +### How do I quickly search the log file for errors? + +You can run `grep` (Linux, macOS) or `Select-String` (Windows) to search through your logs for relevant information. + +Linux & macOS + +``` +cat ~/.chia/mainnet/log/debug.log | grep -i 'error' +``` + +Windows + +``` +Get-Content -Path "~\.chia\mainnet\log\debug.log" | Select-String -Pattern "error" +``` + +#### Harvester log lookup examples + +The time it takes to do a proof challenge should be below 30 seconds. If you see higher times, something is wrong with your setup. + +Here are some example commands you can use to examine `debug.log` for problems. + +Linux & macOS + +``` +tail ~/.chia/mainnet/log/debug.log | grep eligible +``` + +Windows + +``` +Select-String -Path "~\.chia\mainnet\log\debug*" -Pattern "eligible" +Select-String -Path "~\.chia\mainnet\log\debug*" -Pattern "Found [^0] proof" +Select-String -Path "~\.chia\mainnet\log\debug*" -Pattern "Farmed unfinished_block" +Get-Content -Path "~\.chia\mainnet\log\debug.log" -Wait | Select-String -Pattern "found" +``` + +### What is the difference between chia and Chia (chia capitalization)? + +Chia - depending on context, this can refer to Chia Network the company, the Chia software (Chia client), or the Chia blockchain chia - lowercase chia refers to the Chia token, XCH. Similarly, mojos are lowercase. Similarly, mojos are lowercase. + +### How can I use PFX certificates for .NET development on Windows? + +By default, Chia will install `.crt` certificates in `~/.chia/mainnet/config/ssl`. If you are a .NET developer who is developing an application that connects to a full node, it is much easier to do this with `.pfx` certificates. This is because the TLS layer on Windows requires that the private key be written to disk (in a particular way). The PEM-based certificate loading doesn't do that, only PFX-loading does. + +We plan to add `.pfx` certificates by default in a future version of Chia. However, for now there is an easy workaround -- export the certificates to `.pfx` and immediately reimport them. The command to do this in c# is: + +``` +cert = new X509Certificate2(cert.Export(X509ContentType.Pfx)) +``` + +See [this stackoverflow thread](https://stackoverflow.com/questions/72096812/loading-x509certificate2-from-pem-file-results-in-no-credentials-are-available) for more info. + +:::info + +This issue only affects developers of Windows .NET applications. This issue only affects developers of Windows .NET applications. It does not affect Chia users on Windows, nor does it affect users or developers on other Operating Systems. + +::: + +### What are the plans for the project and what are its tokenomics? + +This is the Repository FAQ which focuses on how to use the software. We have released our [Business Whitepaper](https://www.chia.net/2021/02/10/chia-businesss-whitepaper.html) that goes into details of both the tokenomics, the pre-farm, and our go to market strategy. Additionally you can review the [Chia Blog](https://www.chia.net/blog/). + +### How can I contribute? + +You should check out [CONTRIBUTING.md](https://github.com/Chia-Network/chia-blockchain/blob/master/CONTRIBUTING.md) in the repository but the quick answer is to please base your pull requests off the dev branch. The dev branch will only accept rebase merges or squash merges. You can help [translate the application](https://chia.crowdin.com/chia-blockchain-gui) as well. Translating the GUI is especially useful and pretty easy to do with our Crowdin [Chia-Blockchain-GUI](https://chia.crowdin.com/chia-blockchain-gui) tool. + +### What microphone is Gene using? + +Gene uses an [Electro-Voice RE20](https://products.electrovoice.com/na/en/re20). + +### Isn't the current international monetary system good enough? + +No. Around the world, governments and banks cause problematic interactions that make banks difficult to trust, especially in volatile regions like Hong Kong, Venezuela Argentina or Lebanon. International payments, when they are available and work, are slow, expensive and insecure. International SWIFT wires often take 1-5 days. Correspondent banks often charge up to 3% and since the changes to banking since 9/11 and 2008, many countries have limited correspondent banks. International wire fraud losses are very large, and we have a better solution to mitigate these problems. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/glossary.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/glossary.md new file mode 100644 index 00000000000..818e5a69549 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/glossary.md @@ -0,0 +1,113 @@ +--- +title: Glossary +slug: /chia-blockchain/resources/glossary +--- + +# The Great Chia Glossary + +This guide will act as a glossary for many of the concepts utilised in Chia. +If you are familiar with how Bitcoin transactions work, a lot of this will be familiar. + +--- + +- **Aggregated Signature/AggSig** - Aggregated Signatures allow us to condense multiple signatures into a single aggregated signature, such that if we know a public key and value we can verify if it exists inside of the single aggregate. This uses BLS non-interactive aggregation. + +- **Authorized Payees** - Authorized Payees is a smart contract that means that Wallet A can give Wallet B some money, but Wallet B is only allowed to spend that money in ways that Wallet A has explicitly authorised. + +- **CATs** - Chia Asset Token - a special kind of chia coin which are created by users. A CAT is a uniquely marked subset of chia which can't be forged and can be linked to other assets. More information can be found on the [CATs Puzzles page](https://chialisp.com/docs/puzzles/cats). + +- **CAT1** - First version of the Chia token standard, there was a bug in this standard and its fix deprecated the standard creating the CAT2 standard. + +- **CAT2** - Second version of the Chia token standard, there was a bug in the first standard and its fix deprecated the standard creating the CAT2 standard. + +- **Chia** - Uppercase “Chia”. The software, the blockchain, or the company. + +- **chia** - Lowercase "chia" represents the coin aka "xch". + +- **Chia Network Inc.** - Proper format for Chia the company's name. + +- **chia reference wallet** - our own implementation which supports many features, but does not use wallet SDK and contains other wallets - e.g CAT wallets, DID wallet, NFT wallets and is mapped to a specific wallet key. + +- **ChiaLisp** - ChiaLisp is the Turing-complete functional language which the puzzles for spending coin are programmed in. For more information see our [Chialisp site](https://chialisp.com/). + +- **CHIPs** - CHia Improvement Proposals. + +- **CLVM** - The CLVM is the ChiaLisp Virtual Machine which is the sandboxed environment that puzzles and solutions are run in. The CLVM only runs the compiled minimal version of ChiaLisp, though a compiler can convert the higher level ChiaLisp to the compiled minimal version. See more about that [here](https://chialisp.com/clvm/) + +- **CNI** - Chia Network Inc. + +- **Coin (TXO/transaction output)** - A coin stores value. All coins are generated as the output of a transaction or a coinbase reward or fee target. A coin is spent exactly once, allowing its value to go into other coins, and is then permanently destroyed. Each unspent coin is locked with a ChiaLisp program which is that coin’s puzzle, and whoever has the information to solve that puzzle is the person who can spend that coin. The most basic puzzle has a public key and accepts a solution which contains a list of conditions signed by the corresponding private key, so only the owner of the private key can unlock the coin and spend it. + +- **Coin ID/CoinName (TXO ID/transaction output ID)** - The ID of a coin in Chia is generated by hashing the primary input ID, puzzle hash, and amount concatenated in that order. This is very different from Bitcoin which uses much more data to form the TXO ID, restricting what smart contracts are capable of. (See also: [SegWit](https://en.wikipedia.org/wiki/SegWit)) + +- **DAO** - Decentralized Autonomous Organization. + +- **dApp** - Decentralized Application. + +- **DataLayer™** - Datalayer connects an offchain database to the chia blockchain via merkel tree hashes ensuring any and all changes to the database are transparent and auditable. https://chia.net/chia-datalayer. + +- **Decentralised ID (DID)** - A decentralised ID is a smart contract that enables a wallet to act as an ID which can create messages to other IDs. Based on the work of the [identity foundation](https://identity.foundation/). + +- **Farming** - Verifying transactions and creating blocks on the chia blockchain. + +- **full node rpc api** - Full node access with JSON formatting. + +- **green paper** - Overviews the chia blockchain and the various new technologies implemented at the consensus level. + +- **Light Wallet** - Chia client functionality - a chia wallet that does not require a full node but rather gets balance and transaction data from peers in a decentralized method. + +- **NFT** - Non-fungible Token, a token that is inherently and provably unique. + +- **NFT0** - Chia’s in development NFT standard before NFT1 was launched. + +- **NFT1** - Chia’s current NFT standard. + +- **Op Constraints/Conditions** - Constraints are returned by the puzzle when it’s passed the solution. If all of the returned conditions are met then a transaction is valid. + +- **PFP** - Profile picture. + +- **plugin wallet** - A wallet implementation that uses the wallet SDK to provide extremely easy access to adding new coins and app types. + +- **PoS or POS** - Proof of Stake. + +- **PoSpace** - Proof of Space. + +- **PoST** - Proof of Space and Time. + +- **Prepend Signature** - Prepend signatures are used so that we can retain metadata about the structure of an aggregated signature. + +- **Primary Input/Parent** - When a coin is created the coin that was used as input in the transaction is designated as the primary input. This is used to create the coin ID. If more than one coin is used up as an input in a transaction then one of the coins is designated the primary input, and the others simply reinforce the transaction. + +- **Puzzle (Scriptpubkey)** - A ChiaLisp program which specifies the behaviour of a coin when it is spent. A puzzle can either reject a solution or output a set of constraints. + +- **Puzzle Generator** - A wallet will use a Puzzle Generator to define how it wants to receive transactions. Most wallets will want to generate the standard transaction, however by storing a ChiaLisp program that generate a puzzle, all a Sending Wallet needs to do is ask the Recipient Wallet what its Program Generator is and then run that to create the puzzle to lock the coin up with. + +- **Puzzle Generator ID** - This is the hash of a wallet's puzzle generator. A wallet can do a hash-lookup and see if it already knows the source code for that puzzle generator. If not, it will request the full source code and store that information in its lookup table. + +- **Rue** - Rue is an alternative language to Chialisp that compiles to CLVM which the puzzles for spending coin are programmed. Rue is being developed by a community member (Rigidity) and more information can be found on his [github repo](https://github.com/Rigidity/rue) or the [Rue website](https://rue-lang.com/). + +- **Smart Contract/Puzzle** - A smart contract is a specialised ChiaLisp puzzle which locks a coin up and enables complex blockchain interactions. + +- **Solution (Scriptsig)** - This is some ChiaLisp which is passed to the puzzle for evaluation when a transaction is submitted. For more information about how transactions work, and how solutions can generate new coins check out this [guide](https://docs.chia.net/guides/crash-course/signatures/#build-a-solution) + +- **Spend/CoinSolution** - A spend is a reveal of a coin's ID, along with the full puzzle code, and a solution to be ran with the puzzle. The result of a spend is determined by the returned Op Constraints after running the puzzle with the solution. + +- **Spend Bundle** - A spend bundle is a collection of spends grouped together with an aggregated signature to be sent to the network. + +- **Unspents (UTXO set/unspent transaction output set)** - This is the set of all unspent coins on the network. It is used to check if a transaction is valid, acting as a lookup for the puzzles. It maps a coin ID to a birthdate in blockheight. A transaction must contain a reveal of the information used to calculate the ID in order for it to be possible to validate because the unspents doesn’t contain that information, only hashes which can be used to validate it. + +- **Unspent Coin (UTXO/unspent transaction output)** - A coin which has been created but not yet spent and hence is storing value. + +- **VDF** - Verifiable Delay Function. This creates the proofs of time in a method that is verifiable and requires some amount of time to complete. + +- **VPB** - Virtual Private Blockchain. + +- **Wallet** - Software written to interact with transactions. Chia uses Hierarchical Deterministic Wallets (HD Wallets). This means that they can generate many different public keys that are all valid and verifiable as unique to that wallet. A wallet contains a coin if it possesses the information necessary to unlock that coin and create a transaction which spends it. + +- **wallet protocol** - Communication protocol for wallets and full nodes to interact via WebSocket Streamable integrations. + +- **wallet rpc api** - Wallet node access with JSON formatting. + +- **wallet SDK** - Software that calls wallet protocol, potentially abstracting out sync and rollbacks. + +- **white paper** - Overviews Chia Network Inc as a business and its founding objectives. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/bw.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/bw.png new file mode 100644 index 00000000000..f95489e4259 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/bw.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/bw_drive.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/bw_drive.png new file mode 100644 index 00000000000..f942c26c399 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/bw_drive.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/cpu.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/cpu.png new file mode 100644 index 00000000000..20783d77f29 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/cpu.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/cpu1.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/cpu1.png new file mode 100644 index 00000000000..9f8863ef1c8 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/cpu1.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/data_per_day.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/data_per_day.png new file mode 100644 index 00000000000..53ae96198b7 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/data_per_day.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/disk_busy.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/disk_busy.png new file mode 100644 index 00000000000..bd063881e58 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/disk_busy.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/iops.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/iops.png new file mode 100644 index 00000000000..01bb20b7ffd Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/iops.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/iosize_hist.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/iosize_hist.png new file mode 100644 index 00000000000..c854fcdfe05 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/iosize_hist.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/latency.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/latency.png new file mode 100644 index 00000000000..21a76eed20f Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/latency.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/net.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/net.png new file mode 100644 index 00000000000..a3f7ea39b3d Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/net.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/prob_access.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/prob_access.png new file mode 100644 index 00000000000..6e9374fa357 Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/prob_access.png differ diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/uber.png b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/uber.png new file mode 100644 index 00000000000..ab6cfd3613a Binary files /dev/null and b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/images/uber.png differ 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 new file mode 100644 index 00000000000..929dedaea55 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/k-sizes.md @@ -0,0 +1,60 @@ +--- +title: K值大小 +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 | + +:::info +**k=32 is the minimum plot size** that will be eligible for farming. 尽管可能会看到k=25，但这仅用于测试目的。 +::: + +如果是进行交替生成地块，磁盘大小要求可能会根据生成地块处于不同阶段而有所改变。 + +## New constant space factor + +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. + +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 | + +## 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) | + +When planning on how much plotting space is required, only calculate the temporary disk size requirement. + +When stagger plotting, disk size requirement may change depending on which Phase the plotting is at. + +## 大于k=32的地块 + +虽然不是必需的，但可以创建大于k=32的地块。 使用更大的地块并没有太大的好处，因为获胜的机会与最终地块文件的大小成比例。 There are advanced tactics to using a larger `k` value to reduce unused storage space or optimize drive idle states, but these are not recommended for the majority of people. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/references.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/references.md new file mode 100644 index 00000000000..218650f6733 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/references.md @@ -0,0 +1,51 @@ +--- +title: References +slug: /chia-blockchain/resources/references +--- + +## Chia Network + +- [chia.net](https://www.chia.net/) -- Chia's main website +- [chialisp.com](https://chialisp.com) -- the official chialisp website +- [Chia's business white paper](https://www.chia.net/whitepaper "Chia's business white paper") + +## Chia's Technical Specs + +- [Chia's green paper](https://docs.chia.net/chia-blockchain/green-paper/green-paper-abstract "Chia's Green Paper") -- showcases Proofs of Space and Time +- [Proofs of Space specification](https://www.chia.net/assets/Chia_Proof_of_Space_Construction_v1.1.pdf) +- [BLS Signatures](https://github.com/Chia-Network/bls-signatures "Chia's BLS Signatures on GitHub") +- [Verifiable Delay Function (VDF)](https://github.com/Chia-Network/chiavdf "Chia's VDF on GitHub") +- [Proofs of Space](https://github.com/Chia-Network/chiapos "Chia's Proof of Space repository on GitHub") +- [Binary Quadratic Forms](https://github.com/Chia-Network/vdf-competition/blob/main/classgroups.pdf "Binary quadratic forms white paper, by Lipa Long") -- a white paper by Lipa Long +- [How to Store a Permutation Compactly](https://hackmd.io/@dabo/rkP8Pcf9t) by Bram Cohen and Dan Boneh + +## Video + +- [Bram Cohen's 2022 presentation](https://odysee.com/@Chia:d/off-the-chain-Bram-Cohen-2022:5) at Off the Chain 22 regarding custody solutions including authorized payee wallets and clawback transactions. +- [Mariano Sorgente's 2019 presentation](https://youtu.be/_075bzQPooU) at MIT on how to achieve Nakamoto consensus with Proof of Space and VDFs +- [Bram Cohen's 2018 presentation](https://www.youtube.com/watch?v=2Zlcgt8FVz4) at Stanford on Proofs of Space +- [Bram Cohen's 2018 presentation](https://www.youtube.com/watch?v=iqxkO7C-cyk) at BPASE on the [Beyond Hellman](https://eprint.iacr.org/2017/893.pdf "Beyond Hellman's Time-Memory Trade Offs with Applications to Proofs of Space") academic paper ([slides](https://view.publitas.com/chia-network/pbase18slides/page/1) by Hamza Abusalah) +- [Ben Fisch's 2018 presentation](https://www.youtube.com/watch?v=qUoagL7OZ1k&feature=youtu.be) at BPASE 2018 on Verifiable Delay Functions +- [Bram Cohen's 2018 presentation](https://www.facebook.com/BlockchainatBerkeley/videos/2006069823011271/) at Berkeley (which starts about 20:00) +- [Bram Cohen's 2017 presentation](https://www.youtube.com/watch?v=aYG0NxoG7yw) at BPASE on removing waste with Proofs of Space and Time +- [Bram Cohen's 2015 presentation](https://www.youtube.com/watch?v=zZaB4hM8SQ4) at SF Bitcoin Devs Seminar about data structures for scaling Bitcoin with [slides](https://view.publitas.com/chia-network/bitcoin_data_structures/) and [Merkle Set code](https://github.com/bramcohen/MerkleSet) + +## External + +- [Chia's power consumption](https://chiapower.org "Chia's energy consumption statistics") +- [BladeBit CUDA Performance Analysis](https://scienceofmining.com/20230828-BladeBit/BladeBit%20CUDA%20Performance%20Analysis-1.html), by scienceofmining.com +- [A Survey of Two Verifiable Delay Functions](https://eprint.iacr.org/2018/712.pdf "The underlying technology of Proof of Time"), by our advisors Dan Boneh, Benedikt Bünz, and Ben Fisch +- [Simple Verifiable Delay Functions](https://eprint.iacr.org/2018/627.pdf "The basis for Proof of Time"), by our advisor Krzysztof Pietrzak +- [History of Cryptography](https://cs.stanford.edu/people/eroberts/courses/soco/projects/public-key-cryptography/history.html#:~:text=The%20idea%20of%20public%20key,known%20as%20the%20knapsack%20problem), from Stanford University +- [Beyond Hellman](https://eprint.iacr.org/2017/893.pdf "Beyond Hellman's Time-Memory Trade Offs with Applications to Proofs of Space"), by Hamza Abusalah, Jo ̈el Alwen, Bram Cohen, Danylo Khilko, Krzysztof Pietrzak, and Leonid Reyzin +- [POS Longest Chain Protocols](http://tselab.stanford.edu/downloads/PoS_LC_SBC2020.pdf), by Vivek Bagaria, Amir Dembo, Sreeram Kannan, Sewoong Oh, David Tse, Pramod Viswanath, Xuechao Wang, and Ofer Zeitouni +- [Flyclient paper](https://eprint.iacr.org/2019/226.pdf), by Benedikt Bunz, Lucianna Kiffer, Loi Luu, and Mahdi Zamani +- [PoSAT paper](https://arxiv.org/abs/2010.08154), by Soubhik Deb, Sreeram Kannan, and David Tse +- [PoS security vs predictability](https://arxiv.org/pdf/1910.02218.pdf), by Vivek Bagaria, Amir Dembo, Sreeram Kannan, Sewoong Oh, David Tse, Pramod Viswanath, Xuechao Wang, and Ofer Zeitouni +- [bech32m](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) -- the address encoding scheme used by Chia +- [x.509](https://en.wikipedia.org/wiki/X.509) -- the public key certificate used in Chia peer nodes +- [DER](https://wiki.openssl.org/index.php/DER) -- a data structure used with x.509 certificates +- [BLS-12-381](https://github.com/zkcrypto/bls12_381) -- the type of keys Chia uses +- [IETF](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/) -- the BLS signature specification +- [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333) -- a tree structure for deriving BLS keys +- [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) -- registered coin types for BIP-0044 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/storage-benchmarks.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/storage-benchmarks.md new file mode 100644 index 00000000000..fcb8454a0d2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/storage-benchmarks.md @@ -0,0 +1,92 @@ +--- +title: Storage Benchmarks +slug: /chia-blockchain/resources/storage-benchmarks +--- + +:::note Notes + +To have reproducible results the aim should be to limit caching effects. For that: + +- Test data should be forced to storage and larger than flash drive's internal caches +- Block caches should be emptied between tests + +::: + +# [FIO](https://fio.readthedocs.io/en/latest/fio_doc.html) + +`sudo apt update` +`sudo apt install fio` + +Save this file as a job file called "chia.fio" or whatever you want, and change filename to the path of the drive or RAID volume that you want to test + +``` +[global] +bs=128K +iodepth=256 +direct=1 +ioengine=libaio +group_reporting +time_based +name=chia +log_avg_msec=1000 +bwavgtime=1000 +filename=//fiotest.tmp +size=100G + +[rd_qd_256_128k_1w] +stonewall +bs=128k +iodepth=256 +numjobs=1 +rw=read +runtime=60 +write_bw_log=seq_read_bw.log + +[wr_qd_256_128k_1w] +stonewall +bs=128k +iodepth=256 +numjobs=1 +rw=write +runtime=60 +write_bw_log=seq_write_bw.log +``` + +run `sudo fio chia.fio` + +# [IOzone](http://www.iozone.org/) + +This assumes RHEL stack Linux. + +## Install from sources + +``` +sudo yum update -y +sudo yum groupinstall "Development Tools" -y +cd /opt +wget http://www.iozone.org/src/current/iozone3_490.tar +tar -xvf iozone3_490.tar +cd iozone3_490/src/current +make linux-AMD64 +``` + +## Run single threaded + +- Assume the test drive or volume is mounted as **/chia/scratch/disk01** +- -i 0=write/rewrite +- -i 1=read/re-read +- -i 2=random-read/write +- -i 8=random_mix +- -e Include flush (fsync,fflush) in the timing calculations +- -r # record size in Kb +- -s # file size in GB +- -U Mount point to remount between tests, this option will clear the block caches between tests. For this to work, mounting of the disk/volume needs to be configured in /etc/fstab. + +``` +/opt/iozone3_490/src/current/iozone -e -r 256 -s 32G -i 0 -i 1 -i 2 -i 8 -f /chia/scratch/disk01/tfile -U /chia/scratch/disk01 +``` + +## Run multi threaded + +- Assume the test drive or volume is mounted as **/chia/scratch/disk01** +- -I Use DIRECT I/O for all file operations. Tells the filesystem that all operations are to bypass the buffer cache and go directly to disk. This also will use VX_DIRECT on VxFS, and O_DIRECT on Linux, and directio() on Solaris. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/timelord-contest/timelord-contest-rules.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/timelord-contest/timelord-contest-rules.md new file mode 100644 index 00000000000..595ddfb6c47 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/timelord-contest/timelord-contest-rules.md @@ -0,0 +1,72 @@ +--- +title: Timelord Contest Rules +slug: /chia-blockchain/resources/timelord-contest/timelord-contest-rules +--- + +# Chia Academy Program and Contest Terms and Conditions + +## 1. General. + +Chia Network Inc. (“**the Company**”, “**we**”, or “**us**”) invites you to submit your idea, use case, or other requested submission information for consideration as part of the contest, promotion, or other program that the Company is administering (the “**Program**”, and such submission, collectively, a “**Submission**”). The below terms and conditions (these “**Terms**”) govern your Submission and your participation in the Program. All Submissions must meet the following criteria: + +- Submissions (including your personal contact details) must be true, accurate, original, non-infringing and not in violation of any third-party rights (including, by way of example and not limitation, the rights of privacy and publicity), exclusively created, and owned by you, and you must have all rights necessary to submit the Submission. +- Submissions may not contain information of any individuals who have not provided their explicit, legally enforceable authorization or any other sensitive information. +- All Submission materials must be in English or, if not in English, you must provide an English translation of the Submission. +- Submissions must be received by the Company from 12:00am Eastern Time May 1, 2024 through 11:59pm Eastern Time May 31, 2024. +- The Company reserves the right to reject any applicant or Submission for any or no reason in its sole discretion and without notice. + +## 2. Eligibility. + +To participate in a Program, you generally must be 18 years of age or older and reside in the United States or in a jurisdiction where your Submission to the Program does not violate applicable laws or regulations. You may not participate in a Program if you are a resident of a country, state, province or territory where the laws of the United States or local law prohibits participating or receiving a prize in the Program (including, but not limited to, Brazil, Quebec, Russia, Crimea, Cuba, Iran, North Korea, Syria and any other country designated by the United States Treasury's Office of Foreign Assets Control). You may not participate if you are an employee, director, officer, or agent of the Company or its affiliates, or are a family member or live in the household of any employee, director, officer, or agent of the Company or its affiliates. + +## 3. Selection Process. + +Selection of Submissions is at the Company’s sole discretion. The Company’s decisions are final in all matters related to the Program. The Company reserves the right to disqualify Submissions for any reason. If you are selected as a winner or to otherwise participate in the Program, you may be required by the Company to enter into a separate agreement with the Company regarding your participation in the Program. Selected applicants will be required to provide additional information (such as taxpayer, KYC, and payment details), be subject to additional review (such as a background check or identity verification) and accept additional terms regarding the Program, including additional Program participation requirements. You acknowledge that the Company has no obligation to select, post, or use any Submission or to respond to you in any way. + +## 4. Application Period. + +The application period for the Program commences and ends on time and date set forth in the applicable Program web page, unless extended by the Company in its sole discretion. The Company reserves the right, in its sole discretion, to modify, suspend, or cancel the Program at any time for any reason. + +## 5. Intellectual Property. + +By applying to join the Program, you hereby represent and warrant that your Submissions are your original works of authorship, do not contain information that you or any third party considers to be confidential, do not violate or infringe upon the copyrights, trademarks, rights of privacy, publicity, moral rights or other intellectual property or other rights of any person or entity, and do not violate any rules or regulations. If the Submission contains any material or elements that you do not own or that are subject to the rights of third parties, then you represent that you have obtained, prior to submission of the Submissions, any and all releases and consents necessary to permit the Company and its affiliates to use the Submission without additional compensation to evaluate your application. + +## 6. Publicity Rights. + +By making a Submission, you hereby grant to the Company a royalty free, irrevocable, perpetual and worldwide license to use and display your name on the Company’s websites, apps, and/or social media pages and accounts for purposes of marketing and promoting your Submission, the Program, or marketing, using, or improving the Company’s products and services, without compensation of any kind or further notice to or approval from you or any third party. Notwithstanding the foregoing, the Company has the right, but no obligation to promote, market, highlight, or display you or your Submission. + +## 7. Prizes. + +The following shall apply with respect to any prizes that may be awarded to you in connection with a Program (“**Prizes**”). The top three (3) Submissions shall be entitled to receive one (1) ASIC timelord hardware device. The ASIC timelord will be mailed to your address only after your acceptance of any applicable terms and the Company’s receipt of any required forms (collectively the “**Required Forms**”), currently located online at [https://docs.google.com/forms/d/18_eBWc-JmwQl5d9kJsLRwx7QKtVOiNDADLg9rzo-PvI/](https://docs.google.com/forms/d/18_eBWc-JmwQl5d9kJsLRwx7QKtVOiNDADLg9rzo-PvI/), or by such other means as the Company may determine, in each case, at the Company’s sole discretion. Failure to provide correct information on the Required Forms, or other correct information required for the delivery of a Prize, may result in delayed Prize delivery, disqualification, or forfeiture of a Prize. Prizes will be delivered within 60 days of the Company’s receipt and verification of the completed Required Forms. + +## 8. Fees & Taxes. + +You are responsible for any fees associated with receiving or using Account Credits or a Prize, including but not limited to, wiring fees or currency exchange fees. You are responsible for reporting and paying all applicable taxes in your jurisdiction of residence (federal, state/provincial/territorial and local). You may be required to provide certain information to facilitate receipt of the award, including completing and submitting any tax or other forms necessary for compliance with applicable withholding and reporting requirements. United States residents may be required to provide a completed form W-9 and residents of other countries may be required to provide a completed W-8BEN form. You are also responsible for complying with foreign exchange and banking regulations in your respective jurisdictions and reporting the receipt of the Account Credits or Prize to relevant government departments/agencies, if necessary. The Company reserves the right to withhold a portion of the Account Credits or Prize to comply with the tax laws of the United States or other sponsor jurisdiction, or those of your jurisdiction. + +## 9. Disclaimer. + +THE COMPANY MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, REGARDING THE APPLICATION PROCESS OR PARTICIPATION IN THE PROGRAM. + +## 10. General. + +If for any reason your Submission is confirmed to have been erroneously deleted, lost, or otherwise destroyed or corrupted, your sole remedy is to make another Submission. The Company may modify these Terms in its sole discretion. + +## 11. Privacy and Use of Personal Information. + +The Company collects personal information from you when you apply for the Program for the purposes of selecting participants for the Program, administering the Program and contacting you about the Program and the Company’s products and services in accordance with the Company’s Privacy Statement. + +## 12. Limitation on Liability. + +THE COMPANY SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR RELATED TO THIS AGREEMENT, REGARDLESS OF WHETHER SUCH LIABILITY IS BASED UPON CONTRACT, NEGLIGENCE, TORT, STRICT LIABILITY, WARRANTY, OR OTHERWISE. THE MAXIMUM LIABILITY OF THE COMPANY FOR ANY CLAIMS ARISING IN CONNECTION WITH THESE TERMS OR THE PROGRAM WILL NOT EXCEED TWENTY-FIVE DOLLARS ($25.00). + +## 13. Indemnity. + +You and your agents, employees, directors, officers, successors, and assigns agree to indemnify, defend, and hold the Company and its employees, directors, officers, and agents harmless from any claims, damages, liabilities, or expenses arising out of or related to your Submission or participation in the Program or the acceptance, use, or misuse of any prize. + +## 14. Relationship of Parties. + +Nothing set forth herein shall be construed as constituting you and the Company as partners, joint venturers, or as creating the relationships of employer/employee, franchiser/franchisee, or principal/agent between the parties. + +## 15. Governing Law and Disputes. + +These terms and any disputes arising out of or related hereto, will be governed exclusively by the internal laws of the State of California, without regard to its conflicts of laws rules or the United Nations Convention on the International Sale of Goods. The parties acknowledge that these terms evidence a transaction involving interstate commerce. Notwithstanding the preceding sentences with respect to the substantive law of these terms, any arbitration conducted hereunder shall be governed by the Federal Arbitration Act (9 U.S.C. §§ 1-16). The state and federal courts located in San Francisco County, California will have exclusive jurisdiction to adjudicate any dispute arising out of or relating to these terms or their formation, interpretation or enforcement, including any appeal of an arbitration award or for trial court proceedings if the arbitration provision below is found to be unenforceable. Each party hereby consents and submits to the exclusive jurisdiction of such courts. **_Each party also hereby waives any right to jury trial in connection with any action or litigation in any way arising out of or related to these Terms or the Program._** In any action or proceeding to enforce rights under these terms, the prevailing party will be entitled to recover its reasonable costs and attorney’s fees. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/timelord-contest/timelord-contest.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/timelord-contest/timelord-contest.md new file mode 100644 index 00000000000..bdc20e55df1 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-blockchain/resources/timelord-contest/timelord-contest.md @@ -0,0 +1,87 @@ +--- +title: Timelord Contest Overview +slug: /chia-blockchain/resources/timelord-contest/timelord-contest +--- + +## ASIC Timelord/Chia Academy Contest + +:::note +Residents in some locations are not eligible, verify your eligibility [here](/chia-blockchain/resources/timelord-contest/timelord-contest-rules/#2-eligibility). +Content becomes public domain upon submission adhering to the [Apache 2 license](https://github.com/Chia-Network/chia-docs/blob/18453e23e64644a2ca84e5761ce1b23d2becdf5b/LICENSE). +Contest rules can be found [here](/chia-blockchain/resources/timelord-contest/timelord-contest-rules) + +::: + +We’re holding a contest for community members! You could win a timelord for submitting a winning Chia Academy course. + +We're awarding one timelord for up to 3 separate individuals and awarding up to 5 timelords to members of one team to the strongest community-created courses for Chia Academy. Courses should be relevant to the Chia community and blockchain and neutral to third-party projects. +To enter, do the following between May 1-May 31, 2024 at 11:59 p.m. EST: + +1. Create a Chia Academy course in written or video form and submit it to the contest using this [format](https://docs.chia.net/academy-overview/) and this [template](https://github.com/Chia-Network/chia-docs/blob/33269c4ab9a661fbaf2a61aaa062e88639e17f8f/docs/academy/academy-intro/academy-overview.md). +2. Fork the [docs repo](https://github.com/Chia-Network/chia-docs/tree/main) and submit a PR with the `timelord-contest` label. Please review our [Using Github](/contribution/using-github) contribution information if you are new to Github or contributing to the chia repos. +3. Include your Keybase handle so we can notify you if you win. + +Note that residents in some locations are not eligible, and the content becomes public domain once submitted. For information about this, FAQs, and the official contest rules + +--- + +## Requirements and Criteria + +Github Requirements: + +- [Create a Github Account](/contribution/using-github#create-a-github-account) +- [Fork the chia-docs repo](/contribution/using-github#forking-a-repository) +- [Clone the forked repo](/contribution/using-github#cloning-a-forked-repository) +- [Sign all Commits](/contribution/using-github#setup-commit-signing) +- [Submit a PR](/contribution/using-github#making-a-pull-request) + +Content Criteria: + +- Quality of content +- Novelty +- Applicability +- Course structure + +--- + +## Rewards + +We’ll be awarding Timelords to winning submissions in two categories: Individual and Team submissions. + +Up to 3 individual submissions will be chosen as winners, and each will receive a Timelord. One team submission will also be awarded (up to 5 Timelords to 1 team!). + +--- + +## FAQ + +### Where can I find the contest rules? + +The rules are on our [docs site](/chia-blockchain/resources/timelord-contest/timelord-contest-rules). + +### What topics are you interested in receiving? + +Courses should be relevant to the Chia community and blockchain and neutral to third-party projects. + +### How many courses can I submit? + +You can submit as many courses as you like, but you can only win once. + +### What if I’m part of a team? Can I still enter? + +Yes! We encourage teams of up to 5 members to enter. Only one team can win. Members of the one winning team will receive up to 5 timelords in total. + +### Who owns the Chia Academy course after I submit it? + +The course becomes public domain once you submit it. This is outlined in the [Apache 2 license](https://github.com/Chia-Network/chia-docs/blob/18453e23e64644a2ca84e5761ce1b23d2becdf5b/LICENSE). + +### When will I be notified if I win? + +You will be notified no later than the end of June 2024. + +### Who can I contact if I have questions? + +Please use the #support channel in our official [Discord](https://discord.gg/chia) for contest support and questions. + +## Contest Support + +Please use the #support channel in our official [Discord](https://discord.gg/chia) for contest support and questions. 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 new file mode 100644 index 00000000000..a936f3f8d26 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/faq.md @@ -0,0 +1,53 @@ +--- +title: FAQ +slug: /chia-signer/faq +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Chia Signer App: Frequently Asked Questions (FAQ) + +### 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. + +### 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. +- **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: + +- 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). + +### 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. + +### 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. + +### How do I link my Chia Signer key to a Chia Cloud Wallet vault? + +The linking process involves scanning a QR code displayed by your Chia Cloud Wallet using the Signer app. Depending on whether you've already created the key in the Signer app, you can either: + +- Tap on your existing key in the Signer app and select "Link Key," then scan the QR code. +- Or, from the Signer app's main screen, tap the scan button, scan the QR code, and then select an existing key or create a new one as prompted. + +### 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. + +### 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. + +### 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. 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 new file mode 100644 index 00000000000..2de3227fbf8 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/chia-signer/getting-started.md @@ -0,0 +1,72 @@ +--- +title: Getting Started +slug: /chia-signer/getting-started +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +Welcome to the **Chia Signer app**, your secure companion for interacting with the Chia blockchain. This app provides a robust layer of security by allowing you to sign transactions using the dedicated hardware security of your mobile device, keeping your private keys safe. + +This guide will show you how to get started with the Chia Signer app, from setting up your secure key to linking it with your Chia Cloud Wallet and approving transactions. + +**Prerequisites:** + +- An iOS device (iPhone or iPad) running iOS 15 or later and has the Secure Enclave. + +**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. +- **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). + +## 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). + +## 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. +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. +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. + +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)** + 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). + 4. Use your device's camera to scan the QR code displayed by your Chia Cloud Wallet. + + - **Method B: Linking and/or Creating a Key via Main Screen Scan** + 1. From the Chia Signer app's main screen, tap the scan button (often located in the lower-middle part of the screen, resembling a QR code scanner icon). This will activate your device's camera. + 2. Use your device's camera to scan the QR code displayed by your Chia Cloud Wallet. + 3. After scanning, the app will prompt you to "Choose a key." + - If you have existing keys, select the one you wish to link. + - If you need to create a new key, select Generate Key and follow the steps to name and create your key. + +3. **Confirm Link:** + - Regardless of the method used, after selecting or creating your key, confirm the link. Tap the `Link key` button (if not already pressed). + - The Signer app will communicate with the Chia Cloud Wallet to establish the secure link. + - If successful, you will typically see a confirmation, such as a green checkmark, on both the Signer app and the Chia Cloud Wallet interface. + +## 4) Sign Transactions with the Chia Signer App + +Once linked, your Signer app becomes the gatekeeper for all transactions from that specific Chia Cloud Wallet vault. + +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. +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. +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/faq.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/faq.md new file mode 100644 index 00000000000..090ee080a46 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/faq.md @@ -0,0 +1,206 @@ +--- +title: FAQ +slug: /cloud-wallet/faq +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Cloud Wallet + +### What is the Chia Cloud Wallet? + +The Cloud Wallet is a platform for interacting with the Chia blockchain. Assets are stored in vaults, in an app that is always synced with the blockchain. This makes it easy for newcomers to get started with Chia; it also provides a secure custody solution. In addition, it will eventually include an API for developers in Chia's ecosystem to make dApps that use the Chia blockchain. + +### 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). + +### How can I obtain some TXCH for testnet11? + +Visit either our [official faucet site](https://testnet11-faucet.chia.net) or a [community-run faucet](https://txchfaucet.com), and enter your txch address. You should receive some funds for testing within a few minutes. + +### How do I get started with the Cloud Wallet? + +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. + +### How is the Cloud Wallet different from other wallets? + +The Cloud Wallet comes with several advantages versus existing wallets that support Chia assets: +CNI runs several dedicated nodes to support the wallet. This means that the wallet is always synced. +Cloud Wallet assets are secured in a vault instead of with a single BLS key. Vaults are described in detail below, but their primary advantage is that they use multiple keys, which makes them more secure than single-key wallets. + +Cloud Wallet vaults can be secured with either a passkey or with the Chia Signer app, which is described in detail below. + +### Will the Cloud Wallet replace the reference wallet? + +It depends on your use case. The Cloud Wallet will not be used for Chia farming, so farmers will continue to use the reference wallet for creating plots, as well as for farming. Other users might want to migrate to the Cloud Wallet at some point. + +### What if I don't want my Cloud Wallet to connect to Chia's nodes? + +For maximum trustless usage, we will eventually support syncing your Cloud Wallet against a node of your choosing. However, we haven't implemented this feature yet. + +### What is a passkey? + +A passkey provides a way to log onto websites and apps without a username and password. It also can be used for signing digital transactions. There are many locations and devices where you can save a passkey, for example in a hardware key such as a [Yubico](https://www.yubico.com) Yubikey, in a password manager such as [1Password](https://1password.com), or in your OS keychain. [This article](https://www.pcmag.com/explainers/passwordless-authentication-what-it-is-and-why-you-need-it-asap) gives a good overview of what passkeys are and how you can use them. + +### How does the Cloud Wallet use passkeys? + +Two ways – as a replacement for logging in with your email and password, and as a vault signer. + +### What is a vault? + +A vault is a new way to custody your assets on Chia's blockchain. Instead of securing your XCH, CATs, NFTs, etc with a single key, a vault uses multiple keys and more advanced custody rules. The current iteration of Chia vaults have two keys – one for signing transactions (either a passkey or a hardware key from the Chia Signer app), and one for recovery purposes (a BLS key). + +### What is the advantage of using a vault instead of a wallet? + +The Chia reference wallet currently only uses a single key. If this key is lost or stolen, then all of the funds custodied in the wallet will also be lost or stolen. By using Chia vaults, users can feel confident that their funds will remain secure even if one of their keys is lost, and often (as discussed below) if it is stolen. + +### Why do I see “Your vault is being minted, the address will be available soon.” after I create a vault? + +A vault needs to be created on the blockchain after you click the “Create” button. We have set up a faucet to handle this automatically. However, it does take a few minutes for the on-chain transaction to be processed. You should receive an address within five minutes. + +### Can I import an existing wallet into the Cloud Wallet by entering a seed phrase? + +Not at the moment. Currently the Cloud Wallet only supports vaults. We may add support for BLS wallets, but we haven't made that decision yet. + +### How is signing different with the Chia vault than with the reference wallet? + +In the reference wallet, the key used for signing transactions is located on the same device as the wallet. While this setup is still possible when using vaults, it is also possible to keep your signer on a separate device. By separating your vault from its signer, the Cloud Wallet presents a more secure self-custody solution than existing Chia-based wallets. + +### What plans will exist for the Cloud Wallet, and how much will they cost? + +We plan to release three tiers with the Cloud Wallet: + +- Free Tier – currently available, albeit in beta form. It includes one vault, with a single key for spending and a single key for recovery. The free tier will provide easy onboarding for new users, and will offer a more secure solution than what exists in most of the industry. +- Prosumer Tier (coming soon) – will include support for multisig vaults, as well as some advanced trading tools. This will be the perfect solution for individuals and small groups who want to share custody, as well as for high-frequency traders. It will be available for a monthly fee. +- Enterprise Tier (coming soon) – will provide custody, management, and support solutions for large enterprises. + +### Are you planning to improve upon the existing vault technology? + +是的。 With the current setup, the `Free` tier's single-signature vaults use the same underlying Chialisp as the multisig vaults from the `Pro` and `Enterprise` tiers. The only difference is that the Cloud Wallet GUI enforces single-signature signing and recovery for `Free` tier vaults. Longer term, we plan to introduce vaults with significantly more flexibility, which will be useful for end users and large enterprises alike. Stay tuned… + +### Where can I go for support? + +Feel free to ask questions in the #support channel of [our Discord](https://discord.gg/chia). + +### 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. + +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! + +### Why is the `Add Vault` button disabled after I create my first vault? + +Currently the only tier you can choose is the `Free` tier, which only allows you to create one vault. In the future we will enable the `Pro` and `Enterprise` tiers, which enable multiple vaults, along with several other features. + +## Recovery + +### What happens if I lose my spend key? + +You can use your recovery key to swap out the lost key for a new one. + +### What happens if my spend key is stolen? Will all of my funds be stolen? + +It depends. For example, the Chia Signer app recommends using biometric authentication such as a fingerprint or face ID. With this setup, if a thief steals your phone, they will not be able to access the Chia Signer app, and thus your funds will remain secure. You can procure a new smartphone and initiate the recovery process in order to restore your funds. + +However, the current setup is not secure against wrench attacks, where the thief forces you to use your biometrics to sign a transaction to steal all of your funds. Our upcoming multisig solution will be secure against such attacks, as will our longer-term custody solution. + +### What happens if I lose my recovery key? + +You can use your spend key to send your funds to a new 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. + +## Watchtowers + +### What is a watchtower? + +In a Web3 context, a watchtower is a program that monitors a blockchain for events, and takes action when they occur. The first Chia watchtower will look for attempted vault recoveries. When such a recovery is initiated, the watchtower will email the owner of the vault that is being recovered. If the recovery attempt is legitimate, the owner doesn't need to take any action. However, if the recovery is malicious, then the owner can cancel it. + +### What other types of watchtower will you develop? + +We plan to deploy watchtowers to notify users of incoming offers, incoming transactions, and transactions that were affected by a blockchain re-org. We may implement watchtowers for further events in the future. + +### Can I develop my own watchtower? + +Yes! The Chia blockchain is a public ledger, so anyone can build software to monitor it. We may open-source some of our watchtower code as well, which would make it easier for community members to create custom watchtowers for their own needs. + +## Chia Signer + +### 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). + +:::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 + +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. + +::: + +### 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? + +The app has two requirements for iOS devices: + +1. The device must run iOS 15 or later +2. The device must have a Secure Enclave + +The following devices meet both of these requirements: + +- iPhone models beginning with the iPhone 6 +- iPad models beginning with the iPad mini 4 + +Be sure to double check that your device is running at least iOS 15 prior to installing the Chia Signer app. + +### 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. + +### Does the Chia Signer app use blind signing? + +No, but it doesn't use clear signing yet, either. The user is shown the details of the transaction before signing it. This info is significantly more detailed than what can be seen on the small screens of most hardware wallets. However, the end user needs to trust that CNI's servers have not been compromised, so it also isn't clear signing. The light amount of trust required should be sufficient for most users. However, for users who want to sign large transfers with the Chia Signer app, we plan to develop true clear signing in the future. + +### Can I use the Chia Signer app to sign into my Cloud Wallet account? + +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. + +## Security and privacy + +### 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. + +### What risks do end users take regarding CNI's control of the Cloud Wallet website? + +One of the advantages of using vaults is that their spend keys are not directly accessible to the website or its APIs. + +The two risks for Cloud Wallet end users are: + +1. CNI can be forced to turn over metadata to various law enforcement. However, we don't save much metadata beyond what is already available on the blockchain. +2. An attacker could set up a man-in-the-middle attack when you are signing a transaction. The amount of trust required when using the Signer app is already minimal. In the future, we will enable full clear signing, as well as the ability to run the Cloud Wallet against your own full node in order to mitigate this attack vector. + +### Do vaults always use the same address? + +Currently, yes. This is a departure from the reference wallet, which uses a new address for each transaction. The reason vaults always use the same address is because they are singletons -- the vault itself authorizes the spend of coins under its control. This is a different approach from the reference wallet, which uses a BLS key to derive its addresses. + +Users must carefully consider the privacy (and therefore security) implications of reusing an address. When the address doesn't change, it becomes easier to put together a historical record of transactions. Vaults that hold significant value could therefore be targeted with physical attacks, as explained in [a Bitcoin wiki](https://en.bitcoin.it/wiki/Address_reuse). + +Future versions of vaults will have additional security such as multisigs and time locks to mitigate the risk of physical attacks. + +In addition, in the future we plan to support vaults with multiple receive addresses. Stay tuned for more info on that topic. + +### Will the Chia Signer app be open source? + +Yes 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 new file mode 100644 index 00000000000..3a8c3cb54c9 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/getting-started.md @@ -0,0 +1,150 @@ +--- +title: Getting Started +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. + +This guide will show you how to create your first Cloud Wallet vault in a few easy steps. + +1. Browse to the Chia Cloud Wallet website for [mainnet](https://vault.chia.net). + +:::note +Use the [testnet](https://vault.chiatest.net) instance for testing the cloud wallet with txch. +::: + +2. Click the `Sign Up` button: + +
+ Welcome to the Cloud Wallet +
+ +3. Enter your email address and click `Continue`. + +4. Within a few minutes, you should receive an email with the subject "Chia cloud wallet email verification link". Click the link in the email. + +5. Enter your name and click `Set new Passkey`: + +
+ Set a new passkey +
+ +6. You will be given a variety of options for adding a new passkey, for example in a hardware key, a password manager, or the OS keychain. This passkey will be your primary method for signing into the Cloud Wallet. It can also be used for signing Chia transactions. + +Congratulations, you're all set to create your first vault! + +## Create a vault + +:::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 + +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. + +::: + +1. The free tier of the Cloud Wallet only allows you to create a single vault, so you will need to choose from one of the two options. Let's create a vault using the Chia Signer app: + +
+ Create vault with signer app +
+ +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). + + 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 +
+ +4. From the Chia Signer app, tap the `+` button in the upper-right corner to add a new key: + +
+ 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`: + +
+ Generate a hardware key +
+ +6. Your new key will show up in the app's main screen. Tap the button in the lower-middle part of the app and scan the QR code: + +
+ Tap the scan button +
+ +7. Tap `Choose a key`: + +
+ Tap the Choose a key button +
+ +8. Tap your new key: + +
+ Tap your new key +
+ +9. Tap the `Link key` button: + +
+ 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: + +
+ Signer 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. + +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). + +You are now ready to receive funds in your new vault. + +If using the testnet instance of the chia cloud wallet, Testnet11 uses a test currency called TXCH. To obtain some TXCH, you can visit either our [official faucet site](https://testnet11-faucet.chia.net) or a [community-run faucet](https://txchfaucet.com), and enter your vault's address. You should receive some funds for testing within a few minutes. + +
+ Vault with 1 txch +
+ +## Sending funds + +Your vault uses the Chia Signer app to sign transactions. Click the `Send` button to begin the process of sending funds. + +1. Enter a destination address, amount to send, and an optional blockchain fee, then click `Send`: + +
+ Enter info and click Send +
+ +2. You will be shown the details of the transaction: + +
+ View transaction details +
+ +3. Simultaneously, your device with the Chia Signer app should receive a push notification with a signature request. This notification will contain the details of the transaction. Scroll through this request to ensure that everything matches what you see from the Cloud Wallet, and tap `Sign transaction`: + +
+ Signature request +
+ +4. You should see a "success" message on both the Chia Signer app and the Cloud Wallet: + +
+ Successfully signed +
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 new file mode 100644 index 00000000000..f3a754aa202 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/known-issues.md @@ -0,0 +1,32 @@ +--- +title: Known Issues +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. + +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). + +## Cloud Wallet Known Issues + +- All Offer cancellations in the Cloud Wallet will currently be performed on-chain. We plan to support off-chain cancellation soon. +- Under certain circumstances, it is possible to end up with coins from your vault being locked, with no easy way to access them. We will update this soon so that the coins will become accessible again. Even if this does happen, it will not result in a loss of funds. Some examples of when this might occur include when someone cancels an Offer in the same block in which someone else attempts to accept it, and after an Offer expires. +- 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: +::: + +- 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/tooltips.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/tooltips.md new file mode 100644 index 00000000000..b166945f924 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/cloud-wallet/tooltips.md @@ -0,0 +1,52 @@ +--- +title: Tooltips +slug: /cloud-wallet/tooltips +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This page contains tooltip links from the Cloud Wallet. It provides some basic info about the various components. + +## 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. + +## Spend Key + +This is a vault’s primary key used for signing transactions. It can be either a passkey or a hardware key from the Chia Signer app. + +## Recovery Key + +This key can only be used for recovering a vault. It cannot be used for signing transactions. Currently it must be a BLS key. In the future, we will also enable passkeys, as well as hardware and software keys from the Chia Signer app. + +## 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. + +## Recovery Clawback + +When you create a new vault, you need to input the amount of time to wait before a recovery can be completed. This is the "recovery clawback" time. During this time window, you can cancel the recovery if it was initiated maliciously. Note that the default recovery clawback time for the beta is 15 minutes. On mainnet, most people will want to set this to something like 48-72 hours in order to provide ample time to cancel the recovery if necessary. + +## Recovery Phrase + +If you use a BLS key as the recovery key, you will be given a series of 24 words to copy. This is the recovery phrase. You will need to enter this phrase upon initiating a vault recovery. Be sure to copy this phrase carefully, and don’t show it to anyone. We don’t store a copy of this phrase, so we can only show it to you when you create your vault. + +## 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. + +## 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. + +## Clawback + +You can optionally add a time span to a transaction during which you can claw it back. During this time, the recipient can see the incoming transaction, but cannot access the funds. Clawback is primarily useful to prevent sending funds to the wrong address. + +For example, Alice sends 1 XCH to Bob, and she adds a 1-hour clawback. + +- For the next hour, Bob can see the incoming XCH in his vault's transaction list, but he cannot access it. +- 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. 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 404c36a90bb..ec7d20a017e 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 @@ -77,7 +77,7 @@ A fork is a new repository that shares code and visibility settings with the ori 4. By default, forks are named the same as their upstream repositories. Optionally, to further distinguish your fork, in the "Repository name" field, type a name. 5. Optionally, in the "Description" field, type a description of your fork. 6. Optionally, select **Copy the DEFAULT branch only**. - For many forking scenarios, such as contributing to open-source projects, you only need to copy the default branch. If you do not select this option, all branches will be copied into the new fork. + For many forking scenarios, such as contributing to open-source projects, you only need to copy the default branch. If you do not select this option, all branches will be copied into the new fork. 7. Click **Create fork**. :::note @@ -123,16 +123,18 @@ 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 - gpg --full-generate-key - ``` - - If you are not on version 2.1.17 or greater, the gpg --full-generate-key command doesn't work. Paste the text below and skip to step 6. + - If you are on version 2.1.17 or greater, paste the text below to generate a GPG key pair. - ```shell - gpg --default-new-key-algo rsa4096 --gen-key - ``` + ```shell + gpg --full-generate-key + ``` + + - If you are not on version 2.1.17 or greater, the gpg --full-generate-key command doesn't work. Paste the text below and skip to step 6. + + ```shell + gpg --default-new-key-algo rsa4096 --gen-key + ``` 4. At the prompt, specify the kind of key you want, or press `Enter` to accept the default. @@ -143,9 +145,9 @@ Note: Before generating a new GPG key, make sure you've verified your email addr 7. Verify that your selections are correct. 8. Enter your user ID information. - :::note - When asked to enter your email address, ensure that you enter the verified email address for your GitHub account. To keep your email address private, use your GitHub-provided no-reply email address. For more information, see "Verifying your email address" and "Setting your commit email address." - ::: + :::note + When asked to enter your email address, ensure that you enter the verified email address for your GitHub account. To keep your email address private, use your GitHub-provided no-reply email address. For more information, see "Verifying your email address" and "Setting your commit email address." + ::: 9. Type a secure passphrase. @@ -229,7 +231,7 @@ At last, you're ready to propose changes into the main project! This is the fina 1. To do so, head on over to the repository on GitHub where your project lives. For this example, it would be at `https://github.com//chia-docs`. 2. You'll see a banner indicating that your branch is one commit ahead of chia-docs:main. Click **Contribute** and then **Open a pull request**. 3. GitHub will bring you to a page that shows the differences between your fork and the Chia-Network/chia-docs repository. Click **Create pull request**. - - GitHub will bring you to a page where you can enter a title and a description of your changes. It's important to provide as much useful information and a rationale for why you're making this pull request in the first place. The project owner needs to be able to determine whether your change is as useful to everyone as you think it is. + - GitHub will bring you to a page where you can enter a title and a description of your changes. It's important to provide as much useful information and a rationale for why you're making this pull request in the first place. The project owner needs to be able to determine whether your change is as useful to everyone as you think it is. 4. Finally, click **Create pull request**. --- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md index aa40faf918c..efc29703b78 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/docs-home.md @@ -58,17 +58,25 @@ Embark on your Chia Network journey with our Beginner Documentation! Uncover the
- - - + +
+
+ Beginners Farming Guide +
+ +
- - - + +
+
+ Beginners Wallet Guide +
+ +
@@ -127,22 +135,14 @@ Explore the advanced features of Chia Network through our comprehensive document
- - - - - - - - - - - - - - - + +
+
+ Farming Deep Dive +
+ +
@@ -168,7 +168,7 @@ Explore the advanced features of Chia Network through our comprehensive document
- +
CLI Reference @@ -179,10 +179,14 @@ Explore the advanced features of Chia Network through our comprehensive document
- - - + +
+
+ WalletConnect Reference +
+ +
@@ -208,10 +212,14 @@ Navigate Chia Network's Troubleshooting Documentation with precision. Check the
- - - + +
+
+ Node Syncing +
+ +
@@ -270,10 +278,14 @@ Embark on a knowledge journey through Chia Network's Learn documentation. Delve
- - - + +
+
+ Chia Keys +
+ +
@@ -288,10 +300,14 @@ Embark on a knowledge journey through Chia Network's Learn documentation. Delve
- - - + +
+
+ Green Paper +
+ +
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 0e31c2574b1..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 @@ -6,7 +6,7 @@ title: CAT Creation Tutorial import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -The CAT standard allows you to create fungible tokens on the Chia blockchain. This step-by-step guide will go through creating your own CATs. For info on how CATs are built at the Chialisp level, see our [CAT primitive page](https://chialisp.com/cats). +The CAT standard allows you to create fungible tokens on the Chia blockchain. This step-by-step guide will go through creating your own CATs. For info on how CATs are built at the Chialisp level, see our [CAT primitive page](https://chialisp.com/cats). This step-by-step guide will go through creating your own CATs. For info on how CATs are built at the Chialisp level, see our [CAT primitive page](https://chialisp.com/cats). Alternatively, if you're looking for non-fungible tokens on Chia, check out our [NFT guide](/guides/nft-intro). @@ -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. @@ -49,20 +49,20 @@ These concepts are discussed in greater detail in our [CAT primitive page](https Cat issuance comes in two phases. First, you will test your issuance on a testnet. Once ready, you will issue on mainnet. -For this tutorial, we'll use testnet11. +For this tutorial, we'll use testnet10. 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. For more info, see our [testnet documentation](/guides/crash-course/introduction#getting-on-testnet). +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). -3. Start Chia's reference wallet GUI. The command you use will depend on your OS, as well as whether you used a binary installer or installed from source. If you need help, see the installation guide. +3. Start Chia's reference wallet GUI. The command you use will depend on your OS, as well as whether you used a binary installer or installed from source. If you need help, see the installation guide. The command you use will depend on your OS, as well as whether you used a binary installer or installed from source. If you need help, see the installation guide. -When using the GUI, you have the option of running in `Farming Mode` or `Wallet Mode`. Both of these options will work for creating CATs. `Farming Mode` will be faster if you already have a synced full node, but this is not necessary for CAT issuance. +When using the GUI, you have the option of running in `Farming Mode` or `Wallet Mode`. Both of these options will work for creating CATs. When using the GUI, you have the option of running in `Farming Mode` or `Wallet Mode`. Both of these options will work for creating CATs. `Farming Mode` will be faster if you already have a synced full node, but this is not necessary for CAT issuance. :::info @@ -72,13 +72,14 @@ You can also run Chia's reference wallet from a [command line](/reference-client 4. Add a new wallet if you have not already done so. -5. You will need to have a sufficient number of mojos for your CAT issuance and transaction fee(s). You can request some TXCH from the [Testnet11 faucet](https://testnet11-faucet.chia.net). +5. You will need to have a sufficient number of mojos for your CAT issuance and transaction fee(s). You can request some TXCH from the [Testnet10 faucet](https://testnet10-faucet.chia.net). You can request some TXCH from the [Testnet11 faucet](https://testnet11-faucet.chia.net). 6. Before issuing a CAT, you will need to have a synced wallet, as demonstrated by the green checkmark inside the red circle in this image:
Synced wallet
+
Once you have a synced wallet and some TXCH, you are ready to run the CAT admin tool. @@ -96,7 +97,7 @@ values={[ ]}> -Your Linux installation may not come with Python's development tools installed by default. To be sure that these tools are installed, run: +Your Linux installation may not come with Python's development tools installed by default. Your Linux installation may not come with Python's development tools installed by default. To be sure that these tools are installed, run: ```bash sudo apt-get install -y build-essential python3-dev @@ -144,6 +145,31 @@ pip install chia-dev-tools --no-deps Install pytest: +```bash +pip install pytest +``` ./venv/bin/activate +``` + +Install the prerequisites: + +```bash +python3 -m pip install --upgrade pip setuptools wheel +``` + +Install the tool: + +```bash +pip install . +``` + +Install chia dev tools: + +```bash +pip install chia-dev-tools --no-deps +``` + +Install pytest: + ```bash pip install pytest ``` @@ -200,6 +226,23 @@ 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: + +```bash +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. +::: @@ -207,7 +250,7 @@ You might receive an error such as ERROR: Failed building wheel for CAT-admin-to ---
- + Your environment should be all set, but let's make sure: - Run `cats --help`. You should get a usage statement. @@ -224,7 +267,8 @@ To get started, you will create a single-issuance CAT. This is the default way t :::note -A TAIL is a Chialisp program that defines the rules for issuing and melting tokens. Learn more about the [Token and Asset Issuance Limitations program](https://chialisp.com/cats/#tail). +A TAIL is a Chialisp program that defines the rules for issuing and melting tokens. Learn more about the [Token and Asset Issuance Limitations program](https://chialisp.com/cats/#tail). Learn more about the [Token and Asset Issuance Limitations program](https://chialisp.com/cats/#tail). +Single issuance CATs can **NOT** be melted. ::: @@ -232,7 +276,7 @@ A CAT with a single-issuance TAIL will be useful for anyone who wants to create First, figure out how many tokens you want to issue. Because creating a single token takes 1,000 mojos, you will multiply your supply by 1,000 to figure out how much TXCH (or XCH on mainnet) is needed. For example, if you want to issue 1 million tokens, you'll need 1 billion mojos (1/1000 of a TXCH/XCH). -Take note of your _Receive Address_ in the Chia GUI. (Alternatively, run `chia wallet get_address` from a terminal window.) You'll need this address for the next step. +Take note of your _Receive Address_ in the Chia GUI. (Alternatively, run `chia wallet get_address` from a terminal window.) You'll need this address for the next step. (Alternatively, run `chia wallet get_address` from a terminal window.) You'll need this address for the next step. After confirming you are within the admin tool directory, run: @@ -277,10 +321,12 @@ We'll set up this CAT to delegate the same TAIL we set up previously. What this First, figure out how many tokens you want to issue. Because creating a single token takes 1,000 mojos, you will multiply your supply by 1,000 to figure out how much TXCH (or XCH on mainnet) is needed. For example, if you want to issue 1 million tokens, you'll need 1 billion mojos (1/1000 of a TXCH/XCH). :::note +Multi-issuance CATs can be melted with a custom spend bundle as described [here](#melting-a-cat). + Just as with the Single Issuance CAT, we recommend that you include a fee with your transaction. This fee will ensure that your transaction is processed in front of any dust in the mempool. Whether you're running on testnet or mainnet, the recommended fee amount is 100 million mojos (`-m 100000000`). Even though you will run the `cats` command multiple times, the fee will only be applied once, when the transaction is pushed to the network. ::: -Run `chia wallet get_address` from a terminal window to get a new receive address. You will use this address shortly. +Run `chia wallet get_address` from a terminal window to get a new receive address. You will use this address shortly. You will use this address shortly. Run `chia keys show`. Take note of your **fingerprint** and **master public key**. @@ -339,6 +385,7 @@ Now you can add a wallet ID for your new CAT. In the lower left corner, click `M
Manage Token List
+
The first few tokens listed will be there by default (Marmot, Spacebucks, etc). At the end of the list, you should find your CAT's `asset ID`. Feel free to rename your CAT, and click the slider to add a new wallet with that CAT: @@ -346,6 +393,7 @@ The first few tokens listed will be there by default (Marmot, Spacebucks, etc).
Enable new CAT
+
You will now see your token in your wallet with the full issued quantity. As a reminder, this should be the number of mojos spent divided by 1,000 (as each CAT token requires 1,000 mojos to issue). @@ -353,10 +401,30 @@ You will now see your token in your wallet with the full issued quantity. As a r
View new CAT
+
You now have access to your CAT in the GUI. You can send and receive your new tokens just like you would with regular XCH. +## Melting a CAT + +When you spend one or more CAT coins, you provide an Extra Delta in the solution, which is essentially by how much the supply is changing. If it's positive, you're increasing the supply. And if it's negative, you're melting the CAT away. + +When the Extra Delta is non-zero, you have to run the TAIL program, which describes the rules for when you are allowed to change the supply. + +Single issuance CATs cannot be melted because the TAIL only allows being run if the coin has a specific parent. In other words, the supply can only be set once, and never modified thereafter. For multi issuance CATs, you need to sign with the issuance key in order to authorize the supply change, and therefore it does support melting. + +You reveal and run the TAIL by outputting the following condition from the inner puzzle's spend: +`(list CREATE_COIN () -113 )` + +The documentation for this Extra Delta concept can be found [here](https://chialisp.com/cats/#extra-delta). + +This is an [example](https://github.com/xch-dev/chia-wallet-sdk/blob/main/crates/chia-sdk-driver/src/primitives/cat/cat_spend.rs) of melting a CAT from Rigidity's wallet SDK. + +In this example, you start with a supply of 10000, use an extra delta of -3000, reveal the TAIL and output a new CAT with the remaining supply of 7000. + +Here is another [example](https://github.com/irulast/chia_crypto_utils/blob/0bbf32a422e2b624cd3f84b7b643b0f83f18be51/integration_test/cat/cat_multi_issuance_test.dart#L44) of melting a CAT from Irulast's chia crypto utils. + ## Preparing for Mainnet After you are comfortable with issuing your CAT on testnet, you may wish to move to mainnet. **Please keep in mind that there are extra risks inherent to publishing code on a public blockchain.** If your seed phrase is ever exposed, your funds could be stolen. If you created a custom TAIL, there is a possiblity of funds being bricked. **Proceed with caution.** @@ -369,7 +437,7 @@ When you are ready to issue your CAT to mainnet, the first step is to switch to chia configure -t false ``` -The second step is to generate a new key pair and store the mnemonic in a secure manner. You can generate your key by clicking `Add Wallet` and `Create New` from the `Wallet Keys` login screen of the GUI. This will work in the same manner as earlier for our testnet CAT. +The second step is to generate a new key pair and store the mnemonic in a secure manner. The second step is to generate a new key pair and store the mnemonic in a secure manner. You can generate your key by clicking `Add Wallet` and `Create New` from the `Wallet Keys` login screen of the GUI. This will work in the same manner as earlier for our testnet CAT. This will work in the same manner as earlier for our testnet CAT. :::danger We recommend the new keypair being used exclusively for the CAT ownership. @@ -382,9 +450,7 @@ This would be a complex and time-consuming process that would likely result in p ::: :::tip -You can generate keys from the CLI as well. -Use `chia keys show` to see your available keys. Take note of their fingerprint as you will want to _not_ use an existing key. -Generate a key with `chia keys generate`, followed by `chia keys show --show-mnemonic-seed` to reveal the 24 words. +You can generate keys from the CLI as well. Use `chia keys show` to see your available keys. Take note of their fingerprint as you will want to _not_ use an existing key. Generate a key with `chia keys generate`, followed by `chia keys show --show-mnemonic-seed` to reveal the 24 words. ::: Copy your new key pair's **mnemonic seed (24 secret words)** to a secure offline location. These 24 words are all you'll need to restore your wallet in the future. @@ -395,6 +461,6 @@ Finally, you can go through the same process to create a CAT now using real XCH Congratulations! You've created your first CAT. What now? -Well, hopefully you can share your CAT with the world and get some traction. In the meantime, you can learn more about the [Single Issuance TAIL](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/cat_wallet/puzzles/genesis_by_coin_id.clsp) and [Multi Issuance TAIL](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/cat_wallet/puzzles/delegated_tail.clsp). +Well, hopefully you can share your CAT with the world and get some traction. Well, hopefully you can share your CAT with the world and get some traction. In the meantime, you can learn more about the [Single Issuance TAIL](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/cat_wallet/puzzles/genesis_by_coin_id.clsp) and [Multi Issuance TAIL](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/cat_wallet/puzzles/delegated_tail.clsp). This guide was for fungible tokens. Now you can learn about [non-fungible tokens](/guides/nft-intro). 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 041427d9bf7..9a373386035 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 @@ -64,6 +64,7 @@ python -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -72,6 +73,7 @@ python3 -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -164,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. @@ -363,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,6 +624,7 @@ values={[ ```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 2be0f0099eb..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 @@ -44,17 +44,18 @@ values={[ ]}> -- If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: +1. If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: :::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" ``` -- If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: +2. If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: ```powershell .\venv\Scripts\Activate.ps1 @@ -65,25 +66,29 @@ Set-Alias -Name chia "C:\Users\\AppData\Local\chia-blockchain\app- -- If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: +1. If you previously installed Chia from a **binary build**, then set up an alias to the `chia` command: ```bash alias chia="/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/chia" ``` -- If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: +2. If you previously installed Chia **from source**, then navigate to the `chia-blockchain` directory and activate your virtual environment: ```bash . ./activate +``` ./activate ``` @@ -109,9 +114,8 @@ alias chia="/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/c 3. `START_HEIGHT` - The height of the blockchain to start creating the snapshot from (default: `0`). If you are attempting to obtain all records for your CAT, the recommended start height is `1146800`, which is just before CAT1 was introduced. 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. - ::: + :::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: @@ -191,6 +195,7 @@ python3 setup.py install :::note The result may contain several warnings such as `WARNING: The wheel package is not available.` These can be safely ignored. ::: +::: This command may take a few minutes to complete. At the end of the output, you should see something like: @@ -241,6 +246,7 @@ python3 setup_database.py :::tip If you receive an error message such as `ModuleNotFoundError: No module named 'chia'`, then make sure you can run the `chia` command from this directory and try again. ::: +::: If this command succeeds, then it will output: @@ -285,7 +291,7 @@ python3 start.py This command will show its progress according to the block height. If you used the recommended range for `START_HEIGHT` and `TARGET_HEIGHT` in your `.env` file, then this command could take over 40 hours to complete. The reason it takes so long is it needs to process each block, one at a time. If multiple blocks were done in parallel, then there would be a chance that the results would not be accurate. By processing one block at a time, the tool will return the correct results for the range provided. :::note -You can only generate a snapshot for each block once. If you attempt to run this command over a range against which it has already been run, you will receive an error containing this message: +You can only generate a snapshot for each block once. If you attempt to run this command over a range against which it has already been run, you will receive an error containing this message: If you attempt to run this command over a range against which it has already been run, you will receive an error containing this message: ``` sqlite3.IntegrityError: UNIQUE constraint failed: coin_create.coin_name @@ -372,10 +378,10 @@ 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`. +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`. ::: ## Fix EOL Characters {#fix-eol} 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 8dca5f0705e..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 @@ -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 @@ -134,6 +135,7 @@ The VC is also viewable from the GUI:
Authorized provider VC
+
#### VC Holder Wallet @@ -181,6 +183,7 @@ The VC is also viewable from the GUI:
Holder VC
+
#### XCH Wallet @@ -246,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 . ``` @@ -287,6 +303,7 @@ Install the CAT admin tool: ```bash pip install . +``` ``` @@ -371,6 +388,7 @@ Response (truncated): ```bash ... +... Profile 1: -Total Balance: 1.0 -Pending Total Balance: 1.0 @@ -460,6 +478,7 @@ Response (truncated): ```bash ... +... CAT 3ba9e16dca39f3fb...: -Total Balance: 1000.0 (1000000 mojo) -Balance Pending VC Approval: 0.0 (0 mojo) @@ -478,6 +497,7 @@ This information is also viewable in the GUI:
CR-CAT issuance
+
The Authorized Provider now has control of all 1000 of the issued CR-CATs. This type of CAT is distinguished in the GUI by a padlock icon and `Restricted CAT`. The Authorized Provider now has control of all 1000 of the issued CR-CATs. This type of CAT is distinguished in the GUI by a padlock icon and `Restricted CAT`. The Authorized Provider also possesses a VC with the required proof (`test_proof1`), so a green icon appears when viewing the CAT. @@ -493,6 +513,7 @@ You can send CR-CATs just as you would with regular CATs:
CR-CAT send
+
You should see a "success" message: @@ -500,6 +521,7 @@ You should see a "success" message:
CR-CAT send success
+
In this example, the recipient is the VC Holder's wallet. This wallet holds the credential with the required proof (`test_proof1`) for holding this CR-CAT. Because the proof exists, a green `APPROVE` button will appear. @@ -509,6 +531,7 @@ From the VC Holder's wallet, click this button to finalize the transaction:
VC Holder Approve
+
An on-chain transaction is required for the approval to be processed. An on-chain transaction is required for the approval to be processed. This is necessary to guard against unauthorized wallets holding CR-CATs, as will be demonstrated later in this tutorial. Enter a transaction fee and click `APPROVE PENDING TRANSACTIONS`: Enter a transaction fee and click `APPROVE PENDING TRANSACTIONS`: @@ -516,6 +539,7 @@ An on-chain transaction is required for the approval to be processed. An on-chai
Approve pending transactions
+
After the transaction has been processed, the CR-CATs will become available to the VC Holder, who can now send or trade them just like normal CATs. @@ -523,6 +547,7 @@ After the transaction has been processed, the CR-CATs will become available to t
CR-CAT approved
+
### Sending from the CLI @@ -555,6 +580,7 @@ Response: ```bash Submitting transaction... +Submitting transaction... Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] Run 'chia wallet get_transaction -f 3152280463 -tx 0xab577bdce7fdd1be8b4e0634ad69aa5cff66f6d9dc7d26e0119d1a3a740f91e8' to get status ``` @@ -573,6 +599,8 @@ Status: Confirmed Amount sent: 100 CAT 3ba9e16dca39f3fb... To address: txch1yzjq802ym3lv9aupl6nyvv6s24fdm9wpnte2rvhk04arr3jyt4js2287gz Created at: 2023-09-22 09:21:25 +To address: txch1yzjq802ym3lv9aupl6nyvv6s24fdm9wpnte2rvhk04arr3jyt4js2287gz +Created at: 2023-09-22 09:21:25 ``` **After switching to the VC Holder's wallet**, you should see the CR-CATs that are pending approval (in this case `100.0 (100000 mojo)`): @@ -669,6 +697,7 @@ In this example, as the **Authorized Provider**, click `CREATE AN OFFER` from th
Create an Offer
+
Next, fill out the Offer Builder. Next, fill out the Offer Builder. For this example, we will offer to trade 99 CR-CATs for 0.1 TXCH: @@ -676,6 +705,7 @@ Next, fill out the Offer Builder. Next, fill out the Offer Builder. For this exa
Offer Builder
+
After creating the Offer, Authorized Provider can save it as a local file or post it to a marketplace. @@ -685,6 +715,7 @@ For this example, we will change to the **VC Holder** wallet and load the Offer
Accept Offer
+
While the on-chain transaction to accept the Offer is pending, the 99 CR-CATs will be displayed in the VC Holder's `Pending Balance`. Note that the `Pending Balance for Approval` is `0` in this case: Note that the `Pending Balance for Approval` is `0` in this case: @@ -692,6 +723,7 @@ While the on-chain transaction to accept the Offer is pending, the 99 CR-CATs wi
Pending Offer Acceptance
+
After the transaction has been confirmed, the balance is updated. After the transaction has been confirmed, the balance is updated. When receiving CR-CATs via an Offer, there is no need to perform another transaction to approve of the incoming tokens. This is because the proof requirement is already baked into the Offer file. This is because the proof requirement is already baked into the Offer file. @@ -699,6 +731,7 @@ After the transaction has been confirmed, the balance is updated. After the tran
Completed Offer
+
At this point, the VC Holder wallet has full possession of the CR-CATs. @@ -837,6 +870,7 @@ Let's say the Authorized Provider obtains the XCH Wallet's address and sends 50
Send CR-CATs to address lacking proofs
+
Even though the recipient is not allowed to hold these CR-CATs, the transaction itself is valid. Even though the recipient is not allowed to hold these CR-CATs, the transaction itself is valid. However, just as in the examples at the beginning of this tutorial, the XCH Wallet will receive the CR-CATs in the `Pending Balance for Approval` section of the GUI. In this case, the required proof (in the red circle below) is not present. In this case, the required proof (in the red circle below) is not present. @@ -846,11 +880,13 @@ The XCH Wallet can still attempt to approve these CR-CATs:
Proof not present
+
Attempt to approve
+
However, this attempt will fail because the required proofs are missing: @@ -858,6 +894,7 @@ However, this attempt will fail because the required proofs are missing:
Required providers missing
+
The status of these CR-CATs is as follows: @@ -887,6 +924,7 @@ Let's say the owner of the XCH Wallet locates a CR-CAT Offer. Let's say the owne
Offer where required providers missing
+
Any attempts to accept this Offer without first receiving a VC with the required proofs will fail: @@ -894,6 +932,7 @@ Any attempts to accept this Offer without first receiving a VC with the required
Offer acceptance where required providers missing
+
Thus, when using Offers, the funds cannot accidentally be sent to an unauthorized recipient. 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 966e9bdf0a9..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 @@ -105,6 +105,7 @@ python -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -113,6 +114,7 @@ python3 -m venv venv ```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. -::: +:::
@@ -48,6 +49,9 @@ python3 -m venv venv . ./venv/bin/activate python -m pip install --upgrade pip setuptools wheel pip install . +``` ./venv/bin/activate +python -m pip install --upgrade pip setuptools wheel +pip install . ``` @@ -304,7 +308,7 @@ If someone accepts the offer and the transaction is completed, you will receive The first step to getting your offer accepted is to broadcast it in some way. -This file can be uploaded anywhere, but there are many websites out there dedicated to Chia offers. Offer sites include [Offerbin](https://offerbin.io/) and [offerpool](https://offerpool.io/). +This file can be uploaded anywhere, but there are many websites out there dedicated to Chia offers. Offer sites include [Dexie](https://dexie.space/) and [offerpool](https://offerpool.io/). You can accept an offer that has been downloaded to your personal machine with the `take_offer` command. @@ -344,8 +348,7 @@ Use chia wallet get_offers --id 41f5bfab75ff5f35489b0954597aa76c56ed7098aa9ad137 ``` -You'll notice there is a line for `Included Fees`, which is currently 0. As the blockchain becomes more saturated, a fee may need to be applied by either the maker or taker with an additional CLI flag. -Let's continue by getting the offer's information. +You'll notice there is a line for `Included Fees`, which is currently 0. As the blockchain becomes more saturated, a fee may need to be applied by either the maker or taker with an additional CLI flag. Let's continue by getting the offer's information. ```bash chia wallet get_offers --id 41f5bfab75ff5f35489b0954597aa76c56ed7098aa9ad137f0132b584541119f -f 1660000549 @@ -428,8 +431,7 @@ Once you have the image URL and the hash, we can create the NFT with a command l chia wallet nft mint -i -u -nh -m ``` -This will include the wallet ID, URL, data hash, and a fee. -If this command is issued successfully, you will have created an NFT on Chia! +This will include the wallet ID, URL, data hash, and a fee. If this command is issued successfully, you will have created an NFT on Chia! You can get the details of your new NFT with: @@ -465,32 +467,32 @@ Response: ``` NFT minted Successfully with spend bundle: { - 'aggregated_signature': '0x8673a394dca82d91cd1ddeff0b518cb02056fa24ce45b8cda4e7819258c9cc13a68ed71d4d25ef7254358af2f033d99b180b2b0255a8f113d699517e7019b825b09f68eb126da228f82b474f316bc8a657310a527ff54a4668971e9486c39c89', - 'coin_solutions': [{ - 'coin': { - 'amount': 1, - 'parent_coin_info': '0x75690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8d', - 'puzzle_hash': '0xd41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6' - }, - 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff04ff2cff8080808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a0a04d9f57764f54a43e4030befb4d80026e870519aaa66334aef8304f5d0393c2ffff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d7580ffff826c7580ffff82736e01ffff8273740180ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff82ad4cff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff20ffff02ffff03ffff09ffff0122ffff0dff82029f8080ffff01ff02ffff03ffff09ffff0cff82029fff80ffff010280ff1080ffff01ff0101ff8080ff0180ff8080ff018080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff8080808080808080ff0180ff018080ffff04ffff01a0c5abea79afaa001b5427dfa0c8cf42ca6f38f5841b78f9b3c252733eb2de2726ffff04ffff0180ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff04ff82013fffff04ff80ffff04ffff02ffff03ffff22ff82013fffff20ffff09ff82013fff2f808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8205bfffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff82013fff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ff0180ff80808080ffff01ff04ff2fffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff17ffff01ff04ffff04ff10ffff04ffff0bff81a7ffff02ff3effff04ff02ffff04ffff04ff2fffff04ffff04ff05ffff04ffff05ffff14ffff12ff47ff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fff8080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0c05f74b4f7e8b79dbb23118d7bcdebcadbaddac46824acebe455481c3ec850daffff04ffff0180ff0180808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0815cec38feefbc2669d2eab272deb4badc17bc42a0f1cecbf1f5cf8c0219d9b7cdad195b9588291642db49da17b99b6eff018080ff018080808080ff018080808080ff01808080', - 'solution': '0xffffa02f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1dff0180ff01ffffffff80ffff01ffff81f6ff80ff80ff8080ffff33ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ff01ffffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6808080ff8080808080' - }, { - 'coin': { - 'amount': 9734999999, - 'parent_coin_info': '0x265cee97bfc72cc1c41692c9462d098009f5bcade81202cfbacf717a988b8667', - 'puzzle_hash': '0x7b0628c573b77df18bf858b6111be39e25e040f4fdb74c74702dfd94b1bd7fbb' - }, - 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0aa1fdb303fb4e59c8082380e3462a0a4ff3f66ccfb5c40b33b6a13706206b1796f2a32c035a452a26d9926fccb0e3246ff018080', - 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0e520db6f3cab1c1a26f84f6bb19f44c103a3609a2b552ed1e2647dbf600fd160ff85023474bb7e80ffff34ff840fcb944080ffff3cffa0a8520fb03d767496573596438ba3e9414cc845b1d2ab26c159ab64be397dd7ba80ffff3dffa05751070a5bfeabb3f71640bacfa81ea2275c36a25a60bb4381ef598cb56bca578080ff8080' - }, { - 'coin': { - 'amount': 1, - 'parent_coin_info': '0x2f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1d', - 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' - }, - 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', - 'solution': '0xffa0d41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6ff01ff8080' - }] + 'aggregated_signature': '0x8673a394dca82d91cd1ddeff0b518cb02056fa24ce45b8cda4e7819258c9cc13a68ed71d4d25ef7254358af2f033d99b180b2b0255a8f113d699517e7019b825b09f68eb126da228f82b474f316bc8a657310a527ff54a4668971e9486c39c89', + 'coin_solutions': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x75690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8d', + 'puzzle_hash': '0xd41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff04ff2cff8080808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a0a04d9f57764f54a43e4030befb4d80026e870519aaa66334aef8304f5d0393c2ffff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d7580ffff826c7580ffff82736e01ffff8273740180ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff82ad4cff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff20ffff02ffff03ffff09ffff0122ffff0dff82029f8080ffff01ff02ffff03ffff09ffff0cff82029fff80ffff010280ff1080ffff01ff0101ff8080ff0180ff8080ff018080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff8080808080808080ff0180ff018080ffff04ffff01a0c5abea79afaa001b5427dfa0c8cf42ca6f38f5841b78f9b3c252733eb2de2726ffff04ffff0180ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff04ff82013fffff04ff80ffff04ffff02ffff03ffff22ff82013fffff20ffff09ff82013fff2f808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8205bfffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff82013fff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ff0180ff80808080ffff01ff04ff2fffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff17ffff01ff04ffff04ff10ffff04ffff0bff81a7ffff02ff3effff04ff02ffff04ffff04ff2fffff04ffff04ff05ffff04ffff05ffff14ffff12ff47ff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fff8080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa075690e6a336be6223d3282d71085af366a1c94e9418c25ca9f5fba9d29e09a8da0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0c05f74b4f7e8b79dbb23118d7bcdebcadbaddac46824acebe455481c3ec850daffff04ffff0180ff0180808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0815cec38feefbc2669d2eab272deb4badc17bc42a0f1cecbf1f5cf8c0219d9b7cdad195b9588291642db49da17b99b6eff018080ff018080808080ff018080808080ff01808080', + 'solution': '0xffffa02f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1dff0180ff01ffffffff80ffff01ffff81f6ff80ff80ff8080ffff33ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ff01ffffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6ffa0e68767ba2b431eb8efd9b8dd0db668d5c0c00c7a04e83f6bc6504c0f2626fdf6808080ff8080808080' + }, { + 'coin': { + 'amount': 9734999999, + 'parent_coin_info': '0x265cee97bfc72cc1c41692c9462d098009f5bcade81202cfbacf717a988b8667', + 'puzzle_hash': '0x7b0628c573b77df18bf858b6111be39e25e040f4fdb74c74702dfd94b1bd7fbb' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0aa1fdb303fb4e59c8082380e3462a0a4ff3f66ccfb5c40b33b6a13706206b1796f2a32c035a452a26d9926fccb0e3246ff018080', + 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0e520db6f3cab1c1a26f84f6bb19f44c103a3609a2b552ed1e2647dbf600fd160ff85023474bb7e80ffff34ff840fcb944080ffff3cffa0a8520fb03d767496573596438ba3e9414cc845b1d2ab26c159ab64be397dd7ba80ffff3dffa05751070a5bfeabb3f71640bacfa81ea2275c36a25a60bb4381ef598cb56bca578080ff8080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x2f1c4f4568c420033fb690c134ed3ed3d8d9fa3bdb75f1044d51789b59ea3a1d', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', + 'solution': '0xffa0d41dce69252d14db9a19eb0fcbd0e014d416245460b76a9fe4e7a8030e1bb4c6ff01ff8080' + }] } ``` 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 b19cbf5d4d5..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 @@ -21,7 +21,7 @@ This tool was _not_ originally developed with the broader ecosystem in mind. For Before continuing, you might want to familiarize yourself with the following documents: - [Basic description](/guides/custody-tool-description) of how the custody tool works -- [Flow chart](https://docs.chia.net/files/chia-custody-tool.png) to visualize how the custody tool works +- [Flow chart](/img/chia-custody-tool.png) to visualize how the custody tool works - [CLI reference](https://docs.chia.net/reference-client/cli-reference/custody-tool-cli) for all custody commands used in this tutorial :::info @@ -38,7 +38,7 @@ The custody tool uses many parameters, each of which is important. You are highl - A synced full node (mainnet, testnet, or [simulator](/guides/simulator-user-guide "Simulator user guide")) - A synced [Chia wallet](https://docs.chia.net/reference-client/install-and-setup/installation "Chia installation instructions") -- [Python](https://www.python.org/downloads/ "Python downloads page") 3.9 or greater **(will not work with 3.8.x)** +- [Python](https://www.python.org/downloads/ "Python downloads page") 3.9 or greater - [Git command line tool](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git "How to install the Git command line tool") - [Powershell 6](https://www.howtogeek.com/731885/how-to-check-the-powershell-version-in-windows-10/ "How to check your Powershell version") or greater (Windows only) - Visual C++ Redistributable (Windows only) @@ -80,6 +80,7 @@ python -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -88,6 +89,7 @@ python3 -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -123,7 +125,7 @@ If you get a usage statement, then `cic` (Chia Internal Custody) has been instal --- -### Command Notes +## Command Notes :::info A few notes about the commands in this guide @@ -137,12 +139,9 @@ Most of the commands from this tutorial will _not_ alter the blockchain. This in :::warning warning for windows users -Windows uses different line endings than Linux and MacOS. -If you only plan to use Windows for both generating and signing spend bundles, this won't be a problem. +Windows uses different line endings than Linux and MacOS. If you only plan to use Windows for both generating and signing spend bundles, this won't be a problem. -However, if you plan to generate your spend bundles on Windows and sign them using a Linux HSM, then you will need to modify the line endings before signing. -The easiest way to accomplish this is with `dos2unix`. -This is not included with Windows, so you will need to download it from [SourceForge](https://sourceforge.net/projects/dos2unix/). +However, if you plan to generate your spend bundles on Windows and sign them using a Linux HSM, then you will need to modify the line endings before signing. The easiest way to accomplish this is with `dos2unix`. This is not included with Windows, so you will need to download it from [SourceForge](https://sourceforge.net/projects/dos2unix/). The command to convert your spend bundles is then: @@ -249,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 @@ -316,12 +315,9 @@ As a result of running this command, `Configuration (awaiting launch).txt` will ::: -In this step, you will run `cic launch_singleton`, which will create the singleton on the blockchain. -In order to run this command, you will need to have at least 1 mojo in your wallet to create the singleton. +In this step, you will run `cic launch_singleton`, which will create the singleton on the blockchain. In order to run this command, you will need to have at least 1 mojo in your wallet to create the singleton. -The `launch_singleton` command also includes a recommended `--fee` flag to specify a blockchain fee in mojos. -This fee is completely separate from the actual financing of the singleton, which will occur in a later step. -It is also possible to launch the singleton using one wallet and fund it with another -- think of the singleton as a brand new wallet. +The `launch_singleton` command also includes a recommended `--fee` flag to specify a blockchain fee in mojos. This fee is completely separate from the actual financing of the singleton, which will occur in a later step. It is also possible to launch the singleton using one wallet and fund it with another -- think of the singleton as a brand new wallet. Aside from the fees, the `launch_singleton` command includes an optional `--configuration` flag to specify the name and location of the configuration file. By default, the command will look in `./Configuration (awaiting launch).txt`. @@ -375,8 +371,7 @@ Congratulations, you have successfully launched the singleton! (You will need to At this point, the singleton should exist on the blockchain. However, it has not yet been funded. For now, let's view it. -Currently your local custody database does not know about the singleton. -Therefore, in order to view the singleton, you must first synchronize the localhost with the blockchain by running the `sync` command. +Currently your local custody database does not know about the singleton. Therefore, in order to view the singleton, you must first synchronize the localhost with the blockchain by running the `sync` command. The first time you run the `sync` command, you need to specify the configuration file, which will then be copied into your config database. @@ -409,9 +404,7 @@ Outstanding events: REKEYS: ``` -To view the configuration, run `cic show` and add the `-c` flag. -To view the derivation info, run `cic show` and add the `-d` flag. -You can also add both flags. +To view the configuration, run `cic show` and add the `-c` flag. To view the derivation info, run `cic show` and add the `-d` flag. You can also add both flags. For example: @@ -626,8 +619,7 @@ This test will run through the complete sequence of withdrawing money from the s This command generates an unsigned spend bundle which requires specific keys. Signers can take this spend bundle to an HSM for signing. -To begin the payment process, use the `cic payment` command. -For this example, we'll use the following arguments (see the [CLI reference](/reference-client/cli-reference/custody-tool-cli#payment "payment command") for all options): +To begin the payment process, use the `cic payment` command. For this example, we'll use the following arguments (see the [CLI reference](/reference-client/cli-reference/custody-tool-cli#payment "payment command") for all options): - `-f` : The name of the file in which to save the unsigned spend bundle - `-pks`: The public keys that will be used to sign the withdrawal. Exactly `m` keys must be included. The only keys allowed to sign are those that were originally used in the `derive_root` command @@ -750,9 +742,7 @@ Once you have the signed spend bundle on a synced node with some XCH/TXCH for a cic push_tx -b ./withdrawal.signed -m 10000000 ``` -The withdrawal has now been added to the blockchain. However, the money has not yet reached its final destination. -Instead, it will now sit in a "drop coin" (aka escrow) and cannot be withdrawn for at least (`-pc`) seconds, which is built into the singleton and cannot be changed. -For this example, we used 1200 seconds for this value. +The withdrawal has now been added to the blockchain. However, the money has not yet reached its final destination. Instead, it will now sit in a "drop coin" (aka escrow) and cannot be withdrawn for at least (`-pc`) seconds, which is built into the singleton and cannot be changed. For this example, we used 1200 seconds for this value. #### View the payment's status @@ -793,9 +783,7 @@ As the output of this command shows, there is a new payment outstanding (`PAYMEN - If (`-pc`) seconds have not elapsed since the drop coin's creation, the output will display `(Ready at: )` - If (`-pc`) seconds have elapsed, then the output will say `(Ready)` -In either case, claw backs are allowed until the payment has been completed. -(Even if the withdrawal is in "Ready" state, it can still be clawed back. However, because _anyone_ can -complete the withdrawal, claw backs should no longer be assumed to be available once the "Ready" state has been reached.) +In either case, claw backs are allowed until the payment has been completed. (Even if the withdrawal is in "Ready" state, it can still be clawed back. However, because _anyone_ can complete the withdrawal, claw backs should no longer be assumed to be available once the "Ready" state has been reached.) Note that even when the state is "Ready", the next transaction block will still need to be created before the withdrawal is _actually_ ready. @@ -968,8 +956,7 @@ Outstanding events: REKEYS: ``` -Instead of completing the payment, we'll claw it back. If you want to test this feature, be sure to make the value of `-pc` sufficiently large to give yourself plenty of time to perform the clawback. -In this example we still have 17 minutes remaining (`Ready at` minus `Current time` from the above output). +Instead of completing the payment, we'll claw it back. If you want to test this feature, be sure to make the value of `-pc` sufficiently large to give yourself plenty of time to perform the clawback. In this example we still have 17 minutes remaining (`Ready at` minus `Current time` from the above output). #### Create an unsigned spend bundle for the clawback @@ -1053,8 +1040,7 @@ echo 549614102252741379514039214279174962654364157854486736945228183041555384205 This command should have no output. The signatures are now stored in text files. -Finally, merge the claw back signatures into a signed spend bundle. -Note that an arbitrary number of signatures can be passed into this command. We'll use two signatures for this example. +Finally, merge the claw back signatures into a signed spend bundle. Note that an arbitrary number of signatures can be passed into this command. We'll use two signatures for this example. ```bash hsmmerge ./clawback.unsigned ./clawback_1.sig ./clawback_2.sig > clawback.signed @@ -1254,9 +1240,7 @@ Custody rules successfully added to configuration ::: -Next, run `start_rekey`, which will create an unsigned spend bundle for the rekey. Note that in this command, -`-pks` refers to the original keys that must sign to allow the rekey to happen. -The configuration file from the `-new` flag contains all of the new info that will be used after the rekey has completed. +Next, run `start_rekey`, which will create an unsigned spend bundle for the rekey. Note that in this command, `-pks` refers to the original keys that must sign to allow the rekey to happen. The configuration file from the `-new` flag contains all of the new info that will be used after the rekey has completed. ```bash cic start_rekey -f rekey.unsigned -pks "1.pk,2.pk" -new './Configuration (after rekey).txt' @@ -1315,9 +1299,7 @@ echo 555391688726247518407714092604079246104554134754321333331702549926309406250 echo 5561137392380018602752549597282386367838345256392677171809614780347764174154608487537742644428466353746831639451621586320322685820178179047514852085991565214608652175820480007073564769669494661900487484133333312104972188050976529086895435776 > rekey_2.sig ``` -Finally, merge the rekey signatures into a signed spend bundle. -Note that an arbitrary number of signatures can be passed into this command. -For this example, we need to use the two signatures we just calculated: +Finally, merge the rekey signatures into a signed spend bundle. Note that an arbitrary number of signatures can be passed into this command. For this example, we need to use the two signatures we just calculated: ```bash hsmmerge ./rekey.unsigned ./rekey_1.sig ./rekey_2.sig > rekey.signed @@ -1388,12 +1370,9 @@ As the output of this command shows, there is a new rekey outstanding (`REKEY fr - If (`-rc`) seconds have not elapsed since the drop coin's creation, the output will display `(Ready at: )` - If (`-rc`) seconds have elapsed, then the output will say `(Ready)` -In either case, cancellation/clawback is allowed until the rekey is completed. -(Even if the rekey is in "Ready" state, it can still be clawed back. However, because _anyone_ can -complete the rekey, claw backs should no longer be assumed to be available once it reaches the "Ready" state.) +In either case, cancellation/clawback is allowed until the rekey is completed. (Even if the rekey is in "Ready" state, it can still be clawed back. However, because _anyone_ can complete the rekey, claw backs should no longer be assumed to be available once it reaches the "Ready" state.) -Note that even when the state is "Ready", the next transaction block will still need to be created before the rekey is _actually_ ready. -Transaction blocks happen every 52 seconds on average. +Note that even when the state is "Ready", the next transaction block will still need to be created before the rekey is _actually_ ready. Transaction blocks happen every 52 seconds on average. #### Create a signed spend bundle for the completion 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 bed8290ced9..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 @@ -3,11 +3,11 @@ slug: /custody/prefarm-audit-tutorial title: Prefarm Audit Tutorial --- -Chia Network Inc's prefarm is secured by a complex set of custodial rules. This document describes how to use the custody tool to audit the prefarm configuration. A moderate level of technical proficiency is probably needed to understand the details. For a high-level overview of the prefarm custody wallets, see our [blog post](https://www.chia.net/2022/10/29/a-new-home-for-the-prefarm/). +Chia Network Inc's prefarm is secured by a complex set of custodial rules. This document describes how to use the custody tool to audit the prefarm configuration. A moderate level of technical proficiency is probably needed to understand the details. For a high-level overview of the prefarm custody wallets, see our [blog post](https://www.chia.net/2022/10/29/a-new-home-for-the-prefarm/). This document describes how to use the custody tool to audit the prefarm configuration. A moderate level of technical proficiency is probably needed to understand the details. For a high-level overview of the prefarm custody wallets, see our [blog post](https://www.chia.net/2022/10/29/a-new-home-for-the-prefarm/). Other relevant documents: -- [Flow chart](https://docs.chia.net/img/chia-custody-tool.png) to visualize how the custody tool works +- [Flow chart](/img/chia-custody-tool.png) to visualize how the custody tool works - [User guide](/guides/custody-tool-user-guide) to help you get up and running - [CLI reference](/reference-client/cli-reference/custody-tool-cli) for all custody commands used in this tutorial - [Prefarm Alert Tool](https://github.com/Chia-Network/prefarm-alert) to access the public prefarm config files @@ -76,9 +76,7 @@ xch1jj0gm4ahhlu3ke0r0fx955v8axr6za7rzz6hc0y26lewa7zw6fws5nwvv6 :::info -NOTE: A high level of technical proficiency is needed to understand the details of this manual process for what the cic tool does above. -This process is a high-level guide and does not display expected results for each step. -The [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools#install) are needed for this audit. +NOTE: A high level of technical proficiency is needed to understand the details of this manual process for what the cic tool does above. This process is a high-level guide and does not display expected results for each step. NOTE: A high level of technical proficiency is needed to understand the details of this manual process for what the cic tool does above. This process is a high-level guide and does not display expected results for each step. The [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools#install) are needed for this audit. ::: @@ -93,7 +91,7 @@ The [chia-dev-tools](https://github.com/Chia-Network/chia-dev-tools#install) are 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..846342580ab 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 @@ -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..c3281cef48b 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 @@ -278,7 +278,7 @@ Regardless of the status of `FULL NODE`, you may safely proceed with this tutori - Green dot = full node is synced - `FULL NODE` is missing = you are running in `Wallet Mode` -::: +:::
Synced wallet 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 5e1bcf5f839..a213bc6c976 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 @@ -105,6 +105,7 @@ python -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -113,6 +114,7 @@ python3 -m venv venv ```bash python3 -m venv venv . ./venv/bin/activate +``` ./venv/bin/activate ``` @@ -121,7 +123,7 @@ python3 -m venv venv 4. Install the bulk minting tool. This will install a copy of Chia in your virtual environment, as well as all other dependencies for the tool: ```bash -pip install --editable .[dev] +pip install --editable '.[dev]' ``` ## Configure Chia to use the bulk minting tool @@ -139,14 +141,11 @@ chia configure --testnet true ``` :::note -If you previously had been running Chia on mainnet, then your peers table will be populated with mainnet peers. -When you switch to running on the testnet, the peers listed in this table will time out. -Eventually the table will be repopulated with testnet peers, but this can take a long time. -In order to expedite this process, We recommend that you delete your peers tables: +If you previously had been running Chia on mainnet, then your peers table will be populated with mainnet peers. When you switch to running on the testnet, the peers listed in this table will time out. Eventually the table will be repopulated with testnet peers, but this can take a long time. In order to expedite this process, We recommend that you delete your peers tables: - `~/.chia/mainnet/db/peers.dat` - `~/.chia/mainnet/wallet/db/wallet_peers.dat` - ::: +::: 2. We recommend that you use `INFO` level logging instead of the default `WARNING` level. To do this, run: @@ -185,7 +184,7 @@ Showing all public and private keys Fingerprint: 3049838316 (...) - Mnemonic seed (24 secret words): + Mnemonic seed (24 secret words): youth stomach social aware clay pottery benefit asthma mail cry rubber panda wife around provide atom cute sand staff exotic pink east gloom minute ``` @@ -199,7 +198,7 @@ If you ever need to display your address, run `chia keys show`. This command wil 6. In order to continue, you will need to have some TXCH in your wallet. If your total balance is 0, you can obtain 1 TXCH from our faucet. Copy the value of "First wallet address:" from the output of the `chia keys show` command. It will be a long string beginning with "txch". -Open our [testnet faucet page](https://testnet11-faucet.chia.net "Chia's testnet11 faucet link"). Paste your address and click "Submit". +Open our [testnet faucet page](https://testnet10-faucet.chia.net "Chia's testnet10 faucet link"). Paste your address and click "Submit". Paste your address and click "Submit". You will receive this message: `Accepted. Your request is in the queue and will be processed in the order it was received.` At some point you will receive 1 TXCH. Depending on how busy the faucet and the testnet are, this could take several minutes. However, you don't need to wait for your coins to arrive before continuing. @@ -209,12 +208,12 @@ You will receive this message: `Accepted. Your request is in the queue and will mkdir ~/.chia/mainnet/db ``` -8. If you downloaded a copy of the testnet database, you will need to wait for the download to complete before continuing. After the download has completed, use an archive manager such as [7-Zip](https://www.7-zip.org/ "7-Zip's website") to extract the file. You should now have a file in your Downloads folder called `blockchain_v2_testnet11.sqlite`. +8. If you downloaded a copy of the testnet database, you will need to wait for the download to complete before continuing. After the download has completed, use an archive manager such as [7-Zip](https://www.7-zip.org/ "7-Zip's website") to extract the file. If you downloaded a copy of the testnet database, you will need to wait for the download to complete before continuing. After the download has completed, use an archive manager such as [7-Zip](https://www.7-zip.org/ "7-Zip's website") to extract the file. You should now have a file in your Downloads folder called `blockchain_v2_testnet10.sqlite`. Move the database to the folder you just created: ```bash -mv ~/Downloads/blockchain_v2_testnet11.sqlite ~/.chia/mainnet/db +mv ~/Downloads/blockchain_v2_testnet10.sqlite ~/.chia/mainnet/db ``` 9. Start the full node, which will begin syncing to the database file: @@ -235,9 +234,9 @@ chia show -s Eventually, it will say `Full Node Synced`: ```text -Network: testnet11 Port: 58444 RPC Port: 8555 +Network: testnet10 Port: 58444 RPC Port: 8555 Node ID: 82a73b06b3a5f9493a3ac4e3d903026b39c85b748158ba41c623d531947f2a2a -Genesis Challenge: 37a90eb5185a9c4439a91ddc98bbadce7b4feba060d50116a067de66bf236615 +Genesis Challenge: ae83525ba8d1dd3f09b277de18ca3e43fc0af20d20c4b3e92ef2a48bd291ccb2 Current Blockchain Status: Full Node Synced ``` @@ -464,6 +463,14 @@ This message should appear in the output: dos2unix: converting file to Unix format... ``` +:::note + +If you plan to use fees, make sure to split your coins before the next step. If you have a single coin in your wallet you will run into errors when trying to submit the spend bundles. + +The easiest way to split coins is to send a portion of your balance to yourself (yes send xch/txch to your own address), this will split the coin into two the amount you sent and the change. + +::: + 3. Create the spend bundles. This command has six inputs: - `-w`: the wallet ID for the NFT wallet (`3` in this example) @@ -496,7 +503,7 @@ Note that you may see a warning such as: This can be safely ignored. 4. Submit the spend bundles created in the output file (output.pkl in this example). This command has two flags: - - `-m`: an optional transaction fee, in mojos. This is a fee to be used for inclusion in the blockchain, completely separate from the royalty percentage. This fee will be applied once per spend bundle of 25 NFTs. The bulk mint tool will not verify that you have enough money to cover this fee beforehand + - `-m`: an optional transaction fee, in mojos. This is a fee to be used for inclusion in the blockchain, completely separate from the royalty percentage. This fee will be applied once per spend bundle of 25 NFTs. The bulk mint tool will not verify that you have enough money to cover this fee beforehand. If you are getting errors submitting the spend bundle indicating your balance is 0 then please split your coins by sending a portion of your balance to yourself and rerun the create-mint-spend-bundles command. - `-o`: set this to create a separate offer file for each NFT, using the specified price. In this example, the offer price will be 100 mojos ```bash @@ -506,7 +513,7 @@ chianft submit-spend-bundles -m 10 -o 100 output.pkl Each time a spend bundle is submitted, some status info will appear. For example: ```bash -SUBMITTED: 1/4 TX: 104.70s FEE: 0.04s OFFER: 6.02s TOTAL: 120.77s +SUBMITTED: 1/4 TX: 104.70s FEE: 0.04s OFFER: 6.02s TOTAL: 120.77s ``` Expect the total time for each spend bundle to be around 1-2 minutes. A project with `10 000` NFTs could take anywhere from 7-14 hours to complete. @@ -600,7 +607,7 @@ This can be safely ignored. 4. Submit the spend bundles created in the output file (output.pkl in this example). This command has two flags: - `-m`: an optional transaction fee, in mojos. This is a fee to be used for inclusion in the blockchain, completely separate from the royalty percentage. This fee will be applied once per spend bundle of 25 NFTs. The bulk mint tool will not verify that you have enough money to cover this fee beforehand - - `-o`: _Not set._ In this example, we don't provide this option as we will be air-dropping them to their targeted address in the `metadata.csv`. We declared these spend bundles to include a targeted address in the previous command. We would not be able to create offers for NFTs where we are offering the NFT if we are not the owner. (The air-drop address is the NFT owner.) + - `-o`: _Not set._ In this example, we don't provide this option as we will be air-dropping them to their targeted address in the `metadata.csv`. We declared these spend bundles to include a targeted address in the previous command. We would not be able to create offers for NFTs where we are offering the NFT if we are not the owner. (The air-drop address is the NFT owner.) We declared these spend bundles to include a targeted address in the previous command. We would not be able to create offers for NFTs where we are offering the NFT if we are not the owner. (The air-drop address is the NFT owner.) ```bash chianft submit-spend-bundles -m 10 output.pkl @@ -609,7 +616,7 @@ chianft submit-spend-bundles -m 10 output.pkl Each time a spend bundle is submitted, some status info will appear. For example: ```bash -SUBMITTED: 1/4 TX: 104.70s FEE: 0.04s OFFER: 6.02s TOTAL: 120.77s +SUBMITTED: 1/4 TX: 104.70s FEE: 0.04s OFFER: 6.02s TOTAL: 120.77s ``` Expect the total time for each spend bundle to be around 1-2 minutes. A project with `10 000` NFTs could take anywhere from 7-14 hours to complete. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-cli.md index f659bbcbb0a..84e426d6ecc 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-cli.md @@ -209,7 +209,7 @@ Here is a description of the options used: | `-lh` | The hash of the NFT's license. | | -en | The edition number. Specify if this NFT has multiple editions (multiple identical copies of an NFT). | | -et | The edition total number. Specify if this NFT has multiple editions. | -| `-rp` | The royalty percentage expressed as tens of thousandths of a percent. | +| `-rp` | The royalty percentage expressed as hundredths of a percent. | | `--no-did-ownership` | Disables DID ownership. | | `-m` | The fee for this transaction in XCH. | 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 fcb8fc0cc1e..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 | @@ -150,7 +150,7 @@ To install Chia from source, follow our [installation guide](https://docs.chia.n ### Switching to testnet -By default, Chia will run on mainnet. By default, Chia will run on mainnet. To switch to the testnet (recommended) for this guide, see [our testnet instructions](https://docs.chia.net/reference-client/install-and-setup/testnets). +By default, Chia will run on mainnet. To switch to the testnet (recommended) for this guide, see [our testnet instructions](https://docs.chia.net/reference-client/install-and-setup/testnets). ## Configuration diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-rpc.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-rpc.md index 08f9b333e79..d89cdc7b71d 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-rpc.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/nft/nft-rpc.md @@ -276,7 +276,7 @@ Here is a description of the parameters used in the command: | "license_uris" | A list of URIs containing the license. | | "license_hash" | The hash of the license. | | "royalty_address" | The wallet or smart coin address of the creator. | -| "royalty_percentage" | The royalty percentage expressed as tens of thousandths of a percent. | +| "royalty_percentage" | The royalty percentage expressed as hundredths of a percent. | | "target_address" | The address of the owner. | | "edition_number" | If this NFT has multiple **editions** (multiple identical copies of an NFT), then this parameter indicates the edition number of this NFT. | | "edition_total" | If this NFT has multiple **editions**, then this parameter indicates the total number of editions of this NFT. This parameter should be used with `edition_number`. | diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md index a4c14c8a9bb..91ec81703fa 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/seeder-user-guide.md @@ -11,9 +11,9 @@ It does so by crawling through the network, periodically revisiting known nodes The Chia Seeder runs a mini-DNS server. The Chia Seeder runs a mini-DNS server. Anyone can obtain an entry point into Chia’s decentralized and permissionless network via a simple DNS request for reliable node IPs. -The Chia Seeder has very low memory and CPU requirements. It runs a faux full_node process and does not need its own node. +The Chia Seeder has low memory and CPU requirements. It runs a faux full_node process and does not need its own node. -Chia’s core developers have already been running an instance of the Chia Seeder for some time. You can view the current status of this instance by running: You can view the current status of this instance by running: +Chia’s core developers have been running an instance of the Chia Seeder for some time. You can view the current status of this instance by running: ```bash # IPv4 @@ -23,7 +23,7 @@ dig dns-introducer.chia.net dig -t AAAA dns-introducer.chia.net ``` -Chia has now decided to release the Seeder as a tool for anyone to maintain their own list of reliable nodes, which contributes to the further decentralization of Chia’s network by taking this tool off of the core team’s hands. +Chia Network released the Seeder as a tool for anyone to maintain their own list of reliable nodes, which contributes to the further decentralization of Chia’s network by taking this tool off of the core team’s hands. Features: @@ -31,6 +31,8 @@ Features: - Runs a mini-DNS server on port 53, along with a full node to crawl the network. - Stores peer IPs and peer statistics into a database, so that they are persisted across runs. +@dns_xch from Dexie created an [alternate light implemntation}](https://github.com/dexie-space/chia-seeder-light) in Rust that uses 99% less CPU and 66% less RAM. + ## Expectations for Chia Seeder operators The Chia network core developers endeavor to minimize the level of trust in the DNS servers associated with a Chia Seeder. In this regard, it is expected for each Chia Seeder to be run by an individual or organization recognized as well-intentioned within the Chia community. In this regard, it is expected for each Chia Seeder to be run by an individual or organization recognized as well-intentioned within the Chia community. @@ -72,13 +74,13 @@ nameserver 8.8.8.8 nameserver 8.8.4.4 ``` -Once you have completed freeing up port 53, you will then need to allow the python executable in your venv to have access to port 53: +Once you have completed freeing up port 53, you will then need to allow the python executable in your venv to have access to port 53. From an activated venv run `whereis python` and use the result in the command below: ```bash -sudo setcap CAP_NET_BIND_SERVICE=+eip $(readlink -f /home/{{ user }}/chia-blockchain/venv/bin/python) +sudo setcap CAP_NET_BIND_SERVICE=+eip $(readlink -f /home/{{ user }}/chia-blockchain/.venv/bin/python) ``` -Note that anytime you change the python executable by rerunning `sh install.sh` or when `apt` upgrades python, you will need to re-run this command. +Note that anytime you change the python executable by rerunning `sh install.sh` or when `apt` upgrades python, you will need to re-run this command. Also, the exact path to python has changed as of version 2.4.3 and that new usual default is what is specified above. ## Configuration diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md index 50d9d449744..3656e7a5b9f 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/tutorials/offers-cli.md @@ -381,7 +381,7 @@ Wallet ID 4 type COLOURED_COIN CAT King Cole (Asset ID: 1121996b75cce3c746369ace ## Create an expiring Offer (RPC) -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: In addition, we will add an expiry timestamp so that this Offer will expire on Jan. 1, 2024. This is accomplished with the `max_time` flag: +In this example, we will offer 0.1 CATs (`TAIL/Asset 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. This is accomplished with the `max_time` flag: ```bash chia rpc wallet create_offer_for_ids '{"offer":{"1":1000000000000,"91aa49303fd325cf8029cc0ee5e19ac78ec33d641d63b50d0ba859309a73004d":-100},"fee":10000000,"driver_dict":{},"validate_only":false, "max_time": 1704070800}' 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 a14c68ac7b7..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 @@ -124,7 +124,7 @@ This section will show you how to mint, transfer, and revoke a VC using Chia's ` ### Create proofs -First, you must add proofs to the local database. First, you must add proofs to the local database. To do this, run the [add_proof_reveal](/reference-client/cli-reference/vc-cli#add_proof_reveal) command. You can add multiple proofs by reusing the `proof` parameter. For example: You can add multiple proofs by reusing the `proof` parameter. For example: +First, you must add proofs to the local database. To do this, run the [add_proof_reveal](/reference-client/cli-reference/vc-cli#add_proof_reveal) command. You can add multiple proofs by reusing the `proof` parameter. For example: ```bash chia wallet vcs add_proof_reveal --proof test_proof1 --proof test_proof2 @@ -221,7 +221,7 @@ Previously, you added your desired proofs to the local database and calculated t ### Add proofs to a VC -Use the [update_proofs](/reference-client/cli-reference/vc-cli#update_proofs) command to add proofs to a VC. This command must be run from the proof provider's wallet (the wallet that contains the DID used for minting). This command must be run from the proof provider's wallet (the wallet that contains the DID used for minting). +Use the [update_proofs](/reference-client/cli-reference/vc-cli#update_proofs) command to add proofs to a VC. This command must be run from the proof provider's wallet (the wallet that contains the DID used for minting). The `--new-proof-hash` parameter is required; this hash was included in the response from running the `add_proof_reveal` command. @@ -298,7 +298,7 @@ In cases such as this, the proof provider needs to _revoke_ the credentials, ie The only wallet that is allowed to revoke credentials is the proof provider's (the wallet that contains the DID used to mint the VC). -In order to run the [revoke](/reference-client/cli-reference/vc-cli#revoke) command, the proof provider will need to know the parent coin ID (the `-p` parameter). Because VCs are singletons, their parent coin IDs will change every time the VC is spent (every time a change is made). Because VCs are singletons, their parent coin IDs will change every time the VC is spent (every time a change is made). +In order to run the [revoke](/reference-client/cli-reference/vc-cli#revoke) command, the proof provider will need to know the parent coin ID (the `-p` parameter). Because VCs are singletons, their parent coin IDs will change every time the VC is spent (every time a change is made). For testing purposes, the **holder's wallet** can obtain the parent coin ID by running the [vc_get](/reference-client/rpc-reference/vc-rpc#vc_get) RPC. The parent coin ID is the value of the `"parent_coin_info"`. In a production environment, the proof provider will track the VC on-chain and obtain this info immediately prior to revoking the VC. @@ -344,7 +344,7 @@ Proofs: ## RPC Guide -This section will show you how to mint, transfer, and revoke a VC using Chia's `wallet` [CLI commands](/reference-client/cli-reference/vc-cli). A similar walk-through using RPCs will be presented in the [next section](#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 @@ -367,7 +367,7 @@ chia rpc wallet vc_get '{\"vc_id\": \"13ba084e78475327e41c60df5a108965d7a283f065 ### Create proofs -First, you must add proofs to the local database. First, you must add proofs to the local database. To do this, run the [vc_add_proofs](/reference-client/rpc-reference/vc-rpc#vc_add_proofs) command. `"proofs"` is a dictionary of key-value pairs. Unlike the equivalent CLI command, this command allows you to use any string value. `"proofs"` is a dictionary of key-value pairs. Unlike the equivalent CLI command, this command allows you to use any string value. +First, you must add proofs to the local database. To do this, run the [vc_add_proofs](/reference-client/rpc-reference/vc-rpc#vc_add_proofs) command. `"proofs"` is a dictionary of key-value pairs. Unlike the equivalent CLI command, this command allows you to use any string value. ```json chia rpc wallet vc_add_proofs '{"proofs": {"example_proof_1": "example_value_1", "example_proof_2": "example_value_2"}}' @@ -509,7 +509,7 @@ The script will output the proof hash for the proofs your entered. In this examp :::info -If you want to retrieve your original proofs from a proof hash, run the [vc_get_proofs_for_root](/reference-client/rpc-reference/vc-rpc#vc_get_proofs_for_root) command. For example: For example: +If you want to retrieve your original proofs from a proof hash, run the [vc_get_proofs_for_root](/reference-client/rpc-reference/vc-rpc#vc_get_proofs_for_root) command. For example: ```json chia rpc wallet vc_get_proofs_for_root '{"root": "96c9597578333c840f895f30af6d40b9f6c0d69100db1a13ae2e26e4c94acdd3"}' @@ -533,7 +533,7 @@ Note that this command will only succeed if you have already added the correspon ### Mint a VC -To mint a VC, run the [vc_mint](/reference-client/rpc-reference/vc-rpc#vc_mint) command. The `did_id` parameter is required. This is the DID owned by the minting wallet. You may also optionally pass in a `target_address`, where the VC will be delivered. If this parameter is missing, the VC will be sent to the same wallet that owns the DID: The `did_id` parameter is required. This is the DID owned by the minting wallet. You may also optionally pass in a `target_address`, where the VC will be delivered. If this parameter is missing, the VC will be sent to the same wallet that owns the DID: +To mint a VC, run the [vc_mint](/reference-client/rpc-reference/vc-rpc#vc_mint) command. The `did_id` parameter is required. This is the DID owned by the minting wallet. You may also optionally pass in a `target_address`, where the VC will be delivered. If this parameter is missing, the VC will be sent to the same wallet that owns the DID: ```json chia rpc wallet vc_mint '{"did_id": "did:chia:1rnvmwp3wmglslk942mwsrmf7dlkluytyna8mgewel44h4ne3nd9slhtddg", "target_address": "txch1yfcclacd6sch2w9dz394zjuq7pqnmz5g7mrqac0hjhwpzmyahe9sqetxaz", "fee": 100000000}' @@ -669,7 +669,7 @@ Previously, you added your desired proofs to the local database and calculated t ### Add proofs to a VC -In Chia, a singleton is a primitive standard that allows a coin to be recreated with different properties when it is spent. In Chia, a singleton is a primitive standard that allows a coin to be recreated with different properties when it is spent. Chia VCs are singletons; use the [vc_spend](/reference-client/rpc-reference/vc-rpc#vc_spend) command to spend a VC and recreate it with a new set of proofs. +In Chia, a singleton is a primitive standard that allows a coin to be recreated with different properties when it is spent. Chia VCs are singletons; use the [vc_spend](/reference-client/rpc-reference/vc-rpc#vc_spend) command to spend a VC and recreate it with a new set of proofs. The `new_proof_hash` parameter is required; this is the root hash you previously obtained. 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 06adf1f6cca..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 @@ -8,7 +8,13 @@ import TabItem from '@theme/TabItem'; ## Intro -This guide will help developers to create dApps on Chia's blockchain using [WalletConnect](https://walletconnect.com/). It will be expanded upon as more tools are introduced. +WalletConnect allows users to connect dApps to their cryptocurrency wallets. Chia's reference wallet supports WalletConnect for a variety of dApps. + +:::info + +WalletConnect Inc (the company behind the WalletConnect product) has been rebranded to [Reown](https://reown.com/). However, the WalletConnect product lives on in the form of [walletconnect.network](https://walletconnect.network/). We will continue to refer to WalletConnect by its original name on this site. + +::: For more info, see our WalletConnect [command documentation](/reference-client/walletconnect/walletconnect/). @@ -18,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/guides/walletconnect/walletconnect-user-guide.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md index f2985d916c0..4a22488daf3 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/guides/walletconnect/walletconnect-user-guide.md @@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem'; ## Intro -This guide will show you how to use [WalletConnect](https://walletconnect.com/) to connect a sample dApp to your Chia reference wallet. +This guide will show you how to use [WalletConnect](https://walletconnect.network/) to connect a sample dApp to your Chia reference wallet. :::note a few notes @@ -242,7 +242,7 @@ Returning to the sample dApp, a new dialog with the response will appear. In thi
-You have now installed, configured, and used the sample dApp. Feel free to test the other functions, as well as create your own! + You have now installed, configured, and used the sample dApp. Feel free to test the other functions, as well as create your own! --- 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 new file mode 100644 index 00000000000..31851481be2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/asic-hwvdf-cli.md @@ -0,0 +1,116 @@ +--- +sidebar_label: ASICs +title: ASICs HW VDF +slug: /reference-client/cli-reference/asic-hwvdf-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Reference + +### `hw_vdf_client` + +Functionality: Run the ASIC HW VDF Software + +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 + +```bash +hw_vdf_client 8000 3 +``` + +Response: + +``` +2024-04-12T10:32:05.898 Setting frequency to 1100.000000 MHz +2024-04-12T10:32:06.016 Frequency is 1100.000000 MHz +2024-04-12T10:32:06.020 Board voltage is 0.875 V +2024-04-12T10:32:06.020 Setting voltage to 0.880 V +2024-04-12T10:32:06.021 Board voltage is now 0.875 V +2024-04-12T10:32:06.032 Board current is 0.698 A +2024-04-12T10:32:06.043 Board power is 0.610 W +2024-04-12T10:32:06.049 Connecting to 127.0.0.1:8000 +2024-04-12T10:32:06.049 VDF 0: Connected to timelord, waiting for challenge +``` + +
+ +
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 +``` + +Response: + +``` +2024-04-12T10:32:05.898 Setting frequency to 1500.000000 MHz +2024-04-12T10:32:06.016 Frequency is 1500.000000 MHz +2024-04-12T10:32:06.020 Board voltage is 0.875 V +2024-04-12T10:32:06.020 Setting voltage to 0.880 V +2024-04-12T10:32:06.021 Board voltage is now 0.875 V +2024-04-12T10:32:06.032 Board current is 0.698 A +2024-04-12T10:32:06.043 Board power is 0.610 W +2024-04-12T10:32:06.049 Connecting to 192.168.0.122:8000 +2024-04-12T10:32:06.049 VDF 0: Connected to timelord, waiting for challenge +``` + +
+ +
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 +``` + +Response: + +``` +2024-04-12T10:32:05.898 Setting frequency to 1100.000000 MHz +2024-04-12T10:32:06.016 Frequency is 1100.000000 MHz +2024-04-12T10:32:06.020 Board voltage is 0.875 V +2024-04-12T10:32:06.020 Setting voltage to 0.880 V +2024-04-12T10:32:06.021 Board voltage is now 0.875 V +2024-04-12T10:32:06.032 Board current is 0.698 A +2024-04-12T10:32:06.043 Board power is 0.610 W +2024-04-12T10:32:06.049 Connecting to 192.168.0.122:8000 +2024-04-12T10:32:06.049 VDF 0: Connected to timelord, waiting for challenge +``` + +
+ +--- + +## Troubleshooting a Timelord + +For troubleshooting steps please refer to the documentation [here](/reference-client/troubleshooting/timelords). + +--- + +## Timelord support + +Join Our [Discord](https://discord.gg/chia) and jump into the #support channel for support + +--- + +## Timelord FAQ + +For FAQ please refer to the documentation [here](/reference-client/install-and-setup/timelord-install#timelord-faq). + +--- 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 new file mode 100644 index 00000000000..25ba839027f --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cat-admin-cli.md @@ -0,0 +1,240 @@ +--- +sidebar_label: CAT Admin +title: CAT Admin CLI +slug: /reference-client/cli-reference/cat-admin-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Intro + +This document is a reference guide for Chia's CAT Admin Tool, located in the [CAT-admin-tool](https://github.com/Chia-Network/CAT-admin-tool) repository. + +To set up your environment (including installing this tool), follow our [CAT Creation Tutorial](/guides/cat-creation-tutorial). + +## Reference + +### `cats` + +Functionality: Create and administer Chia Asset Tokens (CATs) + +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] | +| -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) + +Request: + +```bash +cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to txch1jk4r06xsj0fnwqk57322yjqzkdyx7kh8h8kvxus3l68tjnkf05aqd9uevs --amount 1000000000000 --as-bytes --select-coin +``` + +Response: + +``` +{ + "amount": 1999731499999, + "parent_coin_info": "0x3179dd9b38f7c4e4de532e346cfefb33affda1f2860ed68aeb0e70c38a5c9f6e", + "puzzle_hash": "0x74fcdd0e27ead17559cf9eaf791c62a6517c0c4fcf5ac3a6f014857571fc7608" +} +Name: 345dd430bcd7a413f8feed25c382d83855edd6ccceb41d1dbc293ca8e49e6b2d +``` + +The "parent_coin_info", "puzzle_hash", and "amount" values are hashed together to create the coin's "Name". + +
+ +
Example 2 - Push a transaction to the network, currying an inner puzzle hash into the TAIL + +Request: + +```bash +cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to txch19k6cl5syzvxgkgulr7m49v2r57yh0aanm23hrffgd89j4nj3ywhqxadyqr --amount 1000000000000 --as-bytes --curry 0x8f4dbff8df3f6aa9303eb47625cf8f09d885f1ad6a2d440582cb6bd45f53d2e8 +``` + +Response: + +```bash +The transaction has been created, would you like to push it to the network? (Y/N)y +Successfully pushed the transaction to the network +Asset ID: 9c39398afb1d7ffa03a589f60e5e39f2ae4572ff7048e689fe3128c339581b2d +Eve Coin ID: 9fe3e95308949cb9c49333f829922dc7118cd3e2fdf365cde669b47852ce3a7b +``` + +After pushing the transaction, the new ID and Eve Coin (singleton parent coin) will be shown. + +
+ +
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**): + +- `--tail`: The tail to use; in this case we'll use a single-issuance TAIL +- `--send-to`: The address to send the CR-CATs to upon minting +- **`--authorized-provider`: The DID that is authorized to issue VCs containing the required proof(s) for this CAT** +- **`--cr-flag`: The proof(s) required for owning this CR-CAT** +- `--amount`: The number of mojos for this issuance (1 million mojos = 1 thousand CR-CATs) +- `-m`: The transaction fee, in mojos +- `--as-bytes`: Use bytes instead of JSON +- `--select-coin`: Instead of minting the CAT, just select a coin to use for the isuance + +```bash +cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to txch1ek6ln2ejdsec6l734x8tggk9j5sepl8nfqjer5yt2dr905f04prqmcjcc5 --authorized-provider did:chia:1x23lnyd2xjefnfly075ngk79duf0yxna35cp86mgnnp4t33senfs4cah7u --cr-flag "test_proof1" --amount 1000000 -m 1000 --as-bytes --select-coin +``` + +Response: + +```bash +{ + "amount": 999694993543, + "parent_coin_info": "0x3ad9ec3ab9039047106476b4b23d05c46a7f02a6114c4eaf82792c3229e74416", + "puzzle_hash": "0xa8180f3997eeda1804508c1f4dbe55ef17808fe2df970bba408807b10e7dd9ba" +} +Name: c5519ac8ef55043b23bef45b1326d445f2c4af579f13dc0cdec10335ccb0a809 +``` + +In the above repsonse, `Name` is the ID of the coin to be used for the minting. Next, run the same command again, but remove the `--select-coin` flag and add `--curry 0x` (the `0x` is required and important here): + +```bash +cats --tail ./reference_tails/genesis_by_coin_id.clsp.hex --send-to txch1ek6ln2ejdsec6l734x8tggk9j5sepl8nfqjer5yt2dr905f04prqmcjcc5 --authorized-provider did:chia:1x23lnyd2xjefnfly075ngk79duf0yxna35cp86mgnnp4t33senfs4cah7u --cr-flag "test_proof1" --amount 1000000 -m 1000 --as-bytes --curry 0xc5519ac8ef55043b23bef45b1326d445f2c4af579f13dc0cdec10335ccb0a809 +``` + +Response: + +```bash +Successfully pushed the transaction to the network +Asset ID: 262a2c2cbb09414652006c4da139a186b3a110bb57cd5d76b6785e4811f1c77c +Eve Coin ID: 692a4f63c56815a33510088a255d695aea472d0f03bb9f0d5cdd5c91a82821f2 +``` + +Just as with standard CATs, the CR-CAT has been minted and sent to its destination address. Asset ID can now be added in the destination wallet. `Asset ID` can now be added in the destination wallet. + +In this case, the destination wallet is the holder of a VC with the proof required to hold this CR-CAT. To verify this, run the vcs get CLI command: To verify this, run the `vcs get` CLI command: + +```bash +chia wallet vcs get +``` + +```bash +Proofs: +- f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 + - test_proof1 + - test_proof2 + +Launcher ID: 1e3cd9da1d4545700c8c26fb7ba452cf28b1c7d78b5fa7434307d32a435718c8 +Coin ID: addf46fac52aac510b31a7dc025528411b5013d89c81174f4726b63a5dc0d395 +Inner Address: txch166pzqd55p2emp9sqaflvyc8x2s4qn4eexrxgrlfwf8khuefp5fqswe84mu +Proof Hash: f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 +``` + +This VC contains the proof that was added to the CR-CAT (`test_proof1`). Once the CR-CAT has been added to this Chia wallet, it will be displayed as type `CRCAT`. For example: + +```bash +chia wallet show +``` + +Response: + +```bash +CAT 262a2c2cbb094146...: + -Total Balance: 1000.0 (1000000 mojo) + -Balance Pending VC Approval: 0.0 (0 mojo) + -Pending Total Balance: 1000.0 (1000000 mojo) + -Spendable: 1000.0 (1000000 mojo) + -Type: CRCAT + -Asset ID: 262a2c2cbb09414652006c4da139a186b3a110bb57cd5d76b6785e4811f1c77c + -Wallet ID: 5 +``` + +
+ +--- + +### `secure_the_bag` + +Functionality: Create a tree of coins from a .csv file containing puzzlehash:amount pairs. Useful for setting up CAT airdrops. + +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) | +| -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 | + +
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 +``` + +The response will be a list of coins created in the tree. The command's progress will also be displayed. The last two lines of the output will be the root puzzle hash and address of the tree: + +``` +... +Secure the bag root puzzle hash: 17060adf6856d2904c4fe90c9690b710cf758aee5968718e2fbfd12f7b9d817f +Secure the bag root address: txch19k6cl5syzvxgkgulr7m49v2r57yh0aanm23hrffgd89j4nj3ywhqxadyqr +``` + +
+ +--- + +### `unwind_the_bag` + +Functionality: Given a coin tree, airdrop CATs to a set of pre-committed puzzle hashes obtained from a .csv file. Requires a coin tree obtained as a result of running the `secure_the_bag` command. + +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 + +```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 +``` + +This example will airdrop the appropriate number of coins to the given puzzle hash. You will need to confirm each coin as it is dropped. + +
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 new file mode 100644 index 00000000000..ebf02384665 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/clawback-cli.md @@ -0,0 +1,461 @@ +--- +title: Clawback +slug: /reference-client/cli-reference/clawback-cli +--- + +## Intro + +This page includes a comprehensive list of Chia's Command Line Interface commands for using the clawback primitive. + +:::warning + +These commands are only relevant for the clawback primitive, which is located in the [chia-clawback-primitive](https://github.com/Chia-Network/chia-clawback-primitive) repository. + +In order to view the commands that are built into the CLI for Chia's reference wallet, see the following `wallet` commands: + +- [clawback](/reference-client/cli-reference/wallet-cli#clawback) +- [get_transactions](/reference-client/cli-reference/wallet-cli#get_transactions) +- [send](/reference-client/cli-reference/wallet-cli#send-1) + +::: + +For more info, see the following: + +- [Clawback primitive guide](/guides/clawback-primitive-guide) +- [Youtube video explaining clawback](https://www.youtube.com/watch?v=_pC38ulU2js) +- [Clawback user guide](/guides/clawback-user-guide) + +## Reference + +## `clawback` + +Functionality: Get info about the `clawback` command + +Usage: `clawback [OPTIONS] COMMAND [ARGS]` + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------- | +| | --version | None | False | Show the version and exit | +| -h | --help | None | False | Show a help message and exit | + +Commands: + +| Name | Description | +| :----- | :-------------------------------------------------- | +| claim | Claim a clawback coin after the timelock has passed | +| claw | Clawback an unclaimed coin | +| create | Send xch to a clawback coin | +| show | Show details of all clawback coins | + +--- + +### `claim` + +Functionality: Claim a clawback coin after the timelock has passed + +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 | +| -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 | + +:::info + +In most cases, if the output of the `clawback show` command contains `Time left: 0 seconds`, this indicates that the Recipient can proceed with the `claim` call. + +However, there is a small window of time where the timer has expired, but a block still hasn't been farmed with a timestamp after the expiry. If the Recipient attempts to make the `claim` call during this window, they will receive the following error: + +``` +You are trying to claim the coin too early +``` + +In this case, the Recipient needs to wait for one more block to be farmed before proceeding with the `claim` call. As a reminder, a new block is farmed every 18.75 seconds, on average. + +::: + +
Example + +First, the Sender creates a new clawback coin with a 60-second timelock: + +```bash +clawback create -t txch1czxl4c42kwem8jllm4xp78jt7t0j0pu9uh9xw5jddegcu703xnpsqaaxxx -a 0.1 -l 60 -m 0.000275 +``` + +Result: + +```bash +Created Coin with ID: ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +Coin { parent_coin_info: f5e408a15299df27a00d0403ea50ed29a06f87a31b638cff1b63ef3e6060b45a, puzzle_hash: 2e91566d9549cb909109d147c79b457d15ced2d8a24dea5a125b1e5c05cdd1ec, amount: 100000000000 } +``` + +The Sender can run the `clawback show` command to show the details of each of their clawback coins: + +```bash +clawback show +``` + +Result: + +```bash +Updating coin records... + + +Coin ID: ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 60 seconds +Time left: 23 seconds +``` + +The timelock expires when the `Time left:` value reaches `0 seconds`: + +```bash +clawback show +``` + +Result: + +```bash +Updating coin records... + + +Coin ID: ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 60 seconds +Time left: 0 seconds +``` + +For your reference, the Recipient wallet currently has a balance of 0 XCH: + +```bash +chia wallet show -f 1231588123 +``` + +Result: + +```bash +Wallet height: 2405060 +Sync status: Synced +Balances, fingerprint: 1231588123 + +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 +``` + +The Recipient (or anyone else) can view the status of the clawback coin if they know the coin ID: + +```bash +clawback show -c ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +``` + +Result: + +```bash +Updating coin records... + + +Coin ID: ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 60 seconds +Time left: 0 seconds +``` + +The value of `Time left:` is `0 seconds`, which indicates that the Recipient can now run the `clawback claim` command to claim the coin: + +```bash +clawback claim -c ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +``` + +Result: + +```bash +Submitted spend to claim coin: ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +``` + +While the `claim` transaction is being processed, it will show in the `Pending Total Balance:` of the Recipient's wallet: + +```bash +chia wallet show -f 1231588123 +``` + +Result: + +```bash +Wallet height: 2405100 +Sync status: Synced +Balances, fingerprint: 1231588123 + +Chia Wallet: + -Total Balance: 0.0 txch (0 mojo) + -Pending Total Balance: 0.1 txch (100000000000 mojo) + -Spendable: 0.0 txch (0 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 +``` + +Finally, the Recipient can view the additional balance in their wallet: + +```bash +chia wallet show -f 1231588123 +``` + +Result: + +``` +Wallet height: 2405465 +Sync status: Synced +Balances, fingerprint: 1231588123 + +Chia Wallet: + -Total Balance: 0.1 txch (100000000000 mojo) + -Pending Total Balance: 0.1 txch (100000000000 mojo) + -Spendable: 0.1 txch (100000000000 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 +``` + +The spend is now complete and can no longer be clawed back. The funds are stored as a standard Chia coin in the Recipient's wallet. + +
+ +--- + +### `claw` + +Functionality: + +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 | +| -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 | + +
Example + +Let's say the following clawback coin exists: + +```bash +clawback show +``` + +Result: + +```bash +Updating coin records... + + +Coin ID: 29056b320b380c0fc4834578ca30318ae9c1d1cddbe39a91197870c4dc474532 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 600 seconds +Time left: 518 seconds +``` + +The same public/private key pair that created this coin must be used to claw it back. + +The Sender will use the clawback claw command, passing in the ID of the coin to claw back: + +```bash +clawback claw -c 29056b320b380c0fc4834578ca30318ae9c1d1cddbe39a91197870c4dc474532 -m 0.000275 +``` + +As a result, the clawback coin will be spent, and a new coin will be created in the Sender's wallet: + +```bash +Submitted spend to claw back coin: 29056b320b380c0fc4834578ca30318ae9c1d1cddbe39a91197870c4dc474532 +``` + +To show the status of the clawback, run the `clawback show` command once again: + +```bash +clawback show +``` + +Result: + +```bash +Updating coin records... +No coins found +``` + +
+ +--- + +### `create` + +Functionality: Make a transaction to create a clawback coin + +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 | +| -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 | + +
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. + +For your reference, here is the Sender wallet's info: + +```bash +chia wallet show -f 3807629793 +``` + +Result: + +```bash +Wallet height: 2391281 +Sync status: Synced +Balances, fingerprint: 3807629793 + +Chia Wallet: + -Total Balance: 8.0 txch (8000000000000 mojo) + -Pending Total Balance: 8.0 txch (8000000000000 mojo) + -Spendable: 8.0 txch (8000000000000 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 +``` + +To create the clawback coin from the Sender's wallet, run the `clawback create` command. The `-t` (Recipient's address) and `-a` (amount in XCH/TXCH) flags are required. By default, the clawback coin will be locked for two weeks. For this example, we will override the default by using the `-t` flag to specify a timelock period of 600 seconds. We will also use the `-m` flag to include a fee of 0.000275 TXCH. + +:::info + +The testnet is constantly being dusted (filled with small transactions) in order to simulate a busy network. Because of this you are always recommended to include a fee with testnet transactions. The 275-million mojo fee from this demo should be sufficient to push your transactions through in the next transaction block. + +If you are running on mainnet, a fee of 275 million mojos is likely higher than the recommended amount. The reference wallet GUI will suggest an appropriate fee to be included with all transactions. + +::: + +The Sender will run the following command in this example (these are only example settings; replace the values as needed): + +```bash +clawback create -t txch1czxl4c42kwem8jllm4xp78jt7t0j0pu9uh9xw5jddegcu703xnpsqaaxxx -a 0.1 -l 600 -m 0.000275 +``` + +Result: + +```bash +Created Coin with ID: 29056b320b380c0fc4834578ca30318ae9c1d1cddbe39a91197870c4dc474532 +Coin { parent_coin_info: dcedd4d573679302ee3f2a54fb51c437b8156e8cd5b1c3c08d25cadf83292c3d, puzzle_hash: 13cb7ce11775a5b42754fb382eb94c846e4be677e6d55bf665b23c075a54e930, amount: 100000000000 } +``` + +As a result of running this command, a new clawback coin has been created on the blockchain, the details of which are shown above. To view this coin, along with other clawback coins created by this wallet, run the `clawback show` command: + +```bash +clawback show +``` + +The basic details of the clawback coin are given: + +```bash +clawback show +Updating coin records... + + +Coin ID: 29056b320b380c0fc4834578ca30318ae9c1d1cddbe39a91197870c4dc474532 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 600 seconds +Time left: 518 seconds +``` + +
+ +--- + +### `show` + +Functionality: Get details for all clawback coins + +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 | +| -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 | + +
Example 1 + +The Sender can show a Clawback coin without passing in the Coin ID: + +```bash +clawback show +``` + +The basic details of the clawback coin are given: + +```bash +clawback show +Updating coin records... + + +Coin ID: 29056b320b380c0fc4834578ca30318ae9c1d1cddbe39a91197870c4dc474532 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 600 seconds +Time left: 518 seconds +``` + +
+ +
Example 2 + +Anyone other than the sender needs to pass in the Coin ID in order to show a Clawback coin: + +```bash +clawback show -c ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +``` + +Result: + +```bash +Updating coin records... + + +Coin ID: ef4b69e65e99261d6e30c8d2d331a8ed84995f3452b95aaa944f76a0f9af74c5 +Amount: 0.1 XCH (100000000000 mojos) +Timelock: 60 seconds +Time left: 0 seconds +``` + +
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 new file mode 100644 index 00000000000..fa94fcceac2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/cli.md @@ -0,0 +1,429 @@ +--- +sidebar_label: Overview +title: CLI Overview +slug: /reference-client/cli-reference/cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# CLI Commands Reference + +This page should provide additional high-level documentation and explanation beyond just `chia -h`. + +This is not meant to be comprehensive, because often the `-h` (help) text is clear enough. We recommend fully investigating with the `-h` switch before looking elsewhere. + +To better understand what a command's options are, append `-h` at the end to see options and explanations. + +Some examples: + +- `chia -h` +- `chia plots -h` +- `chia plots check -h` +- `chia plotters madmax -h` +- `chia start -h` + +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. + +# Locate the `chia` binary executable + +## Mac + +If you installed `Chia.app` in your `/Applications` directory, you can find the `chia` binary at `/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/chia`. + +Do a sanity check in `Terminal.app` with the following command: + +```bash +/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/chia -h +``` + +You can use that if you augment your `PATH` with the following command: + +```bash +PATH=/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon:$PATH +``` + +Then, running the `chia -h` command should work. + +## Windows + +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 + +```bash +~\AppData\Local\Programs\Chia\resources\app.asar.unpacked\daemon\chia.exe +``` + +If installed for all users it can be found at + +```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) + +Command: `chia init` + +First, `init` checks for old versions of Chia installed in your ~/.chia directory. + +If so, `init` migrates these old files to the new version: + +- config (including old SSL files) +- db +- wallet +- Using config.yaml, updates wallet keys and ensures coinbase rewards go to the right wallet puzzlehash. + +If no old version exists, `init`: + +- Creates a default Chia configuration +- Initializes a new SSL key and cert (for secure communication with the GUI) + +# start + +Command: `chia start {service}` + +- 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} + +**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 | + +# 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 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 + +Using the CLI, you can perform the same operations as with the GUI. There is a new command, called `chia plotnft`. Type `chia plotnft -h` to see all the available sub-commands: + +``` +» chia plotnft -h +Usage: chia plotnft [OPTIONS] COMMAND [ARGS]... + +Options: + -h, --help Show this message and exit. + +Commands: + claim Claim rewards from a plot NFT + create Create a plot NFT + get_login_link Create a login link for a pool. To get the launcher id, use + plotnft show. + + inspect Get Detailed plotnft information as JSON + join Join a plot NFT to a Pool + leave Leave a pool and return to self-farming + show Show plotnft information +``` + +To create a Plot NFT, use `chia plotnft create -u https://poolnamehere.com`, entering the URL of the pool you want to use. To create a plot NFT in self-farming mode, do `chia plotnft create -s local`. +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) + +Command: `chia plots check -n [num checks] -l -g [substring]` + +First, this looks in all plot directories from your config.yaml. You can check those directories with `chia plots show`. This command will check whether plots are valid given the plot's associated keys and your machine's stored Chia keys, as well as test the plot with challenges to identify found plots vs. expected number of plots. + +`-g` check only plots with directory or file name containing case-sensitive [substring]. +**If `-g` isn't specified all plots in every plot directory in your config.yaml will be checked.** + +Examples for using `-g` + +- Check plots within a long directory name like `/mnt/chia/DriveA` can use `chia plots check -g DriveA` +- Check only k33 plots can use `chia plots check -g k33` +- Check plots created on October 31, 2020 can use `chia plots check -g 2020-10-31` + +`-l` allows you to find duplicate plots by ID. It checks all plot directories listed in config.yaml and lists out any plot filenames with the same filename ending; `*-[64 char plot ID].plot`. You should use `-l -n 0` if you only want to check for duplicates. + +`-n` represents the number of challenges given. If you don't include an `-n` integer, the default is 30. For instance, if `-n` is 30, then 30 challenges will be given to each plot. The challenges count from 5 (minimum) to `-n`, and are not random. + +Each plot will take each challenge and: + +- Get the quality for the challenge (Is there a proof of space? You should expect 1 proof per challenge, but there may be 0 or more than 1.) +- Get the full proof(s) for the challenge if a proof was present +- Validate that the # of full proofs matches the # of expected quality proofs. + +Finally, you'll see a report the final true proofs vs. expected proofs. + +Therefore, if `-n` is 20, you would expect 20 proofs, but your plot may have more or fewer. + +Running the command with `-n 10` or `-n 20` is good for a very minor check, but won't actually give you much information about if the plots are actually high-quality or not. + +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) + +**What does the ratio of full proofs vs expected proofs mean?** + +- If the ratio is >1, your plot was relatively lucky for this run of challenges. +- If the ratio is \<1, your plot was relatively unlucky. + - This shouldn't really concern you unless your ratio is \<0.70 # If so, do a more thorough `chia plots check` by increasing your `-n` + +The plots check challenge is a static challenge. For example if you run a plots check 20 times, with 30 tries against the same file, it will produce the same result every time. So while you may see a plot ratio \<< 1 for a plot check with `x` number of tries, it does not mean that the plot itself is worthless. It just means that given these static challenges, the plot is producing however many proofs. As the number of tries (`-n`) increases, we would expect the ratio to not be \<< 1. Since Mainnet is live, and given that the blockchain has new challenges with every signage point - just because a plot is having a bad time with one specific challenge, does not mean it has the same results versus another challenge. "Number of plots" and "k-size" are much more influential factors at winning blocks than "proofs produced per challenge". + +**In theory**, a plot with a ratio >> 1 would be more likely to win challenges on the blockchain. Likewise, a plot with a ratio \<< 1 would be less likely to win. However, in practice, this isn't actually going to be noticeable. Therefore, don't worry if your plot check ratios are less than 1, unless they're _significantly_ less than 1 for _many_ `-n`. + +# db + +## [upgrade](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/db.py) + +Command: `chia db upgrade [add flags and parameters]` + +**Flags** + +`--input [PATH]`: (optional) Specify a database input file. Must be a v1 database. + +`--output [PATH]`: (optional) Specify a database output file. Can be any name, but must not already exist. + +`--no-update-config` Don't update the config file to point to your new database. When specifying a custom output file, the config will not be updated regardless. + +**Database upgrade notes** + +- This will upgrade your database from version 1 to version 2, which is around 45% smaller and slightly faster. +- The upgrade could take several hours to complete. Use at your own leisure. +- You do not need to stop your Chia node while performing the upgrade. +- The new database file will be written to the same folder as the original. The current size requirement (2nd quarter 2022) is around 55 GB. _Note that the database is always growing, so the size requirement for the v2 database will have gone up by the time you are reading this — plan accordingly_. After the version 2 file has been created, you can stop Chia and move/delete your version 1 file, which will free up enough space to move your version 2 file to the original folder. Finally, update the references in config.yaml to point to your version 2 file. +- After the upgrade has completed, run `chia start farmer -r`. This will restart your farmer, and begin using your new database. Note that it will have the same peak as version 1 at the time you _initiated_ the upgrade. Your node will still need to run a short sync to fetch the remaining blocks that had gotten added while the upgrade was being performed. +- For more information on the new database version, see our [FAQ](https://docs.chia.net/chia-blockchain/resources/faq/#what-is-the-new-database). + +## [backup](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/db.py) + +Command: `chia db backup [add flags and parameters]` + +**Flags** + +`--backup_file [PATH]`: (optional) Specifies the backup file and location. Default will create the backup in the same directory as the database. + +`--no_indexes`: (optional) Create backup without indexes. + +**Database backup notes** + +- This will vacuum (compress) and backup your database and may take several hours to complete. Use at your own leisure. Use at your own leisure. +- You do not need to stop your Chia node while performing the upgrade. +- The new database file will be written to the same folder as the original with "vacuumed\_" prepended to the name. +- To use the backup database: Close the chia client, remove/delete the main database, rename the backup database to remove "vacuumed\_", and restart the chia client. Note the initial start will take extra time as the client verifies the backup db file. Note the initial start will take extra time as the client verifies the backup db file. + +## [validate](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/cmds/db.py) + +Command: `chia db validate [add flags and parameters]` + +**Flags** + +`--db [PATH]`: (optional) Specifies which database file to validate. Default will use the default database and path. + +`--validate-blocks`: (optional) Validate consistency of properties of the encoded blocks and block records. Note this will increase the validation time. + +**Database validate notes** + +- This will validate your database and may take several hours to complete. Use at your own leisure. Use at your own leisure. +- You do not need to stop your Chia node while performing the upgrade. +- This will start by processing the latest block and traverse to the first block. + +# keys + +## [derive](https://github.com/Chia-Network/chia-blockchain/blob/2f2593661c842b70a0e848752f12777f2df3ed18/chia/cmds/keys.py#L139) + +Command: `chia keys derive [OPTIONS] COMMAND [ARGS]` + +**Flags** + +`-f`, `--fingerprint` `[INTEGER]`: The fingerprint of the key you want to use. + +`--mnemonic-seed-filename` `[TEXT]`: The filename containing the mnemonic seed of the master key to derive from. + +**Notes on deriving keys** + +- This command will display or search for derived keys or wallet-addresses. +- This command requires either a fingerprint or a mnemonic seed file. +- 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) + +Command: `chia keys derive child-key [OPTIONS]` + +**Flags** + +`-t`, `--type` `[farmer|pool|wallet|local|backup|singleton|pool_auth]`: Type of child key to derive. + +`-p`, `--derive-from-hd-path` `[TEXT]`: Derive child keys rooted from a specific HD path. Indices ending in an 'n' indicate that non-observer derivation should used at that index.
+Example HD path: m/12381n/8444n/2/ + +`-i`, `--index` `[INTEGER]`: Index of the first child key to derive. (Index 0 is the first child key.) + +`-n`, `--count` `[INTEGER]`: Number of child keys to derive, starting at index. + +`-d`, `--non-observer-derivation`: Derive keys using non-observer derivation. [default: False] + +`-s`, `--show-private-keys`: Display derived private keys. [default: False] + +`--show-hd-path`: Show the HD path of the derived wallet addresses. [default: False] + +**Examples** + +- Show the first singleton pubkey: `chia keys derive -f child-key -t singleton` + +- Show a pair of public and private keys derived from a mixed observer/non-observer HD path using an imported key's mnemonic seed: `chia keys derive --mnemonic-seed-filename <(chia keys generate_and_print | sed -n 2p) child-key --derive-from-hd-path 'm/12381n/8444n/2/' --show-private-keys --show-hd-path` + +- 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) + +Command: `chia keys derive search [OPTIONS] [SEARCH_TERMS]...` + +**Flags** + +`-l`, `--limit` `[INTEGER]`: Limit the number of derivations to search against. [default: 100] + +`-d`, `--non-observer-derivation`: Search will be performed against keys derived using non-observer derivation. [default: False] + +`-P`, `--show-progress`: Show search progress. [default: False] + +`-t`, `--search-type` `[public_key|private_key|address|all]`: Limit the search to include just the specified types. [default: address, public_key] + +`-p`, `--derive-from-hd-path` `[TEXT]`: Search for items derived from a specific HD path. Indices ending in an 'n' indicate that non-observer derivation should used at that index. Example HD path: m/12381n/8444n/2/ + +**Examples** + +- 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) + +Command: `chia keys derive wallet-address [OPTIONS]` + +**Flags** + +`-i`, `--index` `[INTEGER]`: Index of the first wallet address to derive. Index 0 is the first wallet address. + +`-n`, `--count` `[INTEGER]`: Number of wallet addresses to derive, starting at index. + +`-x`, `--prefix` `[TEXT]`: Address prefix (xch for mainnet, txch for testnet). + +`-d`, `--non-observer-derivation`: Derive wallet addresses using non-observer derivation. [default: False] + +`--show-hd-path`: Show the HD path of the derived wallet addresses. If non-observer-derivation is specified, path indices will have an 'n' suffix. [default: False] + +**Examples** + +- Show first 10 wallet addresses: + + `chia keys derive -f wallet-address -i 0 -n 10 --show-hd-path` + +--- + +# DID + +See our [official DID reference](/reference-client/cli-reference/did-cli). + +--- + +# NFT + +See our [official NFT reference](/reference-client/cli-reference/nft-cli). + +--- + +# Other commands (not all are fully documented) + +```sh +$ chia + +Options: + --root-path PATH Config file root + [default: ~\.chia\mainnet] + --keys-root-path PATH Keyring file root + [default: ~\.chia_keys] + --passphrase-file FILENAME File or descriptor to read the keyring + passphrase from + -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 + +``` + +To see what you can do with each of these commands, use the help flag -h. For example, `chia show -h`. + +To check your full node status, do `chia show -s` and you'll see something like this. To figure how close +you are look at your height. Once fully synced it'll say `Full Node Synced` at the top. + +``` +Current Blockchain Status: Full Node Synced + +Peak: Hash: 34554a10aff6b52545623e18667c9487758fa93a3b2345974da0d263939189dc + Time: Tue Mar 23 2021 20:54:46 JST Height: 19882 + +Estimated network space: 136.225 PiB +Current difficulty: 9 +Current VDF sub_slot_iters: 112197632 +Total iterations since the start of the blockchain: 63291534050 + + Height: | Hash: + 19882 | 34554a10aff6b52545623e18667c9487758fa93a3b2345974da0d263939189dc + 19881 | f53c052cd7ac58539ff5c35cb9d515bc521308a49cec7566b23dba84f76009d8 + 19880 | 924d825a7fdbfd61e4582efbbe1d977bb554b368eea58c349a71e688e43fcc49 + +``` + +You can add and remove directories for your plots with `chia plots add -d 'your_dir'` or `chia plots remove -d 'your_dir'`, help can be found for respective add/remove with `chia plots add/remove -h` + +## Checking Logs and Status + +You can check contents of your wallet with: `chia wallet`, and status of your farmer with `chia farm summary`. + +Check harvester and farmer logs: `grep ~/.chia/mainnet/log/debug.log -e harvester` + +Sample result: + +``` +17:08:03.191 harvester harvester_server : INFO <- harvester_handshake from peer 214b269a425b8223cb50fbd458dab056599348e255f07a018c13ea9efb509ee5 127.0.0.1 +17:08:03.194 farmer farmer_server : INFO -> harvester_handshake to peer 127.0.0.1 65f3fa0b0407a07da8ccf04dfa0f64c28f714726312aa051d3a8529390db4d7a +17:08:03.218 harvester src.plotting.plot_tools : INFO Searching directories ['/home/user/slab1/plots'] +17:08:03.227 harvester src.plotting.plot_tools : INFO Found plot /home/user/slab1/plots/plot-k32-2021-01-11-17-26-bf2363828e469a3417b89eb98cfa9d694809e1ce8bef0ffd1d12853d4227aa0a.plot of size 32 +17:08:03.227 harvester src.plotting.plot_tools : INFO Loaded a total of 1 plots of size 0.09895819725716137 TiB +``` + +Maybe follow logs: `tail -F ~/.chia/mainnet/log/debug.log`. Chia is nice enough to rotate logs for you. 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 new file mode 100644 index 00000000000..984e172061e --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/custody-tool-cli.md @@ -0,0 +1,913 @@ +--- +title: Custody Tool +slug: /reference-client/cli-reference/custody-tool-cli +--- + +### Intro + +Chia's internal custody tool enables multisig, clawback, and rekeying. These features allow you to store assets on Chia's blockchain in one of the most secure setups ever devised. + +This page includes a comprehensive list of Chia's Command Line Interface commands for using the custody tool. + +For more info, see the following: + +- [Basic description](/guides/custody-tool-description) of how the custody tool works +- [Flow chart](/img/chia-custody-tool.png) to visualize how the custody tool works +- [User guide](/guides/custody-tool-user-guide) to help you get up and running + +### Reference + +### `audit` + +Functionality: Export a history of the singleton to a CSV + +Usage: `cic audit [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 | --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 + +Request: + +```bash +cic audit -db './sync (b43314).sqlite' +``` + +Response: + +``` +[ + { + "time": 1665430389, + "action": "HANDLE_PAYMENT", + "params": { + "out_amount": 1000000000, + "recipient_ph": "3377e81d20ad9a3028ffe7e77360c03df48c412f2525aac58035738888adb83d", + "in_amount": 1000000000000, + "completed": true, + "spent_at_height": 1645707 + } + }, + { + "time": 1665449184, + "action": "HANDLE_PAYMENT", + "params": { + "out_amount": 1000000000, + "recipient_ph": "3377e81d20ad9a3028ffe7e77360c03df48c412f2525aac58035738888adb83d", + "completed": false, + "spent_at_height": 1645981, + "clawback_pubkey": "bls12381jjh08qx6hvucdrkgn8mrkafqrrp4j6sm4azndk0wz3precaa0teeyeamwtltxv435tsmx2tyayrwg8jy3x4" + } + }, + { + "time": 1665980779, + "action": "START_REKEY", + "params": { + "from_root": "74905b06591f9d2e615d313d18cfbcbeffcaabe2e70ccdeafda783bacaae52ef", + "to_root": "90ba2a1ce4ca7f094aa1d2c64b7281b18a4e211e704b43ed45bf39f61cdd67d2", + "completed": true, + "spent_at_height": 1674754 + } + }, + { + "time": 1665986686, + "action": "START_REKEY", + "params": { + "from_root": "90ba2a1ce4ca7f094aa1d2c64b7281b18a4e211e704b43ed45bf39f61cdd67d2", + "to_root": "c330a8f9ed6a3fd50953f0b6365019246ea08d854ddbed0da3149dd4006abf1f", + "completed": true, + "spent_at_height": 1674940 + } + } +] +``` + +
+ +--- + +### `clawback` + +Functionality: Clawback a withdrawal or rekey attempt (will be prompted which one) + +Usage: `cic clawback [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 | +| -h | --help | None | False | Show a help message and exit | + +
Example + +Request: + +```bash +cic clawback -f clawback.unsigned -pks "1.pk,2.pk" +``` + +Response: + +None + +
+ +--- + +### `complete` + +Functionality: Complete a withdrawal or rekey attempt (will be prompted which one) + +Usage: `cic complete [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 | +| -h | --help | None | False | Show a help message and exit | + +
Example -- complete a withdrawal + +Request: + +```bash +cic complete -f complete.signed +``` + +Response: + +``` +Which actions would you like to complete?: + +1) PAYMENT to xch1xdm7s8fq4kdrq28lulnhxcxq8h6gcsf0y5j643vqx4ec3z9dhq7sqxsa9j of amount 1000000000 +(Enter index of action to complete): 1 +Successfully wrote spend to complete.signed +``` + +
+ +--- + +### `derive_root` + +Functionality: Take an existing configuration and pubkey set to derive a puzzle root + +Usage: `cic derive_root [OPTIONS]` + +Options: + +| 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 | + +
Example -- set up a 2-of-3 root config + +Request: + +```bash +cic derive_root -pks "1.pk,2.pk,3.pk" -m 2 -n 3 +``` + +Response: + +``` +Custody rules successfully added to configuration +``` + +
+ +--- + +### `examine_spend` + +Functionality: Examine an unsigned spend bundle to see the details before you sign it + +Usage: `cic examine_spend [OPTIONS] SPEND_FILE` + +Options: + +| 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 | + +`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 + +Request: + +```bash +cic examine_spend ./rekey.unsigned +``` + +Response: + +``` +Type: Rekey +From: 74905b06591f9d2e615d313d18cfbcbeffcaabe2e70ccdeafda783bacaae52ef +To: 90ba2a1ce4ca7f094aa1d2c64b7281b18a4e211e704b43ed45bf39f61cdd67d2 +Slow factor: 1 +Spenders: bls12381jjh08qx6hvucdrkgn8mrkafqrrp4j6sm4azndk0wz3precaa0teeyeamwtltxv435tsmx2tyayrwg8jy3x4 +Press Enter to exit +``` + +
+ +--- + +### `export_config` + +Functionality: Export a copy of the current DB's config + +Usage: `cic export_config [OPTIONS]` + +Options: + +| 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 | + +
Example -- export the config to export.bin + +Request: + +```bash +cic export_config -p -f export.bin +``` + +Response: + +``` +Config successfully exported to export.bin +``` + +
+ +--- + +### `increase_security_level` + +Functionality: Initiate an increase of the number of keys required for withdrawal + +Usage: `cic increase_security_level [OPTIONS]` + +Options: + +| 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 | + +
Example -- move to a 4-of-5 config + +Request: + +```bash +cic increase_security_level -db './sync (b43314).sqlite' -pks "1_new.pk,2_new.pk,3_new.pk,4_new.pk" -f lock.unsigned +``` + +Response: + +``` +Successfully wrote spend to lock.unsigned +``` + +
+ +--- + +### `init` + +Functionality: Create a configuration file for the prefarm. The arguments from this command will be committed to **forever**. + +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 | + +
Example + +Request: + +```bash +cic init -d . -wt 600 -pc 1200 -rt 300 -rc 600 -sp 900 +``` + +Response: + +A binary file called `Configuration (needs derivation).txt` will be created in the `-d` location. + +
+ +--- + +### `launch_singleton` + +Functionality: Use 1 mojo to launch the singleton that will control the funds + +Note: This is one of the two commands (along with push_tx) that interacts directly with the blockchain + +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 | +| -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 | + +
Example + +Request: + +```bash +cic launch_singleton --fee 10000000 +``` + +Response: + +``` +Singleton successfully launched +``` + +
+ +--- + +### `p2_address` + +Functionality: Print the address to pay to the singleton + +Usage: `cic p2_address [OPTIONS]` + +Options: + +| 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 | + +
Example + +Request: + +```bash +cic p2_address --prefix txch +``` + +Response: + +An address beginning with `txch` will be output + +
+ +--- + +### `payment` + +Functionality: Absorb/Withdraw money into/from the singleton + +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] | +| -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 | + +
Example + +Request: + +```bash +cic payment -f withdrawal.unsigned -pks "1.pk,2.pk" -a 1000000000 -t -ap +``` + +Response: + +``` +Successfully wrote spend to withdrawal.unsigned +``` + +
+ +--- + +### `push_tx` + +Functionality: Push a signed spend bundle to the network + +Note: This is one of the two commands (along with launch_singleton) that interacts directly with the blockchain + +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 | +| -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 | + +
Example + +Request: + +```bash +cic push_tx -b ./complete.signed -m 10000000 +``` + +Response: + +``` +{'status': 'SUCCESS', 'success': True} +``` + +
+ +--- + +### `show` + +Functionality: Show the status of the singleton, payments, and rekeys + +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 | + +
Example -- show the configuration and derivation + +Request: + +```bash +cic show -c -d +``` + +Response: + +``` +Current time: 1665072285 (10/07/2022, 00:04:45) + +Config up to date: True + +Singleton: + - launcher ID: b433146cc20ef0e3d962423ddb1c6868cd9691e099ae579ab2518d1cd983885c + - amount left: 0 + - amount to claim: 0 + +Outstanding events: + PAYMENTS: + REKEYS: + +Config: + - current root: 74905b06591f9d2e615d313d18cfbcbeffcaabe2e70ccdeafda783bacaae52ef + - withdrawal timelock: 600 seconds + - payment clawback period: 1200 seconds + - rekey cancellation period: 600 seconds + +Derivation Info: + - lock level: 2 + - max lock level: 3 + - min keys to rekey: 1 + - standard rekey timelock: 300 seconds + - slow rekey penalty: 900 seconds + - pubkeys: + - bls123813p8yljrhgskmgqeukg3x6mszh3xtqwwx35t4g6dt0mk2xecyj7elr0fhhrm8t3w7q5zhdelgjlgdspjqxvs + - bls123813uhsu0juw06z8vmtt5ncj6zcexmhtsfemvtj3jhv0vuxh9nqjdar59yh555muzrdpz2uflgzey3sgdnm8y9 + - bls1238152jm50wh89tf70mwj4ncuukqcq6jqmf7pjgznm55c5qaggrvswzccwvsjgwmy9f4cvlx2j97kmh5uc2es6h +``` + +
+ +--- + +### `start_rekey` + +Functionality: Rekey the singleton to a new set of keys/options + +Usage: `cic start_rekey [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 | +| -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 + +Request: + +```bash +cic start_rekey -f rekey.unsigned -pks "1.pk,2.pk" -new './Configuration (after rekey).txt' +``` + +Response: + +``` +Successfully wrote spend to rekey.unsigned +``` + +
+ +--- + +### `sync` + +Functionality: Sync a singleton from an existing configuration + +Usage: `cic sync [OPTIONS]` + +Options: + +| 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 | + +
Example -- sync and show the config + +Request: + +```bash +cic sync -s +``` + +Response: + +``` +Current time: 1665072029 (10/07/2022, 00:00:29) + +Config up to date: True + +Singleton: + - launcher ID: b433146cc20ef0e3d962423ddb1c6868cd9691e099ae579ab2518d1cd983885c + - amount left: 0 + - amount to claim: 0 + +Outstanding events: + PAYMENTS: + REKEYS: +``` + +
+ +--- + +### `update_config` + +Functionality: Update an outdated config in a sync DB with a new config + +Usage: `cic update_config [OPTIONS]` + +Options: + +| 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 | + +
Example -- update config after rekey + +Request: + +```bash +cic update_config -c './Configuration (after rekey).txt' +``` + +Response: + +``` +Configuration update successful +``` + +
+ +--- + +### `which_pubkeys` + +Functionality: Determine which pubkeys make up an aggregate pubkey + +Usage: `cic which_pubkeys [OPTIONS] AGGREGATE_PUBKEY` + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :------------ | :------ | :------- | :------------------------------------------------------------------ | +| -pks | --pubkeys | TEXT | True | A comma separated list of pubkey files that may be in the aggregate | +| -m | --num-pubkeys | INTEGER | False | Check only combinations of a specific number of pubkeys | +| | --no-offset | None | False | Do not try the synthetic versions of the pubkeys | +| -h | --help | None | False | Show a help message and exit | + +--- + +### HSM CLI commands and reference + +These commands are to be run from inside the Hardware Security Module or "vault". + +This is a physical/offline security solution for generating and signing keys. + +### Reference + +### `hsmgen` + +Functionality: Generate a secret exponent (private key) + +Usage: `hsmgen` + +There are no options with this command. It will simply generate and display a single secret exponent. + +
Example 1 -- display key + +The basic command displays a new secret exponent. + +Request: + +```bash +hsmgen +``` + +Response: + +``` +se12celrk5asn0f3w49dxpxe5hg6sg88ezdvp89hpgdqspwj6e03yfq9e6yw4 +``` + +
+
Example 2 -- save a key to a file + +Request: + +```bash +hsmgen > test.se +``` + +Response: + +The secret exponent is saved to test.se. + +
+ +--- + +### `hsmpk` + +Functionality: Derive a public key from a secret exponent + +Usage: `hsmgen ` + +A secret exponent (required) is the only argument allowed. + +
Example 1 + +Derive and display a public key from a file containing a secret exponent: + +```bash +hsmpk $(cat test.se) +``` + +Response: + +``` +bls123813eh73c2cttvqytzjfnjdhnme7ah8mzsc9yzsf2y40mvhfa9rt5nha20jw50ld8h98w9u2wc0wxxl6gttqcr +``` + +
+ +
Example 2 + +Calculate a public key from a file containing a secret exponent and save it to another file: + +```bash +hsmpk $(cat test.se) > test.pk +``` + +Response: + +The public key is saved to test.pk. + +
+ +--- + +### `hsms` + +Functionality: Manage private keys and process signing requests + +Usage: `hsms0 [-h] [-c CREATE_PRIVATE_KEY] [-g GPG_ARGUMENT] path-to-private-keys` + +Positional arguments: + +`path-to-private-keys`: A file containing bech32m-encoded secret exponents. If file name ends with .gpg, "gpg -d" will be invoked automatically. File is read one line at a time. + +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) | +| | --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 | + +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 + +This example will block until the scan is complete. + +Run the basic command and wait for the QR code to be scanned: + +```bash +hsms ./1.se +``` + +Response: + +``` +waiting for qrint-encoded signing requests +``` + +
+ +
Example 2 + +This example will not block. + +Pipe the unsigned spend bundle through hsms0, which will output a signature encoded in base-64 (it might instead be in base-10), along with a QR code (Linux only): +Mock run by just piping the output of 1.se: + +```bash +cat ./initial_absorb.unsigned | hsms -y --nochunks ./1.se +``` + +Response: + +``` +waiting for qrint-encoded signing requests +> 5449140665451649053284096202714691505589365577374007143978191719238477924138728005883662232162434514948867447203715240045617130770165403282022693823446338843409368762077191699285534081208295847253913527216165034379061118404584995264580179968 +``` + +
+ +--- + +### `hsmmerge` + +Functionality: Create a signed `Spend Bundle` from `UnsignedSpends` and signatures. + +Usage: `hsmmerge [-h] path-to-unsigned-spend-as-hex hex-encoded-signature [hex-encoded-signature ...]` + +Positional arguments: + +path-to-unsigned-spend-as-hex: A file containing hex-encoded `UnsignedSpends` +hex-encoded-signature: A hex-encoded signature + +Optional arguments: +-h, --help show a help message and exit + +Note that `hex-encoded-signature` is a list. To add more signatures, append more arguments. + +
Example + +Create a signed spend bundle from two signatures and output to a text file: + +```bash +hsmmerge ./initial_absorb.unsigned ./initial_absorb.sig ./initial_absorb_2.sig > initial_absorb.signed +``` + +Response: + +The signed spend bundle is saved to initial_absorb.signed. + +
+ +--- + +### `hsm_dump_sb` + +Functionality: Dump information about `Spend Bundle` + +Usage: `hsm_dump_sb [-h] hex-encoded-spend-bundle-or-file` + +Positional arguments: + +hex-encoded-spend-bundle-or-file: A hex-encoded `Spend Bundle`. Can be a file containing the spend bundle. + +Optional arguments: + +-h, --help show a help message and exit + +
Example + +Request: + +```bash +hsm_dump_sb ./initial_absorb.signed +``` + +Response: + +The signed spend bundle is output. + +
+ +--- + +### `hsm_test_spend` + +Functionality: Generate a `UnsignedSpend` test as a proof-of-concept + +Usage: `hsm_test_spend [-h] path-to-public-key [path-to-public-key ...]` + +Positional arguments: + +path-to-public-key: A file containing a single bech32m-encoded public key + +Optional arguments: + +-h, --help show a help message and exit + +
Example + +Request: + +```bash +hsm_test_spend test.pk +``` + +Response: + +An unsigned spend bundle is output. + +
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 new file mode 100644 index 00000000000..c18d8d05e43 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/dao-cli.md @@ -0,0 +1,1460 @@ +--- +sidebar_label: DAOs +title: DAO CLI +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. + +:::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!** + +Prior to using the DAO alpha primitive, be sure to read the [list of known issues](/dao-known-issues). + +::: + +## Reference + +## `add` + +Functionality: Create a wallet for an existing DAO + +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 | + +
Example + +Start with a wallet with some XCH or TXCH: + +```bash +chia wallet show +``` + +Response: + +``` +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 +``` + +Next, join a DAO by passing in its Treasury ID: + +```bash +chia dao add -n "Test DAO Wallet" -t dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 +``` + +At first, the response will indicate that the transaction is in process (you will need to choose your wallet fingerprint if more than one exists): + +```bash +Adding wallet for DAO: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 +This may take awhile. +``` + +Eventually, you will receive a message indicating the Treasury ID and the three relevant wallets that have been created: + +```bash +Successfully created DAO Wallet +DAO Treasury ID: 0xdfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 +DAO Wallet ID: 2 +CAT Wallet ID: 3 +DAOCAT Wallet ID: 4 +``` + +At this point, you can show each of these wallets by running `chia wallet show`: + +```bash +chia wallet show +``` + +```bash +Wallet height: 3181174 +Sync status: Synced +Balances, fingerprint: 3046374920 + +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 + +Test DAO Wallet: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DAO + -Treasury ID: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 + -Wallet ID: 2 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 3 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 +``` + +From here, you can add funds, create proposals, vote on proposals, etc. + +
+ +--- + +## `add_funds` + +Functionality: Send funds to a DAO treasury + +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 + +Start by showing the current wallet status: + +```bash +chia wallet show +``` + +Response: + +```bash +Chia Wallet: + -Total Balance: 2.999987147234 txch (2999987147234 mojo) + -Pending Total Balance: 2.999987147234 txch (2999987147234 mojo) + -Spendable: 2.999987147234 txch (2999987147234 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +Profile 1: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DAO + -Treasury ID: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 + -Wallet ID: 3 + +CAT 07e809aa0324acaf...: + -Total Balance: 100.0 (100000 mojo) + -Pending Total Balance: 100.0 (100000 mojo) + -Spendable: 100.0 (100000 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 5 +``` + +Add funds from the main Chia Wallet (ID `1`) to the DAO Wallet (ID `3`). + +Note that the `Wallet IDs` shown here are only examples; yours may differ. + +```bash +chia dao add_funds -i 2 --funding-wallet-id 1 -a 2 -m 0.00001 +``` + +Response: + +```bash +Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] +Run 'chia wallet get_transaction -f 3261611401 -tx 0x180ea0da4b8fbe4e696480ff5fa819fbcc8ae069362127c73cf09acecbd378c2' to get status +``` + +After a few minutes, verify that the transaction was processed successfully: + +```bash +chia wallet get_transaction -f 3261611401 -tx 0x180ea0da4b8fbe4e696480ff5fa819fbcc8ae069362127c73cf09acecbd378c2 +``` + +Response: + +```bash +Transaction 180ea0da4b8fbe4e696480ff5fa819fbcc8ae069362127c73cf09acecbd378c2 +Status: Confirmed +Amount sent: 2 TXCH +To address: txch179tr6euaunzt425l6kyrzgrzyzv572w7820ptan47k3w77x6267s09j0km +Created at: 2023-09-13 21:41:08 +``` + +At this point, 2 TXCH has been removed from wallet `1` and added to wallet `3`, which can be verified by running `balance`: + +```bash +chia dao balance -i 2 +``` + +Response: + +```bash +XCH: 2.0 +``` + +
+ +--- + +## `balance` + +Functionality: Get the asset balances for a DAO treasury + +Usage: chia dao balance \[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 | +| -h | --help | None | False | Show a help message and exit | + +
Example + +```bash +chia dao balance -i 2 +``` + +Response: + +```bash +XCH: 2.0 +``` + +
+ +--- + +## `close_proposal` + +Functionality: Close a DAO proposal + +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 | +| -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] | +| | --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 + +First, show the status of a proposal: + +```bash +chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +Response: + +```bash +Details of Proposal: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +--------------------------- + +Type: SPEND +Status: OPEN +Passed: True +Closable: True + +Proposal XCH Conditions +0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e 1000000000000 +``` + +This proposal's status for `Closable` is `True`, so it can be closed. To do this, run the `close_proposal` command: + +```bash +chia dao close_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d -m 0.0001 +``` + +Response: + +```bash +Submitted proposal close transaction with name: 0x17ff5206551600637d5e5ca57511cf9f0c3ce3dc66466c86102c9e2a8861618e +``` + +After the transaction has been confirmed on-chain, view the status of the proposal once again: + +```bash +chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +Response: + +```bash +Details of Proposal: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +--------------------------- + +Type: SPEND +Status: CLOSED +Passed: True + +Proposal XCH Conditions +0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e 1000000000000 +``` + +This proposal is now closed. The treasury's balance prior to the proposal being created was 2.0 XCH. +Verify that 1 XCH was deducted by showing the current balance: + +```bash +chia dao balance -i 2 +``` + +Response: + +```bash +XCH: 1.000001 +``` + +The extra 0.000001 XCH was added from the proposer's wallet, as a result of the `--proposal-minimum` option being enforced on this DAO (see the [create](#create) command for more details). + +Another way to verify that the correct amount of XCH was spent from treasury is to show the recipient puzzle hash using the full_node RPC: + +```bash +chia rpc full_node get_coin_records_by_puzzle_hash '{"puzzle_hash": "0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e"}' +``` + +Response: + +```bash +{ + "coin_records": [ + { + "coin": { + "amount": 1000000000000, + "parent_coin_info": "0x9ffe88ae3b3ff4ae59524cf4ff200998ac68545d7918d6a3824d9781d0cb12b8", + "puzzle_hash": "0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e" + }, + "coinbase": false, + "confirmed_block_index": 3186133, + "spent": false, + "spent_block_index": 0, + "timestamp": 1694663355 + } + ], + "success": true +} +``` + +
+ +--- + +## `create` + +Functionality: Create a new DAO wallet and treasury + +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] | +| | --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 | + +:::info + +Per singleton rules, `--proposal-minimum` needs to be an odd number (in mojos). If you enter an even number, one mojo will automatically be added to this amount. You will then see the following message when creating the DAO: + +`Adding 1 mojo to proposal minimum amount` + +::: + +:::warning + +This command requires that you have at least two coins in your wallet: one to create the DAO and pay the blockchain fee, and one to mint the DAO CATs. + +If you only have one coin, an error similar to the following will be shown: + +`ValueError: {'error': 'Transaction for 100000 is greater than spendable balance of 0. There may be other transactions pending or our minimum coin amount is too high.', 'success': False}` + +You can split one coin into multiple coins by running the [chia wallet coins split](/reference-client/cli-reference/wallet-cli/#split) command. + +::: + +
Example + +This example will create a DAO with the following options: + +- Proposals must exist for at least 10 blocks before being closed (`--proposal-timelock 10`) +- Proposals must be unspent for at least 2 blocks before being closed (`--soft-close 2`) +- At least 1000 votes ('yes' and 'no' combined) must be received before a proposal can pass (`--attendance-required`) +- At least 50% of votes must be 'yes' in order for a proposal to pass (`--pass-percentage 5000`) +- At least 10 blocks must pass before a proposal can be removed (`--self-destruct 10`) +- At least 5 blocks must pass between oracle spends of the treasury (`--oracle-delay 5`) +- One million mojos will be donated to the treasury upon completion of a proposal. This prevents bad actors from spamming a DAO with untennable proposals (`--proposal-minimum 0.000001`) +- At least 1 vote must be made for a proposal before the wallet will recognise it (`--filter-amount 1`) +- One hundred thousand DAO CATs will be created initially (`--cat-amount 100000`) +- A blockchain fee of 0.00001 XCH will be paid for the transaction that creates the DAO (`-m 0.00001`) +- A second blockchain fee of 0.00001 XCH will be paid for the transaction that creates the DAO CATs (`--fee-for-cat 0.00001`) + +```bash +chia dao create --proposal-timelock 10 --soft-close 2 --attendance-required 1000 --pass-percentage 5000 --self-destruct 10 --oracle-delay 5 --proposal-minimum 0.000001 --filter-amount 1 --cat-amount 100000 -m 0.00001 --fee-for-cat 0.00001 +``` + +Response: + +```bash +Creating new DAO +Adding 1 mojo to proposal minimum amount + +Successfully created DAO Wallet +DAO Treasury ID: 0xdfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 +DAO Wallet ID: 3 +CAT Wallet ID: 4 +DAOCAT Wallet ID: 5 +``` + +Multiple on-chain transactions will be performed. This will take a few minutes. + +To verify that the creation was successful, show your wallet: + +```bash +chia wallet show +``` + +Response: + +```bash +Chia Wallet: + -Total Balance: 2.999987147234 txch (2999987147234 mojo) + -Pending Total Balance: 2.999987147234 txch (2999987147234 mojo) + -Spendable: 2.999987147234 txch (2999987147234 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +Profile 1: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DAO + -Treasury ID: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 + -Wallet ID: 3 + +CAT 07e809aa0324acaf...: + -Total Balance: 100.0 (100000 mojo) + -Pending Total Balance: 100.0 (100000 mojo) + -Spendable: 100.0 (100000 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 5 +``` + +Recall from the DAO's creation response message that the primary DAO wallet's ID is `3`, the CAT wallet's ID is `4`, and the DAO CAT wallet's ID is `5`. + +It is also possible to obtain the DAO's Treasury ID by calling `get_id` and supplying the DAO wallet's ID. For example: + +```bash +chia dao get_id -i 2 +``` + +Response: + +```bash +Treasury ID: 0xdfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 +``` + +
+ +--- + +## create_proposal + +Functionality: Create and add a proposal to a DAO + +There are currently three supported proposal types: spend some of the treasury, update the DAO rules, and mint more of the DAO's CAT. + +### `mint` + +Functionality: Create a proposal to mint new DAO CATs + +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 | + +:::warning + +The votes need to be minted from the treasury's funds, so your DAO will need to have sufficient funds to perform the minting. + +::: + +
Example + +This example will show how to create a proposal to mint 100 DAO CATs and deliver them to another wallet. + +First, a snapshot of the proposer's wallet: + +```bash +chia wallet show +``` + +Response: + +``` +Chia Wallet: + -Total Balance: 0.999356147233 txch (999356147233 mojo) + -Pending Total Balance: 0.999356147233 txch (999356147233 mojo) + -Spendable: 0.999356147233 txch (999356147233 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +Profile 1: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DAO + -Treasury ID: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 + -Wallet ID: 3 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 + +CAT 07e809aa0324acaf...: + -Total Balance: 100000.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 5 +``` + +The following command will be used to create the proposal: + +```bash +chia dao create_proposal mint -i 2 -a 100000 -t txch1u7l0esj4jet6lc4uwm3qj3u3sgdh5y8h4msgl9g833907rrt4k6sj43nfx -v 1 -m 0.00001 +``` + +Response: + +```bash +Successfully created proposal. +Proposal ID: 0x6e11db5e6a94b9f4f867d968ae6f971e6fa4dca9b75ad0d54e0450ebdb1d3c3a +``` + +View the proposal: + +```bash +chia dao show_proposal -i 2 -p 0x6e11db5e6a94b9f4f867d968ae6f971e6fa4dca9b75ad0d54e0450ebdb1d3c3a +``` + +Response: + +```bash +Details of Proposal: 0x6e11db5e6a94b9f4f867d968ae6f971e6fa4dca9b75ad0d54e0450ebdb1d3c3a +--------------------------- + +Type: MINT +Status: OPEN +Passed: False +Yes votes needed: 499 +Closable: False +Total votes needed: 999 +Blocks remaining: 0 + +Amount of CAT to mint: 100000 +Address: txch1u7l0esj4jet6lc4uwm3qj3u3sgdh5y8h4msgl9g833907rrt4k6sj43nfx +``` + +This result shows that 1 vote has been counted so far, from the proposer. +If the proposal succeeds, 100 CATs (100,000 mojos) will be sent to the destination address. + +
+ +### `spend` + +Functionality: Create a proposal to spend DAO funds + +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 + +Be sure to have some CATs locked up for voting. To view the number of CATs that have been locked, run `chia wallet show`: + +```bash +chia wallet show +``` + +Response: + +``` +Chia Wallet: + -Total Balance: 0.999957147234 txch (999957147234 mojo) + -Pending Total Balance: 0.999957147234 txch (999957147234 mojo) + -Spendable: 0.999957147234 txch (999957147234 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +Profile 1: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DAO + -Treasury ID: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 + -Wallet ID: 3 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 + +CAT 07e809aa0324acaf...: + -Total Balance: 100000.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 5 +``` + +In this case, the DAO has `--proposal-minimum` set to `0.000001`. +This means that `0.000001` will be reserved for the proposal's creation. +After the proposal has completed, that amount will be donated to the DAO's treasury. +Additionally, 100 `DAO_CAT` have been locked (100,000 mojos). +To learn how to lock up these CATs, see the [lockup_coins](#lockup_coins) command. + +Next, create the proposal. In this case, we will propose to send 1 XCH (`-a`) to a new wallet address (`-t`) and use 50 of our votes to vote "yes" (`-v`) while adding a 100-million-mojo fee (`-m`) + +```bash +chia dao create_proposal spend -i 2 -t txch1dt8za2parkus8sh77q3hu8xhrjhqzla8n7e7amz270rlcmp9c9hqfmdcx8 -a 1 -v 50 -m 0.0001 +``` + +Response: + +```bash +Created spend proposal for asset: None +Successfully created proposal. +Proposal ID: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +After the proposal has been confirmed on-chain, you can view the details by running `list_proposals` and passing in your DAO treasury wallet (`3` in this example): + +```bash +chia dao list_proposals -i 2 +``` + +Response: + +```bash +############################ +Proposal ID: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +Status: OPEN +Votes for: 50 +Votes against: 0 +------------------------ +Proposals have 2 blocks of soft close time. +############################ +``` + +You can also obtain more details about the proposal from the `show_proposal` command: + +```bash +chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +Response: + +```bash +Details of Proposal: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +--------------------------- + +Type: SPEND +Status: OPEN +Passed: False +Yes votes needed: 450 +Closable: False +Total votes needed: 950 +Blocks remaining: 0 + +Proposal XCH Conditions +0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e 1000000000000 +``` + +
+ +### `update` + +Functionality: Create a proposal to change the DAO rules + +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 + +Let's say a DAO has the following rules: + +```bash +attendance_required: 3000 +oracle_spend_delay: 2 +pass_percentage: 5000 +proposal_minimum_amount: 1000001 +proposal_timelock: 3 +self_destruct_length: 1 +soft_close_length: 2 +``` + +Create a proposal to increase the `pass_percentage` to `7500`, thereby requiring 75% of votes to be "yes" for a proposal to pass (and add 2000 "yes" votes): + +```bash +chia dao create_proposal update -i 2 --pass-percentage 7500 -v 2000 -m 0.0001 +``` + +Response: + +```bash +Successfully created proposal. +Proposal ID: 0x018421004429b253aef317f6af9c222f179fa7931e3a339572025ce6f4c35626 +``` + +The proposal will contain the new rules upon passing: + +```bash +chia dao show_proposal -i 2 -p 0x018421004429b253aef317f6af9c222f179fa7931e3a339572025ce6f4c35626 +``` + +Response: + +```bash +Details of Proposal: 0x018421004429b253aef317f6af9c222f179fa7931e3a339572025ce6f4c35626 +--------------------------- + +Type: UPDATE +Status: OPEN +Passed: True +Closable: False +Total votes needed: 1000 +Blocks remaining: 0 + +Proposed Rules: +attendance_required: 3000 +oracle_spend_delay: 2 +pass_percentage: 7500 +proposal_minimum_amount: 1000001 +proposal_timelock: 3 +self_destruct_length: 1 +soft_close_length: 2 +``` + +
+ +--- + +## `exit_lockup` + +Functionality: Release DAO CATs from voting mode + +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 | + +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 + +First, obtain the current state of the DAO tokens: + +```bash +chia wallet show +``` + +This truncated response shows that 26 tokens are unlocked, and 74 tokens are locked: + +```bash +CAT 3c992efe31910882...: + -Total Balance: 26.0 (26000 mojo) + -Pending Total Balance: 26.0 (26000 mojo) + -Spendable: 26.0 (26000 mojo) + -Type: CAT + -Asset ID: 3c992efe31910882f35a6e0017b6a7ceb0e2f6f7b96a36285d5d11ea015c05a7 + -Wallet ID: 3 + +CAT 3c992efe31910882...: + -Total Balance: 74000.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 3c992efe31910882f35a6e0017b6a7ceb0e2f6f7b96a36285d5d11ea015c05a7 + -Wallet ID: 4 +``` + +Next, unlock all tokens that are available to be unlocked (they cannot have been used to vote on any active proposals): + +```bash +chia dao exit_lockup -i 2 -m 0.00001 +``` + +Response: + +``` +Transaction submitted with spend bundle ID: 0xbe3da7977dd5674ef58a7d8dbd975a990ab52afea11312a06f9edfe0b8f33aff. +``` + +After the transaction has been confirmed, verify that the tokens have been unlocked: + +```bash +chia wallet show +``` + +Response (truncated): + +```bash +CAT a62a729da3c90a22...: + -Total Balance: 100.0 (100000 mojo) + -Pending Total Balance: 100.0 (100000 mojo) + -Spendable: 100.0 (100000 mojo) + -Type: CAT + -Asset ID: a62a729da3c90a22aeb648f64a7499680eceef7c4d98a5dd9e7fa5d14fc3c99e + -Wallet ID: 7 + +CAT a62a729da3c90a22...: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: a62a729da3c90a22aeb648f64a7499680eceef7c4d98a5dd9e7fa5d14fc3c99e + -Wallet ID: 8 +``` + +There are now 100 unlocked tokens and 0 locked tokens. + +
+ +--- + +## `get_id` + +Functionality: Get the Treasury ID of a DAO + +Usage: chia dao get_id \[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 which will receive the funds | +| -h | --help | None | False | Show a help message and exit | + +
Example + +Get the ID of an existing treasury: + +```bash +chia dao get_id -i 2 +``` + +Response: + +```bash +Treasury ID: 0xdfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 +``` + +
+ +--- + +## `list_proposals` + +Functionality: List proposals for the DAO + +Usage: chia dao list_proposals \[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 | +| -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 + +```bash +chia dao list_proposals -i 2 +``` + +Response: + +```bash +############################ +Proposal ID: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +Status: OPEN +Votes for: 50 +Votes against: 0 +------------------------ +Proposals have 2 blocks of soft close time. +############################ +``` + +
+ +--- + +## `lockup_coins` + +Functionality: Lock DAO CATs for voting + +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 | + +This command will lock the specified number of tokens, thereby making them available for voting. + +
Example + +Before locking the tokens, show the current status of the DAO's wallets: + +```bash +chia wallet show +``` + +Response: + +```bash +Chia Wallet: + -Total Balance: 0.999977147234 txch (999977147234 mojo) + -Pending Total Balance: 0.999977147234 txch (999977147234 mojo) + -Spendable: 0.999977147234 txch (999977147234 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +Profile 1: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DAO + -Treasury ID: dfe486693cddf312eae141688e72a0b5f597df152f7f30dcb7c775d0ffaa1a56 + -Wallet ID: 3 + +CAT 07e809aa0324acaf...: + -Total Balance: 100.0 (100000 mojo) + -Pending Total Balance: 100.0 (100000 mojo) + -Spendable: 100.0 (100000 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 + +CAT 07e809aa0324acaf...: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 5 +``` + +In this example, there are 100 tokens in the `CAT` wallet with ID `4`, and 0 tokens in the `DAO_CAT` wallet with ID `5`. + +Next, run the `lockup_coins` command to lock some of the CATs. For example, to lock 74 CATs: + +```bash +chia dao lockup_coins -i 2 -a 74 -m 0.00001 +``` + +The response will show the transaction ID: + +```bash +Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] +Run 'chia wallet get_transaction -f 3261611401 -tx 0xb480143c81d78e739319fe2d52b483ea1f211f0ebb8ff48fc40c9af81da871b3' to get status +``` + +To see the status of the transaction run the command shown in the output of the `lockup_coins` command. For example: + +```bash +chia wallet get_transaction -f 3261611401 -tx 0xb480143c81d78e739319fe2d52b483ea1f211f0ebb8ff48fc40c9af81da871b3 +``` + +Response: + +```bash +Transaction b480143c81d78e739319fe2d52b483ea1f211f0ebb8ff48fc40c9af81da871b3 +Status: Confirmed +Amount sent: 74 CAT 07e809aa0324acaf... +To address: txch1dkd20xfxqc29q7qh7nscjh8njgt0sppx0r03cvzeuzh70auz6ypsfhzles +Created at: 2023-09-13 21:44:48 +``` + +After the transaction has been finalized, view the wallet's balance again: + +```bash +chia wallet show +``` + +The response will show that the `CAT` wallet's balance has decreased and the `DAO_CAT` wallet's balance has increased: + +```bash +CAT 07e809aa0324acaf...: + -Total Balance: 26.0 (26000 mojo) + -Pending Total Balance: 26.0 (26000 mojo) + -Spendable: 26.0 (26000 mojo) + -Type: CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 4 + +CAT 07e809aa0324acaf...: + -Total Balance: 74000.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 07e809aa0324acaf274ce1bb1502d18b31236ac46739e90ebf0a042dbbd2c882 + -Wallet ID: 5 +``` + +The 74 tokens in the `DAO_CAT` wallet can now be used for voting on proposals. + +
+ +--- + +## `release_coins` + +Functionality: Release closed proposals from DAO CATs + +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 + +Let's say this is the state of the wallet: + +```bash +Amazing DAO CAT: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: 0ba7b225ea0aa595384239537b055caa0fa8b627b98b6032439d4f2cd1414bf5 + -Wallet ID: 3 + +CAT 0ba7b225ea0aa595...: + -Total Balance: 1000.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 0ba7b225ea0aa595384239537b055caa0fa8b627b98b6032439d4f2cd1414bf5 + -Wallet ID: 4 +``` + +One thousand DAO_CATs (equivalent to 1 CAT) have been locked up for voting. In this case, some of these DAO_CATs have been used for voting in a proposal that has since closed. + +Next, run the `release_coins` command and add a blockchain fee: + +```bash +chia dao release_coins -i 2 -m 0.0001 +``` + +The response does not contain much info: + +```bash +Transaction not yet submitted to nodes. TX ID: 0xcebd0fdf105855ad51820efee7231cac618f3028d37a7c80c376d4f63ceefa35 +``` + +After a few minutes, the transaction will be completed and the voting coins will have been released. +However, the wallet balance won't reflect this. In order to verify that the CATs have been released, you can run the `exit_lockup` command: + +```bash +chia dao exit_lockup -i 2 -m 0.0001 +``` + +After a few more minutes, show the wallet balance again: + +```bash +Amazing DAO CAT: + -Total Balance: 1.0 (1000 mojo) + -Pending Total Balance: 1.0 (1000 mojo) + -Spendable: 1.0 (1000 mojo) + -Type: CAT + -Asset ID: 0ba7b225ea0aa595384239537b055caa0fa8b627b98b6032439d4f2cd1414bf5 + -Wallet ID: 3 + +CAT 0ba7b225ea0aa595...: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DAO_CAT + -Asset ID: 0ba7b225ea0aa595384239537b055caa0fa8b627b98b6032439d4f2cd1414bf5 + -Wallet ID: 4 +``` + +All 1000 DAO_CATs have been released. They are now reflected as 1 CAT. +If any DAO_CATs had still been locked in a current vote, they would not have unlocked in the `exit_lockup` command. + +
+ +--- + +## `rules` + +Functionality: Get the current rules governing the DAO + +Usage: chia dao rules \[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 | +| -h | --help | None | False | Show a help message and exit | + +
Example + +```bash +chia dao rules -i 2 +``` + +Response: + +```bash +attendance_required: 1000 +oracle_spend_delay: 5 +pass_percentage: 5000 +proposal_minimum_amount: 1000001 +proposal_timelock: 10 +self_destruct_length: 10 +soft_close_length: 2 +``` + +
+ +--- + +## `show_proposal` + +Functionality: Show the details of a specific proposal + +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 | + +
Example + +```bash +chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +Response: + +```bash +Details of Proposal: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +--------------------------- + +Type: SPEND +Status: OPEN +Passed: False +Yes votes needed: 450 +Closable: False +Total votes needed: 950 +Blocks remaining: 0 + +Proposal XCH Conditions +0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e 1000000000000 +``` + +
+ +--- + +## `vote` + +Functionality: Vote on a DAO proposal + +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 + +Start by showing the status of a proposal: + +```bash +chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +Response: + +```bash +Details of Proposal: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +--------------------------- + +Type: SPEND +Status: OPEN +Passed: False +Yes votes needed: 450 +Closable: False +Total votes needed: 950 +Blocks remaining: 0 + +Proposal XCH Conditions +0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e 1000000000000 +``` + +In this example, 450 "Yes" votes are still needed, along with 950 total votes. Next we'll add 100 "yes" votes: + +```bash +chia dao vote -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d -a 100 -m 0.0001 +``` + +Response: + +``` +Submitted spend bundle with name: 0x5975b2e846cbd75335d3ed98a72af1edb4bdaaaf0817307b185d94ff9ad3c2ed +``` + +After the transaction has been confirmed on-chain, show the proposal again: + +```bash + chia dao show_proposal -i 2 -p 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +``` + +The response shows that the 100 "Yes" votes have been counted: + +```bash +Details of Proposal: 0x372a3e3d7f502a542d3c926588b62d5ca580d4ff60a158740563470f2114ef2d +--------------------------- + +Type: SPEND +Status: OPEN +Passed: False +Yes votes needed: 350 +Closable: False +Total votes needed: 850 +Blocks remaining: 0 + +Proposal XCH Conditions +0x6ace2ea83d1db903c2fef0237e1cd71cae017fa79fb3eeec4af3c7fc6c25c16e 1000000000000 +``` + +
+ +--- 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 new file mode 100644 index 00000000000..eeb006f1c32 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/datalayer-cli.md @@ -0,0 +1,1363 @@ +--- +sidebar_label: DataLayer +title: DataLayer CLI +slug: /reference-client/cli-reference/datalayer-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This page includes a comprehensive list of Chia's Command Line Interface commands for interacting with the DataLayer. + +We also have documented the [RPC API](/reference-client/rpc-reference/datalayer-rpc) for interacting with the DataLayer. + +The relevant DataLayer commands can be found by running `chia data`: + +```bash +(venv) $ chia data -h +``` + +Commands that modify the blockchain include an optional fee. This fee can be specified in two ways: + +1. The `-m` / `--fee` parameter can be specified explicitly in the command, as several of the examples in this document show +2. If the fee option is not explicitly specified, then the `data_layer:fee` setting in `~/.chia/mainnet/config/config.yaml` will be used. By default, this is set to 1 billion mojos (0.001 XCH) +3. If neither of these options is set, then no fee will be used + +For commands that change the state of the DataLayer singleton (ie all on-chain commands), you will need to wait for confirmation before running another command. If you run a command before the previous transaction has been confirmed, you will receive this error: `Request failed: {'error': 'Already have a pending root waiting for confirmation.', 'success': False}` + +The commands in this document will work with or without the `=` symbol. Additionally, hashes may or may not be prefixed with `0x`. + +--- + +## Reference + +### `add_mirror` + +Functionality: Add a new mirror from a local or remote data store. Triggers a Chia transaction + +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 | +| -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 | + +
Example + +Create one mirror with multiple URLs: + +```bash +chia data add_mirror -i 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -a 1000 -u http://www.example.com:8575 -u http://www.example2.com:8575 +``` + +Response: + +``` +None +``` + +
+ +--- + +### `add_missing_files` + +Functionality: Use the database to restore all files for one or more local data stores + +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 | + +
Example + +For this example, there is one local store: + +```json +ls ~/.chia/mainnet/data_layer/db/server_files_location_testnet10/ +``` + +Response: + +``` +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-0000000000000000000000000000000000000000000000000000000000000000-delta-2-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-0000000000000000000000000000000000000000000000000000000000000000-full-2-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-b5420e65846ded936d1e4855c066247fc461a3b281cd9e0e69f3cfa4df529ba2-delta-3-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-b5420e65846ded936d1e4855c066247fc461a3b281cd9e0e69f3cfa4df529ba2-full-3-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-d6d6b4d6bbd77aaa5927c8a21a1451b35f4860a7f9a58e51dae04037da9c08e8-delta-4-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-d6d6b4d6bbd77aaa5927c8a21a1451b35f4860a7f9a58e51dae04037da9c08e8-full-4-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-e488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb-delta-1-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-e488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb-full-1-v1.0.dat +``` + +Intentionally move the files and create an empty folder. This will simulate file corruption: + +```json +mv ~/.chia/mainnet/data_layer/db/server_files_location_testnet10 ~/.chia/mainnet/data_layer/db/server_files_location_testnet10_bak +mkdir ~/.chia/mainnet/data_layer/db/server_files_location_testnet10/ +``` + +Next, restore the files: + +```json +chia data add_missing_files +``` + +Response: + +```json +None +``` + +Finally, verify that the files have been restored: + +```json +ls ~/.chia/mainnet/data_layer/db/server_files_location_testnet10/ +``` + +Response: + +```json +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-0000000000000000000000000000000000000000000000000000000000000000-delta-2-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-0000000000000000000000000000000000000000000000000000000000000000-full-2-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-b5420e65846ded936d1e4855c066247fc461a3b281cd9e0e69f3cfa4df529ba2-delta-3-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-b5420e65846ded936d1e4855c066247fc461a3b281cd9e0e69f3cfa4df529ba2-full-3-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-d6d6b4d6bbd77aaa5927c8a21a1451b35f4860a7f9a58e51dae04037da9c08e8-delta-4-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-d6d6b4d6bbd77aaa5927c8a21a1451b35f4860a7f9a58e51dae04037da9c08e8-full-4-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-e488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb-delta-1-v1.0.dat +1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f-e488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb-full-1-v1.0.dat +``` + +
+ +--- + +### `clear_pending_roots` + +Functionality: Clear pending roots that will not be published, associated data may not be recoverable + +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] | +| -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 + +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: + +```bash +chia data clear_pending_roots -i 2772c8108e19f9fa98ff7bc7d4bafd821319bc90af6b610d086b85f4c21fa816 --yes +``` + +Response: + +```bash +{ + "root": { + "generation": 1, + "node_hash": "e488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb", + "status": 1, + "tree_id": "2772c8108e19f9fa98ff7bc7d4bafd821319bc90af6b610d086b85f4c21fa816" + }, + "success": true +} +``` + +
+ +--- + +### `create_data_store` + +Functionality: Create a data store. Triggers a Chia transaction + +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 | + +
Example + +Create a new data store: + +```bash +chia data create_data_store -m 0.00001 +``` + +Response: + +``` +{ + 'id': '1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f', + 'success': True, + 'txs': + [ + { + 'additions': + [ + { + 'amount': 1, + 'parent_coin_info': '0xb4a1a658aaefd10930ecbccd51ac2c9a4853435b14acdb0de84729bfbefc791c', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + { + 'amount': 14999989999999, + 'parent_coin_info': '0xb4a1a658aaefd10930ecbccd51ac2c9a4853435b14acdb0de84729bfbefc791c', + 'puzzle_hash': '0x478255c372cec71557c20459f4b690fb1b7c57da3fcfc4b6396d78d9a396e384' + }, + { + 'amount': 1, + 'parent_coin_info': '0x1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f', + 'puzzle_hash': '0xd650e81d45c7381183c14c3363a81aa78cb3acfe213e46da26df75cd431557f9' + } + ], + 'amount': 1, + 'confirmed': False, + 'confirmed_at_height': 0, + 'created_at_time': 1661141324, + 'fee_amount': 10000000, + 'memos': [], + 'name': '0xaee362ae9d0ce3992b3bfb7cc48bde17f3d794cc383ff1d5e49a4d75dbf004d6', + 'removals': + [ + { + 'amount': 15000000000000, + 'parent_coin_info': '0x81fc1729bad3f19699461b1ee455a92493ef4c1d60ba37d22ac187a18367e08e', + 'puzzle_hash': '0x221c0e9cd9b7f536e9a204ef93519e6c9d4b4c9a049bde8d66fa1816c23120d2' + }, + { + 'amount': 1, + 'parent_coin_info': '0xb4a1a658aaefd10930ecbccd51ac2c9a4853435b14acdb0de84729bfbefc791c', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + } + ], + 'sent': 10, + 'sent_to': [], + 'spend_bundle': { + 'aggregated_signature': '0x8c431f07698ad69fd14ab04d77683801e6b908e441074f5ef5268350483d194a09a8b3cde681cb5c5fcf6444e0c9d4bf00999e8e6ad1522891baa590f82d92e2876b08e34b1f3156d0fe88ce206e5ed1567863e10a0397fd0a8a66bcbd5007b0', + 'coin_spends': + [ + { + 'coin': + { + 'amount': 15000000000000, + 'parent_coin_info': '0x81fc1729bad3f19699461b1ee455a92493ef4c1d60ba37d22ac187a18367e08e', + 'puzzle_hash': '0x221c0e9cd9b7f536e9a204ef93519e6c9d4b4c9a049bde8d66fa1816c23120d2' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0b3deeeb00319624e26767c5cf777cf9a02d046510181ed29f233e2847fa8ef28ede05d2770bb1b8f101ea8ae20527d61ff018080', + 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0478255c372cec71557c20459f4b690fb1b7c57da3fcfc4b6396d78d9a396e384ff860da47513597f80ffff34ff840098968080ffff3cffa084f72a9a3ce5152e1d627a259a0c1c90e6af389cb26af48173d84e374ecc518080ffff3dffa03a0ed375dff192685d1ef9a74424788b04655700bee898f0ea8445f8b55d38338080ff8080' + }, + { + 'coin': + { + 'amount': 1, + 'parent_coin_info': '0xb4a1a658aaefd10930ecbccd51ac2c9a4853435b14acdb0de84729bfbefc791c', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', + 'solution': '0xffa0d650e81d45c7381183c14c3363a81aa78cb3acfe213e46da26df75cd431557f9ff01ffffa00000000000000000000000000000000000000000000000000000000000000000ffa0adcbcbaf4594e8d3057ea3a64a40560720ede80e720f867d2631069c27459de58080' + } + ] + }, + 'to_puzzle_hash': '0x0202020202020202020202020202020202020202020202020202020202020202', + 'trade_id': None, + 'type': 0, + 'wallet_id': 0 + }, + { + 'additions': + [ + { + 'amount': 1, + 'parent_coin_info': '0xb4a1a658aaefd10930ecbccd51ac2c9a4853435b14acdb0de84729bfbefc791c', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + { + 'amount': 14999989999999, + 'parent_coin_info': '0xb4a1a658aaefd10930ecbccd51ac2c9a4853435b14acdb0de84729bfbefc791c', + 'puzzle_hash': '0x478255c372cec71557c20459f4b690fb1b7c57da3fcfc4b6396d78d9a396e384' + } + ], + 'amount': 1, + 'confirmed': False, + 'confirmed_at_height': 0, + 'created_at_time': 1661141324, + 'fee_amount': 10000000, + 'memos': [], + 'name': '0xbb4cb461126d9ea9492e767462b9a4e408e497231c2093474cba2bcfe4397104', + 'removals': + [ + { + 'amount': 15000000000000, + 'parent_coin_info': + '0x81fc1729bad3f19699461b1ee455a92493ef4c1d60ba37d22ac187a18367e08e', + 'puzzle_hash': '0x221c0e9cd9b7f536e9a204ef93519e6c9d4b4c9a049bde8d66fa1816c23120d2' + } + ], + 'sent': 0, + 'sent_to': [], + 'spend_bundle': None, + 'to_puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9', + 'trade_id': None, + 'type': 1, + 'wallet_id': 1 + } + ] +} +``` + +
+ +--- + +### `delete_mirror` + +Functionality: Delete a mirror, by `coin_id`. Triggers a Chia transaction + +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 | + +
Example + +```bash +chia data delete_mirror -c b5756487c17fe3a2628e45a9d3d42e89231af718bb1735e6c8441e07ec005f9d -m 0.000001 +``` + +Response: + +``` +{'success': True} +``` + +
+ +--- + +### `get_keys` + +Functionality: Get all keys associated with a store ID + +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 | + +:::info + +Pagination is disabled by default. If it is enabled (by using the `page` flag), then the JSON response will include `total_pages` and `total_bytes`, in addition to the data. + +If an item is larger than `max-page-size`, an error will be thrown. + +::: + +
Example + +```bash +chia data get_keys --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +``` +{ + 'keys': [ + '0x0004', + '0x0005' + ], + 'success': True +} +``` + +
+ +--- + +### `get_keys_values` + +Functionality: Get all keys and values for a store. Must be subscribed to store ID + +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 | + +:::info + +Pagination is disabled by default. If it is enabled (by using the `page` flag), then the JSON response will include `total_pages` and `total_bytes`, in addition to the data. + +If an item is larger than `max-page-size`, an error will be thrown. + +::: + +
Example + +```bash +chia data get_keys_values --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +``` +{ + 'keys_values': [ + { + 'atom': None, + 'hash': '0x26e60dd9b493eee1f6781fc13dd025e0bfafcde5a103c95dd087d91bd848d406', + 'key': '0x0004', + 'value': '0x0123456789abcdef' + }, + { + 'atom': None, + 'hash': '0xc2dc94c2a85d7db4cfdd1d907bcc441c8fce595db2e2075b973fb8171e2f19a2', + 'key': '0x0005', + 'value': '0xbeadfeed' + } + ], + 'success': True +} +``` + +
+ +--- + +### `get_kv_diff` + +Functionality: Get the kv diff between two hashes within the same store ID + +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 | + +:::info + +Pagination is disabled by default. If it is enabled (by using the `page` flag), then the JSON response will include `total_pages` and `total_bytes`, in addition to the data. + +If an item is larger than `max-page-size`, an error will be thrown. + +::: + +
Example + +```bash +chia data get_kv_diff --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -hash_1 0x26e60dd9b493eee1f6781fc13dd025e0bfafcde5a103c95dd087d91bd848d406 -hash_2 0xc2dc94c2a85d7db4cfdd1d907bcc441c8fce595db2e2075b973fb8171e2f19a2 +``` + +Response: + +``` +{ + 'diff': [ + { + 'key': '0005', + 'type': 'INSERT', + 'value': 'beadfeed' + }, + { + 'key': '0004', + 'type': 'DELETE', + 'value': '0123456789abcdef' + } + ], + 'success': True +} +``` + +
+ +--- + +### `get_mirrors` + +Functionality: List all mirrors for a store ID + +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 | +| -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 | + +
Example + +```bash +chia data get_mirrors -i 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +``` +{ + 'mirrors': [ + { + 'amount': 1000, + 'coin_id': 'b5756487c17fe3a2628e45a9d3d42e89231af718bb1735e6c8441e07ec005f9d', + 'launcher_id': '1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f', + 'ours': True, + 'urls': [ + 'http://www.example.com:8575', + 'http://www.example2.com:8575' + ] + } + ], + 'success': True +} +``` + +
+ +--- + +### `get_owned_stores` + +Functionality: Get owned stores + +Usage: `chia data get_owned_stores [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 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 | + +
Example + +```bash +chia data get_owned_stores +``` + +Response: + +``` +{ + 'store_ids': [ + '39114b28a3674b6c2c0ed65d3518842fd17f9df46794f49cd223f9f3a463f09d', + '5d8f5c88f27804f5c387e070403faece14acb74460bbf7d47739178a3774eff3', + '77e9c21be435dded6e8c9b32e93b2b880665f5b34f860a642f22d3fa500ce457', + '9d0c65e77c750eac28b3fa78e57cdcec59fe53448eb59bdfbfa694d89f262b4b' + ], + 'success': True +} +``` + +
+ +--- + +### `get_proof` + +Functionality: Obtains a merkle proof of inclusion for a given key + +Usage: `chia data get_proof [OPTIONS]` + +Options: + +| 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 | + +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 + +```bash +chia data get_proof --id 7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e -k 0x0003 +``` + +Response: + +```bash +{ + "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" + } + }, + "success": true +} +``` + +
+ +--- + +### `get_root` + +Functionality: Get the Merkle Root and timestamp of a given store ID + +Usage: `chia data get_root [OPTIONS]` + +Options: + +| 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 | + +
Example + +```bash +chia data get_root --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +``` +{ + 'confirmed': True, + 'hash': '0xd6d6b4d6bbd77aaa5927c8a21a1451b35f4860a7f9a58e51dae04037da9c08e8', + 'success': True, + 'timestamp': 1661148611 +} +``` + +
+ +--- + +### `get_root_history` + +Functionality: Get a history of root hashes for a Store ID that you subscribe to + +Usage: `chia data get_root_history [OPTIONS]` + +Options: + +| 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 | + +
Example + +```bash +chia data get_root_history --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +``` +{ + 'root_history': [ + { + 'confirmed': True, + 'root_hash': '0x0000000000000000000000000000000000000000000000000000000000000000', + 'timestamp': 1661141342 + }, + { + 'confirmed': True, + 'root_hash': '0xe488fa1bf0f712b224df0daf312b3d479f80e3a330d4bebd8f26a0d52dc0ebbb', + 'timestamp': 1661144917 + }, + { + 'confirmed': True, + 'root_hash': '0x0000000000000000000000000000000000000000000000000000000000000000', + 'timestamp': 1661145223 + }, + { + 'confirmed': True, + 'root_hash': '0xb5420e65846ded936d1e4855c066247fc461a3b281cd9e0e69f3cfa4df529ba2', + 'timestamp': 1661145404 + }, + { + 'confirmed': True, + 'root_hash': '0xd6d6b4d6bbd77aaa5927c8a21a1451b35f4860a7f9a58e51dae04037da9c08e8', + 'timestamp': 1661148611 + } + ], + 'success': True +} +``` + +
+ +--- + +### `get_subscriptions` + +Functionality: Get subscribed stores, including the owned stores + +Usage: `chia data get_subscriptions [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 | +| -f | --fingerprint | INTEGER | False | Set the fingerprint to specify which wallet to use | +| -h | --help | None | False | Show a help message and exit | + +
Example + +```bash +chia data get_subscriptions +``` + +Response: + +``` +{ + 'store_ids': [ + 'ba934d7f4ad47c34cb1a99d3c57adacb1883cff5528cca67c34f724f3560e401', + '9d0c65e77c750eac28b3fa78e57cdcec59fe53448eb59bdfbfa694d89f262b4b', + '39114b28a3674b6c2c0ed65d3518842fd17f9df46794f49cd223f9f3a463f09d', + '77e9c21be435dded6e8c9b32e93b2b880665f5b34f860a642f22d3fa500ce457', + '5d8f5c88f27804f5c387e070403faece14acb74460bbf7d47739178a3774eff3', + 'a101396917a68f79e9119eaef738162d73e23b43e952561f21bdb1a1c171df89', + '0f2257618880bf2a6d8d3c223147e06fa547520802e44a5359d240cdf0b9dbe7' + ], + 'success': True +} +``` + +
+ +--- + +### `get_sync_status` + +Functionality: Get locally stored root compared to the root of the singleton + +Usage: `chia data get_sync_status [OPTIONS]` + +Options: + +| 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 | + +If the `root_hash` matches the `target_root_hash`, then the store is synced. + +
Example + +```bash +chia data get_sync_status -store 39114b28a3674b6c2c0ed65d3518842fd17f9df46794f49cd223f9f3a463f09d +``` + +Response: + +``` +{ + 'success': True, + 'sync_status': { + 'generation': 1, + 'root_hash': '532d8df550bdbdef28c1a7b27eaefc812afb99eabd59b3c041000c7ea352e900', + 'target_generation': 1, + 'target_root_hash': '532d8df550bdbdef28c1a7b27eaefc812afb99eabd59b3c041000c7ea352e900' + } +} +``` + +
+ +--- + +### `get_value` + +Functionality: Get a value from a Store's key + +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 | + +
Example + +```bash +chia data get_value --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f --key 0004 +``` + +Response: + +``` +{ + 'success': True, + 'value': '0123456789abcdef' +} +``` + +
+ +--- + +### `plugins` + +Functionality: Get information about configured uploader/downloader plugins + +Usage: `chia data plugins [OPTIONS] COMMAND [ARGS]...` + +Commands: `check` (Calls the plugin_info endpoint on all configured plugins) + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------- | +| -h | --help | None | False | Show a help message and exit | + +Note that currently `check` is the only sub-command under the `plugins` command. This command is shown in the example. + +
Example + +```bash +chia data plugins check +``` + +Response: + +```bash +{ + "plugin_status": { + "downloaders": {}, + "uploaders": {} + }, + "success": true +} +``` + +
+ +--- + +### `remove_subscription` + +Functionality: Remove one or more URLs from a data store to which you subscribe. Note that this action will not remove the subscription to the data store itself. For that functionality, use [unsubscribe](#unsubscribe) + +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 | +| -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 | + +
Example + +```bash +chia data remove_subscription -store 8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d -u http://www.example.com:8575 +``` + +Response: + +``` +None +``` + +
+ +--- + +### `subscribe` + +Functionality: Subscribe to a store ID + +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 | +| -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 | + +
Example 1 + +Subscribe to a data store without specifying any URLs: + +```bash +chia data subscribe -store 8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d +``` + +Response: + +``` +None +``` + +Use the `subscriptions` RPC to list all current subscriptions: + +```bash +chia rpc data_layer subscriptions +``` + +Response: + +```bash +{ + "store_ids": [ + "1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f", + "8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d" + ], + "success": true +} +``` + +
+ +
Example 2 + +Subscribe to a data store using multiple URLs where that store resides: + +```bash +chia data subscribe -store 8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d -u http://www.example.com:8575 -u http://www.example2.com:8575 +``` + +Response: + +``` +None +``` + +Use the `subscriptions` RPC to list all current subscriptions: + +```bash +chia rpc data_layer subscriptions +``` + +Response: + +```bash +{ + "store_ids": [ + "1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f", + "8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d" + ], + "success": true +} +``` + +
+ +--- + +### `unsubscribe` + +Functionality: Unsubscribe from a store ID + +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 | + +:::info + +The `unsubscribe` command may or may not delete any data, depending on which version of Chia you are running: + +- Prior to version 2.1, the command did not delete the .dat files, nor did it delete from the database. +- As of version 2.1, the command deletes the .dat files, but does not delete from the database. +- In a future release, the command will also delete from the database. + +::: + +Example: + +
Example + +```bash +chia data unsubscribe -store 8f6ed792bbbf5216f8e55064793f74ce01286b9c1d542cc4a357cf7f8712df1d +``` + +Response: + +``` +None +``` + +
+ +--- + +### `update_data_store` + +Functionality: Update a data store with a given changelist. Triggers a Chia transaction + +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 | +| -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 | + +A few notes on the `-d` / `--changelist` option: + +- The entire list must be formatted as a JSON array +- There are two actions allowed: `insert` and `delete` +- `insert` requires `key` and `value` flags +- `delete` requires a `key` flag only +- Keys and values must be written in hex format. Values can be derived from text or binary. +- Labels, keys and values must all be enclosed in double quotes +- Multiple inserts and deletes are allowed +- The size of a single `value` flag is limited to 100 MiB. However, adding anything close to that size has not been tested and could produce unexpected results. +- On Windows, you must escape the double quotes in the JSON array with backslashes. See below for an example. This is not required on MacOS or Linux. + +The following examples will show the basic functionality of this command. + +
Example 1 -- Insert a single key/value pair + +```bash +chia data update_data_store --id=1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f -d '[{"action":"insert", "key":"0003", "value":"abc123"}]' +``` + +Response: + +``` +{ + 'success': True, + 'tx_id': '0xed157b50b94a849d3d19a0ef4e1b0e07bda863e4d65bd1527fa6f59062bb5c78' +} +``` + +
+ +
Example 2 -- Delete a single key + +```bash +chia data update_data_store --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f --changelist '[{"action":"delete", "key":"0003"}]' +``` + +Response: + +``` +{ + 'success': True, + 'tx_id': '0x2a64ef42baf05c6f4d446ba8638c2f2b2c26e5a91ad62e0c5151df40d0f92ec2' +} +``` + +
+ +
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"}]' +``` + +Response: + +``` +{ + 'success': True, + 'tx_id': '0xea22328f8843fab4149d0589e43217d88047ceeb41ef610e59717d13127bab7c' +} +``` + +List all keys and values after running the previous command: + +```bash +chia data get_keys_values --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +```bash +{ + 'keys_values': [ + { + 'atom': None, + 'hash': '0x7e193b814080e50aa7780bcf71fd0422a0397ad3e57dc1eac71d93183efb39ba', + 'key': '0x0004', + 'value': '0x123abc' + }, + { + 'atom': None, + 'hash': '0xc2dc94c2a85d7db4cfdd1d907bcc441c8fce595db2e2075b973fb8171e2f19a2', + 'key': '0x0005', + 'value': '0xbeadfeed' + } + ], + 'success': True +} +``` + +
+ +
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"}]' +``` + +Response: + +``` +Exception from 'data': {'error': 'Key already present: 0004', 'success': False} +``` + +
+ +
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"}]' +``` + +Response: + +``` +{ + 'success': True, + 'tx_id': '0xf2631a4d326d937b4ac4c89c400d4f33b2d3caf34d7794cf89e2c5d06c9a4648' +} +``` + +Show the result of running the previous command: + +```bash +chia data get_keys_values --id 1a119374fc7d7055d3419fdcd7f93065f28a1e4acacdf9c73b933b27b685550f +``` + +Response: + +```bash +{'keys_values': [{'atom': None, 'hash': '0x26e60dd9b493eee1f6781fc13dd025e0bfafcde5a103c95dd087d91bd848d406', 'key': '0x0004', 'value': '0x0123456789abcdef'}, {'atom': None, 'hash': '0xc2dc94c2a85d7db4cfdd1d907bcc441c8fce595db2e2075b973fb8171e2f19a2', 'key': '0x0005', 'value': '0xbeadfeed'}], 'success': True} +``` + +
+ +
Example 6 -- Show a key/value pair that was inserted into the Climate Warehouse + +```bash +[{"action":"insert","key":"70726f6a6563747c37353339656336392d636238652d343464362d383832332d653062313135303162643433","value":"7b2263757272656e745265676973747279223a2243756c7469766f222c2272656769737472794f664f726967696e223a2243756c7469766f222c226f726967696e50726f6a6563744964223a224d6163546573743135222c2270726f6772616d223a224d6163546573743135222c2270726f6a6563744964223a224d6163546573743135222c2270726f6a6563744e616d65223a224d6163546573743135222c2270726f6a6563744c696e6b223a224d6163546573743135222c2270726f6a656374446576656c6f706572223a224d6163546573743135222c22736563746f72223a22456e6572677920646973747269627574696f6e222c2270726f6a65637454797065223a224f7a6f6e65204465706c6574696e67205375627374616e636573222c22636f766572656442794e4443223a224f757473696465204e4443222c226e6463496e666f726d6174696f6e223a224d6163546573743135222c2270726f6a656374537461747573223a22436f6d706c65746564222c22756e69744d6574726963223a2274434f3265222c226d6574686f646f6c6f6779223a22426173656c696e65204d6574686f646f6c6f677920666f72206465636f6d706f736974696f6e206f66204e324f2066726f6d206578697374696e672061646970696320616369642070726f64756374696f6e20706c616e7473202d2d2d2056657273696f6e20332e30222c2270726f6a65637454616773223a224d6163546573743135222c2276616c69646174696f6e426f6479223a22436172626f6e20436865636b2028496e646961292050726976617465204c74642e222c2270726f6a65637453746174757344617465223a22323032302d30332d32385430303a30303a30302e3030305a222c2276616c69646174696f6e44617465223a22323032322d30332d30315430303a30303a30302e3030305a222c2277617265686f75736550726f6a6563744964223a2237353339656336392d636238652d343464362d383832332d653062313135303162643433222c2274696d65537461676564223a313634363639343630322c226f7267556964223a2230623039643861653437626665323731366263323532383231333463653661613931616333646364663933363335616338656436626362333031626234636238227d"}] +``` + +The hex from this example can be decoded to obtain the following: + +```bash +key = project|7539ec69-cb8e-44d6-8823-e0b11501bd43 +value = { + "currentRegistry":"Cultivo", + "registryOfOrigin":"Cultivo", + "originProjectId":"MacTest15", + "program":"MacTest15", + "projectId":"MacTest15", + "projectName":"MacTest15", + "projectLink":"MacTest15", + "projectDeveloper":"MacTest15", + "sector":"Energy distribution", + "projectType":"Ozone Depleting Substances", + "coveredByNDC":"Outside NDC", + "ndcInformation":"MacTest15", + "projectStatus":"Completed", + "unitMetric":"tCO2e", + "methodology":"Baseline Methodology for decomposition of N2O from existing adipic acid production plants --- Version 3.0", + "projectTags":"MacTest15", + "validationBody":"Carbon Check (India) Private Ltd.", + "projectStatusDate":"2020-03-28T00:00:00.000Z", + "validationDate":"2022-03-01T00:00:00.000Z", + "warehouseProjectId":"7539ec69-cb8e-44d6-8823-e0b11501bd43", + "timeStaged":1646694602, + "orgUid":"0b09d8ae47bfe2716bc25282134ce6aa91ac3dcdf93635ac8ed6bcb301bb4cb8" +} +``` + +
+ +--- + +### `verify_proof` + +Functionality: Verifies a merkle proof of inclusion + +Usage: `chia data verify_proof [OPTIONS]` + +Options: + +| 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 | + +Notes about this command: + +- It only needs to perform a single lookup of the on-chain root. +- It doesn't need to have synced any of the data, or be subscribed to the data store. +- To keep the proofs smaller, only the clvm hash of the key and value are included in the proof, and not the actual key or value. (A clvm hash is just a sha256 hash of the data prepended with 0x01.) +- Datalayer uses CLVM hashes for ease of verification in CLVM, although for this specific use case, there is no on-chain validation happening. +- When using this command, pay attention to the `current_root` value in the returned JSON. + - If `current_root` is `True`, this data chains to the current published root, and so if you synced the data, you can be sure it would be there. + - If `current_root` is `False`, the root has moved from the time the proof was generated. You cannot make any assumptions in this case about whether the data is in fact in the datastore or not since the root has changed, therefore the data might have changed. It is up to the caller to determine how to treat this case; one possible action would be to obtain a new proof. + +The proof to validate requires several fields: + +- `coin_id` +- `inner_puzzle_hash` +- `store_proofs` + - `proofs` + - `key_clvm_hash` + - `value_clvm_hash` + - `node_hash` + - `layers` + +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 + +```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"}}' +``` + +Response: + +```bash +{ + "current_root": true, + "success": true, + "verified_clvm_hashes": { + "inclusions": [ + { + "key_clvm_hash": "0xa143e7ffd81147f136f921fef88760c46c7a05f15b81995f9c5cfed2a737a3f1", + "value_clvm_hash": "0xed052604ee4ff3996c15ef9b2cb0925233a2e78b6168bb6e67d133e074109b42" + } + ], + "store_id": "0x7de232eecc08dc5e524ad42fad205c9ec7dd3f342677edb7c2e139c51f55d40e" + } +} +``` + +
+ +--- + +### `wallet_log_in` + +Functionality: Request that the wallet service be logged in to the specified fingerprint + +Usage: `chia data wallet_log_in [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 wallet in config.yaml | +| -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 new file mode 100644 index 00000000000..8f137c1cf65 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/did-cli.md @@ -0,0 +1,438 @@ +--- +sidebar_label: DIDs +title: DID CLI +slug: /reference-client/cli-reference/did-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This document is a comprehensive listing of CLI commands for interacting with Chia DIDs. + +## Reference + +### `create` + +Functionality: Create a DID wallet + +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. | + +
Example + +Create a new DID: + +```bash +chia wallet did create -n My_DID +``` + +Response: + +``` +Successfully created a DID wallet with name My_DID and id 2 on key 4288332900 +Successfully created a DID did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 in the newly created DID wallet +``` + +View your wallet and DID: + +```bash +chia wallet show +``` + +Response: + +``` +Wallet height: 1117451 +Sync status: Synced +Balances, fingerprint: 4288332900 + +Chia Wallet: + -Total Balance: 0.999989999992 txch (999989999992 mojo) + -Pending Total Balance: 0.999989999991 txch (999989999991 mojo) + -Spendable: 0.0 txch (0 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +My_DID: + -Total Balance: 0.0 + -Pending Total Balance: 1.0 + -Spendable: 0.0 + -Type: DECENTRALIZED_ID + -DID ID: did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 + -Wallet ID: 2 +``` + +
+ +--- + +### `find_lost` + +Functionality: Find the did you should own and recover the DID wallet + +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. | + +
Example + +Locate a DID owned by the local wallet: + +```bash +chia wallet did find_lost -id did:chia:1gam05w9xhdc406t03w79pst7hrhs36yw70ekg7hdsxvgds703kpskr64tz +``` + +Response: + +``` +Successfully found lost DID did:chia:1gam05w9xhdc406t03w79pst7hrhs36yw70ekg7hdsxvgds703kpskr64tz, latest coin ID: 618a2eee48b111517cbd4f8d11889dc78396c9bcbad11c135dcbedb12f60b58b +``` + +
+ +--- + +### `get_details` + +Functionality: Get more details of any DID + +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. | + +Note that `coin_id` could pertain to any DID, not just those owned by this wallet. + +
Example + +Get the latest details of a DID from a coin ID: + +```bash +chia wallet did get_details -id 618a2eee48b111517cbd4f8d11889dc78396c9bcbad11c135dcbedb12f60b58b -l +``` + +Response: + +``` +DID: did:chia:1gam05w9xhdc406t03w79pst7hrhs36yw70ekg7hdsxvgds703kpskr64tz +Coin ID: 618a2eee48b111517cbd4f8d11889dc78396c9bcbad11c135dcbedb12f60b58b +Inner P2 Address: xch172j7w7gzv7c8xlpju8j2qexx8d7nqjet23z5pxtxr0w8yaerrtrq0tuwae +Public Key: a03bd712b40b706102ffb9a70612bfbb7ce3aa30c81a988e3993e1cdfcc652f43d454904f483151b73abcc996fa7c02e +Launcher ID: 4776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83 +DID Metadata: {} +Recovery List Hash: 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a +Recovery Required Verifications: 0 +Last Spend Puzzle: 0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0a03bd712b40b706102ffb9a70612bfbb7ce3aa30c81a988e3993e1cdfcc652f43d454904f483151b73abcc996fa7c02eff018080ffff04ffff01a04bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459affff04ffff0180ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080 +Last Spend Solution: [['0x6bda0005da7a59d65485cc415af74cb4bafc997f8d0446c25fdfc630cda8764b', '0x56e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082', '0x01'], '0x01', ['0x01', ['0x', ['0x01', ['0x33', '0x56e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082', '0x01', ['0xf2a5e7790267b0737c32e1e4a064c63b7d304b2b54454099661bdc7277231ac6']], ['0x33', '0x02a55ce8286e3360f6c7507c7c12102a25ae85e92ee02c058a6aadcadbe11f4a', '0x', ['0x02a55ce8286e3360f6c7507c7c12102a25ae85e92ee02c058a6aadcadbe11f4a']], ['0x33', '0xbabcbe5486a1820d2f91bb738649d13e56a649c554deb3f4756f180891ec1be1', '0x', ['0xbabcbe5486a1820d2f91bb738649d13e56a649c554deb3f4756f180891ec1be1']], ['0x3c', '0xe3ce3f595a6b498335ed5519b1d31903c38da16f55efa3dfbf122113886c1295'], ['0x3d', '0x72304dc38049428843bcee366be361ce94517aa9175c936173e586d520cf0d9e'], ['0x3d', '0x07942250c330ea81e8b98c587fd3c813c5833170c6e33f63fde02386e975fe1f'], ['0x3d', '0xf4bcb562ca143b7823811d29e44f1244136c62f3b15d7d7b7d58d3b60dda3fec'], ['0x3d', '0x6f714cf3869bdd04ade21f4883d11bc2e6bbad04cc730aef8316907eaf93624f'], ['0x3f', '0x7951b5ba3108ced9a70efd7d516c9f9b913a22224b4360bd9cf318ee2ea4f8d6'], ['0x3f', '0x01347a220c1f352a890e4a9e80b47f2262e7225588d3d47654f0fb06834977ce']], '0x']]] +Last Spend Hints: ['f2a5e7790267b0737c32e1e4a064c63b7d304b2b54454099661bdc7277231ac6'] +``` + +
+ +--- + +### `get_did` + +Functionality: Get the DID and Coin ID for a DID wallet + +Usage: `chia wallet did get_did [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 | +| -h | --help | None | False | Show a help message and exit. | + +
Example + +Get info for DID with ID 2: + +```bash +chia wallet did get_did -i 2 +``` + +Response: + +``` +DID: did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 +Coin ID: 0xe6c28c30c7dd2801a4cbfdb0e61186315ae9695dde0a75a6901c1394c3300db8 +``` + +
+ +--- + +### `message_spend` + +Functionality: Generate a DID spend bundle for announcements (does not modify the blockchain) + +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. | + +
Example + +Create a default message spend bundle from a DID wallet: + +```bash +chia wallet did message_spend -i 4 +``` + +Response: + +``` +Message Spend Bundle: +{ + 'aggregated_signature': '0xad0d726ae7935978129b1c9c558b75c2b629aef893c89c3ec989c347a9eb71ddbaa83dadfe923599e7f14276eaeb84d9063d02b9b91fa561d09689716f177c0304aebb701f9c0f04eba9120b561f482e538a72ece30c086ffd942624b0962c83', + 'coin_solutions': [ + { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x0b51251268ff8c71c0d2a74495b8dce93d2a86591501e71e71d8349112ca8051', + 'puzzle_hash': '0x50f90b0ff7cdd672953ccfe8b90c2543673bc8aa56981dd7ccee1c41746f6e72' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0a03bd712b40b706102ffb9a70612bfbb7ce3aa30c81a988e3993e1cdfcc652f43d454904f483151b73abcc996fa7c02eff018080ffff04ffff01a04bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459affff04ffff0180ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080', 'solution': '0xffffa04c534c738148865f4cdb2aaef734810df68dac6cab738544630991ae46a980dfffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082ff0180ff01ffff01ffff80ffff01ffff33ffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082ff01ffffa0f2a5e7790267b0737c32e1e4a064c63b7d304b2b54454099661bdc7277231ac6808080ff80808080' + } + ] +} +``` + +
+ +--- + +### `set_name` + +Functionality: Set the name for a DID wallet + +Usage: `chia wallet did get_did [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 | +| -n | --name | TEXT | True | Set the DID wallet name | +| -h | --help | None | False | Show a help message and exit. | + +
Example + +Set the name for Wallet ID 2 to `New Name`: + +```bash +chia wallet did set_name -i 2 -n "New Name" +``` + +Response: + +``` +Successfully set a new name for DID wallet with id 2: New Name +``` + +Confirm changes: + +``` +chia wallet show +``` + +Response: + +``` +Wallet height: 1117563 +Sync status: Synced +Balances, fingerprint: 4288332900 + +Chia Wallet: + -Total Balance: 0.999989999991 txch (999989999991 mojo) + -Pending Total Balance: 0.999989999991 txch (999989999991 mojo) + -Spendable: 0.999989999991 txch (999989999991 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +New Name: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DECENTRALIZED_ID + -DID ID: did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 + -Wallet ID: 2 + +Connections: +Type IP Ports NodeID Last Connect MiB Up|Dwn +FULL_NODE 127.0.0.1 58444/58444 f40100b8... Jun 15 12:22:02 0.0|1.7 + -Height: No Info -Hash: No Info -Trusted: True +``` + +
+ +--- + +### `sign_message` + +Functionality: Sign a message using a specified DID ID. This command does not modify the blockchain. + +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 | + +
Example + +```bash +chia wallet did sign_message -f 590161281 -i did:chia:1cxw5dqug4gavvgylx88zfkmqv235ryr6j9tvyjwwuga0pa52wjvqavdyar --hex_message "This is a test message." +``` + +Response: + +``` +Message: This is a test message. +Public Key: b478c6a0ef7410679831d616d06e9fca856f6e08b8a6f13f344cc9aa20981ab7fe287663584e2fc53e2ac14edab883ca +Signature: 981ed9b983440c06ae5d9f2f2a0f45c0a00015939d30f512364f44597dc381007ee6911d9320d3c991d5a795823e429f06f35117b1e51c4c30454af19c69f2399e30bff5ea109bc5b95f869f48f2e32d0beccfcbbe72b384903536d3aeed848d +``` + +
+ +--- + +### `transfer` + +Functionality: Transfer a DID + +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 | + +
Example + +```bash +chia wallet did transfer -i 4 -ta xch1gdhch02gp6352plffxqy7ppaar2dvtnek6p2cc79nc5apqzae37sktag6l +``` + +Response: + +``` +Successfully transferred DID to xch1gdhch02gp6352plffxqy7ppaar2dvtnek6p2cc79nc5apqzae37sktag6l +Transaction ID: 0xf6d1a4158a5f278a8cbf2babca8d6894b7bac4c8601b8b564d343168430d740d +Transaction: { + 'additions': [{ + 'amount': 1, + 'parent_coin_info': '0x618a2eee48b111517cbd4f8d11889dc78396c9bcbad11c135dcbedb12f60b58b', + 'puzzle_hash': '0xc4a4c20475a5f7b3c72185c3dc792d3f56cb5325bf6c57a89947576a707c60c9' + }], + 'amount': 1, + 'confirmed': False, + 'confirmed_at_height': 0, + 'created_at_time': 1682568012, + 'fee_amount': 0, + 'memos': { + 'f61f38ceeda5e1d0a042f669cda40e62d38bc01a134efc6a057c29719702748e': '436f8bbd480ea34507e949804f043de8d4d62e79b682ac63c59e29d0805dcc7d' + }, + 'name': '0xf6d1a4158a5f278a8cbf2babca8d6894b7bac4c8601b8b564d343168430d740d', + 'removals': [{ + 'amount': 1, + 'parent_coin_info': '0x0b51251268ff8c71c0d2a74495b8dce93d2a86591501e71e71d8349112ca8051', + 'puzzle_hash': '0x50f90b0ff7cdd672953ccfe8b90c2543673bc8aa56981dd7ccee1c41746f6e72' + }], + 'sent': 0, + 'sent_to': [], + 'spend_bundle': { + 'aggregated_signature': '0x8afa4a5d523bebc954c6c0869c10030b3d3c3bb31853335e9a68ab05686708e9e87ab0a45893f278bf079727f28baada16fcb2141c6b76386b78e71b1c02e0f199a852f111005fbd7fe0466a82753f59a3209f862f067ca3f7241c88c5202091', + 'coin_spends': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x0b51251268ff8c71c0d2a74495b8dce93d2a86591501e71e71d8349112ca8051', + 'puzzle_hash': '0x50f90b0ff7cdd672953ccfe8b90c2543673bc8aa56981dd7ccee1c41746f6e72' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0a03bd712b40b706102ffb9a70612bfbb7ce3aa30c81a988e3993e1cdfcc652f43d454904f483151b73abcc996fa7c02eff018080ffff04ffff01a04bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459affff04ffff0180ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080', + 'solution': '0xffffa04c534c738148865f4cdb2aaef734810df68dac6cab738544630991ae46a980dfffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082ff0180ff01ffff02ffff80ffff01ffff33ffa0856a10b0d4fc93c371fb4cf1e9c77aa0e9beb0e77e2cfafe9d6099c6c43641ebff01ffffa0436f8bbd480ea34507e949804f043de8d4d62e79b682ac63c59e29d0805dcc7d8080ffff3cffa0618a2eee48b111517cbd4f8d11889dc78396c9bcbad11c135dcbedb12f60b58b8080ff8080ff80ff80ff80ff808080' + }] + }, + 'to_address': 'xch17n77yhjjz6ur2lculgjslqqxvcqaf2a8ldmr4f0xte2auu6nl3zsg4feza', + 'to_puzzle_hash': '0xf4fde25e5216b8357f1cfa250f80066601d4aba7fb763aa5e65e55de7353fc45', + 'trade_id': None, + 'type': 1, + 'wallet_id': 4 +} +``` + +
+ +--- + +### `update_metadata` + +Functionality: Update the metadata of a DID + +Usage: `chia wallet did update_metadata [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 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 new file mode 100644 index 00000000000..0d9b44cbbc6 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/nft-cli.md @@ -0,0 +1,812 @@ +--- +sidebar_label: NFTs +title: NFT CLI +slug: /reference-client/cli-reference/nft-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Reference + +### `create` + +Functionality: Create an NFT wallet + +Usage: chia wallet nft 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 | +| -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 | + +
Example 1 - Create an NFT wallet that is not linked to a DID + +Create an NFT Wallet: + +```bash +chia wallet nft create +``` + +Response: + +``` +Successfully created an NFT wallet with id 3 on key 4288332900 +``` + +
+ +
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" +``` + +Response: + +``` +Successfully created an NFT wallet with id 4 on key 4288332900 +``` + +
+
Show both of these NFT wallets + +```bash +chia wallet show +``` + +Response: + +``` +Wallet height: 1117958 +Sync status: Synced +Balances, fingerprint: 4288332900 + +Chia Wallet: + -Total Balance: 0.999989999991 txch (999989999991 mojo) + -Pending Total Balance: 0.999989999991 txch (999989999991 mojo) + -Spendable: 0.999989999991 txch (999989999991 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +New Name: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DECENTRALIZED_ID + -DID ID: did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 + -Wallet ID: 2 + +NFT Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: NFT + -Wallet ID: 3 + +DID-linked NFT Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: NFT + -DID ID: did:chia:17jvhl9z8zj6jma2uxk4mqj22p90hfpf29svlvlyalu8ksyefsvpql7f403 + -Wallet ID: 4 +``` + +
+ +--- + +### `mint` + +Functionality: Mint an NFT + +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 + +```bash +chia wallet nft mint -i 3 -u https://images.pexels.com/photos/11053072/pexels-photo-11053072.jpeg -nh 14836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0 +``` + +Response: + +``` +NFT minted Successfully with spend bundle: +{ + 'aggregated_signature': '0x955e7af8daabdc133b403e6339aaf8db62547bb248b506cedaa66caba69878b93db40297b92ea33d793eb966da7bb9fb0a962830d9cb979c8f92380f29208fd5db9ffb6074945df165ef59aa8910f1f1aa2dba874cfe98bfa7991e10e80a2935', + 'coin_solutions': [{ + 'coin': { + 'amount': 999989999991, + 'parent_coin_info': '0x544366ddf25f8422c0e369eebdf7d0c06b9319c66a3225fcd59d8daed7647a5d' + 'puzzle_hash': '0x05dd4fb123b88ee430282e76beec1f486a0323d69be8dc6f0980de8675df8bb9' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b08fd89a87f712de13cc48ebe15ab7fe57975e61900924b32cb83895b990836bacec7cf331a51ff0c03a97f10c92f9722aff018080', + 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0ff408b795e816dcef40ca081b10aa0e1cff7ff34313455e9d71be9097809582bff8600e8d40c797680ffff3cffa04b296555bd48d1b50d02982ba9b1bcabff474fb6171955f932b50951048424e980ffff3dffa0014a582b02e9f7e3edbf99707b18d155c7348d3a84e87492271f435f923cd9be8080ff8080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0xab48568ee3b109a71d1bb097da77a3c4c5eee7e9add00dee779bf62323598cc7', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', + 'solution': '0xffa084d00d38505206aba8b1658ab6502b6364ff8c39ab05c3d5f25984302fb1e176ff01ff8080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0xe961030a239afe44b11b4fcb89edb98520d32737555e90021e3b0f7ea8d05e8c', + 'puzzle_hash': '0x84d00d38505206aba8b1658ab6502b6364ff8c39ab05c3d5f25984302fb1e176' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0e961030a239afe44b11b4fcb89edb98520d32737555e90021e3b0f7ea8d05e8ca0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff01ff0180808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a031f5e810e2ad078817e8b047306c877ad82c77511aa235179c4a98af413f162affff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d7580ffff826d6800ffff826c7580ffff826c6800ffff82736e01ffff8273740180ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0862ce162a88bbac828dee02d318618d15b1b1d6a8a3f46ad8d5c15fd26e51f4115b3d3f9f9025edb581ce70ca084cda4ff018080ff018080808080ff01808080', + 'solution': '0xffffa0ab48568ee3b109a71d1bb097da77a3c4c5eee7e9add00dee779bf62323598cc7ff0180ff01ffffff80ffff01ffff33ffa0ab8ba18db3cf4f3a2b355a71490013f5273372760cbd991886ef3c05e1ff3ef2ff01ffffa0ab8ba18db3cf4f3a2b355a71490013f5273372760cbd991886ef3c05e1ff3ef2808080ff8080ff018080' + } +]} +``` + +
+ +
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 +``` + +Response: + +``` +NFT minted Successfully with spend bundle: +{ + 'aggregated_signature': '0xb64cc927430004c4ea2a0691a4eaa0095a546d3895bb709f243aeae008585592bdf1bb6a1b8a47d09524969adaa53eda19218391b586302595edcb5245e1de7cb2000a24caf41de5691852d56dc6733edae73e8ee8729aad1a24676f932415e0', + 'coin_solutions': [{ + 'coin': { + 'amount': 989949999979, + 'parent_coin_info': '0x360946634ca064b8b5fb7e57700180372026071361844b7f89d4e169ea9338f8', + 'puzzle_hash': '0xab14a74b9d5db864e9fd5d0d11f273ac27833aee9ef620ce6645d0fba8af845b' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0990651e1f532086b86f02ee2105835359bb32ecc40c6bea72c7836293ce1987029b8315f46b6ee887eb7897e02555831ff018080', + 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa09c5ba7cc1bad5775e0c434159bdfc81a1291a079103e061382a0774f862ccd8dff8600e67d9e3b6a80ffff3cffa04e218ac628b8edc5e27eec0c596daf2d7d360a16db1b5b5a69b33b574ecea30280ffff3dffa0e7bf28c408f4099a590a6b9ef00c476053a3706c39021a98505bd754c5ae7fba8080ff8080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x42318b29a8000f8286f6b4fbb62b50be4f89e4d2717bdbabaad3a25903adb345', + 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', + 'solution': '0xffa02b5775837ee7f6c87e16c8e53b9fcaae0b94cb0b7f89fcaef1b539b36e0f528fff01ff8080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x219966a50132486af9c005352738fedbedd3f8f82f4ae20cb700c0f4d7c50dcc', + 'puzzle_hash': '0x2b5775837ee7f6c87e16c8e53b9fcaae0b94cb0b7f89fcaef1b539b36e0f528f' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0219966a50132486af9c005352738fedbedd3f8f82f4ae20cb700c0f4d7c50dcca0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff01ff0180808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a031f5e810e2ad078817e8b047306c877ad82c77511aa235179c4a98af413f162affff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31323035313336352f706578656c732d70686f746f2d31323035313336352e6a70656780ffff68a0fca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533fffff826d75ff9c68747470733a2f2f6d657461646174615f6578616d706c652e636f6d80ffff826c75ff9b68747470733a2f2f6c6963656e73655f6578616d706c652e636f6d80ffff82736e2affff827374820539ffff826d68a0868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823effff826c68a0358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a8280ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0b65abbed758f97032351ac630c6e7c60f60679fd3492074ef4b72e4961b8f933c5bbe05fc9b583a911b35e43df935824ff018080ff018080808080ff01808080', + 'solution': '0xffffa042318b29a8000f8286f6b4fbb62b50be4f89e4d2717bdbabaad3a25903adb345ff0180ff01ffffff80ffff01ffff33ffa01569ab9d6a71057184423ed27ad44dd4b1a5a7d05fdc843534f5f714c777d636ff01ffffa01569ab9d6a71057184423ed27ad44dd4b1a5a7d05fdc843534f5f714c777d636808080ff8080ff018080' + } +]} +``` + +Show the results of running Example 2: + +```bash +chia wallet nft list -i 2 +``` + +Response: + +``` +NFT identifier: nft1yxvkdfgpxfyx47wqq56jww87m0ka878c9a9wyr9hqrq0f479phxqps7rtf +Launcher coin ID: 219966a50132486af9c005352738fedbedd3f8f82f4ae20cb700c0f4d7c50dcc +Launcher puzhash: eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9 +Current NFT coin ID: b2084a3d30780b3b02c967135bdee387aaf9e5114ffe70275c81f7f3257157e2 +On-chain data/info: ((117 "https://images.pexels.com/photos/12051365/pexels-photo-12051365.jpeg") (104 . 0xfca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533f) (28021 "https://metadata_example.com") (27765 "https://license_example.com") (29550 . 42) (29556 . 1337) (28008 . 0x868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e) (27752 . 0x358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82)) +Owner DID: None +Royalty percentage: None +Royalty puzhash: None +NFT content hash: fca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533f +Metadata hash: 868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e +License hash: 358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82 +NFT edition total: 1337 +Current NFT edition number: 42 +Metadata updater puzhash: fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78b +NFT minting block height: 1126632 +Inner puzzle supports DID: False +NFT is pending for a transaction: False + +URIs: + https://images.pexels.com/photos/12051365/pexels-photo-12051365.jpeg + +Metadata URIs: + https://metadata_example.com + +License URIs: + https://license_example.com +``` + +
+ +
Example 3 - Mint a video NFT that is associated with a DID + +Here we'll use a direct link to a .webp file: + +```bash +chia wallet nft mint -f 3792481086 -i 5 -ra xch1u0p2yq5nez92l0rajw0699ppgu9da8hw3e8qlvphr756zf5yxn6sllagty -ta xch1yr62k5fmpj386rf0ljp3n8p9jzmxuv7axmqpmmkeuucktetummqsvqy4vw -u https://img.starstorm.io/sol3.webp -nh 186ffc3d5694c199c3d970e724d959e7ca2e13d8e7dd26e77c4bb0ddbea13dac -mu "https://pastebin.com/raw/jfuGnCMD" -mh a5b69e5875389f82f57be37ceb28972a5b7a93877982d4a62ce377a62f303159 -lu https://raw.githubusercontent.com/Chia-Network/chia-blockchain/main/LICENSE -lh 30a358857da6b49f57cfe819c1ca43bfe007f528eb784df5da5cb64577e0ffc6 -rp 300 -m 0.000615 +``` + +Response: + +```bash +NFT minted Successfully with spend bundle: +{ + 'aggregated_signature': '0x960d4d884a8d79bef02c04cba5eee28c8003e86812b3c061be546d54a5fa8eedd3adfdbcfc5b1d0d1b9e7e2e7cb8dc0c15f3b3d90e364d604376509d3c085a61ce35080b79aa54e2d36275d39995e38096b4f1f81d2262d5ca63a6e49053c783', + 'coin_solutions': [ + { + 'coin': { + 'amount': 1, 'parent_coin_info': '0x5353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357ea', 'puzzle_hash': '0xb225c8b019a6136f60cdfb00d2be02608bee62a3fbc4fe0739f6b1f7ad5f4e01' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa05353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357eaa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff04ff2cff8080808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a0a04d9f57764f54a43e4030befb4d80026e870519aaa66334aef8304f5d0393c2ffff04ffff01ffff75ffa268747470733a2f2f696d672e7374617273746f726d2e696f2f736f6c332e7765627080ffff68a0186ffc3d5694c199c3d970e724d959e7ca2e13d8e7dd26e77c4bb0ddbea13dacffff826d75ffa168747470733a2f2f706173746562696e2e636f6d2f7261772f6a6675476e434d4480ffff826c75ffc04b68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f436869612d4e6574776f726b2f636869612d626c6f636b636861696e2f6d61696e2f4c4943454e534580ffff82736e01ffff82737401ffff826d68a0a5b69e5875389f82f57be37ceb28972a5b7a93877982d4a62ce377a62f303159ffff826c68a030a358857da6b49f57cfe819c1ca43bfe007f528eb784df5da5cb64577e0ffc680ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff82ad4cff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff20ffff02ffff03ffff09ffff0122ffff0dff82029f8080ffff01ff02ffff03ffff09ffff0cff82029fff80ffff010280ff1080ffff01ff0101ff8080ff0180ff8080ff018080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff8080808080808080ff0180ff018080ffff04ffff01a0c5abea79afaa001b5427dfa0c8cf42ca6f38f5841b78f9b3c252733eb2de2726ffff04ffff0180ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff04ff82013fffff04ff80ffff04ffff02ffff03ffff22ff82013fffff20ffff09ff82013fff2f808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8205bfffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff82013fff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ff0180ff80808080ffff01ff04ff2fffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff17ffff01ff04ffff04ff10ffff04ffff0bff81a7ffff02ff3effff04ff02ffff04ffff04ff2fffff04ffff04ff05ffff04ffff05ffff14ffff12ff47ff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fff8080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa05353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357eaa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0e3c2a20293c88aafbc7d939fa29421470ade9eee8e4e0fb0371fa9a1268434f5ffff04ffff0182012cff0180808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b099b5094c03d5b43a0361c5fad9918bfe52ed120b0732b9a0ae19387bc07772afedb2ad3804963b948a8817218671df67ff018080ff018080808080ff018080808080ff01808080', 'solution': '0xffffa0fa5ea9623319a1d69ec45ea5c05bf17b299afacc250bca7a73e9e41a15ea6710ff0180ff01ffffffff80ffff01ffff81f6ffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83ff80ffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe808280ffff33ffa020f4ab513b0ca27d0d2ffc83199c2590b66e33dd36c01deed9e73165e57cdec1ff01ffffa020f4ab513b0ca27d0d2ffc83199c2590b66e33dd36c01deed9e73165e57cdec1ffa020f4ab513b0ca27d0d2ffc83199c2590b66e33dd36c01deed9e73165e57cdec1808080ff8080808080' + }, { + 'coin': { + 'amount': 64428799996, 'parent_coin_info': '0x329fcd88f889e7c36455960ec3b5b1e96bb70c85f60737381b4991030878c56a', 'puzzle_hash': '0xdb30018910a67bf20b702e4f97e754c75781f57727ac2e91e595fbacb133777d' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0813e0edff6ed8951954b31bd69755ca576df4e786ec7f99148d38fc357a9b8f35082d862c95107f8fac3ec1c10dd524cff018080', 'solution': '0xff80ffff01ffff33ffa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ff0180ffff33ffa0d5ce3fb2ffffd883c20a6dda284036603e102f509f18d99e7e8c75ac8c4d914cff850edb99503b80ffff34ff8424a827c080ffff3cffa0d972ec444a34cd446cf3eca415e682fadaf37a3e720ceba514547275bb53a65980ffff3dffa0d0c9b5213d779b6c8588e3defcfc2464da971c302b5dc7e4745950ca26fe50b28080ff8080' + }, { + 'coin': { + 'amount': 1, 'parent_coin_info': '0xfa5ea9623319a1d69ec45ea5c05bf17b299afacc250bca7a73e9e41a15ea6710', 'puzzle_hash': '0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9' + }, + 'puzzle_reveal': '0xff02ffff01ff04ffff04ff04ffff04ff05ffff04ff0bff80808080ffff04ffff04ff0affff04ffff02ff0effff04ff02ffff04ffff04ff05ffff04ff0bffff04ff17ff80808080ff80808080ff808080ff808080ffff04ffff01ff33ff3cff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff0effff04ff02ffff04ff09ff80808080ffff02ff0effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080', 'solution': '0xffa0b225c8b019a6136f60cdfb00d2be02608bee62a3fbc4fe0739f6b1f7ad5f4e01ff01ff8080' + }, { + 'coin': { + 'amount': 1, 'parent_coin_info': '0x51f92f08fa0ea0b8f4f69d97e8661df327a24176fc5ad093be0d2960923c470f', 'puzzle_hash': '0x50f90b0ff7cdd672953ccfe8b90c2543673bc8aa56981dd7ccee1c41746f6e72' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0a03bd712b40b706102ffb9a70612bfbb7ce3aa30c81a988e3993e1cdfcc652f43d454904f483151b73abcc996fa7c02eff018080ffff04ffff01a04bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459affff04ffff0180ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa04776fa38a6bb7157e96f8bbc50c17eb8ef08e88ef3f3647aed819886c3cf8d83a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080', 'solution': '0xffffa04e2e84217422393f61f62d02762e4e543b05eabd08dea30117a5e57313a550f8ffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082ff0180ff01ffff01ffff80ffff01ffff33ffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe8082ff01ffffa056e33fc1fe1a970cbdedb90559097186587fdd4d484b4fef2d96bd4f3afe80828080ffff3effa05353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357ea8080ff80808080' + } + ] +} +``` + +
+ +--- + +### `set_did` + +Functionality: Set the DID associated with an NFT + +Usage: chia wallet nft set_did [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 | +| -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 + +Set the DID on an NFT in wallet `2` and include a 1-mojo fee: + +```bash +chia wallet nft set_did -f 590161281 -i 2 -di did:chia:1cxw5dqug4gavvgylx88zfkmqv235ryr6j9tvyjwwuga0pa52wjvqavdyar -ni 0xf3450f0cc18e1ded3615eb2ce52bc67be8550ff03fa128f4515b49d157a3d9ad -m 0.000000000001 +``` + +Response: + +``` +Transaction to set DID on NFT has been initiated with: {'aggregated_signature': '0x9925e60697330c525c9a2ba03fa923a10d49c00a37caaecfb6d298fb5ff0eb73c05278ea02f9c90a0399c24a548fbe61002c38988e8d9af0bef4b137b086beee393d547ca70de3b19cc7e698bd8bb89b21ecd0cad23437e0a736db5a6c0ef712', 'coin_solutions': [{'coin': {'amount': 1, 'parent_coin_info': '0xac2e92501afd2c4e9f5ac2dd9d1b997b01fec0f3f40ac2cb3c2d7472f0f3555d', 'puzzle_hash': '0x1a2e7976000f4775ff9d81cd8f6033c9e02e252195632a2da30e3d9e12e55eef'}, 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa05353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357eaa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff04ff2cff8080808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a0a04d9f57764f54a43e4030befb4d80026e870519aaa66334aef8304f5d0393c2ffff04ffff01ffff75ffa268747470733a2f2f696d672e7374617273746f726d2e696f2f736f6c332e7765627080ffff68a0186ffc3d5694c199c3d970e724d959e7ca2e13d8e7dd26e77c4bb0ddbea13dacffff826d75ffa168747470733a2f2f706173746562696e2e636f6d2f7261772f6a6675476e434d4480ffff826c75ffc04b68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f436869612d4e6574776f726b2f636869612d626c6f636b636861696e2f6d61696e2f4c4943454e534580ffff82736e01ffff82737401ffff826d68a0a5b69e5875389f82f57be37ceb28972a5b7a93877982d4a62ce377a62f303159ffff826c68a030a358857da6b49f57cfe819c1ca43bfe007f528eb784df5da5cb64577e0ffc680ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff82ad4cff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff20ffff02ffff03ffff09ffff0122ffff0dff82029f8080ffff01ff02ffff03ffff09ffff0cff82029fff80ffff010280ff1080ffff01ff0101ff8080ff0180ff8080ff018080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff8080808080808080ff0180ff018080ffff04ffff01a0c5abea79afaa001b5427dfa0c8cf42ca6f38f5841b78f9b3c252733eb2de2726ffff04ffff0180ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff04ff82013fffff04ff80ffff04ffff02ffff03ffff22ff82013fffff20ffff09ff82013fff2f808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8205bfffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff82013fff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff8202bfffff04ff15ff8080808080808080ff0180ff80808080ffff01ff04ff2fffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff17ffff01ff04ffff04ff10ffff04ffff0bff81a7ffff02ff3effff04ff02ffff04ffff04ff2fffff04ffff04ff05ffff04ffff05ffff14ffff12ff47ff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fff8080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa05353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357eaa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0e3c2a20293c88aafbc7d939fa29421470ade9eee8e4e0fb0371fa9a1268434f5ffff04ffff0182012cff0180808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0a5b35d3370745ae7634022ddd970379b4ed4acdd2d34622f1dfdf2b9923b16ac6e8b317abcf1cc8beb1e882d341e4458ff018080ff018080808080ff018080808080ff01808080', 'solution': '0xffffa0473da488ddc642669776c16b532efa460a48978b108e25b0a2f8e98ee8ab0290ffa0849e6585823e5b86aadf1950c8d910c361861c88cbfc3ae2552e5ba485d22ba5ff0180ff01ffffffff80ffff01ffff81f6ffa0c19d468388aa3ac6209f31ce24db6062a341907a9156c249cee23af0f68a7498ff80ffa0d58b4b9af7ef78eb649e45cc07b7aa502425639da56cae73560d5cd34cf8c93c80ffff33ffa0c6effdca80227b7e5aa836b666f37d92ada01bdc207af232263675e31148b2c9ff01ffffa0c6effdca80227b7e5aa836b666f37d92ada01bdc207af232263675e31148b2c98080ffff3cffa0f3450f0cc18e1ded3615eb2ce52bc67be8550ff03fa128f4515b49d157a3d9ad8080ff8080808080'}, {'coin': {'amount': 1, 'parent_coin_info': '0xb9d3d05020ebbd6279923377abf33a2cf9714e153f8f283b7b39b7417d1f72ef', 'puzzle_hash': '0x38d332b735c5b1a94b239a4019b9d7b6de4e5846b1d29bc174940e2fbbec7f8f'}, 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3480ffff01ff04ffff04ff20ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff02ff2affff04ff02ffff04ff27ffff04ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff04ffff02ffff03ff77ffff0181b7ffff015780ff0180ff808080808080ffff04ff77ff808080808080ffff02ff3affff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffffff4947ff0233ffff0401ff0102ffffff20ff02ffff03ff05ffff01ff02ff32ffff04ff02ffff04ff0dffff04ffff0bff3cffff0bff34ff2480ffff0bff3cffff0bff3cffff0bff34ff2c80ff0980ffff0bff3cff0bffff0bff34ff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ffff22ffff09ffff0dff0580ff2280ffff09ffff0dff0b80ff2280ffff15ff17ffff0181ff8080ffff01ff0bff05ff0bff1780ffff01ff088080ff0180ff02ffff03ff0bffff01ff02ffff03ffff02ff26ffff04ff02ffff04ff13ff80808080ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff34ff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff3affff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ffffff02ffff03ffff09ff09ff3880ffff01ff02ffff03ffff18ff2dffff010180ffff01ff0101ff8080ff0180ff8080ff0180ff0bff3cffff0bff34ff2880ffff0bff3cffff0bff3cffff0bff34ff2c80ff0580ffff0bff3cffff02ff32ffff04ff02ffff04ff07ffff04ffff0bff34ff3480ff8080808080ffff0bff34ff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff30ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa0c19d468388aa3ac6209f31ce24db6062a341907a9156c249cee23af0f68a7498a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0b478c6a0ef7410679831d616d06e9fca856f6e08b8a6f13f344cc9aa20981ab7fe287663584e2fc53e2ac14edab883caff018080ffff04ffff01a04bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459affff04ffff0180ffff04ffff01ffa07faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9fffa0c19d468388aa3ac6209f31ce24db6062a341907a9156c249cee23af0f68a7498a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080', 'solution': '0xffffa0867f36aff7b70937076b33d6d1ed6851583d009571a664a260f2f0ac6a429c40ffa0d58b4b9af7ef78eb649e45cc07b7aa502425639da56cae73560d5cd34cf8c93cff0180ff01ffff01ffff80ffff01ffff33ffa0d58b4b9af7ef78eb649e45cc07b7aa502425639da56cae73560d5cd34cf8c93cff01ffffa02c3d72acbdb2cc5930bb2f4b5d4f79ca9e8ec0217a9e17eac515a1f1344f9ac88080ffff3effa05353f6bfde64e24706ac698bf920bab1cb608f52f81d6dfbe8ea6283c9d357ea8080ff80808080'}, {'coin': {'amount': 1, 'parent_coin_info': '0x2fb76e4abf88c1bb6033690a9748a873383774690265cbe19eff01970c8cde1a', 'puzzle_hash': '0x9e5ee1d992073324d0b008d17c6258d7bc878296cb03c11791567fac8414e097'}, 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b083e11f56edd8a9983dd41ea03c11637cacb98fda9148947c58357c2fb7bae53b626396972fef4d7850c30221dd89eb75ff018080', 'solution': '0xff80ffff01ffff34ff0180ffff3cffa0c2bb979a83aaa27152aec128b6cf6f8ec56519fea8d51f021779bb05afad14c380ffff3dffa04e1c8e72798000467d29eece739a92e24edf34dc7cc099a0517b3f8b0c29c6678080ff8080'}]} +``` + +
+ +--- + +### `sign_message` + +Functionality: Sign a message using a specified NFT ID. This command does not modify the blockchain. + +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 | + +
Example 1: Basic signing + +```bash +chia wallet nft sign_message -f 590161281 -i nft12dfld077vn3ywp4vdx9ljg96k89kpr6jlqwkm7lgaf3g8jwn2l4q6eytqs -m "This is a test message." +``` + +Response: + +``` +Message: This is a test message. +Public Key: a5b35d3370745ae7634022ddd970379b4ed4acdd2d34622f1dfdf2b9923b16ac6e8b317abcf1cc8beb1e882d341e4458 +Signature: 88eb8bacdc6b19614aa7744c3b3809e3c0ff76ba398fe6eebb7eaeb2fcb35452243edf85f31c92bdc17422511cc529fc16c95d62d91b58ec2b01986d6d768fe2a332edab95057b5ed2c1682d5817b2fc6694a6f1ebd3ee9040d5760c4a230c0d +``` + +
+ +
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). + +Start by signing a message: + +```bash +chia wallet nft sign_message -f 52772570 -i nft1srnr973dl9hqlswfl9wz5f2xap27ue8057yf6hw2erav2tf987vs4ql9y2 -m 'happy happy joy joy' +``` + +Response: + +``` +Message: happy happy joy joy +Public Key: a563d59587cb79ca4ecd544733955f869e9f0f41d0707bc3ada31058917566defd4a1560b528b2bd6849b7c7f29de308 +Signature: 8b7b6fa8cd7689313df0900a726309f40100020f9a1e6ffdf8c0fd043057c383dbbec76cb091b5943330c215831225570be2bf966a148a334e17d8fc888f36a7a08e71faf4ffb3418a0b18a965fbed4208fa83da02071c7c192a80c8ceb8f2b6 +Signing Mode: BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_AUG:CHIP-0002_ +``` + +Next, let's say you want to verify whether the above signature came from a specific NFT. Start by obtaining the NFT's information: + +```bash +chia rpc wallet nft_get_info '{"coin_id":"nft1srnr973dl9hqlswfl9wz5f2xap27ue8057yf6hw2erav2tf987vs4ql9y2"}' +``` + +Note the `p2_address` in the response: + +```bash +{ + "nft_info": { + "chain_info": "((117 \"https://bafybeibhw4np3amsybmddqohgkkxgcbsl3x7lc2pagckc6u422zhz6liai.ipfs.nftstorage.link/8.png\") (104 . 0x57bab753284cad6800460fddfca94f916a0d98a8b5329318075472a31fa22a74) (28021 \"https://bafybeibhw4np3amsybmddqohgkkxgcbsl3x7lc2pagckc6u422zhz6liai.ipfs.nftstorage.link/8.json\") (27765) (29550 . 1) (29556 . 1) (28008 . 0xf1ae0cd509485cfe8f273163ba6dfdd4a7465de3cd2cc912265c420f3768338a))", + "data_hash": "0x57bab753284cad6800460fddfca94f916a0d98a8b5329318075472a31fa22a74", + "data_uris": [ + "https://bafybeibhw4np3amsybmddqohgkkxgcbsl3x7lc2pagckc6u422zhz6liai.ipfs.nftstorage.link/8.png" + ], + "edition_number": 1, + "edition_total": 1, + "launcher_id": "0x80e632fa2df96e0fc1c9f95c2a2546e855ee64efa7889d5dcac8fac52d253f99", + "launcher_puzhash": "0xeff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9", + "license_hash": "0x", + "license_uris": [], + "metadata_hash": "0xf1ae0cd509485cfe8f273163ba6dfdd4a7465de3cd2cc912265c420f3768338a", + "metadata_uris": [ + "https://bafybeibhw4np3amsybmddqohgkkxgcbsl3x7lc2pagckc6u422zhz6liai.ipfs.nftstorage.link/8.json" + ], + "mint_height": 2130045, + "minter_did": null, + "nft_coin_id": "0x6cd6c98916e8fcb6ad8c0fcf28cd2ed8b65c8163f7072bf491366a99f26770ce", + "off_chain_metadata": null, + "owner_did": null, + "p2_address": "0x56eaa066a0d202ffa30cf6a9ecc6d13002c32cc16d9507ef83ae9b8972a9700a", + "pending_transaction": false, + "royalty_percentage": null, + "royalty_puzzle_hash": null, + "supports_did": false, + "updater_puzhash": "0xfe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78b" + }, + "success": true +} +``` + +Next, convert the `p2_address` to an address. Spacescan.io has a [tool](https://www.spacescan.io/tools/puzzlehashconverter) that will perform this conversion. +It is also possible to do this conversion from the command line with the [chia-dev-tools repo](https://github.com/Chia-Network/chia-dev-tools), as shown here: + +```bash +cdv encode --prefix txch 0x56eaa066a0d202ffa30cf6a9ecc6d13002c32cc16d9507ef83ae9b8972a9700a +``` + +Note that the `--prefix` flag is only needed if you are not running on mainnet. In this case, the resulting address begins with `txch`: + +```bash +txch12m42qe4q6gp0lgcv7657e3k3xqpvxtxpdk2s0mur46dcju4fwq9qx5g0vx +``` + +Finally, call the `verify_signature` wallet RPC and pass in the address you just obtained: + +``` +chia rpc wallet verify_signature '{ + "pubkey": "a563d59587cb79ca4ecd544733955f869e9f0f41d0707bc3ada31058917566defd4a1560b528b2bd6849b7c7f29de308", + "signature": "8b7b6fa8cd7689313df0900a726309f40100020f9a1e6ffdf8c0fd043057c383dbbec76cb091b5943330c215831225570be2bf966a148a334e17d8fc888f36a7a08e71faf4ffb3418a0b18a965fbed4208fa83da02071c7c192a80c8ceb8f2b6", + "signing_mode": "BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_AUG:CHIP-0002_", + "message": "happy happy joy joy", + "address": "txch12m42qe4q6gp0lgcv7657e3k3xqpvxtxpdk2s0mur46dcju4fwq9qx5g0vx" +}' +``` + +The result shows that the signature is valid: + +``` +{ + "isValid": true, + "success": true +} +``` + +
+ +--- + +### `list` + +Functionality: List the current NFTs + +Usage: chia wallet nft list [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 | +| | --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 + +```bash +chia wallet nft list -i 2 +``` + +Response: + +``` +NFT identifier: nft1yxvkdfgpxfyx47wqq56jww87m0ka878c9a9wyr9hqrq0f479phxqps7rtf +Launcher coin ID: 219966a50132486af9c005352738fedbedd3f8f82f4ae20cb700c0f4d7c50dcc +Launcher puzhash: eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9 +Current NFT coin ID: b2084a3d30780b3b02c967135bdee387aaf9e5114ffe70275c81f7f3257157e2 +On-chain data/info: ((117 "https://images.pexels.com/photos/12051365/pexels-photo-12051365.jpeg") (104 . 0xfca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533f) (28021 "https://metadata_example.com") (27765 "https://license_example.com") (29550 . 42) (29556 . 1337) (28008 . 0x868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e) (27752 . 0x358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82)) +Owner DID: None +Royalty percentage: None +Royalty puzhash: None +NFT content hash: fca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533f +Metadata hash: 868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e +License hash: 358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82 +NFT edition total: 1337 +Current NFT edition number: 42 +Metadata updater puzhash: fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78b +NFT minting block height: 1126632 +Inner puzzle supports DID: False +NFT is pending for a transaction: False + +URIs: + https://images.pexels.com/photos/12051365/pexels-photo-12051365.jpeg + +Metadata URIs: + https://metadata_example.com + +License URIs: + https://license_example.com +``` + +
+ +
Example 2 - Show NFTs from a wallet that is associated with a DID + +```bash +chia wallet nft list -i 4 +``` + +Response: + +``` +NFT identifier: nft1s5hlcv0q3edg5vf33dkzrg0z35dnhch5tszntcma0zc7mcrpqurqlhwceh +Launcher coin ID: 852ffc31e08e5a8a31318b6c21a1e28d1b3be2f45c0535e37d78b1ede0610706 +Launcher puzhash: eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9 +Current NFT coin ID: 48e92b64a0a5b7f4c7b6d9df1d1766901785ef26970113eb01c64f3444c5c56d +On-chain data/info: ((117 "https://images.pexels.com/photos/11053072/pexels-photo-11053072.jpeg") (104 . 0x14836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0) (28021 "https://metadata_example.com") (27765 "https://license_example.com") (29550 . 42) (29556 . 1337) (28008 . 0x868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e) (27752 . 0x358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82)) +Owner DID: did:chia:16kgxghw80cjlytl7x7zxuuux32v308fnmcgkfrh652rtcdqexm4q7gsarr +Royalty percentage: 300 +Royalty puzhash: 1aaf838ba6d832bb3b80114b3805ddf37f7990dae70df59e031c1aa9f830c392 +NFT content hash: 14836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0 +Metadata hash: 868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823e +License hash: 358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a82 +NFT edition total: 1337 +Current NFT edition number: 42 +Metadata updater puzhash: fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78b +NFT minting block height: 1126708 +Inner puzzle supports DID: True +NFT is pending for a transaction: False + +URIs: + https://images.pexels.com/photos/11053072/pexels-photo-11053072.jpeg + +Metadata URIs: + https://metadata_example.com + +License URIs: + https://license_example.com +``` + +
+ +--- + +### `get_info` + +Functionality: Get info about an NFT + +Usage: chia wallet nft get_info [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 | +| -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 + +Get coin info by NFT Coin ID: + +```bash +chia wallet nft get_info -ni 1338537ad709b6b99430216519780dbee187a3057ce1130ef750d28ccb97e14a +``` + +Response: + +``` +NFT identifier: nft1hf22udrkfvpykwm6fu826e0xdeflha2d99tr7zdnvzuh36leahcsu7h2c3 +Launcher coin ID: ba54ae34764b024b3b7a4f0ead65e66e53fbf54d29563f09b360b978ebf9edf1 +Launcher puzhash: eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9 +Current NFT coin ID: 1338537ad709b6b99430216519780dbee187a3057ce1130ef750d28ccb97e14a +On-chain data/info: ((117 "https://images.pexels.com/photos/11053072/pexels-photo-11053072.jpeg") (104 . 0x14836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0) (28021) (27765) (29550 . 1) (29556 . 1)) +Owner DID: None +Royalty percentage: None +Royalty puzhash: None +NFT content hash: 14836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0 +Metadata hash: +License hash: +NFT edition total: 1 +Current NFT edition number: 1 +Metadata updater puzhash: fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78b +NFT minting block height: 1127233 +Inner puzzle supports DID: False +NFT is pending for a transaction: False + +URIs: + https://images.pexels.com/photos/11053072/pexels-photo-11053072.jpeg + +Metadata URIs: + +License URIs: +``` + +
+ +--- + +### `transfer` + +Functionality: Transfer an NFT + +Usage: chia wallet nft 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 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 + +This recipient in this example will be a common burn address (an address for which nobody has the private key): + +```bash +chia wallet nft transfer -i 2 -ni 889b12b6d4585bb63f51cf9b4e6ac138c2042330c0f3d386d40be6a4a42b9a4a -ta txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh +``` + +Response: + +``` +NFT transferred successfully with spend bundle: +{ + 'aggregated_signature': '0x86f5ca73687ac07518d933f8994b7e6dd73c0359b5266aab7fa744931082bd1220421a65c32900f0a20c66febfb599ba025b45119f5f3312b7abfcb2ae12dfd634b8ad206e227a877782d6c89ed25e7e543af07d31b49650214084add93960f3', + 'coin_solutions': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x0520b0fb4e64341a1eac44ef5f3e7da59650e5d525dce445d3e081783998ce98', + 'puzzle_hash': '0x1c6cbebe36eb2bf3c90e819feeea0c35ad6ead5b10773e10a87821f50acf9ba1' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0e961030a239afe44b11b4fcb89edb98520d32737555e90021e3b0f7ea8d05e8ca0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff01ff0180808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a031f5e810e2ad078817e8b047306c877ad82c77511aa235179c4a98af413f162affff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d7580ffff826d6800ffff826c7580ffff826c6800ffff82736e01ffff8273740180ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b080379d4ac3535dba586bcd0d6e14b87ff1e4a17451c22c68e174ec505e680fc87ff485c08f13021a9e205ee29020ed04ff018080ff018080808080ff01808080', + 'solution': '0xffffa0e961030a239afe44b11b4fcb89edb98520d32737555e90021e3b0f7ea8d05e8cffa0fc75102a5cf3cda8ffa0f8fc2474e4ca464ed1c129b58cc3c1a0fdf721b35d45ff0180ff01ffffff80ffff01ffff33ffa0000000000000000000000000000000000000000000000000000000000000deadff01ffffa0000000000000000000000000000000000000000000000000000000000000dead808080ff80808080' + } +]} +``` + +
+ +
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): + +```bash +chia wallet nft transfer -i 3 -ni 8daa6ce105509c65a7e72e74ed5fa7c46dfbd96987727c85a9808fcf7d4d98a0 -ta txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh +``` + +Response: + +``` +NFT transferred successfully with spend bundle: +{ + 'aggregated_signature': '0xa91bb34bccb51344e09a0a8ced2ef205f95e59ddd1118d54b30b2c9bd36673061ec71fef4b5018fc5538a0b1798f168e065283929f355272ee8443f8553e68d9545f260629e374ea84603fae52d98140703b5480888e0b67101df3934765dac7', + 'coin_solutions': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0x6064cdebf09a8ef51666fbbac40f6ab64321bd473b0098965d8f0486b98bdc6b', + 'puzzle_hash': '0xd56eb24bccec23d6d91cb2adb292f824c770543a242dc6be8f02e18a3e151a80' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0ebfab91ca3950beb014142f2ea0e1606e0ce11cfcd670931ff9a7009e0f2eddfa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff01ff0180808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a031f5e810e2ad078817e8b047306c877ad82c77511aa235179c4a98af413f162affff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31323035313336352f706578656c732d70686f746f2d31323035313336352e6a70656780ffff68a0fca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533fffff826d7580ffff826d6800ffff826c7580ffff826c6800ffff82736e2affff82737482053980ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff88ad4cd55cf7ad6414ff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff80ff80ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff22ffff20ffff09ffff0cff82029fff80ffff010880ff108080ffff09ffff0128ffff0dff82029f808080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ffff03ff81bfffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff80808080808080ffff01ff088080ff018080ff0180ff018080ffff04ffff01a0dacf3308015a4dd77e45a3f79c8b3cea7ec637d05554894c3eb5f779b17f379bffff04ffff01a0f4997f944714b52df55c35abb0494a095f74852a2c19f67c9dff0f6813298302ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff8202ffffff01ff04ff8204ffffff04ff80ffff04ffff02ffff03ffff22ff8204ffffff20ffff09ff8204ffff81bf808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8216ffffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff8204ffff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff2fffff04ff5fffff04ff820affffff04ff15ff80808080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff2fffff04ff5fffff04ff820affffff04ff15ff80808080808080808080ff0180ff80808080ffff01ff04ff81bfffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff5fffff01ff04ffff04ff10ffff04ffff0bffff02ffff03ff82019fffff01ff02ff2effff04ff02ffff04ff2fffff04ff17ffff04ffff0bff2cff82029f80ffff04ffff0bff2cff2f80ff80808080808080ffff011780ff0180ffff02ff3effff04ff02ffff04ffff04ff81bfffff04ffff04ff05ffff04ffff05ffff14ffff12ff82011fff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfff80808080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bff2cff058080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0ebfab91ca3950beb014142f2ea0e1606e0ce11cfcd670931ff9a7009e0f2eddfa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0c0d54c575f6193a6cc3d2e64f975a93ff0b37e13b2bcc449a36dc8ba01645eecffff04ffff0182012cffff04ffff01a0bae24162efbd568f89bc7a340798a6118df0189eb9e3f8697bcea27af99f8f79ffff04ffff01a072dec062874cd4d3aab892a0906688a1ae412b0109982e1797a170add88bdcdcff01808080808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b08fd89a87f712de13cc48ebe15ab7fe57975e61900924b32cb83895b990836bacec7cf331a51ff0c03a97f10c92f9722aff018080ff018080808080ff018080808080ff01808080', + 'solution': '0xffffa0ebfab91ca3950beb014142f2ea0e1606e0ce11cfcd670931ff9a7009e0f2eddfffa0eddf1957208ba252fcc100721f38704ed82f4de63549564ac20824290795c7c1ff0180ff01ffffffff80ffff01ffff81f6ff80ff80ff8080ffff33ffa0000000000000000000000000000000000000000000000000000000000000deadff01ffffa0000000000000000000000000000000000000000000000000000000000000dead808080ff8080808080' + } +]} +``` + +
+ +--- + +### `add_uri` + +Functionality: Add a data URI to an NFT + +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 + +Add a URI to an NFT by NFT coin ID: + +```bash +chia wallet nft add_uri -i 3 -ni 254e54c6c8f2ecec8f4f5ec8291dab47b4042b350b6f1e1852212d194fc61537 -u https://sample.uri +``` + +Response: + +``` +URI added successfully with spend bundle: +{ + 'aggregated_signature': '0xb605edf55dd94da2a22c9eafc1e18ba07740d4e2f36712a15cb17cf425f22dce38a02be75f263bf8227aca3e0649a5731650c068e58dd59571825e5310cc682894284381f6751420cd783dafc7ee044319ea14c1f0a6b3f3f6fabc2bc33d72d4', + 'coin_solutions': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0xf08bc1510b7f293724692f546e1437c5b81bf81048ffa4980218919f260d1df8', + 'puzzle_hash': '0x62b893778a69b217e4392a490c169fa1099d9710e2c273015de98f3e4be5d198' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0aada32f5ab98fa1fa007e793bf77bea2182cac7c3b700ae7a51f71133536ad85a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff01ff0180808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a031f5e810e2ad078817e8b047306c877ad82c77511aa235179c4a98af413f162affff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31323035313336352f706578656c732d70686f746f2d31323035313336352e6a70656780ffff68a0fca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533fffff826d7580ffff826d6800ffff826c7580ffff826c6800ffff82736e2affff82737482053980ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff17ffff04ff0bffff04ffff02ff2fff5f80ff80808080808080ffff04ffff01ffffff88ad4cd55cf7ad6414ff0233ffff3e04ff81f601ffffff0102ffff02ffff03ff05ffff01ff02ff2affff04ff02ffff04ff0dffff04ffff0bff32ffff0bff3cff3480ffff0bff32ffff0bff32ffff0bff3cff2280ff0980ffff0bff32ff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ff04ffff04ff38ffff04ffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ffff02ff2effff04ff02ffff04ffff02ffff03ff81afffff0181afffff010b80ff0180ff80808080ffff04ffff0bff3cff4f80ffff04ffff0bff3cff0580ff8080808080808080ff378080ff82016f80ffffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff2fffff01ff80ff80ff80ff80ff808080808080808080ff0bff32ffff0bff3cff2880ffff0bff32ffff0bff32ffff0bff3cff2280ff0580ffff0bff32ffff02ff2affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff5fffff01ff02ffff03ffff09ff82011fff3880ffff01ff02ffff03ffff09ffff18ff82059f80ff3c80ffff01ff02ffff03ffff20ff81bf80ffff01ff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff82019fffff04ff82017fff80808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff0180ffff01ff02ffff03ffff09ff82011fff2c80ffff01ff02ffff03ffff20ff82017f80ffff01ff04ffff04ff24ffff04ffff0eff10ffff02ff2effff04ff02ffff04ff82019fff8080808080ff808080ffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ffff02ff0bffff04ff17ffff04ff2fffff04ff82019fff8080808080ff8080808080808080808080ffff01ff088080ff0180ffff01ff02ffff03ffff09ff82011fff2480ffff01ff02ffff03ffff22ffff20ffff09ffff0cff82029fff80ffff010880ff108080ffff09ffff0128ffff0dff82029f808080ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff8080808080808080808080ffff01ff088080ff0180ffff01ff04ff819fffff02ff3effff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfffff04ff82017fff808080808080808080808080ff018080ff018080ff0180ffff01ff02ffff03ff81bfffff01ff02ff3affff04ff02ffff04ff05ffff04ff0bffff04ff81bfffff04ffff02ffff03ff82017fffff0182017fffff01ff02ff0bffff04ff17ffff04ff2fffff01ff808080808080ff0180ff80808080808080ffff01ff088080ff018080ff0180ff018080ffff04ffff01a0dacf3308015a4dd77e45a3f79c8b3cea7ec637d05554894c3eb5f779b17f379bffff04ffff01a0f4997f944714b52df55c35abb0494a095f74852a2c19f67c9dff0f6813298302ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff8202ffffff01ff04ff8204ffffff04ff80ffff04ffff02ffff03ffff22ff8204ffffff20ffff09ff8204ffff81bf808080ffff01ff04ffff04ff10ffff04ffff0bffff02ff2effff04ff02ffff04ff09ffff04ff8216ffffff04ffff02ff3effff04ff02ffff04ffff04ff09ffff04ff8204ffff1d8080ff80808080ff808080808080ff1580ff808080ffff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff2fffff04ff5fffff04ff820affffff04ff15ff80808080808080808080ffff01ff02ff16ffff04ff02ffff04ff0bffff04ff17ffff04ff2fffff04ff5fffff04ff820affffff04ff15ff80808080808080808080ff0180ff80808080ffff01ff04ff81bfffff01ff80ff80808080ff0180ffff04ffff01ffffff3f02ff04ff0101ffff822710ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff2cff1480ffff0bff2affff0bff2affff0bff2cff3c80ff0980ffff0bff2aff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff02ffff03ff5fffff01ff04ffff04ff10ffff04ffff0bffff02ffff03ff82019fffff01ff02ff2effff04ff02ffff04ff2fffff04ff17ffff04ffff0bff2cff82029f80ffff04ffff0bff2cff2f80ff80808080808080ffff011780ff0180ffff02ff3effff04ff02ffff04ffff04ff81bfffff04ffff04ff05ffff04ffff05ffff14ffff12ff82011fff0b80ff128080ffff04ffff04ff05ff8080ff80808080ff808080ff8080808080ff808080ffff02ff16ffff04ff02ffff04ff05ffff04ff0bffff04ff17ffff04ff2fffff04ff81dfffff04ff81bfff80808080808080808080ff8080ff0180ffff0bff2affff0bff2cff1880ffff0bff2affff0bff2affff0bff2cff3c80ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff3effff04ff02ffff04ff09ff80808080ffff02ff3effff04ff02ffff04ff0dff8080808080ffff01ff0bff2cff058080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0aada32f5ab98fa1fa007e793bf77bea2182cac7c3b700ae7a51f71133536ad85a0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01a0c0d54c575f6193a6cc3d2e64f975a93ff0b37e13b2bcc449a36dc8ba01645eecffff04ffff0182012cffff04ffff01a0bae24162efbd568f89bc7a340798a6118df0189eb9e3f8697bcea27af99f8f79ffff04ffff01a072dec062874cd4d3aab892a0906688a1ae412b0109982e1797a170add88bdcdcff01808080808080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b08fd89a87f712de13cc48ebe15ab7fe57975e61900924b32cb83895b990836bacec7cf331a51ff0c03a97f10c92f9722aff018080ff018080808080ff018080808080ff01808080', + 'solution': '0xffffa0aada32f5ab98fa1fa007e793bf77bea2182cac7c3b700ae7a51f71133536ad85ffa0c55f3fa2c44b8fb25157acff215284af585ead5eb2946c73f4dea8dab52ba836ff0180ff01ffffffff80ffff01ffff33ffa005dd4fb123b88ee430282e76beec1f486a0323d69be8dc6f0980de8675df8bb9ff01ffffa005dd4fb123b88ee430282e76beec1f486a0323d69be8dc6f0980de8675df8bb98080ffff81e8ffff02ffff01ff04ffff04ffff02ffff03ffff22ff27ff3780ffff01ff02ffff03ffff21ffff09ff27ffff01826d7580ffff09ff27ffff01826c7580ffff09ff27ffff01758080ffff01ff02ff02ffff04ff02ffff04ff05ffff04ff27ffff04ff37ff808080808080ffff010580ff0180ffff010580ff0180ffff04ff0bff808080ffff01ff808080ffff04ffff01ff02ffff03ff05ffff01ff02ffff03ffff09ff11ff0b80ffff01ff04ffff04ff0bffff04ff17ff198080ff0d80ffff01ff04ff09ffff02ff02ffff04ff02ffff04ff0dffff04ff0bffff04ff17ff8080808080808080ff0180ff8080ff0180ff018080ffff759268747470733a2f2f73616d706c652e75726980ffff81f6ff80ff80ff808080ff8080808080' + } +]} +``` + +Get new NFT info by Wallet ID: + +```bash +chia wallet nft list -i 3 +``` + +Response: + +``` +NFT identifier: nft14tdr9adtnraplgq8u7fm7aa75gvzetru8dcq4ea9rac3xdfk4kzsm47vr5 +Launcher coin ID: aada32f5ab98fa1fa007e793bf77bea2182cac7c3b700ae7a51f71133536ad85 +Launcher puzhash: eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9 +Current NFT coin ID: 02de32c2c18c5a1049cfd5192021a9a8b08388e1ecd9e915468724fe91e4669b +On-chain data/info: ((117 "https://sample.uri" "https://images.pexels.com/photos/12051365/pexels-photo-12051365.jpeg") (104 . 0xfca3e8ddae9bf8dc7d4100f36d15395744650b3751420cc647fcf973243b533f) (28021) (28008 . 0x00) (27765) (27752 . 0x00) (29550 . 42) (29556 . 1337)) +``` + +
+ +--- + +### `set_did` + +Functionality: Set a DID on an NFT + +Usage: chia wallet nft set_did [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 | +| -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 +``` + +Response: + +``` +Transaction to set DID on NFT has been initiated with: +{ + 'aggregated_signature': '0x85b31b9cab5f943e8aee056869abe5b83cf6f4ba82abf0818eb235f29776c1413980e97944dd305c11bd936b1412324e19cc5a7dbff3be62f1ed0b8fe6b7dffec019036882cc09988c76ca978164767f31af5e95f4ea919f5c7c9ec8d1fc21cc', + 'coin_solutions': [{ + 'coin': { + 'amount': 1, + 'parent_coin_info': '0xf3c16450c3bda3f913ebcb9ad8291e8bd658d3c0e166d745203106e1149df51b', + 'puzzle_hash': '0xccd5da42dd88885494d6a8fa7863310565eec33961d7425554bfeaa23d16a563' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa049285cc9f2b0990f874e1319fe26ad749f15eb89cb5fd16bd75a1bb5c2a05a0ba0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ff3effff04ff02ffff04ff05ffff04ffff02ff2fff5f80ffff04ff80ffff04ffff04ffff04ff0bffff04ff17ff808080ffff01ff808080ffff01ff8080808080808080ffff04ffff01ffffff0233ff04ff0101ffff02ff02ffff03ff05ffff01ff02ff1affff04ff02ffff04ff0dffff04ffff0bff12ffff0bff2cff1480ffff0bff12ffff0bff12ffff0bff2cff3c80ff0980ffff0bff12ff0bffff0bff2cff8080808080ff8080808080ffff010b80ff0180ffff0bff12ffff0bff2cff1080ffff0bff12ffff0bff12ffff0bff2cff3c80ff0580ffff0bff12ffff02ff1affff04ff02ffff04ff07ffff04ffff0bff2cff2c80ff8080808080ffff0bff2cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff02ffff03ff0bffff01ff02ffff03ffff09ff23ff1880ffff01ff02ffff03ffff18ff81b3ff2c80ffff01ff02ffff03ffff20ff1780ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff33ffff04ff2fffff04ff5fff8080808080808080ffff01ff088080ff0180ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff0180ffff01ff02ffff03ffff09ff23ffff0181e880ffff01ff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ffff02ffff03ffff22ffff09ffff02ff2effff04ff02ffff04ff53ff80808080ff82014f80ffff20ff5f8080ffff01ff02ff53ffff04ff818fffff04ff82014fffff04ff81b3ff8080808080ffff01ff088080ff0180ffff01ff0180808080808080ffff01ff04ff13ffff02ff3effff04ff02ffff04ff05ffff04ff1bffff04ff17ffff04ff2fffff04ff5fff80808080808080808080ff018080ff0180ffff01ff04ffff04ff18ffff04ffff02ff16ffff04ff02ffff04ff05ffff04ff27ffff04ffff0bff2cff82014f80ffff04ffff02ff2effff04ff02ffff04ff818fff80808080ffff04ffff0bff2cff0580ff8080808080808080ff378080ff81af8080ff0180ff018080ffff04ffff01a031f5e810e2ad078817e8b047306c877ad82c77511aa235179c4a98af413f162affff04ffff01ffff75ffc04468747470733a2f2f696d616765732e706578656c732e636f6d2f70686f746f732f31313035333037322f706578656c732d70686f746f2d31313035333037322e6a70656780ffff68a014836b86a48e1b2b5e857213af97534704475b4c155d34b2cb83ed4b7cba2bb0ffff826d75ff9c68747470733a2f2f6d657461646174615f6578616d706c652e636f6d80ffff826c75ff9b68747470733a2f2f6c6963656e73655f6578616d706c652e636f6d80ffff82736e2affff827374820539ffff826d68a0868463c2ae6f8a9585156c9ad9f4b9b01eeacc56fec82aa629c97135ff21823effff826c68a0358d4eb4aedefbec22824036299eff24216d213a95c8f986f862f0a89a250a8280ffff04ffff01a0fe8a4b4e27a2e29a4d3fc7ce9d527adbcaccbab6ada3903ccf3ba9a769d2d78bffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b0b905b9eb2b50c70016c7851f9f089bfc2ce28fb86106a10324408db18a401d5ae89b2f49ecbdec8c28bd23a7b9851337ff018080ff018080808080ff01808080', + 'solution': '0xffffa049285cc9f2b0990f874e1319fe26ad749f15eb89cb5fd16bd75a1bb5c2a05a0bffa093d60f351de47e725af74e1f610b9414025bd5bb22b2c1309eacdae760efb8abff0180ff01ffffff80ffff01ffff33ffa01569ab9d6a71057184423ed27ad44dd4b1a5a7d05fdc843534f5f714c777d636ff01ffffa01569ab9d6a71057184423ed27ad44dd4b1a5a7d05fdc843534f5f714c777d636808080ff80808080' + }, { + 'coin': { + 'amount': 1, + 'parent_coin_info': '0xdaefa89b6346915a8925a3c825201d21ea2b5f655766fbc9b244d5cdf0b6d3e4', + 'puzzle_hash': '0xe28652b116337599961cb6d138091bbced075a0cee2b8307360ec98c62f7e2d8' + }, + 'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ffff18ff2fff3c80ffff01ff04ffff04ff10ffff04ff2fff808080ffff04ffff02ff3effff04ff02ffff04ff05ffff04ffff0bff27ffff02ffff03ff77ffff01ff02ff36ffff04ff02ffff04ff09ffff04ff57ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ffff011d80ff0180ffff02ffff03ff77ffff0181b7ffff015780ff018080ffff04ff77ff808080808080ffff02ff26ffff04ff02ffff04ff05ffff04ffff02ff0bff5f80ffff01ff8080808080808080ffff01ff088080ff0180ffff04ffff01ffffff49ff4702ff33ff0401ffff01ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff3cff2c80ffff0bff2affff0bff2affff0bff3cff1280ff0980ffff0bff2aff0bffff0bff3cff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff0bffff01ff02ffff03ffff02ffff03ffff09ff23ff1480ffff01ff02ffff03ffff18ff81b3ff3c80ffff01ff0101ff8080ff0180ff8080ff0180ffff01ff02ffff03ffff20ff1780ffff01ff02ffff03ffff09ff81b3ffff01818f80ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff808080808080ffff01ff04ffff04ff23ffff04ffff02ff36ffff04ff02ffff04ff09ffff04ff53ffff04ffff02ff2effff04ff02ffff04ff05ff80808080ff808080808080ff738080ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff3cff8080808080808080ff0180ffff01ff088080ff0180ffff01ff04ff13ffff02ff26ffff04ff02ffff04ff05ffff04ff1bffff04ff17ff8080808080808080ff0180ffff01ff02ffff03ff17ff80ffff01ff088080ff018080ff0180ff0bff2affff0bff3cff3880ffff0bff2affff0bff2affff0bff3cff1280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff3cff3c80ff8080808080ffff0bff3cff8080808080ffff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff2effff04ff02ffff04ff09ff80808080ffff02ff2effff04ff02ffff04ff0dff8080808080ffff01ff0bff3cff058080ff0180ff02ffff03ffff21ff17ffff09ff0bff158080ffff01ff04ff28ffff04ff0bff808080ffff01ff088080ff0180ff018080ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0d590645dc77e25f22ffe37846e73868a99179d33de11648efaa286bc341936eaa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff81bfffff01ff02ff05ff82017f80ffff01ff02ffff03ffff22ffff09ffff02ff7effff04ff02ffff04ff8217ffff80808080ff0b80ffff15ff17ff808080ffff01ff04ffff04ff28ffff04ff82017fff808080ffff04ffff04ff34ffff04ff8202ffffff04ff82017fffff04ffff04ff8202ffff8080ff8080808080ffff04ffff04ff38ffff04ff822fffff808080ffff02ff26ffff04ff02ffff04ff2fffff04ff17ffff04ff8217ffffff04ff822fffffff04ff8202ffffff04ff8205ffffff04ff820bffffff01ff8080808080808080808080808080ffff01ff088080ff018080ff0180ffff04ffff01ffffffff313dff4946ffff0233ff3c04ffffff0101ff02ff02ffff03ff05ffff01ff02ff3affff04ff02ffff04ff0dffff04ffff0bff2affff0bff22ff3c80ffff0bff2affff0bff2affff0bff22ff3280ff0980ffff0bff2aff0bffff0bff22ff8080808080ff8080808080ffff010b80ff0180ffffff02ffff03ff17ffff01ff02ffff03ff82013fffff01ff04ffff04ff30ffff04ffff0bffff0bffff02ff36ffff04ff02ffff04ff05ffff04ff27ffff04ff82023fffff04ff82053fffff04ff820b3fff8080808080808080ffff02ff7effff04ff02ffff04ffff02ff2effff04ff02ffff04ff2fffff04ff5fffff04ff82017fff808080808080ff8080808080ff2f80ff808080ffff02ff26ffff04ff02ffff04ff05ffff04ff0bffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ffff10ff8202ffffff010180ff808080808080808080808080ffff01ff02ff26ffff04ff02ffff04ff05ffff04ff37ffff04ff2fffff04ff5fffff04ff8201bfffff04ff82017fffff04ff8202ffff8080808080808080808080ff0180ffff01ff02ffff03ffff15ff8202ffffff11ff0bffff01018080ffff01ff04ffff04ff20ffff04ff82017fffff04ff5fff80808080ff8080ffff01ff088080ff018080ff0180ff0bff17ffff02ff5effff04ff02ffff04ff09ffff04ff2fffff04ffff02ff7effff04ff02ffff04ffff04ff09ffff04ff0bff1d8080ff80808080ff808080808080ff5f80ffff04ffff0101ffff04ffff04ff2cffff04ff05ff808080ffff04ffff04ff20ffff04ff17ffff04ff0bff80808080ff80808080ffff0bff2affff0bff22ff2480ffff0bff2affff0bff2affff0bff22ff3280ff0580ffff0bff2affff02ff3affff04ff02ffff04ff07ffff04ffff0bff22ff2280ff8080808080ffff0bff22ff8080808080ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff7effff04ff02ffff04ff09ff80808080ffff02ff7effff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01ff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b091f4a1811c7ccdf84207e433bc470ef9aaed1f141960017918fc3427b5e3bbff3513c3023b43a2f8a66d37df12c0aaddff018080ffff04ffff01a04bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459affff04ffff0180ffff04ffff01ffa0f1e8350cec62f8204aaf867cc3c12cae369f619258206616108c6cfd7be760b3ffa0d590645dc77e25f22ffe37846e73868a99179d33de11648efaa286bc341936eaa0eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9ffff04ffff0180ff01808080808080ff01808080', + 'solution': '0xffffa0729faa60d6708cf6dd20af3c87419b8fb527b16b0510f14c50d76356f213e088ffa078a56af36aa6b98edf7a05b7bbb94d1afbb7e9640dfdbeeefba3c67f8d24c97cff0180ff01ffff01ffff80ffff01ffff33ffa078a56af36aa6b98edf7a05b7bbb94d1afbb7e9640dfdbeeefba3c67f8d24c97cff01ffffa078a56af36aa6b98edf7a05b7bbb94d1afbb7e9640dfdbeeefba3c67f8d24c97c8080ffff3effa049285cc9f2b0990f874e1319fe26ad749f15eb89cb5fd16bd75a1bb5c2a05a0b8080ff80808080' + } +]} +``` + +
+ +--- 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 new file mode 100644 index 00000000000..f4a3e0bbbe3 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/offer-cli.md @@ -0,0 +1,111 @@ +--- +sidebar_label: Offers +title: Offer CLI +slug: /reference-client/cli-reference/offer-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +
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. + +For example, here is a typical RPC command on Linux and MacOS: + +```powershell +chia rpc wallet create_new_wallet '{"wallet_type": "nft_wallet"}' +``` + +To run the same command on Windows, you need to escape the quotes, so it looks like this: + +```powershell +chia rpc wallet create_new_wallet '{\"wallet_type\": \"nft_wallet\"}' +``` + +
+ +## Reference + +### `make_offer` + +Functionality: Create an offer of XCH/CATs for XCH/CATs. + +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 | + +--- + +### **`take_offer`** + +Functionality: Examine or take an offer. + +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 | + +--- + +### **`cancel_offer`** + +Functionality: Cancel an existing offer. Must be the offer's Maker. + +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 | + +--- + +### **`get_offers`** + +Functionality: Get the status of existing offers. + +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 | 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 new file mode 100644 index 00000000000..079aa62078b --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/plotter-cli.md @@ -0,0 +1,294 @@ +--- +sidebar_label: Plotters +title: Plotters +slug: /reference-client/cli-reference/plotter-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This document is a comprehensive listing of CLI commands for creating plots from within Chia. + +## Reference + +### `chiapos` + +Functionality: Use the `chiapos` plotter + +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] | +| -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 | + +### `madmax` + +Functionality: Use the madMAx plotter + +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 | + +--- + +## `bladebit` + +Functionality: Use one of the BladeBit plotters + +Usage: chia plotters bladebit \[cudaplot | ramplot | diskplot\] \[OPTIONS\] + +### `cudaplot` + +Functionality: Use the BladeBit CUDA plotter + +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 | + +:::warning warning + +A few notes about the `disk-16` option: + +- As of BladeBit 3.0.1 (Chia 2.1.0), `disk-16` is experimental. +- This option has been disabled in the Chia 2.1.0 release. It is currently only available from the [standalone version](https://github.com/Chia-Network/bladebit/) of BladeBit. +- Plots created with this option on Linux with direct I/O disabled appear to work, but more testing is still needed. +- Plots created with this option on Windows are more likely to encounter issues. +- Be sure to check all plots created with this option, as they could be invalid even if the plotter appeared to succeed. + +::: + +:::info + +Computers with at least 256 GB of system memory should not use either the `disk-128` or `disk-16` options. +They should also not use `tmp_dir` or `tmp_dir2`. +In this case, plotting will be performed entirely in memory. + +Computers with at least 128 GB of system memory (but less than 256 GB) should use the `disk-128`, `tmp_dir`, and `tmp_dir2` options. +In this case, most of the plotting will be done in memory, and some will be done on disk. + +Linux computers with at least 16 GB of system memory (but less than 128 GB) can use the `disk-16`, `tmp_dir`, and `tmp_dir2` options. +However, **do so at your own risk**. (See the above warning for details.) +In this case, as much of the plotting as possible will be done in memory, and the rest will be done on disk. + +::: + +### `ramplot` + +Functionality: Use the BladeBit RAM plotter + +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 | + +### `diskplot` + +Functionality: Use the BladeBit disk plotter + +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 | + +### `simulate` + +Functionality: Determine your farm's maximum capacity; this command is **only** avaible with the [standalone version](https://github.com/Chia-Network/bladebit/) of BladeBit. + +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 | + +--- + +## `drplotter` + +Functionality: Use the DrPlotter plotter + +Usage: drplotter [plot | verify] [OPTIONS] + +### `plot` + +Functionality: Plot with the DrPlotter plotter + +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 | + +### `verify` + +Functionality: Verify plots with the DrPlotter plotter + +Usage: drplotter verify [OPTIONS] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -f | --file | TEXT | False | File to read from | +| -d | --directory | TEXT | False | Check all files in directory | + +--- + +## `drsolver` + +Functionality: Use the DrSolver harvester + +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 | +| | --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] | + +--- + +## `drserver` + +Functionality: Use the DrServer harvester + +Usage: drserver [OPTIONS] + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :------ | :------- | :--------------------------- | +| -h | --help | None | False | Show a help message and exit | +| -p | --port | INTEGER | True | Server port | +| -t | --token | TEXT | True | Server token | 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 new file mode 100644 index 00000000000..3c82db69528 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/simulator-cli.md @@ -0,0 +1,879 @@ +--- +sidebar_label: Simulator +title: Simulator CLI Reference +slug: /reference-client/cli-reference/simulator-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +## Intro + +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 Command Line Interface commands for using the simulator. + +For more info, see the following: + +- [Simulator User Guide](/guides/simulator-user-guide) +- [Simulator RPC API](/reference-client/rpc-reference/simulator-rpc) + +--- + +## Reference + +### `create` + +Functionality: Set up a Chia Simulator + +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 + +Use all default values, with no keys present on the local machine. + +In this case, a new key will be created, along with several k-19 plots. Finally, the simulator will be started and the genesis block will be farmed: + +```bash +chia dev sim create +``` + +Response: + +``` +Using this Directory: /home/user/.chia/simulator/main + +No keys in keychain. Press 'q' to quit, or press any other key to generate a new key. +Generating private key +Added private key with public key fingerprint 3045631419 +Creating chia directory & config... +CHIA_ROOT is set to /home/user/.chia/simulator/main +Chia directory /home/user/.chia/simulator/main +Setting Testnet +Default full node port, introducer and network setting updated +Restart any running chia services for changes to take effect +Can't find private CA, creating a new one in /home/user/.chia/simulator/main to generate TLS certificates +SSL file permissions are correct +Setting the xch destination for the farmer reward (1/8 plus fees, solo and pooling) to txch1y8efcgt9fthxzghw0xcdvru6rnvfpp4ywg0pruuztse0zweh98ws0z7j0q +Setting the xch destination address for pool reward (7/8 for solo only) to txch1y8efcgt9fthxzghw0xcdvru6rnvfpp4ywg0pruuztse0zweh98ws0z7j0q +To change the XCH destination addresses, edit the `xch_target_address` entries in /home/user/.chia/simulator/main/config/config.yaml. + +To see your keys, run 'chia keys show --show-mnemonic-seed' +Please Wait, Generating plots... +This may take up to a minute if you are on a slow machine + +Starting plotting progress into temporary dirs: /home/user/.chia/simulator/plots/tmp and /home/user/.chia/simulator/plots/tmp +ID: 11ab61868e8e25cab4db09d10813da8a02b23408683aea8e71afd907316a8509 +Plot size is: 19 +Buffer size is: 100MiB +Using 16 buckets +Final Directory is: /home/user/.chia/simulator/plots +Using 2 threads of stripe size 2000 +Process ID is: 15337 + +Starting phase 1/4: Forward Propagation into tmp files... Tue Sep 27 21:50:39 2022 +Computing table 1 +Progress update: 0.01 +F1 complete, time: 0.039 seconds. CPU (27.96%) Tue Sep 27 21:50:40 2022 +Computing table 2 +Progress update: 0.06 + Bucket 0 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 1 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 2 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 3 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 4 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 5 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 6 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 7 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 8 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 9 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 10 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 11 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 12 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 13 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 14 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 15 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Total matches: 524787 +Forward propagation table time: 0.381 seconds. CPU (88.320%) Tue Sep 27 21:50:40 2022 +Computing table 3 + +... +... + +Starting phase 4/4: Write Checkpoint tables into "/home/user/.chia/simulator/plots/tmp/plot-k19-01b3db7aa435879c6cdb8aa3b1602121ba60326e4809e0f8989cd481257290dd.plot.2.tmp" ... Tue Sep 27 21:50:53 2022 + Starting to write C1 and C3 tables + Bucket 0 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 1 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 2 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 3 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 4 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 5 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 6 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 7 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 8 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 9 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 10 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 11 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 12 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 13 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 14 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Bucket 15 QS. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. force_qs: 1 + Finished writing C1 and C3 tables + Writing C2 table + Finished writing C2 table + Final table pointers: + P1: 0x10c + P2: 0x114ef8 + P3: 0x20eedf + P4: 0x30a249 + P5: 0x40903c + P6: 0x512dca + P7: 0x642835 + C1: 0x779c35 + C2: 0x779cd1 + C3: 0x779cd7 +Time for phase 4 = 0.133 seconds. CPU (65.200%) Tue Sep 27 21:50:53 2022 +Approximate working space used (without final file): 0.019 GiB +Final File size: 0.008 GiB +Total time = 3.910 seconds. CPU (81.260%) Tue Sep 27 21:50:53 2022 +Renamed final file from "/home/user/.chia/simulator/plots/tmp/plot-k19-01b3db7aa435879c6cdb8aa3b1602121ba60326e4809e0f8989cd481257290dd.plot.2.tmp" to "/home/user/.chia/simulator/plots/plot-k19-01b3db7aa435879c6cdb8aa3b1602121ba60326e4809e0f8989cd481257290dd.plot" +New plots generated. + + +Farming & Prefarm reward address: txch1qm90eg9rx92dytr86fc4xqrjkpxxhfz59zxry24f7244u5ptlans0au950 + +Configuration Wizard Complete. +Starting Simulator now... + + +Daemon not started yet +Starting daemon +chia_full_node_simulator: started +Please wait, generating genesis block. +Farmed 1 Transaction blocks +Block Height is now: 1 +Genesis block generated, exiting. +``` + +
+ +
Example 2 + +Use all default values, with a key and plots already generated: + +```bash +chia dev sim create +``` + +Response: + +``` +Using this Directory: /home/user/.chia/simulator/main + +Fingerprints: +If you already used one of these keys, select that fingerprint to skip the plotting process. Otherwise, select any key below. +1) 3045631419 +Choose a simulator key [1-1] ('q' to quit, or 'g' to generate a new key): 1 +Creating chia directory & config... +Please Wait, Generating plots... +This may take up to a minute if you are on a slow machine +Using Existing Plots + +Farming & Prefarm reward address: txch1qm90eg9rx92dytr86fc4xqrjkpxxhfz59zxry24f7244u5ptlans0au950 + +Configuration Wizard Complete. +Starting Simulator now... + + +Daemon not started yet +Starting daemon +chia_full_node_simulator: started +Please wait, generating genesis block. +Genesis block already exists, exiting. +``` + +
+ +
Example 3 + +Add a mnemonic seed for a key that does not yet exist on this machine. + +In this case, the key will be added and plots will be generated: + +```bash +chia dev sim create --mnemonic "use scrap doll sugar october repair color owner know click awkward tragic skate bleak great jeans clean marriage wheat concert pudding sketch horse quick" +``` + +Response: + +``` +Using this Directory: /home/user/.chia/simulator/main + +Added private key with public key fingerprint 3505952827 +Creating chia directory & config... +Please Wait, Generating plots... +This may take up to a minute if you are on a slow machine + +Starting plotting progress into temporary dirs: /home/user/.chia/simulator/plots/tmp and /home/user/.chia/simulator/plots/tmp +ID: e66ecd90151b7e20a2b9a347b794bee638976816282a4eabe85170730b755821 +Plot size is: 19 +Buffer size is: 100MiB +Using 16 buckets +Final Directory is: /home/user/.chia/simulator/plots +Using 2 threads of stripe size 2000 +Process ID is: 15978 + +Starting phase 1/4: Forward Propagation into tmp files... Tue Sep 27 22:14:15 2022 +Computing table 1 +Progress update: 0.01 +F1 complete, time: 0.014 seconds. CPU (93.63%) Tue Sep 27 22:14:15 2022 +Computing table 2 +Progress update: 0.06 + Bucket 0 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 1 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 2 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 3 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 4 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 5 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 6 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 7 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 8 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 9 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 10 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 11 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 12 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 13 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Bucket 14 uniform sort. Ram: 0.088GiB, u_sort min: 0.001GiB, qs min: 0.000GiB. + Bucket 15 uniform sort. Ram: 0.088GiB, u_sort min: 0.000GiB, qs min: 0.000GiB. + Total matches: 523642 +Forward propagation table time: 0.337 seconds. CPU (88.970%) Tue Sep 27 22:14:15 2022 +Computing table 3 + +... +... + +Time for phase 4 = 0.144 seconds. CPU (61.970%) Tue Sep 27 22:14:28 2022 +Approximate working space used (without final file): 0.019 GiB +Final File size: 0.008 GiB +Total time = 4.825 seconds. CPU (70.780%) Tue Sep 27 22:14:28 2022 +Renamed final file from "/home/user/.chia/simulator/plots/tmp/plot-k19-545dc9d108ac447c16d2f6b803b2f7f9bbd7288cc04c0920a32b8c528238ae01.plot.2.tmp" to "/home/user/.chia/simulator/plots/plot-k19-545dc9d108ac447c16d2f6b803b2f7f9bbd7288cc04c0920a32b8c528238ae01.plot" +Plot /home/user/.chia/simulator/plots/plot-k19-01b3db7aa435879c6cdb8aa3b1602121ba60326e4809e0f8989cd481257290dd.plot has a farmer public key that is not in the farmer's pk list. +Plot /home/user/.chia/simulator/plots/plot-k19-088e54328bbb7cab3132fab4b7fe1fd8b1903d132a219ab9a8b1411bd518fa41.plot has a farmer public key that is not in the farmer's pk list. +Plot /home/user/.chia/simulator/plots/plot-k19-11ab61868e8e25cab4db09d10813da8a02b23408683aea8e71afd907316a8509.plot has a farmer public key that is not in the farmer's pk list. +New plots generated. + + +Farming & Prefarm reward address: txch1r6ryxsyj8s956fn5hy4lsk3v8g8jt54ghulf47ga6u66rh3utezqnsny7t + +Configuration Wizard Complete. +Starting Simulator now... + + +Daemon not started yet +Starting daemon +chia_full_node_simulator: started +Please wait, generating genesis block. +Farmed 1 Transaction blocks +Block Height is now: 1 +Genesis block generated, exiting. +``` + +
+ +--- + +### `autofarm` + +Functionality: Enable or disable auto farming on transaction submission + +Usage: `chia dev sim autofarm [OPTIONS] [on|off]` + +Options: + +| Short Command | Long Command | Type | Required | Description | +| :------------ | :----------- | :--- | :------- | :--------------------------- | +| -h | --help | None | False | Show a help message and exit | + +Auto farming is enabled by default. The examples will show you how to disable/enable it. + +
Example 1 + +Disable auto farming: + +```bash +chia dev sim autofarm off +``` + +Response: + +``` +Auto farming is now off +``` + +
+ +
Example 2 + +Enable auto farming: + +```bash +chia dev sim autofarm on +``` + +Response: + +``` +Auto farming is now on +``` + +
+ +--- + +### `farm` + +Functionality: Farm one or more blocks + +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 | + +
Example 1 + +Farm one transaction block using the default values: + +```bash +chia dev sim farm +``` + +Response: + +``` +Farmed 1 Transaction blocks +Block Height is now: 2 +``` + +
+ +
Example 2 + +Farm multiple transaction blocks: + +```bash +chia dev sim farm -b 3 +``` + +Response: + +``` +Farmed 3 Transaction blocks +Block Height is now: 5 +``` + +
+ +
Example 3 + +Farm multiple blocks (transaction or non-transaction): + +```bash +chia dev sim farm -b 3 -n +``` + +Response: + +``` +Farmed 3 blocks +Block Height is now: 8 +``` + +
+ +
Example 4 + +Farm a transaction block and send the reward to a different address. + +(WARNING: As of this writing in September 2022, this doesn't actually work. The primary address is still used. For more info, see: +https://github.com/Chia-Network/chia-dev-tools/issues/48) + +First, check the state of the primary wallet: + +```bash +chia wallet show +``` + +The wallet contains the prefarm (21 million TXCH), as well as 12 TXCH from farming rewards: + +``` +Wallet height: 8 +Sync status: Synced +Balances, fingerprint: 3446212044 + +Chia Wallet: + -Total Balance: 21000012.0 txch (21000012000000000000 mojo) + -Pending Total Balance: 21000012.0 txch (21000012000000000000 mojo) + -Spendable: 21000012.0 txch (21000012000000000000 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 +``` + +Next, farm the block. For this example we'll send the reward to the burn address: + +```bash +chia dev sim farm -a txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh +``` + +Response: + +```bash +Farmed 1 Transaction blocks +Block Height is now: 9 +``` + +To verify that the reward was not sent to the default wallet, show its status again: + +```bash +chia wallet show +``` + +Response: + +``` +Wallet height: 9 +Sync status: Synced +Balances, fingerprint: 3446212044 + +Chia Wallet: + -Total Balance: 21000014.0 txch (21000014000000000000 mojo) + -Pending Total Balance: 21000014.0 txch (21000014000000000000 mojo) + -Spendable: 21000014.0 txch (21000014000000000000 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 +``` + +
+ +--- + +### `revert` + +Functionality: Revert existing transactions and advance the chain with the reverted state intact + +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 | + +
Example 1 + +Revert the transactions from one block and advance the chain by one block: + +```bash +chia dev sim revert +``` + +Response: + +``` +All transactions in Block: 9 and above were successfully reverted. +Block Height is now: 11 +``` + +
+ +
Example 2 + +Revert transactions from three blocks and advance the chain by five blocks: + +```bash +chia dev sim revert -b 3 -n 5 +``` + +The chain was on block 12 prior to this command. Blocks 9 and above will have their transactions reverted, and the chain will advance to block 17: + +```bash +All transactions in Block: 9 and above were successfully reverted. +Block Height is now: 17 +``` + +
+ +
Example 3 + +Revert all transactions in the blockchain (note that this could take several minutes): + +```bash +chia dev sim revert -r +``` + +Response: + +```bash +All transactions in Block: 16 and above were successfully reverted. +Block Height is now: 18 +``` + +
+ +--- + +### `start` + +Functionality: Start service groups + +Usage: `chia dev sim start [OPTIONS]` + +Options: + +| 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 | + +
Example 1 + +Use the default values. This will start the daemon and the simulator, but not the wallet: + +```bash +chia dev sim start +``` + +Response: + +``` +Daemon not started yet +Starting daemon +chia_full_node_simulator: started +``` + +
+ +
Example 2 + +Status before this example: Simulator is running and wallet is not running. + +Restart the simulator and start the wallet: + +```bash +chia dev sim start -r -w +``` + +Response: + +```bash +chia_full_node_simulator: stopped +chia_full_node_simulator: started +chia_wallet: started +``` + +
+ +--- + +### `status` + +Functionality: Get information about the state of the simulator. + +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) | +| -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 | + +
Example 1 + +Show the status using the default values: + +```bash +chia dev sim status +``` + +Response: + +``` +Network: simulator0 Port: 48593 RPC Port: 18406 +Node ID: 6ca9a8ebe8ed4b2cba673666a29a75d18b3c358fee6e29153cde55ee33320261 +Genesis Challenge: eb8c4d20b322be8d9fddbf9412016bdffe9a2901d7edb0e364e94266d0e095f7 +Current Blockchain Status: Full Node Synced + +Peak: Hash: 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + Time: Wed Sep 28 2022 00:02:39 HKT Height: 10 + +Estimated network space: 15.384 MiB +Current difficulty: 1024 +Current VDF sub_slot_iters: 1024 +Total iterations since the start of the blockchain: 36460 + + Height: | Hash: + 10 | 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + 9 | e564309d7a4ad72bdf8f0dce838f5d91108ed49dddf88027aca9d8888ab86436 + 8 | a24f84ac2ccf11d43af21e2b416b92230b4f7b7db052db9a7ca9dc6ee2a9fb43 + 7 | f615455590b922362d2558e32141190ef474d60cc2a6d8f1acdeae899d798349 + 6 | 8b44d5a7e664ccbf92d34538e5f18f84c6f361871a12e797c9ce567c111ef97f + 5 | 4e79d87856af757835bf3fa083965b57c0bcadbb00ded733ca8a4451a615a3d6 + 4 | 7e3421e5448f58f2aab693aaeb506c953145d46cb9d58547a2bf53b0e35ac584 + 3 | 4c7e1e15646fa05e0d920d6b06b5574b3214568a84fb171a9dcdfe657990433a + 2 | bbb21b5a1ec18739fabcf231d15c51eb0b73900c178e4cfa329dadbef9d7a492 + 1 | 2a7df0f20b654d66fa4f77a54060855b5a9532f79b36d12bfd175831a321e6ba + +Current Farming address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2, with a balance of: 21000016.0 TXCH. +``` + +
+ +
Example 2 + +Include key info with the status (CAUTION: this includes the key's seed phrase): + +```bash +chia dev sim status -k +``` + +Response: + +```bash +Using fingerprint 3446212044 + +Fingerprint: 3446212044 +Master public key (m): 85e97db8c445bd82aad6e24b39f50764744f5050df1cd3d5cdaf9af43d334c4b2df72bd3c6c3fd0b8a6985a4063814e9 +Farmer public key (m/12381/8444/0/0): 99134f4041f349a1cffd05e77850349463697a1179416d5538efd84b0e68edb93f8ee119451b90a48cc4a7103f1385a3 +Pool public key (m/12381/8444/1/0): a3fc6e527242366680378faecf475bc7bba6083817d2671b447563df079954ca96ad1609f9802e2ada99f103799f5991 +First wallet address: txch1v3wjjapxvepyadvr2wgp7272md84lv6kmaxyxm4lq5le2jcc90zqkxhgv6 +Master private key (m): 38a46d85d64de2a606f26b4abc31ae5afc3fd522df9d88d2f2ab98cae0e5261e +First wallet secret key (m/12381/8444/2/0): PrivateKey 51d49f53301e068bb941bf93fda9ddd59404a5e5f6a338706f9ad65be277669b + Mnemonic seed (24 secret words): +dragon marriage portion employ net stumble grid silk ladder fan dove small noise stick divert transfer since siege fit annual dwarf gate fox garage + +Network: simulator0 Port: 48593 RPC Port: 18406 +Node ID: 6ca9a8ebe8ed4b2cba673666a29a75d18b3c358fee6e29153cde55ee33320261 +Genesis Challenge: eb8c4d20b322be8d9fddbf9412016bdffe9a2901d7edb0e364e94266d0e095f7 +Current Blockchain Status: Full Node Synced + +Peak: Hash: 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + Time: Wed Sep 28 2022 00:02:39 HKT Height: 10 + +Estimated network space: 15.384 MiB +Current difficulty: 1024 +Current VDF sub_slot_iters: 1024 +Total iterations since the start of the blockchain: 36460 + + Height: | Hash: + 10 | 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + 9 | e564309d7a4ad72bdf8f0dce838f5d91108ed49dddf88027aca9d8888ab86436 + 8 | a24f84ac2ccf11d43af21e2b416b92230b4f7b7db052db9a7ca9dc6ee2a9fb43 + 7 | f615455590b922362d2558e32141190ef474d60cc2a6d8f1acdeae899d798349 + 6 | 8b44d5a7e664ccbf92d34538e5f18f84c6f361871a12e797c9ce567c111ef97f + 5 | 4e79d87856af757835bf3fa083965b57c0bcadbb00ded733ca8a4451a615a3d6 + 4 | 7e3421e5448f58f2aab693aaeb506c953145d46cb9d58547a2bf53b0e35ac584 + 3 | 4c7e1e15646fa05e0d920d6b06b5574b3214568a84fb171a9dcdfe657990433a + 2 | bbb21b5a1ec18739fabcf231d15c51eb0b73900c178e4cfa329dadbef9d7a492 + 1 | 2a7df0f20b654d66fa4f77a54060855b5a9532f79b36d12bfd175831a321e6ba + +Current Farming address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2, with a balance of: 21000016.0 TXCH. +``` + +
+ +
Example 3 + +Show all coins, including reward coins: + +```bash +chia dev sim status -c -i +``` + +Response: + +```bash +Network: simulator0 Port: 48593 RPC Port: 18406 +Node ID: 6ca9a8ebe8ed4b2cba673666a29a75d18b3c358fee6e29153cde55ee33320261 +Genesis Challenge: eb8c4d20b322be8d9fddbf9412016bdffe9a2901d7edb0e364e94266d0e095f7 +Current Blockchain Status: Full Node Synced + +Peak: Hash: 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + Time: Wed Sep 28 2022 00:02:39 HKT Height: 10 + +Estimated network space: 15.384 MiB +Current difficulty: 1024 +Current VDF sub_slot_iters: 1024 +Total iterations since the start of the blockchain: 36460 + + Height: | Hash: + 10 | 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + 9 | e564309d7a4ad72bdf8f0dce838f5d91108ed49dddf88027aca9d8888ab86436 + 8 | a24f84ac2ccf11d43af21e2b416b92230b4f7b7db052db9a7ca9dc6ee2a9fb43 + 7 | f615455590b922362d2558e32141190ef474d60cc2a6d8f1acdeae899d798349 + 6 | 8b44d5a7e664ccbf92d34538e5f18f84c6f361871a12e797c9ce567c111ef97f + 5 | 4e79d87856af757835bf3fa083965b57c0bcadbb00ded733ca8a4451a615a3d6 + 4 | 7e3421e5448f58f2aab693aaeb506c953145d46cb9d58547a2bf53b0e35ac584 + 3 | 4c7e1e15646fa05e0d920d6b06b5574b3214568a84fb171a9dcdfe657990433a + 2 | bbb21b5a1ec18739fabcf231d15c51eb0b73900c178e4cfa329dadbef9d7a492 + 1 | 2a7df0f20b654d66fa4f77a54060855b5a9532f79b36d12bfd175831a321e6ba + +Current Farming address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2, with a balance of: 21000016.0 TXCH. +All Coins: +Coin 0x32ee11f63aca323db7e2bdfd71b29968d2605dbefcf2d5aea69b4acb278a6c56 +Wallet Address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2 +Confirmed at block: 9 +Spent: No +Coin Amount: 1750000000000 mojo +Parent Coin ID: 0xeb8c4d20b322be8d9fddbf9412016bdf00000000000000000000000000000007 +Created at: 2022-09-28 00:00:45 + +Coin 0x9d69c01f1d52a3d2f48553aa14f8c86661a31853f5ac9badcfa8ec4ef86d1eae +Wallet Address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2 +Confirmed at block: 5 +Spent: No +Coin Amount: 250000000000 mojo +Parent Coin ID: 0xfe9a2901d7edb0e364e94266d0e095f700000000000000000000000000000004 +Created at: 2022-09-27 23:50:07 + +... +... +``` + +
+ +
Example 4 + +Show the balance of each address: + +```bash +chia dev sim status -a +``` + +Response: + +```bash +Network: simulator0 Port: 48593 RPC Port: 18406 +Node ID: 6ca9a8ebe8ed4b2cba673666a29a75d18b3c358fee6e29153cde55ee33320261 +Genesis Challenge: eb8c4d20b322be8d9fddbf9412016bdffe9a2901d7edb0e364e94266d0e095f7 +Current Blockchain Status: Full Node Synced + +Peak: Hash: 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + Time: Wed Sep 28 2022 00:02:39 HKT Height: 10 + +Estimated network space: 15.384 MiB +Current difficulty: 1024 +Current VDF sub_slot_iters: 1024 +Total iterations since the start of the blockchain: 36460 + + Height: | Hash: + 10 | 293660bf6d6f724829448b97eb04abc6146a65b37d0b957983f69df952413a61 + 9 | e564309d7a4ad72bdf8f0dce838f5d91108ed49dddf88027aca9d8888ab86436 + 8 | a24f84ac2ccf11d43af21e2b416b92230b4f7b7db052db9a7ca9dc6ee2a9fb43 + 7 | f615455590b922362d2558e32141190ef474d60cc2a6d8f1acdeae899d798349 + 6 | 8b44d5a7e664ccbf92d34538e5f18f84c6f361871a12e797c9ce567c111ef97f + 5 | 4e79d87856af757835bf3fa083965b57c0bcadbb00ded733ca8a4451a615a3d6 + 4 | 7e3421e5448f58f2aab693aaeb506c953145d46cb9d58547a2bf53b0e35ac584 + 3 | 4c7e1e15646fa05e0d920d6b06b5574b3214568a84fb171a9dcdfe657990433a + 2 | bbb21b5a1ec18739fabcf231d15c51eb0b73900c178e4cfa329dadbef9d7a492 + 1 | 2a7df0f20b654d66fa4f77a54060855b5a9532f79b36d12bfd175831a321e6ba + +Current Farming address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2, with a balance of: 21000016.0 TXCH. +All Addresses: +Address: txch1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqm6ksh7qddh has a balance of: 2000000000000 mojo, with a total of: 2 transactions. + +Address: txch1t7e7pnxzxas207gh4q08sukvjg0emk7gvkpdld8kfmhxd7k4uaqq9x4yd2 has a balance of: 21000016000000000000 mojo, with a total of: 18 transactions. +``` + +
+ +--- + +### `stop` + +Functionality: + +Usage: `chia dev sim stop [OPTIONS]` + +Options: Stop running services + +| 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 | + +
Example 1 + +Stop the simulator with the default values: + +```bash +chia dev sim stop +``` + +Response: + +``` +chia_full_node_simulator: Stopped +``` + +Use `ps` to show Chia's status: + +```bash +ps | grep chia +``` + +The response shows that the daemon and wallet are still running: + +```bash + 2343 pts/0 00:00:01 chia_daemon + 23422 pts/0 00:00:05 chia_wallet +``` + +
+ +
Example 2 + +Stop the simulator, daemon, and wallet: + +```bash +chia dev sim stop -d -w +``` + +Response: + +```bash +chia_wallet: Stopped +chia_full_node_simulator: Stopped +Daemon stopped +``` + +
+ +--- 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 new file mode 100644 index 00000000000..d081b71ca27 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/vc-cli.md @@ -0,0 +1,358 @@ +--- +sidebar_label: VCs +title: Verifiable Credentials +slug: /reference-client/cli-reference/vc-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This document is a comprehensive listing of CLI commands for interacting with Chia VCs. + +## Reference + +### `add_proof_reveal` + +Functionality: Add a series of proofs that will combine to a single proof hash + +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 | +| -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 | + +
Example 1 + +Add two proofs: + +```bash +chia wallet vcs add_proof_reveal -f 2108245669 --proof test_proof1 --proof test_proof2 +``` + +Response: + +``` +Proofs added to DB successfully! +``` + +
+ +
Example 2 + +Get the root hash of the tree created from adding two proofs: + +```bash +chia wallet vcs add_proof_reveal -f 2108245669 --proof test_proof1 --proof test_proof2 --root-only +``` + +Response: + +``` +Proof Hash: f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 +``` + +
+ +--- + +### `get` + +Functionality: Get a list of existing VCs + +Usage: chia wallet vcs get [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 | +| -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 + +```bash +chia wallet vcs get -f 2108245669 +``` + +Response: + +```bash +Proofs: + +Launcher ID: 89a4ff17372dd3a8814712c0988b87b508a04cd7fa61d0228ce54b74111e7160 +Coin ID: 72e522fecc64b539f8979b89e4cf2ffbcf8ba985faf4b701bcc882c6aec9e040 +Inner Address: txch1at35qwx6djmadnh9v77a72z8vcaxsle36ke3dj26gcpt2fnh654qsqecnj +``` + +
+ +--- + +### `get_proofs_for_root` + +Functionality: Get the stored proof flags for a given proof hash + +Usage: chia wallet vcs get_proofs_for_root [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 | +| -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 + +Search for a hash currently stored in the VC: + +```bash +chia wallet vcs get_proofs_for_root -f 2108245669 --proof-hash f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 +``` + +Response: + +```bash +Proofs: + - test_proof1 + - test_proof2 +``` + +
+ +--- + +### `mint` + +Functionality: Mint a VC + +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 + +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: + +```bash +chia wallet did create -f 2108245669 -n Provider_DID -m 0.0001 +``` + +Response: + +```bash +Successfully created a DID wallet with name Provider_DID and id 2 on key 2108245669 +Successfully created a DID did:chia:1n2s77g7rer2v62xzrvd0at6tgx8m4g8t6encghs375r64lc6e5mssdkap3 in the newly created DID wallet +``` + +Next, mint a new VC. Note that the DID specified with `-d` must be owned by the fingerprint specified with `-f` (or the one selected if `-f` is not used). For example: + +```bash +chia wallet vcs mint -f 2108245669 -d did:chia:1n2s77g7rer2v62xzrvd0at6tgx8m4g8t6encghs375r64lc6e5mssdkap3 -m 0.0001 +``` + +Response: + +```bash +New VC with launcher ID minted: 13ba084e78475327e41c60df5a108965d7a283f065b5506e266ffb3563937b6c +Relevant TX records: + +Transaction e114763824c11c84bd1e3b5b0ba6540cb2ed2aef0f371170e8beecaac29d87c2 +Status: Pending +Amount sent: 1E-12 XCH +To address: txch1at35qwx6djmadnh9v77a72z8vcaxsle36ke3dj26gcpt2fnh654qsqecnj +Created at: 2023-06-15 10:02:31 +``` + +After the transaction has been confirmed, it is possible to show the VC by running the `get` command: + +```bash +chia wallet vcs get -f 2108245669 +``` + +Response: + +```bash +Proofs: + +Launcher ID: 89a4ff17372dd3a8814712c0988b87b508a04cd7fa61d0228ce54b74111e7160 +Coin ID: 72e522fecc64b539f8979b89e4cf2ffbcf8ba985faf4b701bcc882c6aec9e040 +Inner Address: txch1at35qwx6djmadnh9v77a72z8vcaxsle36ke3dj26gcpt2fnh654qsqecnj +``` + +It is recommended that you save the `Launcher ID` because it will be needed if the VC needs to be revoked later. + +No proofs have been added yet. This is accomplished with the [update_proofs](#update_proofs) command. + +
+ +--- + +### `revoke` + +Functionality: Revoke any VC if you have the proper DID and the VC's parent coin + +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] | +| | --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 | + +
Example + +Revoke the proofs from a VC. A few notes: A few notes: + +- The only wallet authorized to call this command is the wallet that contains the DID that created the VC + +```bash +chia wallet vcs revoke -l 0x420f69cc8b541be7a0bf1d94ec028a8b2a875ee2cd6721f5316cf1b02519d13a -m 0.0001 +``` + +Response: + +```bash +VC successfully revoked! +Relevant TX records: + +Transaction 286cc31575aa167c4b34cbc0a768a162caefb6afea77560db0693934ac3fbf1e +Status: Pending +Amount sent: 1E-12 XCH +To address: txch1ehkl33dypc7mg820c7j94zfg8pz5j5lqtx7253nmxft52ryvzw8stx7czc +Created at: 2023-06-23 13:33:50 + +Transaction ae6378e84742ab6abb07df666291093938ec9e06ae8e2b4066d7386d94289ba3 +Status: Pending +Amount sent: 0 XCH +To address: txch1mahlm65l8q9frcqcfveekx3a29cd74w6gfajqy05ukz2afrzg03syqkz3p +Created at: 2023-06-23 13:33:50 +``` + +After the transactions have completed, the holder of the VC can now show that the VC does not contain any proofs: + +```bash +chia wallet vcs get +``` + +Response: + +```bash +Proofs: +``` + +
+ +--- + +### `update_proofs` + +Functionality: Update a VC's proofs if you have the provider DID + +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] | +| | --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 | + +
Example + +Update the proofs. A few notes: A few notes: + +- The only wallet authorized to call this command is the wallet that contains the DID that created the VC +- The `-t` parameter must point to a puzzle hash, not an address +- The `-p` parameter can be obtained by calling `add_proof_reveal` and adding the `--root-only` flag + +```bash +chia wallet vcs update_proofs -f 2108245669 -l 89a4ff17372dd3a8814712c0988b87b508a04cd7fa61d0228ce54b74111e7160 -t 0x6fc9728dcd29358fae2194a1145d54c58acfa4de0380c60f8af377742e67788b -p f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 -m 0.0001 +``` + +Response: + +``` +Proofs successfully updated! +Relevant TX records: + +Transaction 76f5ea8475d695e798518cd405070dc22542e31fc85220ff7d2ca7b44852a45b +Status: Pending +Amount sent: 0 XCH +To address: txch10xjm79zct87gc8ux5vzrhnnt03zjn4ntn5y95w37rsfmp4rxjycquqctuc +Created at: 2023-06-15 10:15:27 + +Transaction f9eebb0520d024aaf4ae176d554c0f806b8d724d21d5da03b5f541fafd69c99f +Status: Pending +Amount sent: 1E-12 XCH +To address: txch1dlyh9rwd9y6clt3pjjs3gh25ck9vlfx7qwqvvru27dmhgtn80z9s2rruam +Created at: 2023-06-15 10:15:28 +``` + +After the transactions have completed, the VC will have been transferred to its destination puzzle hash (if one was provided). + +The new owner of the VC can now view the proof(s): + +```bash +chia wallet vcs get -f 2053849171 +``` + +```bash +Proofs: +- f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 + - test_proof1 + - test_proof2 + +Launcher ID: 89a4ff17372dd3a8814712c0988b87b508a04cd7fa61d0228ce54b74111e7160 +Coin ID: 72e522fecc64b539f8979b89e4cf2ffbcf8ba985faf4b701bcc882c6aec9e040 +Inner Address: txch1at35qwx6djmadnh9v77a72z8vcaxsle36ke3dj26gcpt2fnh654qsqecnj +Proof Hash: f063e22557705b14425b8fca60018796b4364eb6354f45d0b99431a71d3043e5 +``` + +
+ +--- 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 new file mode 100644 index 00000000000..f97848b7f5e --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/cli-reference/wallet-cli.md @@ -0,0 +1,1829 @@ +--- +sidebar_label: Wallet +title: Wallet CLI +slug: /reference-client/cli-reference/wallet-cli +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +This document is a reference for Chia's `wallet` CLI commands. The following `wallet` commands are documented on their own dedicated pages: + +- [DIDs](/reference-client/cli-reference/did-cli) (Decentralized Identifiers) +- [NFTs](/reference-client/cli-reference/nft-cli) (Non-Fungible Tokens) +- [Offers](/reference-client/cli-reference/offer-cli) + +## Reference + +## `add_token` + +Functionality: Add/Rename a CAT to the wallet by its asset ID + +Usage: chia wallet add_token [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 | +| -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 + +Add the Spacebucks token: + +```bash +chia wallet add_token --asset-id a628c1c2c6fcb74d53746157e438e108eab5c0bb3e5c80ff9b1910b3e4832913 --token-name Spacebucks --fingerprint 2121994410 +``` + +Response: + +``` +Successfully added Spacebucks with wallet id 3 on key 2121994410 +``` + +
+ +--- + +## coins: + +Functionality: List, split, and combine your wallet's coins + +### `list` + +Functionality: List coins in a wallet, with options for filtering + +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 | + +:::info + +By default, it you have more than 200 unspent coins worth less than one million mojos in your wallet, the dust filter will be activated. +Any coins that have been filtered will not be listed. +You can disable the dust filter by editing `~/.chia/mainnet/config/config.yaml` and changing the value of `xch_spam_amount` to `0`. +[More info on the dust filter](/chia-blockchain/resources/faq#what-is-the-dust-filter). + +::: + +Example 1 will give a baseline: + +
Example 1 + +List all coins for a given fingerprint: + +```bash +chia wallet coins list -f 590161281 +``` + +In the response, note that pagination is enabled by default: + +``` +There are a total of 7 coins in wallet 1. +7 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000010000000 (10000000 mojo), Confirmed in block: 2767623 + +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x242e1c68d1cd5c151c77702006596efc65e733c1803c3aa5617203f39904db54 + Address: xch1cdw9mgrzw9aa0rskg023wuf9pmqh87qakv4jwlenwxfddu88mqusg990d4 Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 2768188 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc + Address: xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46 Amount: 0.000000099999 (99999 mojo), Confirmed in block: 2767579 + +Press q to quit, or c to continue +c +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 +``` + +
+ +The following examples all use the same coin state that was obtained in Example 1: + +
Example 2: exclude small coins + +Exclude coins smaller than 0.1 XCH: + +```bash +chia wallet coins list -f 590161281 --min-amount 0.1 +``` + +Response: + +```bash +There are a total of 3 coins in wallet 1. +3 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x242e1c68d1cd5c151c77702006596efc65e733c1803c3aa5617203f39904db54 + Address: xch1cdw9mgrzw9aa0rskg023wuf9pmqh87qakv4jwlenwxfddu88mqusg990d4 Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 2768188 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 +``` + +
+ +
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: + +```bash + chia wallet coins list -f 590161281 --max-amount 0.00001 +``` + +Response: + +```bash +There are a total of 4 coins in wallet 1. +4 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000010000000 (10000000 mojo), Confirmed in block: 2767623 + +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc + Address: xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46 Amount: 0.000000099999 (99999 mojo), Confirmed in block: 2767579 +``` + +
+ +
Example 4: exclude specific coins + +Use the `--exclude-coin` flag multiple times to exclude individual coins: + +```bash +chia wallet coins list -f 590161281 --exclude-coin 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 --exclude-coin 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 +``` + +Response: + +```bash +There are a total of 5 coins in wallet 1. +5 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x242e1c68d1cd5c151c77702006596efc65e733c1803c3aa5617203f39904db54 + Address: xch1cdw9mgrzw9aa0rskg023wuf9pmqh87qakv4jwlenwxfddu88mqusg990d4 Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 2768188 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc + Address: xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46 Amount: 0.000000099999 (99999 mojo), Confirmed in block: 2767579 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 +``` + +
+ +
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: + +```bash +chia wallet coins list -f 590161281 --exclude-amount 0.0000001 --exclude-amount 0.241499799999 +``` + +Response: + +```bash +There are a total of 4 coins in wallet 1. +4 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000010000000 (10000000 mojo), Confirmed in block: 2767623 + +Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc + Address: xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46 Amount: 0.000000099999 (99999 mojo), Confirmed in block: 2767579 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 +``` + +
+ +
Example 6: disable pagination + +The `--no-paginate` flag will cause _all_ coins to be listed with no additional input from the user: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +Response: + +```bash +There are a total of 7 coins in wallet 1. +7 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000010000000 (10000000 mojo), Confirmed in block: 2767623 + +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x242e1c68d1cd5c151c77702006596efc65e733c1803c3aa5617203f39904db54 + Address: xch1cdw9mgrzw9aa0rskg023wuf9pmqh87qakv4jwlenwxfddu88mqusg990d4 Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 2768188 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc + Address: xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46 Amount: 0.000000099999 (99999 mojo), Confirmed in block: 2767579 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 +``` + +
+ +
Example 7: list a CAT + +First, list all assets in the wallet: + +```bash +chia wallet show +``` + +Response: + +```bash +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 + +CAT 91bfdb4a750308c2...: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: 91bfdb4a750308c25b12d0f787309df590a4cad80e7466accdd99b1d1759d9e4 + -Wallet ID: 2 + +CAT for Chris: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: 7ff763080ccdb75b5858f9c1570a213d70e9f363b2ce21736e1fd66a87c5b09a + -Wallet ID: 3 + +Test CAT: + -Total Balance: 1000000.0 (1000000000 mojo) + -Pending Total Balance: 1000000.0 (1000000000 mojo) + -Spendable: 1000000.0 (1000000000 mojo) + -Type: CAT + -Asset ID: 242fe92390a22bcdcb213a30af7fe230fda4e36820aeede81d64c65094b10dc1 + -Wallet ID: 4 +``` + +In this case, we want to list the `Test CAT` coins, which are in `Wallet ID: 4`. + +```bash +chia wallet coins list -i 4 +``` + +Response: + +```bash +There are a total of 2 coins in wallet 4. +2 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xe733a3d5b1549ad9a1dbac7436e037a2d9c4e05c44ad1853d8449649dce4c377 + Address: txch1r9vxnelmmwa3s9kxntrx6nmpcf6ckgkc87gegxx235ylgdk0wcqqkyrm8h Amount: 999999.000000000000 (999999000 mojo), Confirmed in block: 1181995 + +Coin ID: 0xd04e594bcb117238afc335347dfa9bbe1c6917c008685266601ca182520a05b1 + Address: txch173nuz5pvajxaek2lu2726kcjn5gdjmv643x7t8dr44x7tzsgvhdsl3m6wy Amount: 1.000000000000 (1000 mojo), Confirmed in block: 1231837 +``` + +Note that each CAT consists of 1000 mojos. In this case, the larger coin is worth `999 999`, or `999 999 000` mojos. + +
+ +--- + +### `combine` + +Functionality: Combine coins (typically used for combining dust). Functionality: Combine coins (typically used for combining dust). The maximum number of coins that can be combined within a single transaction is 500. + +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] | +| -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 + +First, list all coins, without pagination: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +Result: + +```bash +There are a total of 7 coins in wallet 1. +7 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000010000000 (10000000 mojo), Confirmed in block: 2767623 + +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc + Address: xch1q94gd4hd62ecx08d0kuagmp5cr8umrwtcvatfupmd7uyzhuf4c4sy2zd46 Amount: 0.000000099999 (99999 mojo), Confirmed in block: 2767579 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0xc1d5123dc10d3fb949df266a51c0591fe87c9914157cc82e248cd5e2f4b09965 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 3064891 +``` + +Next, select two specific coins to combine, and supply a 1000-mojo blockchain fee: + +``` +chia wallet coins combine -f 590161281 --input-coin 0xdd4e3bf8bd9f5079ca90315ed36fde77af0c04352a296b397bcdaff655ce3e35 --input-coin 0x2749503fb302b9654fc9f0dabd88787083ad341aaeee4a2bac113feb92ae59fc --fee 0.000000001 +``` + +Response: + +```bash +Combining 2 coins. +Would you like to Continue? (y/n): y +Transaction sent: dfc2ff46fd6cd2923371096d8e2b98d65dcfec25156dd53a15a4dedf4b4a8085 +To get status, use command: chia wallet get_transaction -f 590161281 -tx 0xdfc2ff46fd6cd2923371096d8e2b98d65dcfec25156dd53a15a4dedf4b4a8085 +``` + +Get the status of this command: + +```bash +chia wallet get_transaction -f 590161281 -tx 0xdfc2ff46fd6cd2923371096d8e2b98d65dcfec25156dd53a15a4dedf4b4a8085 +``` + +Result: + +```bash +Transaction dfc2ff46fd6cd2923371096d8e2b98d65dcfec25156dd53a15a4dedf4b4a8085 +Status: Confirmed +Amount sent: 0.000010098999 XCH +To address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu +Created at: 2023-01-05 12:51:05 +``` + +After the transaction has been confirmed, show all coins once again: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +The two specified coins have been combined (see the last coin in the list), and 1000 mojos has been deducted as a blockchain fee: + +```bash +There are a total of 6 coins in wallet 1. +6 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0xc1d5123dc10d3fb949df266a51c0591fe87c9914157cc82e248cd5e2f4b09965 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 3064891 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +
+ +
Example 2: enable min/max thresholds + +Start by listing all coins, with pagination disabled: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +Response: + +```bash +There are a total of 6 coins in wallet 1. +6 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x8ac5ff2d0ea13f61de631c7519581f030c3236710e5ea62c81a03182da4b7984 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.249979799998 (249979799998 mojo), Confirmed in block: 2767623 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0xc1d5123dc10d3fb949df266a51c0591fe87c9914157cc82e248cd5e2f4b09965 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.241499799999 (241499799999 mojo), Confirmed in block: 3064891 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +Combine all coins worth at least 0.1 XCH and at most 0.25 XCH. Add a 1000-mojo blockchain fee: + +```bash +chia wallet coins combine -f 590161281 --min-amount 0.1 --max-dust-amount 0.25 --fee 0.000000001 +``` + +Response: + +```bash +Combining 2 coins. +Would you like to Continue? (y/n): y +Transaction sent: 899eda2f67bf70261599629be19c3b6b1c4657e3fb1f6bc18d6690f92ee6bdfa +To get status, use command: chia wallet get_transaction -f 590161281 -tx 0x899eda2f67bf70261599629be19c3b6b1c4657e3fb1f6bc18d6690f92ee6bdfa +``` + +Show the result of the transaction: + +```bash +chia wallet get_transaction -f 590161281 -tx 0x899eda2f67bf70261599629be19c3b6b1c4657e3fb1f6bc18d6690f92ee6bdfa +``` + +Response: + +```bash +Transaction 899eda2f67bf70261599629be19c3b6b1c4657e3fb1f6bc18d6690f92ee6bdfa +Status: Confirmed +Amount sent: 0.491479598997 XCH +To address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu +Created at: 2023-01-05 12:59:27 +``` + +After the transaction has completed, list all coins once again. The two coins between the min and max thresholds have been combined, minus a 1000-mojo blockchain fee: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +Response: + +```bash +There are a total of 5 coins in wallet 1. +5 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0x25eb90a2a8cba2a9f0e3ddac8850f2861815856776109beedbbaa3db483be14a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.491479598997 (491479598997 mojo), Confirmed in block: 3064939 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +
+ +
Example 3: combine the two smallest coins + +Start by listing all coins, with pagination disabled: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +Response: + +```bash +chia wallet coins list -f 590161281 --no-paginate +There are a total of 5 coins in wallet 1. +5 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xf3b39365c6740a06bae6fe0e94405c8a2679d4bccd1abb725d4338bbc8800156 + Address: xch133pklxpat09ahykk6q56gyfa5kq09lzrh9p7jtwlq65l2njl2qpsz036vx Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2767579 + +Coin ID: 0x976c7291b6c946a425b57ae21b7f5c5fe1a5c122fa797d6fa598d8931541f833 + Address: xch1m66vmtxm3xlerru7r49l7sfurphlusxywrkkl8q5a5mwvemwjawqq5ygjp Amount: 0.000000100000 (100000 mojo), Confirmed in block: 2768188 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0x25eb90a2a8cba2a9f0e3ddac8850f2861815856776109beedbbaa3db483be14a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.491479598997 (491479598997 mojo), Confirmed in block: 3064939 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +Combine the two smallest coins, with a 1000-mojo blockchain fee: + +```bash +chia wallet coins combine -f 590161281 --number-of-coins 2 --fee 0.000000001 +``` + +Response: + +```bash +Combining 2 coins. +Would you like to Continue? (y/n): y +Transaction sent: efa130a51d877f57a93fa45835f1d95a77f17ff50eb82adfe457eae14a952c21 +To get status, use command: chia wallet get_transaction -f 590161281 -tx 0xefa130a51d877f57a93fa45835f1d95a77f17ff50eb82adfe457eae14a952c21 +``` + +Get the status of the transaction: + +```bash +chia wallet get_transaction -f 590161281 -tx 0xefa130a51d877f57a93fa45835f1d95a77f17ff50eb82adfe457eae14a952c21 +``` + +Response: + +```bash +Transaction efa130a51d877f57a93fa45835f1d95a77f17ff50eb82adfe457eae14a952c21 +Status: Confirmed +Amount sent: 1.99E-7 XCH +To address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu +Created at: 2023-01-05 13:24:28 +``` + +After the transaction has been confirmed, list the coins again: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +The two smallest coins have been combined, along with a 1000-mojo blockchain fee: + +```bash +There are a total of 4 coins in wallet 1. +4 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x25eb90a2a8cba2a9f0e3ddac8850f2861815856776109beedbbaa3db483be14a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.491479598997 (491479598997 mojo), Confirmed in block: 3064939 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0x7934503c149a124a67888891fb2a7f813b5a5afe40d38384f6986fb3e3eec5fe + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000000199000 (199000 mojo), Confirmed in block: 3065014 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +
+ +
Example 4: largest first / target amount + +Start by listing all coins, with pagination disabled: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +```bash +There are a total of 4 coins in wallet 1. +4 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x25eb90a2a8cba2a9f0e3ddac8850f2861815856776109beedbbaa3db483be14a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.491479598997 (491479598997 mojo), Confirmed in block: 3064939 + +Coin ID: 0x1c51b470e3fc7f97e155fd72e464f2192426d35857d78777a2a9c08358252eeb + Address: xch15pmsqc28x3vgms4ma3z0x4t5qh9hkalqnay8fz9rmvph2lfh575qzerres Amount: 0.500000000000 (500000000000 mojo), Confirmed in block: 2735639 + +Coin ID: 0x7934503c149a124a67888891fb2a7f813b5a5afe40d38384f6986fb3e3eec5fe + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000000199000 (199000 mojo), Confirmed in block: 3065014 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +Combine coins until their value is at least 0.6, starting with the largest coin. Include a 1000-mojo blockchain fee: + +```bash +chia wallet coins combine -f 590161281 --largest-first --target-amount 0.6 --fee 0.000000001 +``` + +Response: + +```bash +Combining 2 coins. +Would you like to Continue? (y/n): y +Transaction sent: 5fa8b6393d876a11a05768f06b84032f2bf20b81c6239b189c11187fab477cbb +To get status, use command: chia wallet get_transaction -f 590161281 -tx 0x5fa8b6393d876a11a05768f06b84032f2bf20b81c6239b189c11187fab477cbb +``` + +After the transaction has been confirmed, show all coins again: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +The largest coin was selected first. This coin's value was less than 0.6, so the next largest coin was selected. The total was greater than 0.6, so only those two coins were combined, and a 1000-mojo fee was deducted from the resulting coin: + +```bash +There are a total of 3 coins in wallet 1. +3 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xc58618fd5c30245291377901d3b911fe0ee7e826b28ae4875e60a2fd09d6fc52 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.991479597997 (991479597997 mojo), Confirmed in block: 3065287 + +Coin ID: 0x7934503c149a124a67888891fb2a7f813b5a5afe40d38384f6986fb3e3eec5fe + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000000199000 (199000 mojo), Confirmed in block: 3065014 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +
+ +
Example 5: error case + +Start by listing all coins of at least 0.9 XCH: + +```bash +chia wallet coins list -f 590161281 --min-amount 0.9 +``` + +The result shows that there is only one coin of this size: + +```bash +There are a total of 1 coins in wallet 1. +1 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xc58618fd5c30245291377901d3b911fe0ee7e826b28ae4875e60a2fd09d6fc52 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.991479597997 (991479597997 mojo), Confirmed in block: 3065287 +``` + +Now run the `combine` command with the same parameters: + +```bash +chia wallet coins combine -f 590161281 --min-amount 0.9 +``` + +Result: + +``` +Only one coin found, you need at least two coins to combine. +``` + +This shows that you cannot combine a single coin. Lowering (or removing) the `--min-amount` could result in more than one coin being selected. + +
+ +
Example 6: default settings + +Start by listing all coins, with pagination disabled: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +Response: + +```bash +There are a total of 3 coins in wallet 1. +3 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xc58618fd5c30245291377901d3b911fe0ee7e826b28ae4875e60a2fd09d6fc52 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.991479597997 (991479597997 mojo), Confirmed in block: 3065287 + +Coin ID: 0x7934503c149a124a67888891fb2a7f813b5a5afe40d38384f6986fb3e3eec5fe + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000000199000 (199000 mojo), Confirmed in block: 3065014 + +Coin ID: 0xbeaf029a3a09792d5f77193c7efa1de09d46e85dde0e0acdb5e53e41237ccf1a + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.000010098999 (10098999 mojo), Confirmed in block: 3064913 +``` + +Run the `combine` command with the default settings: + +```bash +chia wallet coins combine -f 590161281 +``` + +Up to 500 coins will be combined by default, starting with the smallest coin. In this case, there are only three coins to combine: + +```bash +Combining 3 coins. +Would you like to Continue? (y/n): y +Transaction sent: 8f285700e4c6db9290739206e21349bf484bd1e650c8281c6b8095f0e333af3b +To get status, use command: chia wallet get_transaction -f 590161281 -tx 0x8f285700e4c6db9290739206e21349bf484bd1e650c8281c6b8095f0e333af3b +``` + +After the transaction has completed, list all coins again: + +```bash +chia wallet coins list -f 590161281 +``` + +There is now only one coin in the wallet: + +```bash +There are a total of 1 coins in wallet 1. +1 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x5dc5106862c7e00b0611b79137dbd7520e4c90da1bbbadb01a4518e3e4ec1797 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.991489895996 (991489895996 mojo), Confirmed in block: 3065530 +``` + +
+ +--- + +### `split` + +Functionality: Split one coin into one or more new coins + +Usage: chia wallet coins split [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] | +| -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. +If any value remains after splitting, this will be stored in a new coin. + +For example, if you split a coin worth 10 XCH, using `--number-of-coins 3` and `--amount-per-coin 1`, then you will end up with three new coins worth 1 XCH each, along with another coin (the remainder of the original coin) worth 7 XCH. + +When splitting a CAT, `--amount-per-coin` refers to the CAT value, where 1 CAT is 1000 mojos. + +Keep in mind that (by default) the [dust filter](/chia-blockchain/resources/faq#what-is-the-dust-filter) will be activated if you have over 200 coins worth one million mojos in your wallet. +Therefore, if you split a coin into more than 200 coins worth less than one million mojos, not all of them will show up in your wallet unless you modify or disable the dust filter (see the above link for instructions). + +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 + +First, list the coins available: + +```bash +chia wallet coins list -f 590161281 +``` + +Response: + +``` +There are a total of 1 coins in wallet 1. +1 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x5dc5106862c7e00b0611b79137dbd7520e4c90da1bbbadb01a4518e3e4ec1797 + Address: xch1ju90mhn8nq7nnd25whap56ajf6eraxayw6qlk6f7sr0w3jf5d2ps9x0zzu Amount: 0.991489895996 (991489895996 mojo), Confirmed in block: 3065530 +``` + +Split the existing coin into five coins of 0.15 XCH, and include a 1000-mojo blockchain fee: + +```bash +chia wallet coins split -f 590161281 --number-of-coins 5 --amount-per-coin 0.15 --target-coin-id 0x5dc5106862c7e00b0611b79137dbd7520e4c90da1bbbadb01a4518e3e4ec1797 --fee 0.000000001 +``` + +Result: + +``` +Transaction sent: 2489efe8c89e72459a09bb681b121c3acee0e9f40d65c37c8a9d98bb7cb47d09 +To get status, use command: chia wallet get_transaction -f 590161281 -tx 0x2489efe8c89e72459a09bb681b121c3acee0e9f40d65c37c8a9d98bb7cb47d09 +``` + +View the result of the transaction: + +``` +chia wallet get_transaction -f 590161281 -tx 0x2489efe8c89e72459a09bb681b121c3acee0e9f40d65c37c8a9d98bb7cb47d09 +``` + +Result: + +``` +Transaction 2489efe8c89e72459a09bb681b121c3acee0e9f40d65c37c8a9d98bb7cb47d09 +Status: Confirmed +Amount sent: 0.75 XCH +To address: xch1p2hs025nkujyqk4a6qxfxfde6uvcajqhmq2kzvacj79wf8kfvaxqw3t4zp +Created at: 2023-01-05 16:15:31 +``` + +Finally, show the coins again after splitting: + +```bash +chia wallet coins list -f 590161281 --no-paginate +``` + +As requested, the original coin was split into five coins worth 0.15 XCH apiece. The remaining value is held in a sixth coin, minus a 1000-mojo blockchain fee: + +```bash +There are a total of 6 coins in wallet 1. +6 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x9781d2b0d70667cfe3dd330eddcdf77aa01e68b55bb015f2280197875022f1a6 + Address: xch1p2hs025nkujyqk4a6qxfxfde6uvcajqhmq2kzvacj79wf8kfvaxqw3t4zp Amount: 0.150000000000 (150000000000 mojo), Confirmed in block: 3065575 + +Coin ID: 0x4e67664448a4a2341a678f3940676f13ccea27a8be3b742b9f7396f2e5a9cc32 + Address: xch15gt90usala3xducfee96lc4gu2su2ks56htav9gklwmmssh7t5gspuwrvh Amount: 0.150000000000 (150000000000 mojo), Confirmed in block: 3065575 + +Coin ID: 0x9d3106af6877dde3d6fc00ffd5fde2813bf7db3e7e1fa69dd96685c8d061d81b + Address: xch105khmcltukhupkzn4h88clkyqptsm88zyzg2vhlcpr76sd0vkggqm8vfdc Amount: 0.150000000000 (150000000000 mojo), Confirmed in block: 3065575 + +Coin ID: 0x57ef317fd0c9b0139d1546fbb0ccd3006fa820abb239ec8539d5726621f387c0 + Address: xch15yr7nk2wqxmy77g5z42vxav6knukgud69wzzl0n8fnra9d7eudaq8ty25a Amount: 0.150000000000 (150000000000 mojo), Confirmed in block: 3065575 + +Coin ID: 0x1e5fc6f0deb9d3f8300052d0a0504697fbd9dd76709e4fc3ff58a65bb73cbc28 + Address: xch17nxgus99p679j2z0gw0326nt5wddap7n0q7cqh3zs385hmkdspcq6lhk6l Amount: 0.241489894996 (241489894996 mojo), Confirmed in block: 3065575 + +Coin ID: 0x27049c58aad594bdb83a0f191098f438218cbd7066700342034709afb2470c0d + Address: xch1kfce8cjec26qg0gh0rw44vvy90zsnm63tmf0ux4rrj8yv4t905ps8vjce7 Amount: 0.150000000000 (150000000000 mojo), Confirmed in block: 3065575 +``` + +
+ +
Example 2: split a CAT + +Start by listing the CATs in `Wallet ID: 4`: + +```bash +chia wallet coins list -i 4 +``` + +Response: + +```bash +There are a total of 2 coins in wallet 4. +2 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0xe733a3d5b1549ad9a1dbac7436e037a2d9c4e05c44ad1853d8449649dce4c377 + Address: txch1r9vxnelmmwa3s9kxntrx6nmpcf6ckgkc87gegxx235ylgdk0wcqqkyrm8h Amount: 999999.000000000000 (999999000 mojo), Confirmed in block: 1181995 + +Coin ID: 0xd04e594bcb117238afc335347dfa9bbe1c6917c008685266601ca182520a05b1 + Address: txch173nuz5pvajxaek2lu2726kcjn5gdjmv643x7t8dr44x7tzsgvhdsl3m6wy Amount: 1.000000000000 (1000 mojo), Confirmed in block: 1231837 +``` + +We will split the larger coin. In this case, we'll create three new coins of equal value, and the remainder will be held in a larger coin. + +```bash +chia wallet coins split -i 4 -n 3 -m 0.0001 -a 100 -t 0xe733a3d5b1549ad9a1dbac7436e037a2d9c4e05c44ad1853d8449649dce4c377 +``` + +Response: + +```bash +Transaction sent: 9b1e2122d641dc72ada458bb03076525cadb4e23a3f61dc685bca09bf61e5eec +To get status, use command: chia wallet get_transaction -f 3179192453 -tx 0x9b1e2122d641dc72ada458bb03076525cadb4e23a3f61dc685bca09bf61e5eec +``` + +Splitting requires an on-chain transaction. After this transaction has completed, list the existing CATs again: + +```bash +chia wallet coins list -i 4 +``` + +Response: + +```bash +There are a total of 5 coins in wallet 4. +5 confirmed coins. +0 unconfirmed additions. +0 unconfirmed removals. +Confirmed coins: +Coin ID: 0x5c244b3595199c358a944a4456bcf4c35e7bcd19eee1c2a2697a17321f35c608 + Address: txch1w5q3yhucsukk65kgzndr2scyjafunjwn2yk8aeea4hfpzpes557qxktxlv Amount: 999699.000000000000 (999699000 mojo), Confirmed in block: 1251072 + +Coin ID: 0x91699526de75d68bc9b7b39e1db4967c0562d49a9a3a4a644a09443c2f30df15 + Address: txch1767d5rq2hqdr0d40ku8wqf47gxnrpegz4zay0fsv45vlthjjvv7spxqnyx Amount: 100.000000000000 (100000 mojo), Confirmed in block: 1251072 + +Coin ID: 0x57b6a932ddaedde1c3bcdf80d37be6e721042bc2e065207f7e192a68c8b2b775 + Address: txch1w3tq64f9dz44enl63yar0scqpqph2lr7hegnsg8zsvq7kmgxd6fq52pfg2 Amount: 100.000000000000 (100000 mojo), Confirmed in block: 1251072 + +Coin ID: 0xd04e594bcb117238afc335347dfa9bbe1c6917c008685266601ca182520a05b1 + Address: txch173nuz5pvajxaek2lu2726kcjn5gdjmv643x7t8dr44x7tzsgvhdsl3m6wy Amount: 1.000000000000 (1000 mojo), Confirmed in block: 1231837 + +Coin ID: 0xc7699ff3bde093aae6d3ce53b77362fa1beee155d438f0f8f35de700f0861469 + Address: txch17hzqs0qvvru86xzfqvy9206sww2ack3x4kpaj8ar2r3t9254f93qjv0fsp Amount: 100.000000000000 (100000 mojo), Confirmed in block: 1251072 +``` + +There are three new coins, each worth 100. The original coin worth 1 remains intact, and the larger coin has been reduced in value by 300. + +
+ +--- + +## `clawback` + +Functionality: Claim or revert a Clawback transaction + +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 | + +Note that wallet will automatically detect whether the transactions should be reverted (clawed back) or claimed. + +
Example 1: clawback + +First, create the clawback. This is a normal `send` command, with an extra `--clawback` timer: + +```bash +chia wallet send -f 4045726944 -a 1 -e "Sending 1 TXCH with 1-hour clawback" -m 0.0001 -t txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze --clawback_time 3600 +``` + +Response: + +``` +Submitting transaction... +Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] +Run 'chia wallet get_transaction -f 4045726944 -tx 0x5a41dbe755a7a44b827b61cfa384e79bef5f79370f63fa7ffe1ea29212a26bf6' to get status +``` + +After the above transaction has been confirmed on-chain, obtain the ID for the clawback transaction: + +```bash +chia wallet get_transactions -f 4045726944 -l 1 --clawback +``` + +Response: + +```bash +Transaction 0661d157b33597c33e5dc2027f07a1f0cbdc72fa950ca9617e08af326ceb7c81 +Status: Pending +Amount received in clawback as sender: 1 TXCH +To address: txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze +Created at: 2023-06-14 13:14:16 +Recipient claimable time: 2023-06-14 14:14:16 +``` + +Next, claw back the transaction: + +```bash +chia wallet clawback -f 4045726944 -ids 0661d157b33597c33e5dc2027f07a1f0cbdc72fa950ca9617e08af326ceb7c81 -m 0.0001 +``` + +Response: + +```bash +{'success': True, 'transaction_ids': ['a8295c3924a8ad079093995d3129a38e26faa01ffca175572d21881865dc48ff']} +``` + +Finally, show the clawback transaction to verify that it was confirmed: + +```bash +chia wallet get_transaction -f 4045726944 -tx 0xa8295c3924a8ad079093995d3129a38e26faa01ffca175572d21881865dc48ff +``` + +```bash +Transaction a8295c3924a8ad079093995d3129a38e26faa01ffca175572d21881865dc48ff +Status: Confirmed +Amount claim/clawback: 1 TXCH +To address: txch1dmdj4ee0ss3m7zunaymz47kdejv2pfwxdhcdjh6zffg935yqmvlsqpvvjq +Created at: 2023-06-14 13:17:33 +``` + +
+ +
Example 2: claim + +Set up a clawback send transaction with a 60-second clawback window: + +```bash +chia wallet send -f 4045726944 -a 1 -e "Sending 1 TXCH with 60-second clawback" -m 0.0001 -t txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze --clawback_time 60 +``` + +Response: + +```bash +Submitting transaction... +Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] +Run 'chia wallet get_transaction -f 4045726944 -tx 0x3ca82042aba188d47a80b663523847fa6050a21e04647c7b31ad3aa9d8d5450f' to get status +``` + +Get the status of the latest clawback transaction: + +```bash +chia wallet get_transactions -f 4045726944 -l 1 --clawback +``` + +Response: + +```bash +Transaction d4d29b6381e4248fc7361abb900a154e14d3120f6ecc01e7aaccaf9d984ed2f3 +Status: Pending +Amount received in clawback as sender: 1 TXCH +To address: txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze +Created at: 2023-06-14 13:28:38 +Recipient claimable time: 2023-06-14 13:29:38 +``` + +From the receiver's wallet, claim the transaction after the claimable time has elapsed: + +```bash +chia wallet clawback -f 2457176934 -ids d4d29b6381e4248fc7361abb900a154e14d3120f6ecc01e7aaccaf9d984ed2f3 -m 0.0001 +``` + +Response: + +```bash +{'success': True, 'transaction_ids': ['e969bb32b4b01e2c14f67c9d6c467645779c1898d08eb4e041c937f4ba3fe9cb']} +``` + +Finally, show the last transaction's status: + +```bash +chia wallet get_transaction -f 2457176934 -tx 0xe969bb32b4b01e2c14f67c9d6c467645779c1898d08eb4e041c937f4ba3fe9cb +``` + +Response: + +```bash +Transaction e969bb32b4b01e2c14f67c9d6c467645779c1898d08eb4e041c937f4ba3fe9cb +Status: Confirmed +Amount claim/clawback: 1 TXCH +To address: txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze +Created at: 2023-06-14 13:33:10 +``` + +
+ +--- + +## `delete_unconfirmed_transactions` + +Functionality: Deletes all unconfirmed transactions for this wallet ID + +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 | +| -h | --help | None | False | Show a help message and exit | + +
Example + +```bash +chia wallet delete_unconfirmed_transactions --fingerprint 2121994410 +``` + +Response: + +``` +Successfully deleted all unconfirmed transactions for wallet id 1 on key 2121994410 +``` + +
+ +--- + +## `get_address` + +Functionality: Get a wallet receive address + +Usage: chia wallet get_address [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 | +| -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 + +Get a new address: + +```bash +chia wallet get_address --fingerprint 2121994410 --new-address +``` + +Response: + +``` +xch1jp5thqu3dhwkvvh5p77lvlackddrd9q2zpt58zs6yqr2c4yvregs69ayqr +``` + +
+ +--- + +## `get_derivation_index` + +Functionality: Get the last puzzle hash derivation path index + +Usage: chia wallet get_derivation_index [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 | +| -h | --help | None | False | Show a help message and exit | + +
Example + +```bash +chia wallet get_derivation_index --fingerprint 2121994410 +``` + +Response: + +``` +Last derivation index: 346 +``` + +
+ +--- + +## `get_transaction` + +Functionality: Get a transaction + +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 | + +
Example + +```bash +chia wallet get_transaction --fingerprint 2121994410 --tx_id 1b32a7f42c88b70924e3ec70d2a377b2b5c5f28de14736a3e2b5d411dec98c06 +``` + +Response: + +``` +Transaction 1b32a7f42c88b70924e3ec70d2a377b2b5c5f28de14736a3e2b5d411dec98c06 +Status: Confirmed +Amount sent: 1.99E-10 XCH +To address: xch1799u8mjkq4wt6t3avgcfxqk56qcwkx2dv9rw9q2yahm8taq4jwcqxaqd6m +Created at: 2022-11-30 09:59:09 +``` + +
+ +--- + +## `get_transactions` + +Functionality: Get all transactions + +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 + +Start by showing all wallets associated with the current fingerprint: + +```bash +chia wallet show +``` + +Response (truncated): + +```bash +Wallet height: 3045395 +Sync status: Synced +Balances, fingerprint: 2104826454 + +Chia Wallet: + -Total Balance: 35.683924454174 txch (35683924454174 mojo) + -Pending Total Balance: 35.683924454174 txch (35683924454174 mojo) + -Spendable: 35.084802204177 txch (35084802204177 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +NFT Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: NFT + -Wallet ID: 2 + +``` + +Next, obtain a single transaction from wallet `1`, a `STANDARD_WALLET`, by including the `-o` (offset) and `-l` (limit) flags: + +```bash +chia wallet get_transactions -i 1 -o 2 -l 1 +``` + +Response: + +```bash +Transaction 1a4a2c93e32fd2a5a19b85e6a2114c6a2b972b4ed7d203dc23a1574d6a1383a1 +Status: Confirmed +Amount sent: 5 TXCH +To address: txch1z2gtnmph3jp9cz28phchztylrkqhf8c4ckgtjg3ew7ducztxl8gsfqttlc +Created at: 2023-08-01 19:55:51 +``` + +
+ +
Example 2: Show all transactions from a CAT + +Start by showing all wallets associated with the current fingerprint: + +```bash +chia wallet show +``` + +Response: + +```bash +Wallet height: 3045482 +Sync status: Synced +Balances, fingerprint: 2104826454 + +Chia Wallet: + -Total Balance: 35.683924454174 txch (35683924454174 mojo) + -Pending Total Balance: 35.683924454174 txch (35683924454174 mojo) + -Spendable: 35.084802204177 txch (35084802204177 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +NFT Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: NFT + -Wallet ID: 2 + +DID did:chia:1kzxqrt8f2h8psr8zuzen9dxgmxx5v35s0rj3jy637qjannu3zlesds0el5: + -Total Balance: 1.0 + -Pending Total Balance: 1.0 + -Spendable: 1.0 + -Type: DECENTRALIZED_ID + -DID ID: did:chia:1kzxqrt8f2h8psr8zuzen9dxgmxx5v35s0rj3jy637qjannu3zlesds0el5 + -Wallet ID: 3 + +NFT Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: NFT + -DID ID: did:chia:1kzxqrt8f2h8psr8zuzen9dxgmxx5v35s0rj3jy637qjannu3zlesds0el5 + -Wallet ID: 4 + +DataLayer Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DATA_LAYER + -Wallet ID: 5 + +CAT f17f88130c635228...: + -Total Balance: 0.034 (34 mojo) + -Pending Total Balance: 0.034 (34 mojo) + -Spendable: 0.034 (34 mojo) + -Type: CAT + -Asset ID: f17f88130c63522821f1a75466849354eee69c414c774bd9f3873ab643e9574d + -Wallet ID: 6 + +CAT aaee6b63bcbc4aef...: + -Total Balance: 10.0 (10000 mojo) + -Pending Total Balance: 10.0 (10000 mojo) + -Spendable: 10.0 (10000 mojo) + -Type: CAT + -Asset ID: aaee6b63bcbc4aef0a005d31119ad65e5228b0ddff18c5c563fd7a4db54fb084 + -Wallet ID: 7 + +Pool wallet: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: POOLING_WALLET + -Wallet ID: 11 +``` + +Next, show all transactions from `Wallet ID` `7`, a CAT wallet: + +```bash +chia wallet get_transactions -i 7 +``` + +Response: + +```bash +Transaction 38306b461975741641d397330bb34c01681bb242119bd4aa457c06e2080cf257 +Status: Confirmed +Amount received: 10 CAT aaee6b63bcbc4aef... +To address: txch1stn20rhgmh5wvmyyfj2etdpdp73fla0ga4ymtsejz600dszf392s58kx2s +Created at: 2022-12-14 00:40:39 +``` + +
+ +--- + +## notifications: + +Functionality: Send, receive, and delete wallet notifications + +### `delete` + +Functionality: Delete notification(s) that are in your wallet + +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 | + +
Example + +Delete all notifications: + +```bash +chia wallet notifications delete --fingerprint 2121994410 --all +``` + +Response: + +``` +Success: True +``` + +
+ +--- + +### `get` + +Functionality: Get notification(s) that are in your wallet + +Usage: chia wallet notifications get [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 | 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 + +To set up your wallet to receive notifications, follow [these instructions](/chia-blockchain/resources/faq#how-do-i-configure-my-system-to-send-and-receive-notifications) + +::: + +
Example + +```bash +chia wallet notifications get --fingerprint 2121994410 +``` + +Response: + +``` +ID: d844464f871a468c008dd76b882214403f6aaa2e19bd1ab549e4423406202f55 +message: This is a test message +amount: 10000000 +``` + +
+ +--- + +### `send` + +Functionality: Send a notification to the owner of an address + +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 | + +
Example + +Send a test notification: + +```bash +chia wallet notifications send --fingerprint 3792481086 --to-address xch1jp5thqu3dhwkvvh5p77lvlackddrd9q2zpt58zs6yqr2c4yvregs69ayqr --message "This is a test message" --fee 0.000000000001 +``` + +Response: + +``` +Notification sent successfully. +``` + +
+ +--- + +## `send` + +Functionality: Send chia or other assets to another wallet + +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 + +Send 1000 mojos with a test memo: + +```bash +chia wallet send --fingerprint 3792481086 --address xch1jp5thqu3dhwkvvh5p77lvlackddrd9q2zpt58zs6yqr2c4yvregs69ayqr --memo "This is a test memo" --fee 0.000000000001 --amount 0.000000001 +``` + +Response: + +``` +Submitting transaction... +Transaction submitted to nodes: [{'peer_id': 'cda6b919f90af6f021ccf6ca748a30d03b22622863654b57bd74896dd60c4eca', 'inclusion_status': 'SUCCESS', 'error_msg': None}] +Run 'chia wallet get_transaction -f 3792481086 -tx 0x6fbac9409dbdef3cfa8a8fd82be88caef5be4547fe882c12d5b1ef0cbd17ecfe' to get status +``` + +
+ +
Example 2: clawback + +Send 1 TXCH and include a 3600-second (1 hour) clawback: + +```bash +chia wallet send -f 4045726944 -a 1 -e "Sending 1 TXCH with 1-hour clawback" -m 0.0001 -t txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze --clawback_time 3600 +``` + +Response: + +``` +Submitting transaction... +Transaction submitted to nodes: [{'peer_id': 'b3d9de85d29931c10050b56c7afb91c99141943fc81ff2d1a8425e52be0d08ab', 'inclusion_status': 'SUCCESS', 'error_msg': None}] +Run 'chia wallet get_transaction -f 4045726944 -tx 0x3012893bf84b66c849f54b1c4bd893000188a7f728e439d3d6634048e8474482' to get status +``` + +View the transaction's status: + +```bash +chia wallet get_transaction -f 4045726944 -tx 0x3012893bf84b66c849f54b1c4bd893000188a7f728e439d3d6634048e8474482 +``` + +Response: + +```bash +Transaction 3012893bf84b66c849f54b1c4bd893000188a7f728e439d3d6634048e8474482 +Status: Confirmed +Amount sent: 1 TXCH +To address: txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze +Created at: 2023-06-14 10:07:51 +``` + +Note that the status is `Confirmed` even though it is a pending clawback transaction. +This is because the original transaction _has_ been confirmed and a new pending clawback transaction has been created. + +To view the pending clawback transaction, call `get_transactions` and include the `--clawback` flag (`-l 1` is used here to show only the latest transaction): + +```bash +chia wallet get_transactions -f 4045726944 -l 1 --clawback +``` + +The response shows the time at which the transaction will be claimable: + +```bash +Transaction fdee443b5588dff2eb5471d18dee51617749849ed29583e2315481f52dad98cc +Status: Pending +Amount received in clawback as sender: 1 TXCH +To address: txch1pxam7zakgqfcfr0xm8xcemm76d637w6sg0l7j8h6gv7rdlf8cfxs326mze +Created at: 2023-06-14 10:08:44 +Recipient claimable time: 2023-06-14 11:08:44 +``` + +
+ +--- + +## `show` + +Functionality: Show wallet information + +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 | + +
Example + +```bash +chia wallet show --fingerprint 2121994410 +``` + +Response: + +``` +Wallet height: 2896197 +Sync status: Synced +Balances, fingerprint: 2121994410 + +Chia Wallet: + -Total Balance: 0.196510003997 xch (196510003997 mojo) + -Pending Total Balance: 0.196510003997 xch (196510003997 mojo) + -Spendable: 0.196510003997 xch (196510003997 mojo) + -Type: STANDARD_WALLET + -Wallet ID: 1 + +NFT Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: NFT + -Wallet ID: 2 + +Spacebucks: + -Total Balance: 0.0 (0 mojo) + -Pending Total Balance: 0.0 (0 mojo) + -Spendable: 0.0 (0 mojo) + -Type: CAT + -Asset ID: a628c1c2c6fcb74d53746157e438e108eab5c0bb3e5c80ff9b1910b3e4832913 + -Wallet ID: 3 + +DataLayer Wallet: + -Total Balance: 0.0 + -Pending Total Balance: 0.0 + -Spendable: 0.0 + -Type: DATA_LAYER + -Wallet ID: 4 +``` + +
+ +--- + +## `sign_message` + +Functionality: Sign a message by a derivation address + +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 | + +
Example + +```bash +chia wallet sign_message --fingerprint 2121994410 --address xch1jp5thqu3dhwkvvh5p77lvlackddrd9q2zpt58zs6yqr2c4yvregs69ayqr --hex_message 0xdeadbeef +``` + +Response: + +``` +Message: 0xdeadbeef +Public Key: b1632788b1384508103e9714336f99c50fd08fc025ebf637f6f386967469750edc8f91cb2da843ece824e7f052e4f349 +Signature: 8b198ebfd05569ec1d06abc2bc9625e9361b5cf9837693cbc4ce3113de6c13d5528739c488e400444696d3fd169e666a0ed3498547aa5bcdfe15793ac8336505043fa393c063ae2756c1eedfadd82dbc50808f2f50b15724eba4e46ae1001225 +``` + +
+ +--- + +## `update_derivation_index` + +Functionality: Generate additional derived puzzle hashes starting at the provided index + +Usage: chia wallet update_derivation_index [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 | --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 + +```bash +chia wallet update_derivation_index --fingerprint 2121994410 --index 475 +``` + +Response: + +``` +Updating derivation index... This may take a while. +Updated derivation index: 475 +Your balances may take a while to update. +``` + +
+ +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/coin-selection.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/coin-selection.md index bcb13848ffe..69cdcc8b394 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/coin-selection.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/coin-selection.md @@ -3,7 +3,7 @@ title: Coin Selection slug: /reference-client/coin-selection --- -Chia uses the [Coin Set](/chia-blockchain/coin-set-model/intro) model of accounting, under which _everything_ is a coin. When Chia wallets perform certain actions, they must select one or more coins to spend or reserve. (Coin selection is performed automatically by the software; the wallet's user is not involved.) When Chia wallets perform certain actions, they must select one or more coins to spend or reserve. (Coin selection is performed automatically by the software; the wallet's user is not involved.) +Chia uses the [Coin Set](/chia-blockchain/coin-set-model/intro) model of accounting, under which _everything_ is a coin. When Chia wallets perform certain actions, they must select one or more coins to spend or reserve. (Coin selection is performed automatically by the software; the wallet's user is not involved.) Actions that require coin selection include, but are not limited to: 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 new file mode 100644 index 00000000000..1d9adce86f8 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/dual-farming-testnet-mainnet.md @@ -0,0 +1,93 @@ +--- +title: Dual Farming +slug: /reference-client/farming/dual-farming-testnet-mainnet +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::info + +（译注：本文关于切换到测试网的方法已经过时，不再具有参考意义，因此本文为机翻） +这些说明适用于Linux。 在MacOS上可以采用类似的方法。 + +::: + +在某些情况下，您可能希望在主网上耕种的同时，在其中一个测试网络上也进行耕种，而不会将它们从主网中移除。 这是可以实现的，但需要额外的工作来为测试网络Chia安装设置唯一的端口。 + +有几个设置的选项。 You can either ensure you have the `CHIA_ROOT` set to unique values for each instance you want to run, or else run the installations on separate users. These instructions will show setting a specific `CHIA_ROOT`. + +## 设置主网安装 + +For the mainnet installation, we will stick with the default ports and `CHIA_ROOT`, so these steps are essentially no different than the standard [installation instructions](/reference-client/install-and-setup/installation). + +## 设置测试网络安装 + +1. (Optional) Install [yq](https://github.com/mikefarah/yq#install) to make editing the yaml files easier + 1. Alternatively, you can manually edit the ports in `config.yaml` +2. 运行以下命令： + +```bash +export CHIA_ROOT=~/.chia/testnet +``` + +3. 运行以下命令： + +```bash +chia init +``` + +4. 运行以下命令： + +```bash +chia configure --testnet true +``` + +5. cd to the `~/.chia/testnet/config` directory and run the following script. 或者，您也可以手动编辑文件。 You do not need to use the ports listed below. 您不需要使用下面列出的端口，但是如果选择更改端口号，请确保它们与主网的默认值不同： + +```bash +yq -i '.daemon_port = 55401' ./config.yaml +yq -i '."*".log_syslog_port = 1514' ./config.yaml + +yq -i '.data_layer.rpc_port = 10562' ./config.yaml +yq -i '.data_layer.wallet_peer.port = 11256' ./config.yaml +yq -i '.data_layer.host_port = 10575' ./config.yaml + +yq -i '.farmer.port = 10447' ./config.yaml +yq -i '.farmer.rpc_port = 10559' ./config.yaml + +yq -i '.harvester.rpc_port = 10560' ./config.yaml +yq -i '.harvester.farmer_peers.port = 10447' ./config.yaml + +yq -i '.wallet.rpc_port = 11256' ./config.yaml + +yq -i '.full_node.rpc_port = 10555' ./config.yaml + +yq -i '.timelord.rpc_port = 10557' ./config.yaml +yq -i '.timelord.vdf_server.port = 10000' ./config.yaml +yq -i '.timelord_launcher.port = 10000' ./config.yaml + +yq -i '.ui.rpc_port = 10555' ./config.yaml +yq -i '.ui.daemon_port = 55401' ./config.yaml +``` + +6. 运行以下命令： + +```bash +chia start farmer +``` + +## 在主网和测试网络之间切换 + +To swap between running commands for mainnet and running commands for testnet, you need to ensure your `CHIA_ROOT` is set properly before running any commands: + +- 主网： + + ```bash + export CHIA_ROOT=~/.chia/mainnet + ``` + +- 测试网络： + ```bash + export CHIA_ROOT=~/.chia/testnet + ``` 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 new file mode 100644 index 00000000000..37371f2214a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-basics.md @@ -0,0 +1,48 @@ +--- +title: Farming Basics +slug: /reference-client/farming/farming-basics +--- + +Farming is the next step after [plotting](/reference-client/plotting/plotting-basics). Once a plot has been created, you have a chance of winning Chia as long as the file is being stored and the Chia farming software is running. + +When farming, you allocate a certain amount of storage space in order to have a chance at winning Chia. The more plots you have, the higher your chances of winning. The more plots you have, the higher your chances of winning. + +Farming is similar to a lottery. Each plot acts like a lottery ticket, where a new drawing is performed every 9 seconds or so. If you win the lottery, you earn the right to create a new block, and you will be rewarded with Chia. With an average of 4608 blocks a day, you'll have many chances to win. + +Our [consensus](/chia-blockchain/consensus/consensus-intro) section has the technical details of how this "lottery" system works. + +## 预计获得奖励时间 + +You can find your win time estimation from the **Farming** tab in the Chia software. It's important to note that this is **just an estimation**. The real time could be 2-5x greater than -- or less than -- this estimation, depending on luck. + +:::info +Prior wins (or lack thereof) do not determine new wins. 如果预计获得奖励的时间是一周，但已经过去了三个月，那么离获得奖励并没有更近，与开始时相同。 +::: + +## 使用联合耕种池来应对 + +To combat the infrequency and inconsistency of winning, you can [join a pool](/reference-client/farming/pool-farming). It works similar to a lottery pool. Instead of occasionally earning a large reward, you will frequently earn a small payment. In the long run, pooling and solo-farming (aka **self-pooling**) will yield the same result (minus any pool fee), but pooling is much more predictable, and recommended for most farmers. + +An additional benefit of pooling is instant feedback as to whether your farm is running properly. 如果是独自耕种，可能会不确定自己是否真的能赢得一个区块。 如果是独自耕种，可能会不确定自己是否真的能赢得一个区块。 + +Chia设计了官方的联合耕种协议（pooling protocol），以一种其他加密货币从未尝试过的方式引入了矿池。 This allows for officially-supported predictability without compromising on decentralization. + +## 区块奖励 + +With each new block, a certain amount of Chia is rewarded to the farmer that created it. With each new block, a certain amount of Chia is rewarded to the farmer that created it. Chia launched with a block reward of 2 XCH per block. This comes out to 64 XCH distributed every 10 minutes. This comes out to 64 XCH distributed every 10 minutes. + +Every three years, there is a scheduled halving of the block reward. Every three years, there is a scheduled halving of the block reward. This means that three years after mainnet launch, the block reward is cut in half, to 1 XCH. + +以下是完整的区块奖励计划： + +| 年份 | 区块奖励 | XCH / 10 mins | +| ----- | ------------------------- | ------------- | +| 1-3 | 2.0 XCH | 64 | +| 4-6 | 1.0 XCH | 32 | +| 7-9 | 0.5 XCH | 16 | +| 10-12 | 0.25 XCH | 8 | +| 13+ | 0.125 XCH | 4 | + +Starting with year 13, block rewards are forever locked in at an average of 4 XCH every 10 minutes. + +随着时间的推移，新产生的XCH相对于现有XCH的比例将下降。 因此，Chia的通货膨胀率将持续下降。 Chia's inflation falls through 0.5% 22 years after mainnet launch. 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 new file mode 100644 index 00000000000..81023ad4494 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-compressed-plots.md @@ -0,0 +1,102 @@ +--- +sidebar_label: Compressed Plots +title: Compressed Plot Farming +slug: /reference-client/farming/farming-compressed-plots +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +As detailed in the [plotting](/reference-client/plotting/plotting-basics) section, compressed plots are supported for both plotting and harvesting as of Chia version 2.0. Before you can harvest compressed plots, you need to inform your harvesters of the fact that they exist. + +:::info + +As of Chia version 2.0, decompression must be performed at the harvester level. You therefore will need to apply the settings listed on this page to each of your harvesters individually. As of Chia version 2.0, decompression must be performed at the harvester level. You therefore will need to apply the settings listed on this page to each of your harvesters individually. This also means that each individual harvester will need to be capable of decompressing the plots that have been installed locally. + +In the future, we plan to enable decompression at the farmer level. In the future, we plan to enable decompression at the farmer level. This means that only one computer on your network will need to be equipped with a fast CPU or GPU for decompressing plots. + +::: + +## Enable compressed plot support + +### GUI + +1. Navigate to the `Settings` panel in the lower-left corner of the GUI. +2. Click the `HARVESTER` tab at the top of the panel. The following screen will appear: + +
+ Enable compressed farming +
+ +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. + + 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. + +For example, if your harvester has one CPU with eight cores, you might use the following settings: +_ `Parallel Decompressor Count`: `1` +_ `Decompressor Thread Count`: `6` + +This would instruct the harvester process to use six of the eight cores for decompressing plots, and to use the remaining cores to run the OS, etc. 5. If you want to use a GPU for harvesting, slide the `Enable GPU Harvesting` slider to the right, as shown in the above image. Note that in order to use this setting, your harvester must have an NVIDIA CUDA-class GPU. For harvesting C7 plots, 600-700 MB of DRAM is required. 6. If your harvester has multiple GPUs, you can use `GPU Device Index` to choose which one to use. If your harvester only has one GPU, then leave this set to `0`. + +After all of these settings have been properly set, click the red `RESTART LOCAL HARVESTER TO APPLY CHANGES` button. After your harvester restarts, it will use the updated settings. + +### CLI + +All of the new harvester settings live inside `~/.chia/mainnet/config/config.yaml`. + +If you have never installed Chia on this harvester, `config.yaml` won't exist. In this case, run the following command to generate a new copy: + +```bash +chia init +``` + +If you have previously installed Chia on this computer, then `config.yaml` likely already exists. In this case, you will need to add several new settings. However, + +- If you run `chia init` when the config file already exists, Chia won't make any modifications. +- If you delete `config.yaml` and run `chia init`, the new settings will be added, but you will lose any custom changes you previously made. + +In the case where `config.yaml` already exists, you therefore are recommended to do the following: + +1. Edit `config.yaml` +2. Search for `harvester:` +3. From inside this section, add the following parameters, which include the default settings: + +```bash +parallel_decompressor_count: 0 +decompressor_thread_count: 0 +use_gpu_harvesting: false +enforce_gpu_index: false +gpu_index: 0 +decompressor_timeout: 20 +disable_cpu_affinity: false +max_compression_level_allowed: 7 +``` + +At this point, regardless of whether you are upgrading or running a new build of Chia on this harvester, your copy of `config.yaml` contains all of the latest settings. Their definitions and recommended values are as follows: + +- `parallel_decompressor_count`: The number of CPUs to be used for decompressing plots. If this is set to `0`, then harvesting of compressed plots will be disabled. For GPU harvesting, set this value to `1`. For CPU harvesting, set it to the number of CPUs you want to use for decompression (typically `1`). +- `decompressor_thread_count`: The number of CPU 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 CPU cores. +- `use_gpu_harvesting`: Set to `true` to enable harvesting with a GPU. use_gpu_harvesting: Set to true to enable harvesting with a GPU. Note that in order to use this setting, your harvester must have an NVIDIA GPU with CUDA capability 5.2 and up, with at least 8GB of vRAM. +- `gpu_index`: If your harvester has multiple GPUs, use this setting to choose which one to use. If your harvester only has one GPU, then leave this set to `0`. +- `enforce_gpu_index`: Set to `true` if your harvester has more than one GPU and you want to use one other than the default of `0`. +- `decompressor_timeout`: The number of seconds for your decompressor to time out. The default value of `20` is typically fine. +- `disable_cpu_affinity`: This should typically be `false`. When it is `false`, when using multiple CPU decompressors, each with multiple threads, the threads for each decompressor will be assigned to different physical CPUs. This prevents them for competing over compute time. If it is set to `true`, the threads for each decompressor will be assigned to the same CPU. +- `max_compression_level_allowed`: The highest level of compression your harvester will support. In Chia version 2.0, the maximum level is `7`. This will likely be increased in the future, but for now, you cannot increase it beyond the default. You can, however, set it to a lower number if desired. + +After you have finished making these updates, save `config.yaml` and restart your harvester by running the following command: + +```bash +chia start harvester -r +``` + +Your new settings will be applied. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-considerations.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-considerations.md new file mode 100644 index 00000000000..8b1103104b5 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-considerations.md @@ -0,0 +1,22 @@ +--- +title: Farming Considerations +slug: /reference-client/farming/farming-considerations +--- + +# 耕种硬件考虑事项 + +在Chia中，奖励随存储空间的大小而增加(因此称为“Proof of Space”)。 存储是一种商品，并且与其他计算设备相比，功耗相对较低。 一般来说，Chia农民预计会将大部分投资花在硬盘上(通常为80-90%)，其余用于运营开支。 效率较低的农场可能会将50-80%的成本花在硬盘上，其余用于运营支出(OpEx)，例如电力和冷却费用。 我们可以逆向思考，并考虑建立Chia农场的目标。 + +1. 最大化在给定占地面积中可以容纳的存储容量。 在数据中心中，这通常被称为每个机架单元的TB。 This can be achieved by having dense storage systems (e.g. JBOD, NAS) and using high-capacity hard disk drives (HDD) + Spend as little as possible. 每TB附加的$或每个驱动器附加的$，因为系统成本是按照农民可以连接的驱动器数量来摊销的，驱动器数量越多，每个驱动器的成本越低。 +2. 最小化功耗。 我们希望Chia尽可能地节能，因此我们希望支持耕种平台尽量减少农民的功耗开销。 在构建良好的Chia农场中，硬盘消耗了大部分电能。 +3. 电源效率。 我们希望我们消耗的电能被硬盘和农民使用，而不是浪费在电源供应效率或过多的冷却(风扇)中。 +4. 最小化噪音(以分贝为单位)。 如果您将农民放在家里，您需要它相对安静。 如果您将农民放在合作基础设施、数据中心或远程位置，噪音就不是问题。 噪音与冷却(风扇速度)和功耗通常是相互权衡的。 +5. 保持硬盘的冷却。 当HDD保持在建议的温度工作范围内时，其寿命(故障率)更长。 这在消费级和数据中心级HDD之间有所不同。 为了实现这一点，需要在耕种机箱中提供足够的气流和风扇，并通过SMART监控硬盘。 +6. 可靠性和可用性(运行时间)。 我们不希望耕种系统崩溃。 我们不希望农民上的任何单个故障组件导致整个系统崩溃。 We do not want farming downtime (this is lost time and XCH farming) + Host connectivity. 一般来说，耕种将通过网络(NAS、网络附加存储)远程连接，或者直接连接到农民(DAS、直接附加存储)。 没有一种正确的方式来连接许多驱动器，但通常DAS会是Chia耕种的最低成本和复杂性选项。 +7. Redundancy & RAID. 大多数存储系统设计时考虑到持久性存储，并且包含RAID、纠删码、镜像或备份等冗余功能。 这在Chia中并非必需，因为在设备故障时可以重新创建Plot，并且使用冗余存储与其在Chia中耕作所获得的空间相比，通常会超过创建Plot的能源和时间成本。 对于拥有有限生成地块能力的小规模农民可能不是这种情况，但绝大多数用户不需要在Chia中使用任何形式的RAID。 +8. Nice to haves (these are standard in JBODs that make life much, much easier) + Hot-swap, field-replaceable drives: the ability to swap a hard drive without taking the system offline (turning it off), generally accessible through the front or top of the chassis + staggered spin-up: hard drives consume much more power (25W) for the first 10 seconds or so that they are turned on, from something called in-rush current. 相比之下，耕种中每个硬盘需要3.5-5W的待机功耗。 Staggered spin-up spins up only a certain number of drives at a time to limit max power consumption + slot identification: hard drives fail. 当这种情况发生时，您希望能够轻松地识别包含故障硬盘的插槽。 这通过LED指示完成。 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 new file mode 100644 index 00000000000..fd05109b7e2 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/farming-many-machines.md @@ -0,0 +1,214 @@ +--- +title: Farming on Many Machines +slug: /reference-client/farming/farming-many-machines +--- + +另一个标题: + +# 如何在其它不是主要设备的机器上进行收割 + +:::tip + +Always make sure to protect yourself from malicious actors by [securing your chia and making yourself a hard target](https://www.chia.net/2021/05/28/securing-your-chia-how-to-be-a-hard-target/) + +::: + +This guide will show you how to run a harvester on each machine in your network. This architecture is composed of one main machine which runs the farmer, full node, and wallet, and other machines which run only the harvester. 只有主机将连接到Chia网络。 This architecture is composed of one main machine which runs the farmer, full node, and wallet, and other machines which run only the harvester. 只有主机将连接到Chia网络。 + +This is the recommended setup for all Chia farms that use more than one computer. It uses less bandwidth, space and CPU versus running a full node on each computer. It also keeps your keys safer because they will only need to be stored on one computer. Finally, it makes your overall farm quicker and more efficient when replying to challenges. It uses less bandwidth, space and CPU versus running a full node on each computer. It also keeps your keys safer because they will only need to be stored on one computer. Finally, it makes your overall farm quicker and more efficient when replying to challenges. + +To secure communication between your harvester and **main** machine, TLS is used where your **main** machine will be the private Certification Authority (CA) that signs all certificates. Each harvester must have its own signed certificate to properly communicate with your **main** machine. + +``` + _____ Harvester 1 (certificate A) + / +other network peers -------- Main machine (CA) ------ Harvester 2 (certificate B) + \_____ Harvester 3 (certificate C) +``` + +If you are more of a visual learner, JM made a video outlining the steps from this tutorial. This video is from 2021, but the steps are still relevant today: This video is from 2021, but the steps are still relevant today: + + + +## 先决条件 + +- First, make sure Chia is installed on all machines and initialized by running the following command: + + ```bash + chia init + ``` + +- When creating plots on the harvesters, run the correct command based on which plotter you want to use. More information about the plotters available and their usage can be found here: https://docs.chia.net/reference-client/plotting/plotting-software/ + +- A copy of your **main** machine CA directory needs to be accessible by your harvester machines. This directory is located in: + + ```bash + ~/.chia/mainnet/config/ssl/ca + ``` + + 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 + + Be aware that major updates might need you to copy the new `ca` contents. Verify that the harvester does not report SSL errors on connection attempts. + +## 设置步骤 + +For each harvester, follow these steps: + +1. Make sure your **main** machine's IP address on port 8447 is accessible by your harvester machines +2. Shut down all Chia daemon processes by running: + +```bash +chia stop all -d +``` + +3. 备份收割节点中的所有设置。 +4. Run the following command on your harvester, where `` is the copy of your **main** machine's `/ca` directory that you put in a temp folder: + +```bash +chia init -c +``` + +This command creates a new certificate signed by your **main** machine's CA. + +:::warning + +For step 4, you are using a copy of your `/ca` directory from your main machine temporarily. DO NOT replace the `/ca` folder on your harvester. Put the `/ca` directory into a temp folder on your harvester. You're going to show your harvester these files temporarily and then you can delete the `/ca` directory in your temp folder. This keeps your system more secure by limiting the exposure to your certificates. + +::: + +5. Open the following file in each harvester: + +```bash +~/.chia/mainnet/config/config.yaml +``` + +Search for the remote **`harvester`**'s farmer_peer section (NOT `full_node`). Enter the local IP address of your main machine (typically `192.168.xxx.yyy`) as the `host` value. + +In other words, replace `` in the following snippet with your main machine's local IP: + +```bash +harvester: + chia_ssl_ca: + crt: config/ssl/ca/chia_ca.crt + key: config/ssl/ca/chia_ca.key + farmer_peers: + - host: localhost + port: 8447 +``` + +6. Launch the harvester by running the following command: + +```bash +chia start harvester -r +``` + +You should see a new connection on your main machine in your `INFO` level logs. + +:::note + +To stop the harvester, run the following command: + +```bash +chia stop harvester +``` + +::: + +:::warning + +You cannot copy the entire `config/ssl` directory from one machine to another. Each harvester must have a different set of TLS certificates for your **main** machine to recognize it as different harvesters. Unintended bugs can occur, including harvesters failing to work properly when the **same** certificates are shared among different machines. + +::: + +:::info + +A few minutes after the GUI starts running, it will begin to show harvester plots. The easiest way to see if it's working is to go the `Farm` tab, and check the `Last Attempted Proof` pane. Every nine seconds or so, you should see the different harvesters reporting numbers under `Plots Passed Filter` such as `0 / 26`, `1 / 412`, `3 / 864`, etc. + +::: + +After your farmer has been running for a few minutes, you can run the following command to obtain a list of harvesters: + +```bash +chia farm summary +``` + +If you need to debug, you can set the logging level to `DEBUG` by running this command: + +```bash +chia configure --log-level DEBUG +``` + +You will need to restart your farmer for the change to take effect: + +```bash +chia start -r farmer +``` + +Now you can check the log `~/.chia/mainnet/log/debug.log` and see if you get messages like the following: + +```bash +[time stamp] farmer farmer_server : DEBUG -> new_signage_point_harvester to peer [harvester IP address] [peer id - 64 char hexadecimal] +[time stamp] farmer farmer_server : DEBUG <- farming_info from peer [peer id - 64 char hexadecimal] [harvester IP address] +[time stamp] farmer farmer_server : DEBUG <- new_proof_of_space from peer [peer id - 64 char hexadecimal] [harvester IP address] +``` + +The outgoing `new_signage_point_harvester` message states the farmer sent a challenge to your harvester and the incoming `farming_info` message indicates a response. The `new_proof_of_space` message states the harvester found a proof for the challenge. You will get more `new_signage_point` and `farming_info` messages than `new_proof_of_space` messages. + +Here's how to find your logs: [Where to Find Things](/reference-client/troubleshooting/check-if-things-are-working) + +## 在多台机器上的良好安全实践 + +(This is basically repeating what @mariano54 said in [this discussion](https://github.com/Chia-Network/chia-blockchain/discussions/1116#discussioncomment-420398).) + +安全是关于做出更好的选择。 永远无法达到100%的安全性，但可以始终通过做出更好的选择来提高安全性。 + +### 保持密钥分离 + +In other words, _only use the keys specific to your machine's purpose_. + +- 主密钥（master/farming key）不应该出现在用于生成地块的机器上。 +- 主密钥（master/farming key）不应该出现在收割节点机器上。 + +#### 在多台机器上生成地块 + +As stated [above](/reference-client/farming/farming-many-machines#prerequisites), run the following command when creating plots: + +```bash +chia plots create -f -p +``` + +When you use the `-f` and `-p` parameters, you do not need to copy the keys to the local plotting machine. + +#### 在多台机器上进行收割 + +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) + +不让钱包受到黑客攻击的一种方法是不让它暴露在互联网上。 Here is how to do this: [Chia Keys Management](/reference-client/install-and-setup/key-management) + +:::info +Your reward address for Chia rewards should be a separate key as well, kept in an offline machine. 可以在另一台计算机上生成一个地址，并将该地址放入config.yaml文件中的 farmer.xch_target_address 和 pool.xch_target_address 字段中，这样，如果您的耕种机器受到黑客攻击，就不会丢失以前的奖励。 ([Source](https://github.com/Chia-Network/chia-blockchain/discussions/1116#discussioncomment-420398)) +::: + +## 如何查看密钥 + +:::warning + +仅在安全的地方查看密钥，并确保没有其他人能看到您的屏幕。 + +::: + +### 使用命令行界面（CLI） + +```bash +chia keys show +``` + +### 使用图形用户界面（GUI） + +Click on the _Logout_ icon at the top right. 会看到列出的钱包。 点击眼睛图标。 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 new file mode 100644 index 00000000000..60ac58ecda7 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/pool-farming.md @@ -0,0 +1,400 @@ +--- +title: 联合耕种（Pool Farming） +slug: /reference-client/farming/pool-farming +--- + +由于不断增长的网络空间（network space，netspace），在 Chia 中获得区块奖励会变得非常困难，即便是使用多个硬盘进行耕种的用户，也可能需要数月甚至数年的时间。 联合耕种可以确保持续获得小额但稳定的区块奖励。 例如，独自耕种每20周可以获得2XCH的用户，通过加入联合耕种可以每周以更加稳定的方式获得0.1XCH。 + +Chia的联合耕种协议（pooling protocol）允许将地块分配给“联合耕种农田（Plot NFT）”，它类似于区块链上的合约，您可以控制它，并在其中设置当前分配到哪个联合耕种地址。 还可以随时更改分配给NFT地块的联合耕种地址。 + +使用联合耕种协议，农民（farmer）将与特定的联合耕种服务器通信，并频繁向该联合耕种地址发送空间证明，用以证明拥有已生成空间的大小。 因此，联合耕种服务器可以跟踪其每个成员（即农民）的空间，每当其中一名成员赢得一个区块时，联合耕种服务器可以根据每个农民贡献的空间比例分发奖励。 + +正因如此，联合耕种有点像彩票保险：所有成员参与Chia的“彩票”，每当其中一名成员中奖时，联合耕种获得奖励并将其分配给所有成员，减去一小笔手续费。 The reward is divided into two tranches: 7/8 is split among the pool members, and the other 1/8 goes directly to the farmer who won the block. + +## Chia联合耕种（Pooling）的六个步骤 + +:::note + +The official pooling protocol was introduced in verion 1.2 in mid-2021. All plots created before this point, as well as newer plots created with following the pooling protocol, are not eligible for pooling. The official pooling protocol was introduced in verion 1.2 in mid-2021. All plots created before this point, as well as newer plots created with following the pooling protocol, are not eligible for pooling. If you have any of these "OG" plots, you can either recreate them using a plot NFT, or co-farm them on the same machine as your official pool plots. + +::: + +### 第一步：同步全节点和钱包 + +In order to set up your farm for pooling, you need to have a synced full node and wallet. In the upper-right corner of your wallet, you should see green icons next to FUll NODE and WALLET: In the upper-right corner of your wallet, you should see green icons next to `FUll NODE` and `WALLET`: + +
+ Sync status +

+ +:::info + +If you want to avoid syncing from genesis, you can download a [database checkpoint](https://www.chia.net/downloads/#database-checkpoint). + +For more info, see our [blog post](https://www.chia.net/2023/03/19/introducing-chia-blockchain-database-bittorent-checkpoints/) on this subject. + +::: + +### 第二步：获取一些XCH + +开始联合耕种之前，请确保钱包里面拥有一小笔XCH。 可以向朋友索取mojo（1 mojo等于0.000000000001 XCH），或者到https://faucet.chia.net/获取mojo。 You can use the receive address on the `Tokens` page, and you can also create new receive addresses. Any of the receive addresses can be used; they are all part of the same wallet. + +### 第三步：创建联合耕种农田（Plot NFT） + +一旦钱包里有了XCH，就可以前往"联合耕种"页面，然后点击"新建联合耕种农田"。 + +#### Using the CLI + +主要有两个选项： + +1. 独自耕种：这个联合耕种农田不会连接到任何联合耕种服务器，1.75 XCH将直接进入你的钱包。 这与旧的（原始）地块（OG）不同，因为旧地块永远锁定在独自耕种状态。 + 使用命令行： + +```bash +chia plotnft create -s local +``` + +2. 连接联合耕种：加入一个联合耕种池，并在生成地块后立即开始耕种。 + 使用命令行： + +```bash +chia plotnft create -s pool -u https://bar.examplepool.org +``` + +请注意，即便选择的是选项1，以后仍然可以加入联合耕种池，并且可以随时切换到其它池。 If you decide +to join a pool, enter the url (must start with _https://_), and look at the description. 如果同意, 则开始创建联合耕种农田, 并等待它被确认 (只点击一次)。 这可能需要几分钟的时间才能得到确认，然后出现在“联合耕种”选项卡中。 +您只需要 1 个联合耕种农田。 + +#### 使用图形用户界面（GUI） + +Click the `Pooling` icon on the left side of your wallet, and click `JOIN A POOL`: + +
+ Join a pool +

+ +Select `Connect to pool`. You will need to enter a valid pool URL. For a list of Chia pools, see [chialinks.com](https://chialinks.com/pools). + +Creating a plot NFT requires an on-chain transaction that will cost one mojo. You are also recommended to enter a blockchain fee. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes. You are also recommended to enter a blockchain fee. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes. + +
+ Create a plot NFT +

+ +If you entered a valid pool URL, the details will pop up. For example, this pool has a fee of 1%. If everything looks acceptable, click CREATE: If everything looks acceptable, click `CREATE`: + +
+ Pool details +

+ +Your transaction will be pushed to the blockchain. While it is pending, a new screen will appear: While it is pending, a new screen will appear: + +
+ Plot NFT pending +

+ +After the transaction has been finalized (typically 1-3 minutes), the details of your plot NFT will appear. + +:::info + +A two-word name will automatically be assigned to your plot NFT. + +::: + +### 第 4 步：添加地块 + +You can now start creating plots for this Plot NFT, which means these plots will be "pooling" and can earn rewards more often. + +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) + +### 第五步：管理联合耕种农田。 + +You should see your plots in the `Pooling` dialog. The status should say `Pooling`. 在这里，可以看到当前农田的难度，已获得的积分（points）以及联合耕种池认为您拥有的积分（积分余额）。 + +
+ Plot NFT details +

+ +难度是一个对于每个联合耕种农田都不同的值，它决定了为这些地块寻找证明的难度。 这个值会自动设置，以决定查找证明的频繁程度（每隔几分钟或几小时）。 +Each proof found will award you with `difficulty` points. 拥有大量地块的农民将拥有较高的难度，以保持磁盘使用量在较低水平。 + +积分是一种计算地块找到了多少证明的方式。 每个K32地块每天平均会获得10个积分，与难度无关。 积分与Chia（XCH）不同。 积分只是反映了进行了多少耕种的值。 可以将其视为一种会计工具。 根据您获得的积分数，由联合耕种池定期发放XCH，并将您的积分重置为0，这是矿池的责任。 + +To change pools, click on the `CHANGE POOL` button and enter the new pool URL. 请注意，更改联合耕种池有一个等待期，可能会持续几分钟到一小时左右。 请在此过程中不要关闭应用程序。 可以随意更改联合耕种池，而且不需要进行注册或支付任何罚款。 请注意，如果更改了联合耕种池，之前的耕种池不再有义务继续向你支付收益。 + +您应该确保在过去24小时内的积分数是准确的。 每天每个k32地块应该获得大约10个积分，所以如果有100个k32的地块，每天应该获得大约1000个积分。 确保您的积分在持续增长。 支付后，积分余额将重置为零。 积分将随机出现，因为查找证明也是随机的。 因此，预计会有很多变化，并且会有好运和坏运的时候。 + +### 第六步：等待支付 + +所有操作都已经完成了。 如果你的积分余额在增加，意味着已经正确连接到联合耕种池耕种。可以查看你所在的跟中池，看看奖励是多久发放一次，也可以选择登录到耕种池的界面。 + +## 附加信息 + +### 多个联合耕种农田 + +可以在同一个密钥上拥有多个联合耕种农田，可以同时进行耕种。 还可以同时使用原始 (OG) 地块进行耕种。 + +### 多台电脑 + +You can take your 24-word seed phrase and enter it into a different computer, and when it is synched, the current Plot NFTs and pool information will be automatically downloaded from the blockchain. All information about your pool, plot NFTs, and smart contract addresses is completely backed up on the blockchain, and can be recovered using the seed phrase. All information about your pool, plot NFTs, and smart contract addresses is completely backed up on the blockchain, and can be recovered using the seed phrase. + +### 多个密钥 + +也可以同时使用多个密钥进行耕种，但需谨慎操作。 每个密钥都必须分别同步，如果在计算机A中更改了耕种池，那么您必须在计算机B上同步您的钱包以便分别耕种。 如果计算机B有多个密钥，请确保将每个密钥同步到联合耕种农田的最新状态。 + +### 联合耕种池手续费 + +耕种池手续费是耕种池在将奖励分发给农民时收取的一小部分费用。 Each pool can set their own fee structure. + +### 区块链手续费 + +Blockchain fees are paid to the creator of the block (farmers), to incentivize them to include your transaction. If the blockchain is busy, you might have to pay small a small fee to get your transaction included. (Creating a plot NFT and changing pools both require an on-chain transaction.) If the blockchain is busy, you might have to +pay small a small fee to get your transaction included. (Creating a plot NFT and changing pools both require an on-chain transaction.) + +### 无效状态 + +如果进入了无效状态，需要重新加入或再次切换到独自耕种。 这可能发生在耕种池切换操作完成之前关闭GUI的情况下。 请单击"更换联合耕种池"，然后重新输入耕种池网址，或切换到独自耕种。 有时可能需要等待一段时间，直到耕种池切换超时完成。 + +### 支付地址 + +区块奖励分为两部分，耕种池部分（总奖励的7/8）和农民部分（总奖励的1/8）。 + +- 耕种池部分将支付给耕种池，耕种池将根据其支付计划支付给您。 在GUI的“联合耕种”选项卡中可以进行配置：点击联合耕种农田界面右上角的三个点，然后点击“编辑支付地址”。 This is also configurable in `config.yaml` in the pool_list section under payout_instructions. +- The farmer portion will go to your farmer target address. This is configurable in the Farm tab of the GUI, or in `config.yaml` under farmer.xch_target_address. + +### 独自耕种 + +如果是在独自耕种，在获得区块奖励后还需要额外进行奖励的领取。 这可以通过图像界面或命令行完成。 领取奖励没有时间限制，但是如果在切换到其他耕种池之前没有领取奖励，那么新的耕种池将有权利领取这些奖励，您将失去这部分资金。 + +### 远程收割机 + +远程收割机（Remote harvesters）的工作方式与以往一样。 They do not need to have any keys, and you can plot directly on another machine with the `-f` and `-c` arguments. The farmer machine needs to have the private key for the `-f` key, and the private key for the wallet that created the plot NFT. 在进行联合耕种时，收割机会更频繁地查找证明，因为难度较低。 Remote harvester plots will now be visible by doing `chia farm summary`. + +### 命令行 + +Using the CLI, you can perform the same operations as with the GUI. There is a new command, called `chia plotnft`. Type `chia plotnft -h` to see all the available sub-commands: + +``` +» chia plotnft -h +Usage: chia plotnft [OPTIONS] COMMAND [ARGS]... + +Options: + -h, --help Show this message and exit. + +Commands: + claim Claim rewards from a plot NFT + create Create a plot NFT + get_login_link Create a login link for a pool. To get the launcher id, use + plotnft show. + + inspect Get Detailed plotnft information as JSON + join Join a plot NFT to a Pool + leave Leave a pool and return to self-farming + show Show plotnft information +``` + +To create a Plot NFT, run: + +```bash +chia plotnft create -u +``` + +Be sure to change `` to the URL of the pool you want to use. + +To create a plot NFT in self-farming mode, run: + +```bash +chia plotnft create -s local +``` + +To switch pools, you can run: + +```bash +chia plotnft join +``` + +To leave a pool (switch to self farming), run: + +```bash +chia plotnft leave +``` + +To view the status of your Plot NFT, run: + +```bash +chia plotnft show +``` + +--- + +## Pooling FAQ + +### 什么是联合耕种农田？ + +一个联合耕种农田（plot NFT）是区块链上的智能币或代币，允许用户管理他们在耕种池中的成员资格。 Users can assign the plot NFT to any pool they want, at any point. 在生成地块时，可以选择一个农田，并且该地块将永远与该农田绑定在一起。 在生成地块时，可以选择一个农田，并且该地块将永远与该农田绑定在一起。 农田是“非同质化”的，因为它们不可互换；每个农田代表一个独特的耕种池合约。 + +### 需要支付XCH来创建联合耕种农田或切换耕种池吗？ + +Each plot NFT you create will require 1 mojo (1 trillionth of a XCH) + transaction fee. 切换耕种池只需要支付交易手续费。 切换耕种池只需要支付交易手续费。 如果您没有任何XCH，可以从Chia的官方水龙头获得100个mojo：https://faucet.chia.net/ + +### 可以同时在旧土地和新地块上耕种吗？ + +是的。 农民可以在一台机器上同时耕种旧土地和新地块。 旧地块不会受到创建的联合耕种农田或新地块的任何影响。 + +### 如何新地块分配给一个耕种池？ + +首先，在图形用户界面（GUI）的新的联合耕种选项卡中创建一个“联合耕种农田”（开发者在其代码中称其为“singleton”）。 When you create a new portable plot, you must assign it a specific Plot NFT (for those using CLI, this replaces the Pool Public Key `-p` with a Pool Contract Address `-c`). 所有使用相同“联合耕种农田”生成的地块都可以分配到同一个耕种池进行耕种。 可以在同一密钥上拥有多个“联合耕种农田”。 + +### 在Chia的图形用户界面（GUI）和命令行界面（CLI）中，“Key”（密钥）和“Wallet”（钱包）之间有什么区别？ + +一个用户可以在运行Chia的机器上拥有一个或多个密钥。 A key is represented by the private information (24 words) and the public identifier called the `fingerprint`. 在使用GUI或CLI时，一次只能登录一个密钥。 每个密钥必须单独同步，可以通过点击“钱包”选项卡来检查它是否同步。 每个密钥还可以关联1个或多个钱包。 标准钱包默认创建，它控制您的Chia。 还可以根据需要创建任意数量的联合耕种农田，它们也是钱包，每个都有自己的“钱包ID”，并且它们与您用于创建它们的密钥绑定。 In the CLI, you use both `fingerprint` and `wallet_id` to perform operations on Plot NFTs, which represent the key and wallet ID for that Plot NFT. + +### Chia耕种池（pooling）与其他加密货币的不同之处在哪里？ + +Chia has three major differences from most other crypto pooling protocol: + +1. Joining pools is permissionless. 在加入之前不需要在耕种池(矿池)服务器上注册账户。 在加入之前不需要在耕种池(矿池)服务器上注册账户。 +2. Farmers receive 1/8 of the block reward plus transaction fees, while the pool receives 7/8 of the reward to redistribute (minus pool fees) amongst all pool participants. +3. The farmer with the winning proof will farm the block, not the pool server. + +### 如何搭建一个自己的耕种池？ + +如果您有编写其他加密货币的矿池（耕种池）服务器代码的经验，那么将该矿池代码与Chia的参考耕种池代码进行适配将会比较简单。 我们强烈建议只有拥有良好的操作安全性（OPSEC）和商业经验的人运行公共矿池服务器。 根据您运营矿池业务的国家，您可能需要遵守特定司法管辖区的税收、反洗钱（AML）和了解您的客户（KYC）法律。 由于XCH的盈利能力，所有矿池都将成为黑客攻击的目标，如果您遭受任何损失，您可能会面临法律责任。 + +### 在哪里可以找到Chia耕种池列表？ + +一个加密货币社区网站列出了所有即将推出的Chia耕种池：https://miningpoolstats.stream/chia + +### 我可以在Discord上宣传我的耕种池吗？ + +您只能在Discord的#Promote-community-projects频道中每天宣传您的耕种池一次。 如果您频繁发送广告或垃圾信息，管理员会警告您，并且如果您继续这样做，可能会将您禁止。 + +### 为什么Chia不运营自己的官方耕种池？ + +我们希望有一个健康的、相互竞争且没有官方特权耕种池生态。 + +### 我可以将我的耕种池命名为chiapool.com吗？ + +我们不允许耕种池使用"Chia"作为首个词或其等价词（比如"Chia矿池"）。 不过，可以使用类似"一个Chia耕种池"的表述，尽管这可能需要一个免费且易于获取的许可证。 请访问https://www.chia.net/terms/ 了解更多关于获取许可证的信息。 + +### 如果一个耕种池获得了整个网络51%的算力，他们是否能够接管整个网络？ + +答案是否定的，Chia的耕种池（矿池）协议被设计成由个体农民（farmer）来产生区块，但耕种池的奖励会进入耕种池操作者的钱包。 这确保即使一个耕种池拥有51%的网络算力，他们也必须控制所有具有51%网络算力的农民节点，才能进行任何恶意活动。 这将非常困难，除非所有具有51%网络算力的农民都下载了由像Bram一样高水平天才编程的恶意Chia客户端。 + +### 我还有很多疑问，应该在哪里进行提问？ + +Join our dedicated [Discord](https://discord.gg/chia) + +Friendly reminder: do NOT at `@` or Direct Message (DM) developers or mods. 只需在Discord中发布您的问题，我们会在有空的时候回答您的问题。 + +## 技术类常见问题解答 + +### 我在哪里可以查看Chia耕种池参考代码？ + +可以在这里找到它：https://github.com/Chia-Network/pool-reference。 +README文件中包含了它的工作原理说明，而规范文件则包含了实现细节的详细说明。 + +### 参考耕种池代码使用哪种编程语言编写的？ + +Python + +### 将Chia的参考耕种池（矿池）代码添加到我现有矿池代码有多难？ + +如果您之前已经编写过矿池代码，那么参考耕种池（矿池）代码将会很容易理解。 只需要将PoW的概念替换为Chia的通过PoST评估每个农民参与度的方法，并且适应使用Chia的智能合约来收集和分配XCH，这就是主要的工作。 + +### 作为一名程序员，虽然之前没有编写过矿池代码，但使用Chia的参考耕种池（矿池）代码，是否能够运行一个耕种池呢？ + +如果这是您第一次编写矿池代码，我们建议您查看已建立的比特币（BTC）或以太坊（ETH）矿池的源代码以及它们为用户提供的功能。 您可能会面对来自这些加密货币社区的大型矿池运营商的竞争，他们将在Chia上推出功能丰富的矿池。 例如，排行榜、钱包浏览器、随机奖励、分层矿池费用等。 + +### 耕种池（矿池）代码中使用的变量名称 + +- puzzle_hash: 一个地址（address），但是以不同的格式呈现。 地址是易于阅读的。 +- singleton: 一个智能硬币（合约），保证是唯一的，并由用户控制。 +- launcher_id: singleton的唯一标识 +- points: 积分（points）表示农民所完成的工作量。 它是通过提交的证明数量按难度加权计算得出的。 一个k32地块每天可以10个积分（points）。 要累积1000积分，需要在一天内完成 10 TiB 的耕种量。 这相当于PoW矿池中的份额。 + +### How does one calculate a farmer's space? + +A farmer's space can be estimated by the number of points submitted over each unit of time, or points/second. 每个k32地块平均每天获得10个积分（points）。 每个k32地块平均每天获得10个积分（points）。 So `10 / 86400 = 0.0001157 points/second` for each plot. Per byte, that is `L = 0.0001157 / 108884400275 = 1.06259482265 * 10^-15`. To calculate total space `S`, take the total number of points found `P`, and the time period in seconds `T` and do `S = P / (L*T)`.\ +For example for 340 points in 6 hours, use `P=340, T=21600, L=1.06259482265e-15`, `S = 340/(21600*1.06259482265e-15) = 14,813,492,786,900 bytes`. Dividing by `1024^4` we get `13.4727932044 TiB`. + +:::info + +Note that this calculation is based on the new constant space factor estimation of 0.78005, as detailed in the [space factor table](/chia-blockchain/resources/k-sizes#new-constant-space-factor). + +::: + +### How does difficulty affect farmer's space calculation? + +随着难度的增加，农民进行的查找次数减少，找到的证明（proof）数量也减少，但每个单位时间内收到的积分（points） 数量不会增加。 想象一下这种情况：在难度为1的情况下，每个k32地块每天获得 10个证明（proof），而在难度为 10 的情况下，每天只能获得1个证明（proof）。 作为一个矿池服务器，您更喜欢每个k32地块每天获得难度为10的1个证明（proof）。 This is why we allow pool servers to set a minimum difficulty level to reduce the number of proofs each farmer needs to send to prove their space. + +### 如何识别提交了部分证明（partial proofs）的农民？ + +农民将提供他们的 "launcher_id"，这是该农民所属联合耕种农田（矿池组）的ID。 同时，耕种池还会验证存储空间的证明和农民的签名，以确保只有真正的农民能够获得奖励。 + +### 耕种池服务器是否需要跟踪所有农民及其奖励份额？ + +是的，耕种池操作者需要编写代码来跟踪所有农民及其奖励份额。 Chia的耕种池协议假设加入耕种池不需要注册，因此每个提交有效部分证明的 "launcher_id" 都需要被耕种池服务器进行跟踪。 + +### 单例（singleton）可以执行哪些操作？ + +对于单例，有一些操作可以执行： + +- 更改耕种池（需要拥有者的签名） +- 退出耕种池，这是宣布您将更改耕种池（需要拥有者的签名） +- 领取奖励（不需要任何签名，奖励将发送到单例中指定的地址） + +### How do pools collect rewards? + +- 农民加入矿池后，他们会将自己的单例（singleton）分配给矿池的拼图哈希（pool_puzzle_hash）。 +- 当农民赢得一个区块时，矿池奖励将被发送到p2_singleton_puzzle_hash（农民单例的拼图哈希）。 +- 矿池将扫描区块链，查找发送给农民单例的新奖励。 +- 矿池将向获胜的农民单例发送奖励认领请求。 +- 农民单例将发送耕种池奖励部分XCH到pool_puzzle_hash（矿池拼图哈希）。 +- 矿池将定期分发奖励给具有积分（points）的农民。 + +### 如何判断服务器是否从特定客户端收到足够的部分证明（partials）？ + +耕种池只知道收到的部分证明数量，并不知道农民的确切总算力。 算力可以通过以下方法计算：每个k32地块在主网上平均每天可以获得10 个积分（points）。 这意味着如果难度设置为 1，那么每天会收到 10 个部分证明（partials）；如果难度设置为 10，则每个k32地块每天会收到 1 个部分证明。 + +### 为什么我在测试网上收到的积分（points）比在主网上多？ + +The 10 points per day per k32 plot only applies to mainnet, which has a `DIFFICULTY_CONSTANT_FACTOR` of 2^67. To get +the points per day per k32 on testnet, divide 2^67 by the testnet `DIFFICULTY_CONSTANT_FACTOR`, found in `config.yaml`, and +multiply by 10. 这样可以轻松地使用k25s参与测试网。 + +### k32和k25之间的预期比例是多少？ + +Look at the file `win_simulation.py` on this repo. This uses the function `_expected_plot_size` from chia-blockchain, +which uses the formula: `((2 * k) + 1) * (2 ** (k - 1))` to compute plot size. 将 k 值代入公式并进行计算。 + +### 如何计算在Z时间内，具有Y大小的地块在X难度下可以获得多少个部分证明（partials）？ + +Look at the `win_simulation.py` file. + +### 我可以在主网上使用测试网的联合耕种地块吗？ + +不能，只能在主网上使用为主网创建的地块，在测试网上使用为测试网创建的地块。 + +### 这是否意味着Chia的分叉（forks）不能使用这些联合耕种地块？ + +Chia的分叉可以通过向农民目标地址发送1.75 XCH（Chia币）来轻松使用这些联合耕种地块，从而使得它们变成独自耕种的地块。 If the alternate blockchain wants to do pooling as well, they need to create a special transaction +which `reserves` a singleton by providing the `launcher_id`, and launcher spend (including owner signature). 然后，代码可以自动将该单例分配给提交它的用户。 + +### 联合耕种池是否支持其他区块链矿池中使用的各种支付方式？ + +一般而言，是的，因为支付系统是由耕种池（矿池）运营者管理的，而不是由区块链管理的。 我们建议对这个领域不熟悉的耕种池（矿池）运营者选择较为稳健的支付方式，比如PPLNS（基于上次提交的部分证明数的支付方式）。 然而在技术层面上，您可以利用任何支付系统，因为代码是由您管理的（这是在您广泛扩展参考代码或从头开始构建自己的耕种池（矿池）时假定的）。 但是，如果您选择像FPPS（固定支付量与算力奖励相关）/PPS（按提交的部分证明数来支付）等支付方式，您需要意识到可能存在“死权重”攻击的风险（这在其他区块链协议上也可能发生）。 恶意参与者可能会牺牲大量收益来损害您耕种池（矿池）的方差比率，导致您的耕种池（矿池）运行亏损。 因此，我们建议不要使用FPPS/PPS系统，除非您具有丰富的耕种池（矿池）运营经验，并知道如何构建应对措施以确保您的耕种池（矿池）稳定应对方差风险。 + +### 矿池服务器需要支持Chia客户端的API方法有哪些呢？ + +矿池需要支持几种API方法。 这些API方法在这里有详细的文档说明：https://github.com/Chia-Network/pool-reference/blob/main/SPECIFICATION.md + +### Where can I see the video Technical Q&A on Chia Pooling: + +For those interested in the Chia Pools for Pool Operators video and presentation, you can find it here: + +- https://youtu.be/XzSZwxowPzw +- https://www.chia.net/assets/presentations/2021-06-02_Pooling_for_Pool_Operators.pdf diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/reference-farming-hardware.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/reference-farming-hardware.md new file mode 100644 index 00000000000..81152d9c28a --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/farming/reference-farming-hardware.md @@ -0,0 +1,42 @@ +--- +title: Reference Farming Hardware +slug: /reference-client/farming/reference-farming-hardware +--- + +# 参考耕种（Farming）硬件 - 适用于任何规模的耕种 + +## 好奇者 + +开始Chia耕种的最简单方法是将USB硬盘连接到台式计算机，或者安装SATA硬盘。 耕种所需的最小存储量仅为一个地块(Plot)！ 初学者应该从几个硬盘开始，使耕种运行值得，每月赚取几美元。 可以使用台式计算机来生成地块（plots）（请参阅生成地块部分）。 还有一些公司（如Evergreen），通过提供预先生成地块的硬盘和移动应用程序，简化了生成地块的过程。 对于好奇的农民来说，生成地块可能是限制因素，因为他们的台式计算机或笔记本可能没有足够的计算资源和适合生成地块的临时SSD存储，但即使对于初学者来说，用地块填满一个硬盘也相当容易。 + + + +## 爱好者 + +当您拥有几百TB的存储空间时，考虑使用专用的台式计算机用于Chia耕种，或者使用NAS或外部存储盒。 一个经验法则是要查看每个插槽（每个硬盘）的成本，以免为了存储磁盘而花费比磁盘本身更多的钱！ + + + +### NAS + +NAS（网络附加存储）是一种专用设备，通过硬盘槽位、轻量级CPU和DRAM提供存储服务。 NAS通过网络提供存储（与直连存储DAS相对）。 NAS在较小的空间中拥有大量硬盘，非常高效节能。 唯一的缺点是它们通常比原始存储盒更昂贵，因为它们是为消费者存储和应用而设计的。 + +### 多硬盘的外部存储（USB） + +使用USB的外部存储盒可以通过单个USB电缆连接5-8个硬盘，并具有集成电源和散热（风扇）。 这对于爱好者来说是一个很好的选择，可以扩展他们目前的计算机硬件。 + +### 带有大量硬盘的台式计算机 + +标准的全塔式台式计算机可以容纳8-12个3.5英寸硬盘。 这些机箱对于那些已经组建过标准台式计算机的人来说非常友好，安装硬盘只需用SATA数据线和ATX电源就可以，不需要大量专业计算机经验。 + +## 专业用户 + +专业用户的存储目标是超过1PB，这时更高级的策略开始发挥作用。 这些策略包括GPU绘图、HBA（主机总线适配器）和使用的企业级存储服务器。 使用过的企业级存储设备是一个很好的起点，因为可以在eBay等二手市场上找到价格便宜的高硬盘计数的服务器。 旧的JBOD（仅有一堆硬盘）可以容纳24-45个硬盘，可以在二手市场上找到几百美元的价格。 尽管这些设备成本较低，但农民需要了解企业级存储协议和基础设施，比如SAS。 专业用户通常混合使用消费者和企业级设备，以在购买时以无情的成本效益。 + + + +## 专业农民 + +致力于多个PB的严肃的Chia农民将不得不进入服务器机架的世界。 幸运的是，世界各地的数据中心已经为在服务器机架中存储极大量的数据设计出了最佳方式。 严肃的农民将使用JBODs。 JBOD（仅有一堆磁盘）是一种专用设备，用于容纳大量硬盘，并不包含任何集成的计算资源。 JBOD通常由一个机箱、标识每个硬盘的机箱插槽、SAS扩展器和背板、风扇和电源组成。 JBOD中的所有磁盘可以通过连接到主机服务器或台式计算机的单个SAS电缆来访问，该电缆通过HBA（主机总线适配器）将PCIe插槽转换为SAS接口。 严肃的农民将在机架中放置许多这样的JBOD，以获得非常高密度的存储，使用现代JBOD和高容量HDD，单个机架可以达到超过10PB的存储容量。 + + 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 new file mode 100644 index 00000000000..e3a3ed2047c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/farming-guide.md @@ -0,0 +1,428 @@ +--- +sidebar_label: Farming Guide +title: Beginner's Guide to Farming +slug: /reference-client/getting-started/farming-guide +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +So you want to be a Chia farmer? You've come to the right place! + +Chia plotting and farming can seem daunting at first, but it's a relatively straightforward process: + +1. [Obtain hardware](#obtain-hardware) +2. [Install Chia](#install-chia) +3. [Run and configure Chia](#run-and-configure-chia) +4. [Create a plot](#create-a-plot) +5. [Start farming](#start-farming) + +This guide will take you through each of these steps. We will set up a Chia farm, which includes syncing a full node and creating your first plot. This will take anywhere from an hour to several days, depending on a number of factors. But don't worry -- most of this time will not require you to be active on your computer. + +:::info + +This guide is intentionally light on technical details. It is only intended to help new users set up a basic farm, ideally using equipment they already own. Subsequent pages on this website will go into the concepts introduced in this guide in much greater detail. + +::: + +Ready? Let's get started! + +## Obtain hardware + +You may already have everything you need, but let's make sure. (All you need for this tutorial is the minimum requirements. We'll cover more optimized setups later.) + +### Computer + +Most computers made after 2010 can be used for farming, as long as they have a 64-bit CPU. Windows, Linux, and Mac OS are supported. This entire guide was created from a Windows laptop. + +_Farming_ does not require a fast computer. The minimum spec is a Raspberry Pi4 with 4 GB of RAM for a CLI farm, or 8 GB for a GUI farm. (This guide will show you how to set up a GUI farm.) Many farmers choose a Pi because it consumes very little electricity. + +_Plotting_, on the other hand, is resource-intensive. Luckily, once a plot has been created, it can be farmed for many years. A Pi _can_ be used for plotting, but it will be quite slow. As will a laptop. Long-term, these are not great options. + +However, for creating your first plot, it's a good idea to use the equipment you already own. Once you get a feel for Chia farming, you will have a much better idea of what to acquire later. + +### Plot storage + +For this guide, we will create a single plot. This will require: + +- 4 GB of available RAM + - If you don't have this much, you can use Linux swap space, but it will be very slow +- 275 GB of temporary storage + - An HDD will work, but it will be slow + - An SSD will be much faster; it's a good option for this tutorial + - RAM is the fastest option (the minimum for RAM plotting is 256 GB; if you don't have that much, don't worry about it for now) +- 108.8 GB of free space where the plot will live + - An SSD will work, but is overkill + - The vast majority of plots are stored on HDDs + +A laptop or desktop with 400 GB of free space will satisfy these requirements. A 512-GB external SSD (available for ~$35 on Amazon) is another option. + +### Database SSD + +In order to store the blockchain database, an SSD with at least 520 MB/s read/write speeds is required (it doesn't need to be a high-speed NVMe SSD, but unfortunately HDDs aren't fast enough). As of mid-2023 the database is ~130 GB; a 256 GB SSD will likely be usable until 2025. External and internal SSDs are both fine. + +:::info + +Let's say you have a computer without much free space. If you add a 1024-GB external SSD, it will be sufficient to create and store a plot, as well as to store the blockchain database. This will not be an ideal setup for +creating a larger farm. But if you already have this equipment, you can set up a small farm without spending any money. + +::: + +Once you have the required hardware, it's time to install Chia. + +## Install Chia + +Head to [the official download page](https://www.chia.net/downloads/); download and run the installer for your Operating System. The default settings are fine for most setups. + +Two check boxes will be shown on the last screen after the install has completed. It's a good idea to check both of them. Doing so will allow you to type `chia` in a terminal window without requiring the full path, and it will automatically start the application. + +
+ Check both boxes +

+ +## Run and configure Chia + +The first time Chia starts, you will be given the option to run in either Wallet Mode or Farming Mode. You will be setting up a Chia farm, so click `CHOOSE FARMING MODE`: + +
+ Choose farming mode +

+ +### Create a wallet + +Assuming you don't have a wallet yet, click `CREATE A NEW WALLET KEY` (If you already have a wallet, you can import it by clicking the green `ADD WALLET` button): + +
+ Create a new wallet key +

+ +You will be presented with a list of twenty-four words. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is important. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is also important. + +You can also choose a custom name for your wallet. Click NEXT when you are finished. Click `NEXT` when you are finished. + +:::warning + +If someone obtains a copy of these words, they can steal your entire wallet, including all of its funds. Be sure to store your recovery phrase in a safe place. Be sure to store your recovery phrase in a safe place. + +::: + +
+ Wallet seed phrase +

+ +You will be taken to your wallet, which will show a zero-XCH balance. There will be two round icons in the upper-right corner, one for the full node and one for the wallet: + +- Full node -- this icon will appear red until you connect to at least one peer. At this point it will turn yellow, which indicates that your full node is syncing. +- Wallet -- this icon will appear yellow at first. Your wallet will attempt to connect to three peers for syncing. It should be synced within a few seconds, at which point the icon will turn green. + +
+ Zero wallet balance +

+ +### Fund your wallet + +If you think you will ever want to join a pool (recommended for small and medium farms), you will need at least one mojo (one trillionth of an XCH). To help with this, we have set up an online faucet at [faucet.chia.net](https://faucet.chia.net/). + +To use the faucet you will need to identify your **Master Public Key** (also referred to as the **Public Key**). +You can use either the GUI or CLI to identify the Master Public Key by following these steps: + +#### GUI + +:::warning +Never share your private / secret keys or mnemonics with anyone. These give access to spend funds from your wallet. +::: + +1. In the top right corner select logout: + +
+ Logout of the Chia wallet +

+ +2. Using the desired keys menu, select details: + +
+ Select Details for a Chia keyset +

+ +3. View and copy the **Public Key** to the field on the Faucet page: + +
+ Chia keys detail screen, Public Key highlighted +

+ +#### CLI + +:::warning +**NEVER** share your private / secret keys or mnemonics with anyone. These give access to spend funds from your wallet. +::: + +In order to view your keys from the cli, run `chia keys show`, optionally including the `-f ` flag to show only the info for the key you just generated: + +1. From terminal (mac/linux) or powershell (windows) run `chia keys show`: + +```bash +chia keys show +``` + +2. View and copy the **Master Public Key** to the field on the faucet page: + +```bash +Showing all public keys derived from your master seed and private key: + +Label: Demo Wallet +Fingerprint: 2281896037 +Master public key (m): 96ce91d974daa0990e6681ac2de3e3f49142f6b655a081817832265c143e658a6e60a5dec856f292f45fe2d04c7856f6** +Farmer public key (m/12381/8444/0/0): a9e366b26f155491af9a903c0ed9717bfd09a71cbe283eeda825128fd7c6b9ac60e1608f9f008adcfbf66e233d5b4ce8 +Pool public key (m/12381/8444/1/0): 9566fa434f342dd5f9380a6bfc59dd7d1abd22869a425a8ca09cf27200eaa6aad5bc8fc00db90af832eb8028b0c6e3f0 +First wallet address: xch1kr3zf7dqw5q953ex6zt33lndj90q0zlh68404tsntnljthnwqs2qvjmwrg +``` + +:::note +For more security best practices please review the [Securing Your Chia – How to Be a Hard Target](https://www.chia.net/2021/05/28/securing-your-chia-how-to-be-a-hard-target/) blog article. +::: + +:::info + +You can continue with this guide while waiting for your 100 mojos to arrive. + +::: + +### Sync your node + +Click the `Full Node` icon on the left side of your wallet: + +
+ Syncing from genesis +

+ +This screen shows your node's syncing status. In order to farm Chia, your node needs to be fully synced. You have two options to achieve this: + +1. Sync from genesis -- the above image shows this happening. Your node will connect with up to 80 peers and download information for each block. This is the most secure way to sync a node, and the only way to be sure that the information is accurate. However, it will take at least a few days, and possibly a week or more to sync from genesis, depending on your node's speed, your internet connection, and the quality of the peers to which you connect. +2. Download a checkpoint database -- this option will allow you to sync much faster, but you have to trust that the information is accurate. For most users, this will be a worthwhile tradeoff. + - Head to our official [checkpoint download page](https://www.chia.net/downloads/#database-checkpoint) and click the `Torrent` link for the mainnet Database. + - When your download has completed, use [BitTorrent](https://www.bittorrent.com/) to open it; be sure to verify it with the checksum listed on the download page. + - Move the database to the appropriate destination (see below). + +:::warning + +**Never** download a database from a third party. A database or torrent file with a checksum that does not match the checksum from the official download page is likely malware. Installing malware will result in all of your XCH being stolen, or worse. + +::: + +:::info + +By default, the database will be stored in `~/.chia/mainnet/db`. If you don't want to store it there (for example, if your computer lacks sufficient free space), you will need to change your configuration: + +- Edit `~/.chia/mainnet/config/config.yaml` -- this is this primary configuration file for all Chia settings. +- Search for `database_path` in the `full_node:` section. + - The default value is `db/blockchain_v2_CHALLENGE.sqlite`. + - Change the path to the location of your database. For example, to store the database on an external SSD, you might change this to `/media/externalSSD/db/blockchain_v2_CHALLENGE.sqlite`. You do not need to change the name of the .sqlite file. + +If you change this setting, you will need to restart Chia for the change to be applied. + +::: + +Even if you choose to download the checkpoint database, it will take some time for your node to sync. This is because the checkpoint database is only updated once every three months. You will therefore need to sync from the time the checkpoint was taken until the head of the chain. + +Regardless of which method you choose for syncing, you can continue with this guide while waiting. + +### Join a pool + +Over the long term, your reward for farming will be directly proportional to the total space on the network (AKA netspace). For example, if your farm controls 1% of the netspace, it will win 1% of the rewards, on average. + +Over the short-to-medium term, luck can play a large factor in your winnings. Small farms _could_ get lucky and win an outsized number of rewards very quickly, but they are equally likely to be unlucky. + +For this tutorial, we are creating a single plot, the smallest farm possible. As of this writing, a single-plot farm will only collect a reward once every 161 years! + +So why even bother trying? + +That's where pooling becomes valuable. Pools, well, _pool_ their farming resources. When one member of a pool wins a reward, it is split among all participants according to the amount of space they contributed. The effect is a smoothing out of one's rewards over time, resulting in a consistent payout. Most users with small farms (and even some with large farms) join a pool. + +Click the `Pooling` icon on the left side of your wallet, and click `JOIN A POOL`: + +
+ Join a pool +

+ +Before you can join a pool, you will need to create a plot NFT. This will allow you to easily change pools later. + +Select `Connect to pool`. You will need to enter a valid pool URL. We will use OpenChia for this example, but there are many great pools to choose from. For a list of reputable pools, see [Chialinks.com](https://chialinks.com/pools/). (Chia Network Inc. does not run a pool, and is not affiliated with OpenChia or Chialinks). + +:::info + +If you don't want to join a pool, select `Self pool`. This will assign you to a pool with only one participant: you. Later, you can join a pool with the same plot NFT if desired. + +::: + +Creating a plot NFT requires an on-chain transaction that will cost one mojo. You are also recommended to enter a blockchain fee. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes. You are also recommended to enter a blockchain fee. If you used the faucet, you will now have 100 mojos. Depending on how busy the network is, a one-mojo fee is typically enough to complete your transaction within a few minutes. + +
+ Create a plot NFT +

+ +:::info + +If you have not received your faucet payment, unfortunately you will not be able to create a plot NFT. This is a really important step. If you skip it, you will only ever be able to solo farm with the plots you create. You are therefore not recommended to skip this step. + +If your faucet payout has not arrived after more than 10 minutes, someone on [Discord](https://discord.gg/chia) might be willing to send you some mojos if you ask nicely. + +::: + +If you entered a valid pool URL, the details will pop up. For example, this pool has a fee of 1%. If everything looks acceptable, click CREATE: For example, this pool has a fee of 1%. If everything looks acceptable, click `CREATE`: + +
+ Pool details +

+ +Your transaction will be pushed to the blockchain. While it is pending, a new screen will appear: While it is pending, a new screen will appear: + +
+ Plot NFT pending +

+ +After the transaction has been finalized (typically 1-3 minutes), the details of your plot NFT will appear: + +
+ Plot NFT details +

+ +A two-word name will automatically be assigned to your plot NFT, in this case "Harlequin Koala". In order to determine how much space you are contributing, your pool will periodically send you challenges. If you want to change pools later, simply return to this screen and click `CHANGE POOL`. + +:::note + +Pools typically require you to wait for 30 minutes before leaving. This is to prevent you from leaving the pool when you are about to farm a block, thus keeping the reward for yourself. + +::: + +:::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](/docs/chia-blockchain/introduction.md#pooling). + +::: + +## Create a plot + +Plots are large files that consist almost entirely of cryptographic data to be used in Chia farming. The plot creation process does not require a full node or wallet to be synced. In fact, it doesn't even require an internet connection. + +For this tutorial, we will create a plot from inside the same application that runs the node and wallet. For the creation of subsequent plots, you may want to offload this work to a computer that has been optimized for plotting. + +From the Chia application, click the `Farm` icon and click `ADD A PLOT`: + +
+ Add a plot +

+ +If you previously created a plot NFT, it will show up now. The plots you create will be associated with this NFT. It is important that you associate all of your plots to the same NFT in order to farm to a pool, as well as to be able to change pools easily if desired. As long as your plot NFT shows up here, there is no need to change it: + +
+ Plot NFT +

+ +Next, you will need to choose a plotter. When creating a single plot, `Chia Proof of Space` and `madMAx` both will work on almost all hardware. The plot from this example was created with `madMAx` because it requires the smallest amount of temporary disk space. + +:::info + +When building a larger farm, the plotter you choose will depend greatly on your available hardware. It may help to experiment with multiple plotters to get a feel for which ones work best for your setup. For details on each of the available plotters, see our [Plotting Software](/reference-client/plotting/plotting-software) section. + +::: + +
+ Choose plotter +

+ +For the `Keys` section, you typically won't need to change anything. + +
+ Keys +

+ +Next, you will need to choose a `k` value, and possibly a compression level. + +`k` is a constant that dictates the size of the plot. The minimum `k` for Chia's mainnet is 32. This is also the most common size used, by far. With each increment in this value, all of a plot's associated parameters are doubled. For example, a k33 plot is twice as large as a k32 plot, and it requires twice the memory, temporary storage, and time to be created. + +For this tutorial, we'll choose k32. Note that some plotters are only capable of creating k32 plots, so you might not see any other options. + +:::info + +Due to advancements in technology, the minimum `k` value will likely need to be increased at some point. This would require you to replot all k32 plots. However, there are currently no plans to increase the minimum `k`, and we will do our best to give you at least a one-year notice if any such plans are made. + +::: + +Certain plotters are also capable of creating compressed plots, which are discussed in great detail in the [Plotting Basics](/reference-client/plotting/plotting-basics) section. If the `Compression Level` dropdown appears, fee free to select `3`. This is a modest level of compression that even low-power systems can harvest. Most farmers will want to create compressed plots, but for now we just want to get a feel for creating a single plot. A C0 (uncompressed) plot is fine for accomplishing this goal. + +
+ Choose K value +

+ +Next, you need to select the temporary and final directories for your plot. The medium for temporary storage will greatly affect the speed at which your plot is created: + +- **RAM** -- For plots created entirely in RAM, there is no temporary storage. RAM plotters can typically create k32 plots in a few minutes, but they also require a significant amount of memory (256 GB - 416 GB, depending on the plotter). +- **SSD** -- Most farmers choose to use an enterprise NVMe SSD for the temporary storage. These SSDs can handle large amounts of reads and writes in their lifetimes. +- **HDD** -- If you don't mind plotting slowly, you can choose a directory located on an HDD. + +The final directory is where the plot will be copied after it has been created. The final directory is where the plot will be copied after it has been created. Most farmers will choose to use an HDD as the final directory. However, for this tutorial an NVMe SSD was used for both the temporary and final directories. + +:::warning + +SSDs are rated for a certain number of writes. Creating a plot is write-intensive. If you plan to create thousands of plots, avoid doing so on a consumer SSD or you will risk wearing it out. + +::: + +You will also need to choose how many plots to create. Certain plotters can be optimized by creating multiple plots in parallel. However, we will only create a single plot for this tutorial: + +
+ Temporary and final directories +

+ +After you have gone through all of these settings, click `CREATE`. You will be taken to a progress panel: + +
+ Plot creation progress +

+ +The amount of time required to create this plot is highly dependent on your hardware. The world record time to create a k32 plot is around 30 seconds. The plot for this tutorial was created on a laptop in around 3 hours. + +:::info + +Some of the available plotters can create k25 plots. These plots are significantly smaller than k32, so they can be created quickly. However, they are for testing purposes only. Any proof of space taken from a plot smaller than k32 on mainnet will be rejected. + +::: + +While waiting for your plot to be created, feel free to browse through the Chia application. However, if you shut down the application, the plotting process will be stopped and all progress will be lost. There is no "pause" button for plotting. + +## Start farming + +Before you can begin farming, you need to be running a synced full node. Earlier in this tutorial, you either chose to sync from genesis, or to sync from a checkpoint database. In both cases, the `Full Node` screen will eventually show a status of `Synced`: + +
+ Synced node +

+ +Your node is now synced. If your plot has finished being created, you are also farming. To verify this, click the `Farm` icon: + +
+ Farm health +

+ +You will be shown a number of details about your farm. As long as the `Farm Health` section has all green icons, everything is working as expected. + +**Congratulations! You have become a Chia farmer.** + +There is still a lot to learn, but you already have the basic knowledge needed to grow your farm. + +## Next steps + +Once you have a small farm up and running, you can decide whether to expand, and how to do so. The following pages will show you: + +- [Basic details of Chia plots](/reference-client/plotting/plotting-basics), including "compressed" versus "uncompressed" plots +- [How to select the optimal computer for plotting](/reference-client/plotting/plotting-hardware) +- [List of Chia plotting software](/reference-client/plotting/plotting-software) +- [How to choose a plot compression level](/reference-client/plotting/plotting-compression) +- [How to create Chia plots](/reference-client/plotting/plotting-how-to) +- [Notes about SSD encurance](/reference-client/plotting/ssd-endurance) +- [How to move plots](/reference-client/plotting/moving-plots) to their final destinations + +## 如何获得帮助 + +- Get help on CNI's official [Discord](https://discord.gg/chia), in the `#farming-and-plotting` and `#support` channels. +- Get more questions answered in the [plotting FAQ](/reference-client/troubleshooting/plotting-faq). diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/using-the-gui.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/using-the-gui.md new file mode 100644 index 00000000000..034a896e109 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/using-the-gui.md @@ -0,0 +1,106 @@ +--- +title: 使用图形用户界面（GUI） +slug: /reference-client/getting-started/using-the-gui +--- + +## Getting Things Set Up + +Getting started with Chia is easy with the use of the graphical user interface (GUI). Upon opening and selecting wallet or farming mode, you'll be given the ability to create a key. Each key is a 24 ordered word seed phrase used to control your wallet. **Do not share your 24 words with anyone**. + +

+ select key +

+ +You will also be given the option to use the Chia GUI in **farming mode** or **wallet mode**. We'll start with farming mode. Don't worry if you've already chosen wallet mode as this can be easily changed within settings (as well as dark mode and language choice). + +## Settings + +Before we get to the fun stuff, let's take a look at the settings you'll want to know about to use Chia properly. + +First, here is how you switch between farming and wallet mode. + +

+ settings +

+ +At the bottom of the settings you'll see the option for setting a passphrase. This is an additional layer of security that requires a password to access the Chia client. + +:::warning +Enabling a passphrase is a recommended step for protecting your funds, but it only protects your local Chia client. This may stop someone from steeling your funds while you're away from your desk, but does not protect your funds if someone gains access to your 24 words. +::: + +## Syncing + +Upon opening Chia, your wallet will need to sync. You'll need to see a green checkmark next to the **WALLET** label in the upper-right corner before seeing any tokens you have. + +

+ synced +

+ +All transactions on the Chia blockchain are added to blocks. These blocks are downloaded sequentially as your client syncs. If someone has sent you Chia (or any other tokens on the Chia blockchain), your node doesn't know the transaction exists until you've synced past that block. + +## Tokens + +The main cryptocurrency of the Chia network is Chia (XCH). This is used for sending value between wallets and also for fees to ensure transactions go through. In addition to Chia, we have tokens, which are cryptocurrencies built on top of the Chia blockchain. These tokens are known as CATs (Chia asset tokens). + +When you open the Tokens tab for the first time, it will look this: + +

+ tokens tab +

+ +We have no Chia and no tokens. You can see a list of other tokens that can be acquired within the **manage token list** section. + +

+ tokens +

+ +These are all tokens that can be received the same way as Chia, but will have a unique quantity, utility, and value. Both Chia and any CATs can be sent to your **receive address**. Your wallet will have multiple receive addresses, so this value may change. + +

+ receive address +

+ +Additionally, you can send tokens to any other address. + +

+ sending XCH +

+ +Upon sending the transaction, it will be broadcasted to full nodes in the network. The fee will help push your transaction through to the blockchain after it reaches the mempool of a full node. Farmers get not only block rewards but also transaction fees, so transactions with fees are prioritized. We recommend a fee of at least .000005 XCH. + +## NFTs + +NFTs are non-fungible tokens (each is unique) and are supported natively in Chia. + +Upon opening your NFTs for the first time, you'll only be met with a message to start collecting NFTs. + +

+ go collect some gems +

+ +One way to get NFTs is to find them in a marketplace such as [Dexie](https://dexie.space/nft). + +In the next section we will learn about offers which can be used to acquire NFTs in a decentralized way. + +[Read more about NFTs](https://chialisp.com/nfts). + +## Offers + +When acquiring NFTs or tokens, you may need to make an offer for them. Offers are a form of decentralized exchange. Using offers you can trade one asset for another with no middleman. + +

+ offers +

+ +By using offers you are embracing the decentralized nature of the Chia blockchain. + +[Read more about offers](https://chialisp.com/offers). + +## Run Chia Services in the Background + +Starting in version 2.3.0, this is possible. When you attempt to close the application, the confirmation window will now display a checkbox. If you want to continue running your full node, harvester, farmer, etc after closing the GUI, be sure to check the checkbox, as demonstrated in the following image: + +

+ offers +

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 new file mode 100644 index 00000000000..60c7517b020 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/getting-started/wallet-guide.md @@ -0,0 +1,680 @@ +--- +title: Wallet Guide +slug: /reference-client/getting-started/wallet-guide +--- + +# Wallet Guide + +So you want to set up and use a chia wallet? You've come to the right place! + +1. [Install Chia](#install-chia) +2. [Run and Configure Chia](#run-and-configure-chia) +3. [Create a Wallet](#create-a-wallet) +4. [Use the Chia Wallet](#use-the-chia-wallet) + +This guide will take you through each of these steps. We will set up a Chia wallet, which includes syncing a wallet node and learning about offer files. + +:::info + +This guide is intentionally light on technical details. It is only intended to help new users set up a basic wallet. Subsequent pages on this website will go into the concepts introduced in this guide in much greater detail. + +::: + +Ready? Let's get started! + +## Install Chia + +Head to [the official download page](https://www.chia.net/downloads/); download and run the installer for your Operating System. The default settings are fine for most setups. + +Two check boxes will be shown on the last screen after the install has completed. It's a good idea to check both of them. Doing so will allow you to type `chia` in a terminal window without requiring the full path, and it will automatically start the application. + +
+ Check both boxes +

+ +## Run and configure Chia + +The first time Chia starts, you will be given the option to run in either Wallet Mode or Farming Mode. You will be setting up a Chia wallet, so click `CHOOSE WALLET MODE`: + +
+ Choose wallet mode +

+ +## Create a wallet + +Assuming you don't have a wallet yet, click `CREATE A NEW WALLET KEY` (If you already have a wallet, you can import it by clicking the green `ADD WALLET` button): + +
+ Create a new wallet key +

+ +You will be presented with a list of twenty-four words. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is important. This is your wallet's recovery phrase. These words are all that are needed to recover your wallet on a new computer. Write them down and store them in a safe place. The order of the words is also important. + +You can also choose a custom name for your wallet. Click NEXT when you are finished. Click `NEXT` when you are finished. + +:::warning + +If someone obtains a copy of these words, they can steal your entire wallet, including all of its funds. Be sure to store your recovery phrase in a safe place. Be sure to store your recovery phrase in a safe place. + +::: + +
+ Wallet seed phrase +

+ +You will be taken to your wallet, which will show a zero-XCH balance. There will be a round icon in the upper-right corner for the wallet sync status: + +- Wallet -- this icon will appear yellow at first. Your wallet will attempt to connect to three peers for syncing. It should be synced within a few seconds, at which point the icon will turn green. + +
+ Zero wallet balance +

+ +--- + +## Use the Chia Wallet + +This tutorial demonstrates using Chia Offers with the reference wallet GUI. + +See also our [command line tutorial](/guides/offers-cli-tutorial) and our Offers standard [reference](https://chialisp.com/offers). + +Chia Asset Tokens (CATs) are fungible assets on Chia's blockchain. In Chia parlance, "CAT" and "token" are often used interchangeably. Each CAT must come with its own Token and Asset Issuance Limiter (TAIL), a program that dictates how the CAT may be issued. For more information, see our [CAT standard](https://chialisp.com/cats) documentation. + +### Add a new CAT + +1. If you would like to acquire a CAT from an Offer, your wallet will need to recognize the CAT first. Click `MANAGE TOKEN LIST` in the lower-left corner of the reference wallet GUI: + +
+ manage token list +

+ +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: + +
+ add token +

+ +3. If your new CAT is not included in the reference wallet, you will need to obtain its Asset ID (TAIL). There are multiple websites that provide a listing of CATs and their IDs. One such site is [spacescan.io](https://www.spacescan.io). Simply browse to the website, then search for your CAT. For example, here is a search for "dexie bucks": + +
+ search for dexie bucks +

+ +In addition to CATs, Spacescan provides a listing of NFTs. In certain cases, such as with Dexie Bucks, there are CAT _and_ NFT collections with the same name. In this case, be sure to click on `CAT2`, as in the above image. + +The result will show you the details of the CAT you selected, including its ID. Copy this ID by clicking the icon as shown here: + +
+ copy dexie bucks ID +

+ +It is recommended that you check with another source of truth to make sure you have the correct ID. Another website that provides a listing of CATs and their IDs is [taildatabase.com](https://www.taildatabase.com/). Browse to this site, click the `Explore` menu, and search for your CAT. The name should appear in the search results: + +
+ taildatabase dexie bucks search +

+ +Some information about the CAT will appear, including its Asset ID, as highlighted here: + +
+ taildatabase dexie bucks asset ID +

+ +Copy this ID and continue to the next step. + +:::warning + +If someone sends you an Asset ID (TAIL), do not assume it is correct. Instead, double-check with [spacescan.io](https://www.spacescan.io) or [taildatabase.com](https://www.taildatabase.com/) (or preferably both) to verify that you have the correct ID. + +::: + +3. Enter the name and asset ID for your new CAT, then click `ADD`: + +
+ One Meeellion CATs +

+ +Your new CAT will now appear in the "Tokens" list in your wallet. + +### Create an XCH-CAT offer + +For our first example Offer, we will offer 1 XCH in exchange for the new CAT. + +1. Click the `Offers` icon, then click `CREATE AN OFFER` to get started: + +
+ create an offer +

+ +2. Next, fill in the details of the Offer. By default, the Offer will be set to expire after 7 days. This is likely fine in most cases. (If an Offer never expires, there is a chance it will be taken as arbitrage long after the maker has forgotten about it.) However, feel free to enter a different expiration time if desired. + +In this example, we will offer 1 XCH for 1000 tokens, and include a small blockchain fee, which will only be applied when the Offer is taken. + +After all of the details have been filled in, click `CREATE OFFER`: + +
+ fill in offer details +

+ +3. If anyone acquires this Offer and it is still valid, they will be able to take it. Click the `I UNDERSTAND` button and the Offer will be created: + +
+ confirm offer +

+ +3. At this point, the Offer has been created locally. However, until you share it, it is unlikely that anyone will know it exists. Feel free to email the Offer file, share it on social media, etc. The Offer file does not contain any sensitive data. Whoever sees it will only have two options: take it or ignore it. + +You can also use the panel that appears to share your Offer in a few default locations: +_ Dexie -- a bulletin board that acts as a Decentralized EXchange (DEX) +_ Hashgreen -- another DEX, as well as an Automated Market Maker (AMM) +_ Offerpool -- a bulletin board for sharing offers +_ Spacescan -- an explorer and bulletin board \* Finally, you can save the file to your local computer and share it however you want

+ +
+ distribute offer +

+ +4. The Offer will now appear as `Pending Accept`, and the amount of time (if any) until it expires will also be shown: + +
+ offer pending status +

+ +Congratulations! You have created an Offer. A few things to note: + +- Your wallet has reserved the coin(s) necessary to complete the Offer. +- The blockchain has not recorded this Offer. +- You can distribute the Offer file wherever you want. +- Anyone who sees the Offer file can attempt to accept it. + +--- + +### Accept an offer + +This example will use a different computer to accept the Offer that was created in the previous example. Keep in mind, offers are accepted on a first-come, first-served basis. + +1. Prior to accepting the Offer, this wallet has 1,000,000 CATs: + +
+ One Meeellion CATs +

+ +2. Click `Offers`, then view the Offer by either loading, dragging/dropping, or pasting the file: + +
+ view offer +

+ +3. In this case, the Offer will expire in 6 days. The Taker must give 1000 CATs in exchange for 1 TXCH. The Maker has included a blockchain fee, and the Taker has the option of adding to this fee if desired. If the terms are acceptable, click `ACCEPT OFFER`: + +
+ accept offer +

+ +4. You will need to confirm that you actually want to accept the Offer, which will initiate an on-chain transaction: + +
+ verify acceptance of offer +

+ +5. The Offer has been accepted. Click `OK`: + +
+ offer accepted +

+ +6. While the blockchain transaction is pending, you will see this status in the `Offers you accepted` panel: + +
+ offer pending confirm +

+ +7. Meanwhile, the `Tokens` screen will show the pending XCH and CAT amounts: + +
+ 1 XCH incoming +

+ +
+ 1000 CATs outgoing +

+ +8. After the transaction has been confirmed (typically 1-3 minutes), the Offer's status will be updated to `Confirmed`: + +
+ plus 1 XCH +

+ +9. The final XCH and CAT balances will then be reflected in the `Tokens` screen: + +
+ minus 1000 CATs +

+ +
+ offer pending status +

+ +--- + +### Cancel an offer + +You can cancel any Offer you created, as long as it has not already been accepted. + +1. In the "Offers" dialog, locate the Offer you want to cancel. It must be in the "Pending Accept" state. + +Click the three dots in the "Actions" column: + +
+ Pending Accept +

+ +2. Click "Cancel Offer". + +
+ Cancel Offer +

+ +3. The "Cancel Offer" dialog will appear. The default option is to cancel on the blockchain, as shown in the red circle in the image below. + +This option will use your wallet to spend the coin(s) you had offered, and create new coins of the same type and value. This process does not involve taking the other end of the Offer, so you will not receive any funds of the type you had requested. The end result is that your wallet's balance will be the same as it was before you made the Offer (minus any transaction fees). + +The advantage of canceling in this manner is that it ensures that nobody can accept your Offer in the future. The disadvantages are that you will need to wait a few minutes for your transaction to be processed, and that you may have to pay a transaction fee. + +
+ Cancel on blockchain +

+ +4. If you uncheck the checkbox, your wallet will un-reserve the coins for your Offer. However, nothing will be recorded on the blockchain. If you have copied your Offer file elsewhere, someone could still accept it. + +The advantages of this option are that it will cancel your Offer instantly, and there's no need to include a fee. + +
+ Cancel off chain +

+ +5. If you left the checkbox checked in the previous step, your Offer will enter the "Pending Cancel" state while the cancellation is being recorded on the blockchain. This could take several minutes. + +
+ Pending Cancel +

+ +6. When your order has been successfully canceled, it will enter the "Cancelled" state. Your funds are now available in your wallet. + +
+ Cancelled +

+ +--- + +### NFT Offers + +You can also create Offers to buy or sell NFTs. While it is possible to select NFTs from the `Offers` dialog, this example will demonstrate how to do so directly from the `NFTs` dialog. + +1. Enter the `NFTs` dialog and select the NFT(s) to offer. If you would like to offer more than one NFT, click the checkbox (as shown below) to enter multi-select mode. To offer all of your NFTs, click `SELECT ALL`: + +
+ Cancelled +

+ +2. In this case, both of the NFTs are selected. Next, click `ACTIONS` and `Create Offer`: + +
+ Cancelled +

+ +3. The `Offer Maker` dialog will appear. Fill in any additional details for your Offer (be sure to request something!), and click `CREATE OFFER`: + +
+ Cancelled +

+ +3. Share the Offer as you would with a CAT Offer. After the Offer has been created, the NFTs being offered will appear in the Offer summary: + +
+ Cancelled +

+ +--- + +### NFT Swaps + +You can also swap NFTs for other NFTs, just like trading cards. + +1. From the `Offers` dialog, select the NFT(s) you would like to offer and request. You can mix and match the Offer with a combination of XCH, CATs, and NFTs: + +
+ Multi NFT swap +

+ +2. When you are satisfied with terms of the Offer, click `CREATE OFFER`: + +
+ Cancelled +

+ +3. After the Offer has been created, the assets to be trade will be displayed in the summary, just as with other Offers: + +
+ Cancelled +

+ +--- + +### Offer notifications + +It is also possible to send a peer-to-peer notification to the owner of an NFT you would like to buy. You don't even need to know who owns the NFT; the notification will figure it out for you. + +This example will continue with the same NFT-NFT Offer from the last section. + +1. After creating an Offer to acquire an NFT, share it to Dexie, Mint Garden, etc: + +
+ Share on Dexie +

+ +2. Be sure to verify that the Offer is correct; after it is shared publicly, someone could accept it: + +
+ Share Offer +

+ +3. Click `NOTIFY CURRENT OWNER`: + +
+ Notify current owner +

+ +4. You have the option to add a transaction fee for the notification. You can also choose whether to allow counter offers: + +
+ Send message +

+ +5. A new offer coin will be created. If the owner of the NFT you would like to acquire is using the reference wallet, the wallet will notice this new coin and examine its contents. A new notification will appear in the owner's wallet. Click the notification bell: + +
+ Incoming notification +

+ +6. A summary of the Offer will appear. Click the summary to see the details of the Offer: + +
+ View Offer +

+ +--- + +### Default expiration time + +By default, all Offers will expire seven days after being created. However, you can modify the expiration time on individual Offers, and you can also modify the default expiration time. From the `GENERAL` tab in the `Settings` menu, scroll down to `Offer Expiration Time`. From here, you can modify the default, or even disable expiring Offers altogether: + +
+ Change default from general settings +

+ +You can also access this setting from the `Offer Builder` menu by clicking `Change default timing`: + +
+ Access default settings from Offer creation +

+ +--- + +### Potential issues + +This section will detail a non-comprehensive list of issues you might encounter while making or taking offers. + +#### Contents: + +- [Maker doesn't have enough money](#maker-doesnt-have-enough-money) +- [Taker doesn't have enough money](#taker-doesnt-have-enough-money) +- [Taker accepts an unknown CAT offer](#taker-accepts-an-unknown-cat-offer) +- [Taker attempts to accept an invalid offer](#taker-attempts-to-accept-an-invalid-offer) +- [Maker cancels an Offer locally, Taker accepts the offer](#maker-cancels-an-offer-locally-taker-accepts-the-offer) +- [Whole coins must be reserved](#whole-coins-must-be-reserved) +- [Offer involving a CAT1 is invalid](#offer-involving-a-cat1-is-invalid) + +--- + +#### Maker doesn't have enough money + +Let's say a Maker has wallets for XCH and CKC, with no money in either of them. + +
+0 XCH wallet +
+
+0 CKC wallet +

+ +The maker attempts to make an ambitious offer: 100 XCH for 1 million CKC. + +
+Offer 100 XCH for 1 million CKC +

+ +However, the Maker does not have enough money to create this Offer. As a result, an Error is displayed: + +
+Amount exceeds spendable balance +
+ +--- + +#### Taker doesn't have enough money + +Let's say the Taker has a wallet with no money in it: + +
+0 XCH wallet +

+ +And there's an outstanding Offer requesting 0.1 XCH for 10,000 CKC: + +
+Accept offer +

+ +However, the Taker does not have enough money to accept this Offer. As a result, an Error is displayed: + +
+Insufficient funds +
+ +--- + +#### Taker accepts an unknown CAT offer + +You should be extra careful before accepting offers for unknown CATs. This is because the Offer _might_ be a scam where a different -- and worthless -- token is actually being offered. + +Here's how the scam would work: + +Let's say a potential Taker has 0.1 XCH in their wallet. + +
+0.1 XCH wallet +

+ +There is an Offer of 0.25 Shibe (an unknown CAT) in exchange for 0.1 XCH. + +Here's the Offer from the Taker's perspective: + +
+Offer shibe for XCH +

+ +The Taker decides to accept the Offer. + +There is a warning dialog about the unknown cat, after which the Offer is confirmed successfully: + +
+Unknown CAT warning +
+
+Unknown CAT success +

+ +Notice that the Offer file was named `0.25_Shibe_for_0.1_XCH.offer`, but the file name itself does _not_ dictate the contents of the Offer. The Taker may have inadvertently accepted an Offer for a worthless token! + +Luckily, it is easy to avoid this scam by cross-referencing the unknown CAT's ID before accepting the Offer. In this case, the Taker should verify from a trusted source that `4ac6a35e5fecb50d85604b19250a942afdc81876fe11db1f9d970c95dcf2c43f` indeed corresponds to Shibe. + +Chia does install a list of known CATs by default, so this scam should be rare, but you should always be diligent in scrutinizing offers for unknown CATs. + +--- + +#### Taker attempts to accept an invalid offer + +If the Maker has canceled the Offer on the blockchain, or a Taker has already taken the Offer, it is no longer valid. + +Any potential Takers will be conveyed this information upon viewing the Offer. For example: + +
+Invalid offer +
+ +--- + +#### Maker cancels an Offer locally, Taker accepts the offer + +This example will demonstrate that if you need to cancel an Offer, you should always do so on-chain unless you are certain the Offer file has not left your computer. + +Let's say a Maker has 0.1 XCH and 1 USDS: + +
+0.1 XCH in wallet +
+
+1 USDS in wallet +

+ +The Maker offers 0.1 XCH in exchange for 10 USDS: + +
+Offer 0.1 XCH for 10 USDS +

+ +The Maker then decides to cancel the Offer, and unchecks the "Cancel on blockchain" checkbox: + +
+Cancel offer off chain +

+ +The offer's state is immediately changed to "Cancelled". + +
+Canceled offer off chain +

+ +After the Offer has been canceled, a Taker notices the Offer file and decides to accept it: + +
+Accept a canceled offer +
+
+Confirm a canceled offer +

+ +Later, the Maker notices that the Offer has gone through, despite having been canceled: + +
+Post-offer 0 XCH +
+
+Post-offer 11 USDS +

+ +If the Offer had been canceled on-chain, the reserved coins would have been spent. At that point, even if someone else had gotten access to the Offer file, the Offer itself would've been invalid. + +The lesson here is do _not_ uncheck the "Cancel on blockchain" checkbox unless you're certain the Offer file has never left your computer. + +--- + +#### Whole coins must be reserved + +Under the coin set model, coins can be of any value. When an Offer is created, the Maker's wallet must reserve enough coins to meet the requirements of the Offer. + +The coin set model [has many advantages](/chia-blockchain/coin-set-model/intro) over the account model, but it can create some situations that take time to understand. + +For example, let's say a Maker has 1 XCH and 0 USDS: + +
+1 XCH in wallet +
+
+0 USDS in wallet +

+ +The Maker creates an Offer of 0.1 XCH for 10 USDS. + +The Maker received the XCH in one lump sum, so there is a single coin worth 1 XCH in the Maker's wallet. + +This is viewable in the offer's details: + +
+Offer in Pending Accept state +
+
+Show offer's details +
+
+One coin used for offer
+Scroll to the bottom to view coins reserved for the Offer. +
+

+ +While the Offer is pending, the Maker attempts to send 0.1 XCH to another address. + +Notice that while the Total Balance is 1, the Spendable Balance is 0. + +
+Can't send while Offer pending +

+ +This should be possible -- the Maker has 0.9 XCH, even after taking the Offer into account. The reason for the Exception is because the Maker only has a single coin worth 1 XCH, and that coin has already been reserved for the Offer. + +It's similar to using a $10 bill to buy something for $1. Before you receive your change, you can't buy anything else. On the other hand, if you had started with two $5 bills and bought the same $1 item, you could've purchased something else while waiting for your change. + +The Maker can work around this issue by canceling the Offer, then breaking the single large coin into multiple small ones. One simple way to do this would be to send money to him/herself: + +
+Maker sends money to him/herself +

+ +The Maker can then recreate the same Offer. The new offer's details show a coin worth 0.9 XCH being reserved: + +
+New details of Maker's offer +

+ +The Maker's wallet shows a Total Balance of 1 XCH. This is the same as before, but there are now two coins that sum to 1 XCH. + +Because there are now two coins in the Maker's wallet, and only one (worth 0.9 XCH) has been reserved for the Offer, the Spendable Balance is 0.1 XCH: + +
+Maker has 0.1 XCH available +

+ +The Maker can now send 0.1 XCH to another wallet, even while the Offer is still pending: + +
+Successful send while Offer pending +

+ +One of the Maker's coins has been reserved for the Offer, and the other has been sent to another wallet. The Maker can further break apart the large coin as needed. + +--- + +#### Offer involving a CAT1 is invalid + +The CAT1 Standard reached its end of life (EOL) with block 2,311,760 in July 2022. Any offers that include a CAT1 on either side of the trade will result in an invalid offer error. + +--- + +### Further reading + +- [Offers blog entry](https://www.chia.net/2022/01/12/chia-offers-are-here-en.html) +- [Offers reference](https://chialisp.com/offers) +- [CLI tutorial](/guides/offers-cli-tutorial) +- [Info on the coin set model](/chia-blockchain/coin-set-model/intro) diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/headless-node.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/headless-node.md new file mode 100644 index 00000000000..254b71ba0d4 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/headless-node.md @@ -0,0 +1,93 @@ +--- +title: Headless Node +slug: /reference-client/install-and-setup/headless-node +--- + +Exposing a Chia daemon to the network is an advanced configuration. This allows other computers to communicate with the Chia daemon, including the ability to create transactions and send XCH. + +**If you do not know how to configure and properly secure a computer network _do not_ use a remote daemon.** + +_Never_ expose the Chia daemon to the internet. + +# Setup + +The following instructions are for a Linux-based farmer (daemon host) and Windows GUI (main node). The same concept applies to other OS combinations. + +## On the daemon host + +### Expose the daemon to the network + +In `config.yaml`, change `self_hostname` from `localhost` to `0.0.0.0`. This binds the daemon to all IPv4 addresses on the local machine. + +Next, open the port that the daemon is listening on (55400 by default). The UI assumes that the daemon is already running and it will _not_ attempt to start a remote daemon. Using [ufw](https://help.ubuntu.com/community/UFW) and restricting traffic to just the UI's host: + +```bash +sudo ufw allow from to any port 55400 proto tcp +``` + +### Copy the daemon's cert files + +To secure their connection, the GUI will need the daemon's certificates. Copy these files to the Windows machine: + +```bash +~/.chia/mainnet/config/ssl/daemon/private_daemon.crt +~/.chia/mainnet/config/ssl/daemon/private_daemon.key +``` + +## On the GUI host + +### Reference the daemon's cert files + +Place the daemon's cert files, copied earlier, in the following location: + +```bash +~/.chia/mainnet/config/ssl/ui/ +~/.chia/mainnet/config/ssl/ui/ +``` + +Find the `ui` section in `config.yaml` and specify the following settings: + +```yaml +daemon_host: +daemon_port: 55400 +daemon_ssl: + private_crt: config/ssl/ui/private_daemon.crt + private_key: config/ssl/ui/private_daemon.key +``` + +# Troubleshooting + +## GUI Client + +### Can the GUI find the config folder? + +The first thing to check is that the daemon's websocket URI shows up on the title bar. It should look like this: + +![image](https://user-images.githubusercontent.com/5160233/111890456-6ca97f00-89b7-11eb-8f20-a8dc80d0d138.png) + +Make sure there isn't a [syntax error](https://yamlchecker.com/) in config.yaml. + +### Can the GUI find the remote daemon's certs? + +Double check that in the `ui` section the crt and key paths are correct. It _shouldn't_ point to the folder where the local certs are stored. It has to point to the folder where you copied the daemon's certs. + +## Connectivity + +### Has the daemon been bound to a routable IP address? + +On the daemon host run `sudo netstat -tulpn | grep 55400` or your OS's equivalent. It should show something similar to `tcp 0 0 0.0.0.0:55400 0.0.0.0:* LISTEN 2925/chia_daemon`. + +If you see `127.0.0.1` it means you haven't changed the daemon's bind IP address. The loopback address is not routable on the network. Double check that `self_hostname: 0.0.0.0` is correct in the config. Also, make sure you have fully restarted the daemon: + +```bash +chia stop all -d +chia start farmer +``` + +### Is the daemon's port opened on the firewall? + +Run `sudo ufw status | grep 55400` or your OS and firewall equivalent. You should see something like `55400/tcp ALLOW`. + +### Is VMWare Plugin Service bound to daemon port? + +Verify that the default port 55400 is not bound to VMWare Plugin or other service on the daemon host. If pre-bound, stop that other service or change the `daemon_port` value in `config.yaml`. `netstat -tulpn` includes the process name of listeners. It should be `chia_daemon`. 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 new file mode 100644 index 00000000000..29d965f1045 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/installation.md @@ -0,0 +1,1146 @@ +--- +title: Advanced Installation +slug: /reference-client/install-and-setup/installation +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::info + +This page will go into the details of the various different ways to install Chia. If you already installed Chia as part of the Farming Guide, then feel free to skip ahead to the [Plotting Basics](/reference-client/plotting/plotting-basics) page. + +::: + +There are various ways to install Chia, with the best method depending on what you intend to do: + +- If you simply wish to use the Chia wallet, or to run a farm on a single personal computer, then we recommend installing the GUI from our [official downloads page](https://www.chia.net/downloads) for Windows and MacOS, and for Linux users to install the package [as described below](#using-the-cli). The GUI is the simplest way to interact with the Chia client and ideal for most non-developer use cases. + +- If you intend to run a dedicated Chia full node on a server and connect to it programmatically using the [RPC interface](/reference-client/rpc-reference/rpc), the best method would be to install and run Chia via the command line on a proper server environment. + +- 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](/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._** + +## System Requirements + +The minimum supported specs are that of the Raspberry Pi 4, 4GB model: + +- Quad core 1.5Ghz CPU (must be 64 bit) +- 4 GB RAM +- As of Chia version 2.5, Python versions 3.9 and later are supported + +### Drive Format + +Chia plot files are at least 108GB in size (for K32). To plot successfully requires drives formatted to support large files. Formats that will work include NTFS, APFS, exFAT, and ext4. Do not use drives with FAT formatting (for example FAT12, FAT16, and FAT32), or else plotting will fail. Future versions of Chia will check for unsupported drives, but for now it's up to each user to check their drive format. + +### Sleep kills plots + +If the computer or hard drives go to sleep during the plotting process, it will fail, and you will need to start over. Please ensure all sleep, hibernate and power saving modes for your computer and hard drives are disabled before starting the Chia plotting process. In the future, Chia will have a resume plot feature. In the meantime, if you do get a failed plot, delete all \*.tmp files before starting a new plot. Please ensure all sleep, hibernate and power saving modes for your computer and hard drives are disabled before starting the Chia plotting process. In the future, Chia will have a resume plot feature. In the meantime, if you do get a failed plot, delete all `*.tmp` files before starting a new plot. + +--- + +## Install + +### Using the CLI + +_This method is intended for linux environments_ + + + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repository +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chia.list > /dev/null +sudo apt-get update + +# Install chia-blockchain +sudo apt-get install chia-blockchain + +# Use chia-blockchain-cli instead for CLI only +``` + + + + +```bash +# Install packages +sudo yum install -y yum-utils +sudo yum-config-manager --add-repo https://repo.chia.net/rhel/chia-blockchain.repo + +# Install chia-blockchain +sudo yum install chia-blockchain + +# Use chia-blockchain-cli for CLI only +``` + + + + +```bash +# Install packages +sudo dnf install 'dnf-command(config-manager)' +sudo dnf config-manager --add-repo https://repo.chia.net/rhel/chia-blockchain.repo + +# Install chia-blockchain +sudo dnf install chia-blockchain + +# Use chia-blockchain-cli for CLI only +``` + + + + +```bash +# Create virtual environment +python -m venv venv + +# Activate virtual environment +. ./venv/bin/activate # MacOS / Linux +./venv/Scripts/Activate.ps1 # Windows + +# Update pip +pip install --upgrade pip + +# Install chia-blockchain +pip install --extra-index-url https://pypi.chia.net/simple chia-blockchain miniupnpc +``` + +Chia strives to provide [binary wheels](https://pythonwheels.com) for modern systems. If your system does not have binary wheels, you may need to install development tools to build some Python extensions from source. If you're attempting to install from source, setting the environment variable `BUILD_VDF_CLIENT` to `N` will skip trying to build Timelord components that aren't very cross platform, e.g. `export BUILD_VDF_CLIENT=N`. + + + + +### From Source + +_This method is primarily intended for contributing to the Chia codebase_ + + +```bash +# Download chia-blockchain +git clone https://github.com/Chia-Network/chia-blockchain -b latest --recurse-submodules + +# Change directory +cd chia-blockchain + +# Install dependencies +sh install.sh + +# Activate virtual environment +. ./activate + +# Initialize +chia init +``` + +The following is how you update to the latest version: + +```bash +# Change directory +cd chia-blockchain + +# Activate the virtual environment +. ./activate + +# Stop running services +chia stop -d all + +# Deactivate the virtual environment +deactivate + +# Remove the current virtual environments +rm -r venv +rm -r .penv +rm -r .venv + +# Pull the latest version +git fetch +git checkout latest +git reset --hard FETCH_HEAD --recurse-submodules + +# If you get RELEASE.dev0 then delete the package-lock.json in chia-blockchain-gui and install.sh again + +# This should say "nothing to commit, working tree clean" +# if you have uncommitted changes, RELEASE.dev0 will be reported +git status + +# Install the new version +sh install.sh + +# Activate the virtual environment +. ./activate + +# Initialize the new version +chia init +``` + + + + +```bash +# Download chia-blockchain +git clone https://github.com/Chia-Network/chia-blockchain -b latest --recurse-submodules + +# Change directory +cd chia-blockchain + +# Install dependencies +./Install.ps1 + +# Activate virtual environment +. ./venv/Scripts/Activate.ps1 + +# Initialize +chia init +``` + +The following is how you update to the latest version: + +```bash +# Change directory +cd chia-blockchain + +# Activate the virtual environment +. ./venv/Scripts/Activate.ps1 + +# Stop running services +chia stop -d all + +# Deactivate the virtual environment +deactivate + +# Remove the current virtual environment +rm -r venv +rm -r .penv +rm -r .venv + +# Pull the latest version +git fetch +git checkout latest +git reset --hard FETCH_HEAD --recurse-submodules + +# If you get RELEASE.dev0 then delete the package-lock.json in chia-blockchain-gui and install.sh again + +# This should say "nothing to commit, working tree clean" +# if you have uncommitted changes, RELEASE.dev0 will be reported +git status + +# Install the new version +./Install.ps1 + +# Activate the virtual environment +. ./venv/Scripts/Activate.ps1 + +# Initialize the new version +chia init +``` + + + + +### Raspberry Pi 4 {#raspberry-pi} + +:::note +Chia does not support the Raspberry Pi 3, and we do not recommend running the GUI on the 4GB Raspberry Pi 4 model. + +It is highly recommended you put the Chia blockchain and wallet database on an SSD or NVMe drive, rather than the SD card. +::: + +#### Swap {#raspberry-pi-swap} + +It is suggested that you set up 1024 MiB of swap: + + + +Run the following commands to set up the swap: + +```bash +sudo dd if=/dev/zero of=/swap bs=1M count=1024 +sudo chmod 600 /swap +sudo mkswap /swap +sudo swapon /swap +``` + +Add this line to `/etc/fstab` so that swap available on reboot: + +```bash +/swap swap swap defaults 0 0 +``` + + + + +Here is an excellent [walk-through of increasing swap space](https://pimylifeup.com/raspberry-pi-swap-file/) on Raspbian 64. + + + + +#### Setup {#raspberry-pi-setup} + +Run the following commands to prepare for installation: + +```bash +# Requirements to compile the blockchain +sudo apt-get install -y build-essential python3-dev + +# If you are not using Raspbian 64, add this +export PIP_EXTRA_INDEX_URL=https://www.piwheels.org/simple/ + +# Make sure you have 64-bit Python 3.9 or later +python3 -c 'import platform; print(platform.architecture())' +``` + +#### Proceed {#raspberry-pi-install} + +:::note +If you run into an error during the build process, make sure you are running a 64-bit version of the OS. + +You can check by running `uname -a`. If it says `arm7l`, you need a 64-bit version of the OS. The `uname -a` output should end with `aarch64 GNU/Linux`. +::: + +Finally, follow the typical [from source installation for Linux](#from-source) to continue. + +#### Disable Timelord {#raspberry-pi-timelord} + +This is not necessary when installing from source. + +However, if you install Chia in some other way, disable the timelord build process: + +```bash +export BUILD_VDF_CLIENT=N +``` + +### Other environments + + + + +Installation instructions for docker are found on the container repo: +[Docker](https://github.com/orgs/Chia-Network/packages/container/package/chia) + + + + +You can run chia-blockchain in Ubuntu 20.04 LTS via WSL2 on Windows. + +NOTE: WSL2 plotting is currently only _slightly_ faster than plotting on the native windows client. WSL2 requires significant tweaking to set up correctly. If you find that daunting, it's probably easier to just use the native windows client. + +**You can not run the GUI** as WSL2 doesn't yet support graphical interfaces from WSL2. + +#### Check if you already have WSL2 or WSL1 installed: + +From PowerShell, type: + +``` +wsl -l -v +``` + +If you get a listing of help topics for wsl commands, you have WSL1, and need to upgrade. To upgrade, [follow the instructions here](https://docs.microsoft.com/en-us/windows/wsl/install-win10#update-to-wsl-2). If you get a blank result or a listing of installed Linux versions, you have WSL2 and are OK to proceed. + +#### If WSL is not installed: + +From an Administrator PowerShell: + +``` +dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart +dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all +``` + +You will be prompted to reboot. + +#### Installing a new WSL2 instance: + +Install Ubuntu 20.04 LTS from the Microsoft Store and run it and complete its initial install steps. You now have a linux bash shell environment that can run linux native software on Windows. + +#### Install from source - WSL2 + +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. + +#### Increasing the WSL Maximum Storage Capacity + +WSL2 uses a Virtual Hardware Disk (VHD) to store files, and it automatically resizes as files grow. **However, the VHD has an initial maximum size of 256 GB.** Therefore, the default WSL2 VHD is probably only capable of plotting k=30 plots. To plot anything larger, you will need to increase the maximum allowable size. [Follow the guide here.](https://docs.microsoft.com/en-us/windows/wsl/compare-versions#expanding-the-size-of-your-wsl-2-virtual-hardware-disk) + +#### Setting a maximum limit to WSL2 memory access + +If you try plotting Chia in WSL2 without limiting the memory access, WSL2 will use 100% of your available machine's memory, and your computer will get bogged down and begin swapping memory to your hard drive. This will severely cripple your plotting speeds. To set the maximum memory that WSL2 is allowed to use, create a configuration file [as described in this guide](https://www.bleepingcomputer.com/news/microsoft/windows-10-wsl2-now-allows-you-to-configure-global-options/). + +#### WSL VHD Plotting Nuances + +Plotting within WSL2 can write to either the native VHD (which is EXT4) or to any other drive, which can be NTFS or any other FS-type. Writing to the native VHD is faster than writing out to another drive. + +Plotting uses three commands for directory control: + +`-t` for initial temp directory. Phases 1 and 2 happen here. + +`-2` for secondary temp directory. Phase 3 (compression) happens here. + +`-d` for final destination. Phase 4 happens here. + +Plotting works such that `-t` and `-2` require the exact same amount of storage space. Therefore, if `-t` and `-2` point to the same drive, that drive needs 2x the final file size + 1x the max working file size. + +For maximum speed, `-t` and `-2` should be inside the WSL2 filesystem. Something like: `-t ~/chia_temp -2 ~/chia_temp`. Just beware that the WSL2 VHD will need a much larger maximum capacity. + +`-d` can point to any other drive for the final destination. + + + + +#### Install from source - Amazon Linux 2 + +See [install from source](/docs/reference-client/install-and-setup/installation.md#from-source) for detailed instruction. + +#### Install from binary package + +```bash +# Install chia-blockchain as a binary package +python -m venv venv +ln -s venv/bin/activate +. ./activate +pip install --upgrade pip + +pip install --extra-index-url https://pypi.chia.net/simple chia-blockchain miniupnpc +``` + + + + +_**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 + +_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._ + +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. + +``` +# Update your packages and ports; if ports are already installed as part of your fresh install run portsnap update instead of fetch/extract. +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 + +``` + +#### gcc notes + +After installing gcc version 9.0, this message appears: + +``` +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 +pkg install screen tmux +``` + +#### Repo Cloning and Virtual Environment (venv) Activation + +**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 latest chia-blockchain repository, via HTTP: +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" +``` + +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. + +On line 25 of chia/util/keychain.py, change: + +``` +elif platform=="linux": +``` + +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. + +``` +keyring.keyring_key = "your keyring password" # type: ignore +``` + +can be changed like so: + +``` +keyring.keyring_key = "Too Many Secrets" +``` + +Now, you will build Chia! + +``` +sh install.sh +``` + +Once done, run: + +``` +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. + +``` +sed -i .bak 's/enable_upnp: True/enable_upnp: False' ~/.chia/mainnet/config/config.yaml +``` + +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/). + +--- + +#### Installed and Ready to Farm! + +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). + + + + +_**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 + +# DONE, Chia is installed now, start using it by creating a config and keys + +chia init +chia keys generate + +# if you are going to setup port forwarding, disable upnp +chia configure --enable-upnp false + +chia start node wallet farmer harvester +``` + +#### GUI Build / Usage + +_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 + +As root (or using doas / sudo), first install some additional OpenBSD packages required for GUI usage: + +```bash +pkg_add -i electron +``` + +#### Build + +```bash +cd chia-blockchain +. ./activate + +cd chia-blockchain-gui + +# build / set up GUI +npm run build + +# 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. + +rm -rf node_modules/electron +``` + +#### Launch GUI + +The GUI can now be launched using the following commands: + +```bash +cd chia-blockchain +. ./activate + +cd chia-blockchain-gui +npm run electron +``` + + + + +--- + +## Directory Structure + +``` +.chia/ +└── mainnet/ + ├─ config/ + │ ├─ config.yaml + │ └─ ssl/ + ├─ db/ + ├─ log/ + │ └─ debug.log + ├─ run/ + └─ wallet/ +``` + +All data used by the Chia blockchain is stored at the location set with the `CHIA_ROOT` environment variable, which defaults to `~/.chia/mainnet` (the hidden folder `.chia` inside of your home directory) if unset. + +The blockchain database is stored under the `db` subdirectory. It is possible to copy the database file to use as a backup or put on another machine. To resync the full node from the start, delete the database file and restart the node. + +The config file under the `config` subdirectory. Its name is `config.yaml`, and it can be used to find the root cause of problems. + +It is possible to configure the `CHIA_ROOT` environment variable to another location. A common use for this would be to switch it to `~/.chia/testnet` to have a separate config for the testnet. + +--- + +## CLI + +Using the CLI gives greater and more precise control over the various Chia services such as the full node. As of 1.8.2, when installing from an installer or package CLI commands will be automatically added to your path for Windows and Linux. For more details on the commands, read the [CLI Reference](/reference-client/rpc-reference/rpc). + + + + +The CLI commands are stored in the following location: + +```bash +/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon +``` + +To be able to use these commands without going to that directory in the terminal, add it to the path. + +This can be done by running the following command: + +```bash +export PATH=/Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon:$PATH +``` + +To load this on startup, add it to the `.bashrc`, `.bash_profile`, or `.zshrc` file depending on which is used by the shell. + + + + +The CLI commands are stored in the following location: +If installed for the user it can be found at + +```bash +~\AppData\Local\Programs\Chia\resources\app.asar.unpacked\daemon +``` + +If installed for all users it can be found at + +```bash +C:\Program Files\Chia\resources\app.asar.unpacked\daemon\chia.exe +``` + + + + +The CLI commands are stored in the following location: + + ``` + /usr/bin/chia + ``` + +This location should already be included in your system's PATH, so you should be able to run `chia` directly from the command line without any further setup. + + + + +## GUI + +The GUI is the most user-friendly method of interacting with Chia for non-developer uses, and it can be installed manually from the CLI if you installed from source. + + + + +```bash +# Install the GUI +. ./install-gui.sh + +# Start the GUI +sh start-gui.sh +``` + +The following is how you update to the latest version: + +```bash +# Change directory into the GUI +cd chia-blockchain-gui + +# Pull the latest version +git fetch + +# Change directory +cd .. + +# Change permissions on install script +chmod +x ./install-gui.sh + +# Install the new version of the GUI +./install-gui.sh + +# Start the GUI +bash start-gui.sh +``` + + + + +```bash +# Install the GUI +. .\Install-gui.ps1 + +# Change directory +cd chia-blockchain-gui + +# Start the GUI +Start-Process -NoNewWindow npm run electron +``` + +The following is how you update to the latest version: + +```bash +# Change directory +cd chia-blockchain-gui + +# Pull the latest version +git fetch + +# Change directory +cd .. + +# Install the new version of the GUI +./Install-gui.ps1 + +# Change directory +cd chia-blockchain-gui + +# Start the GUI +Start-Process -NoNewWindow npm run electron +``` + + + + +## Initial Startup + +Upon launch the GUI will set everything up automatically, however if installing from source then the initial setup needs to be done manually via the CLI. + +First, initialize the Chia configuration files: + +```bash +chia init +``` + +Then, generate your keys: + +```bash +chia keys generate +``` + +Finally, start the farmer and its full node: + +```bash +chia start farmer +``` + +### Systemd + +Linux users who have installed the `chia-blockchain-cli` package using [apt, yum, or dnf](https://docs.chia.net/reference-client/install-and-setup/installation/#using-the-cli) will receive systemd configuration files for initializing and managing the Chia processes. Each Chia service needs to be managed separately with systemd, except for the chia-daemon, which will be initialized automatically when any other Chia service is started with systemd (for example, the data-layer service will not automatically start the wallet service - both need to be started individually with systemd). A user must be specified during the initialization to ensure the resulting process can find the Chia root directory. The included systemd files support the default Chia directory location of `/home//.chia/mainnet` only. + +To start a Chia process with systemd, the command format is `systemctl start chia-@`. For example, if starting a Chia full node for the Linux user `ubuntu`, the command would be: + +``` +systemctl start chia-full-node@ubuntu +``` + +To start the full-node at system boot: + +``` +systemctl enable chia-full-node@ubuntu +``` + +The services available to be managed with systemd are: + +``` +chia-crawler +chia-data-layer +chia-data-layer-http +chia-farmer +chia-full-node +chia-harvester +chia-introducer +chia-seeder +chia-timelord +chia-wallet +``` + +Note that the `chia-timelord` service runs the timelord coordinator service, but not the VDF clients. + +## Troubleshooting + +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.\ +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. + +## Testnets + +To join a testnet, follow the instructions on [How to Join the Official Testnet](/reference-client/install-and-setup/testnets#join-the-official-testnet). + +It is recommended that you keep a separate testnet environment by prepending `CHIA_ROOT="~/.chia/testnetx"` to all of your cli commands. For example, `CHIA_ROOT="~/.chia/testnet11" chia init`. An easier way to do this is to run `export CHIA_ROOT="~/.chia/testnet11"` so that all commands will use testnet11 instead of mainnet. You can update all config values to the testnet values by running `chia configure -t true`. + +## Beta and release candidate installations + +### From Source + +_This method is primarily intended for contributing to the Chia codebase_ + + +```bash +# Download chia-blockchain +git clone https://github.com/Chia-Network/chia-blockchain -b latest --recurse-submodules + +# Change directory +cd chia-blockchain + +# Checkout the beta or release candidate by tag, tags can be found https://github.com/Chia-Network/chia-blockchain/tags. +git checkout tags/2.1.2-rc2 + +# Install dependencies +sh install.sh + +# Activate virtual environment +. ./activate + +# Initialize +chia init +``` + + + + +```bash +# Download chia-blockchain +git clone https://github.com/Chia-Network/chia-blockchain -b latest --recurse-submodules + +# Change directory +cd chia-blockchain + +# Checkout the beta or release candidate by tag, tags can be found https://github.com/Chia-Network/chia-blockchain/tags. +git checkout tags/2.1.2-rc2 + +# Install dependencies +./Install.ps1 + +# Activate virtual environment +. ./venv/Scripts/Activate.ps1 + +# Initialize +chia init +``` + + + + +### From packaged installer + + + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repository +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/prerelease/debian/ prerelease main" | sudo tee /etc/apt/sources.list.d/chia-blockchain-prerelease.list > /dev/null +sudo apt-get update + +# Install chia-blockchain +sudo apt-get install chia-blockchain + +# Use chia-blockchain-cli instead for CLI only +``` + + + + +```bash +# Navigate to downloads page +Open https://github.com/Chia-Network/chia-blockchain/releases in a web browser + +# Download the correct asset +Navigate to the release candidate of interest and download the necessary installer for your OS (ex. exe for windows) + +# Install the downloaded installer +Using your system finder/file explorer install the downloaded installer (note - make sure no other versions of chia are installed prior to this step) +``` + + + diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/key-management.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/key-management.md new file mode 100644 index 00000000000..d6823cf0756 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/key-management.md @@ -0,0 +1,49 @@ +--- +title: Key Management +slug: /reference-client/install-and-setup/key-management +--- + +The purpose of this page is to provide guidance on how to setup Chia keys for plotting, farming, receiving rewards and managing your wallet. +It does not explain the Chia Keys Architecture. You can find this [Chia Keys Architecture](/chia-blockchain/keys/architecture) explanation. +It is mostly CLI focused; sorry GUI users. + +## 1 key (default) + +This solution is the most straightforward, you use only one key for everything: plotting, farming, receiving rewards, managing your wallet. +It is the default configuration when you install chia-network for the first time. +The CLI (or GUI) creates a new private master key on the first initialization. Show can see it's mnemonic by typing `chia keys show`. + +By default, the rewards from farming will be sent to this private key's wallet address. + +With this setup you can farm, plot and manage your XCH all at once. +The risk is that, if your computer is compromised, the attacker would have access to your wallet and could potentially steal the XCH. + +Another solution for farming XCH and securing them is to use two keys: + +## 2 Keys (farming key + cold storage key) + +1. Default key used for: plotting and farming +2. Cold storage key used for: Wallet operations. Receiving/Sending funds and receiving farming rewards. + +The downside of that solution is that you will not have direct access to your wallet and XCH. Would you want to do an XCH operation you will have to manually import the cold storage key. The upside is: even if your computer is compromised the attacker will not be able to access your wallet. Since the private key receiving rewards will not be stored on it. + +Configuration steps: + +- Create a second key for "wallet" operation purposes: `chia keys generate` +- Write down the mnemonic on a paper you will not lose. If you lose it your key and XCH will be lost for ever ! +- Remember the fingerprint for the next step +- Find the "First wallet address": `chia keys show` and copy it +- Open `~/.chia/mainnet/config/config.yaml` +- Edit: `xch_target_address: XXX` replace it with the newly generated "First wallet address". + - There should be two occurrence of `xch_target_address`. One under the `farmer` section and the other one under the `pool` section. +- Save the file and close it. +- Delete the second key: `chia keys delete -f ` + - /!\ **Caution**: make sure you have a backup of the 24 words mnemonic or you will lose access to the key for ever. +- It should prompt a WARNING message like "Deleting private_key with fingerprint ``" + :::warning + Using a farmer address which we don't have the private keys for. We searched the first 500 addresses. Consider overriding `` with `` + ::: +- Make sure the `` corresponds to your second key wallet address. + +Your setup is complete. Your machine can farm XCH and rewards will be sent to the key that you stored on paper. +Would you need to transfer funds you can add it back to your computer's Chia keychain by doing: `chia keys add` diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/password-protected-keys.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/password-protected-keys.md new file mode 100644 index 00000000000..be7a58e36bc --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/password-protected-keys.md @@ -0,0 +1,124 @@ +--- +title: Password Protected Keys +slug: /reference-client/install-and-setup/password-protected-keys +--- + +## Overview + +We are introducing a new feature that allows users to specify a passphrase to protect their Chia keys across all currently supported platforms. Along with passphrase protection, this feature also introduces a new keyring file for storing those keys. By implementing a common key storage format, moving Chia keys between installations is greatly simplified, eliminating the need to re-enter each key's 24-word mnemonic. Any keys stored in the new keyring will be encrypted using a key derived from the specified passphrase. + +:::warning +Your passphrase protects only from local access of your Chia client. **You must still protect your 24 words.** + +Chia is unable to assist with the recovery of a forgotten passphrase. Be sure to **backup the 24-word mnemonic** for each of your keys. If you forget your passphrase, you will be able to recover by importing your keys from their 24-word mnemonic. +::: + +## Motivation + +Chia's supported platforms each provide different solutions for storing sensitive data, with varying levels of security and different user experiences per platform. In addition, these platform dependent solutions for storing sensitive data did not provide a mechanism for the user to passphrase-protect Chia keys outside of whatever protection the OS already provided. + +On Linux, the cryptfile keyring Python module has been used with a fixed key. + +On macOS, the Keychain is used to securely store each key, sometimes requiring one or more system prompts to authorize access to the key material. + +This resulted in a system where keys were considered to be secure on systems, but that level of security was subjective to individual use cases and OS configuration, and not suitable for everyone's needs. Our primary goals with this passphrase feature have been to grant more control to our users, uniformly secure Chia keys, and to simplify the task of moving keys from one installation to another. + +## New Keyring + +The new keyring file is a YAML document named `keyring.yaml`. Upon launch, Chia will automatically create an empty `keyring.yaml` file residing at: + +`%HOMEDRIVE%%HOMEPATH%/.chia_keys/keyring.yaml` (Windows) + +`~/.chia_keys/keyring.yaml` (macOS and Linux) + +Note that in this release, any new keys created or imported will be stored in the new `keyring.yaml` file and not in the previous location. + +Keys in this new keyring file are encrypted using ChaCha20-Poly1305 ([RFC 7539, Section 2.8](https://datatracker.ietf.org/doc/html/rfc7539.html#section-2.8)) which provides encryption and authentication (AEAD). The encryption key is derived from the user's passphrase using PBKDF2 with SHA-256 ([RFC 2898](https://datatracker.ietf.org/doc/html/rfc2898)). + +## Migration + +:::danger +We **STRONGLY** recommend that users create backups of their 24-word mnemonic before migrating their keys. +::: + +Existing users with keys will want to migrate their keys from the previous location to the new `keyring.yaml` file, and optionally protect those keys with a passphrase. We recommend all users create a strong passphrase. On macOS and Windows, users will have the option to save their passphrase to the macOS Keychain or Windows Credential Manager respectively, allowing for Chia to run unattended (such as after a reboot due to a power failure). + +When launching the Chia GUI application, a migration prompt will automatically appear if existing keys are detected. The GUI migration process is nearly instantaneous and will not delete or modify those keys that were found. It's strongly encouraged that users perform the migration step right away to move to the new keyring. If necessary, it's possible to skip the migration step and continue using Chia as before, however, any attempts to add or delete a key will first require completion of the migration process. + +From the command line interface, keyring migration can be initiated by setting a passphrase for the new keyring, or by adding or deleting a key. When performing keyring migration from the command line, the user will have the option of deleting those old keys that were found and successfully migrated. + +:::note +It is possible to migrate keys to the new key storage and not set a passphrase. In this case, the `keyring.yaml` file will remain encrypted with a fixed key. When you remove a passphrase, that passphrase will also be removed from the macOS Keychain or Windows Credential Manager (if saved there by the user). +::: + +## Command Line Reference + +### Setting/Updating/Removing Passphrases + +Setting or updating a passphrase for keyring.yaml. This will prompt for keyring migration as necessary: + +``` +chia passphrase set +``` + +When setting a passphrase, an optional hint may be specified. This hint will be displayed by the GUI when prompting for your keyring passphrase: + +``` +chia passphrase set --hint "Summer of 2020" +``` + +Removing a passphrase from `keyring.yaml`. Note, keyring.yaml always keeps keys stored in an encrypted form. Without a user-specified passphrase, a fixed encryption is used: + +``` +chia passphrase remove +``` + +### Passphrase Hints + +A passphrase hint can be set to assist in remembering the keyring passphrase. The hint data is stored in keyring.yaml as cleartext (not encrypted). + +Setting a passphrase hint when a passphrase is in use. This command will fail if a passphrase hasn't been previously set: + +``` +chia passphrase hint set "Summer of 2020" +``` + +Removing a passphrase hint. This command will fail if a passphrase and passphrase hint haven't been previously set: + +``` +chia passphrase hint delete +``` + +Displaying a passphrase hint. This command will fail if a passphrase and passphrase hint haven't been previously set: + +``` +chia passphrase hint display +``` + +### Reading Passphrases From a File + +Passphrases may be accessed from a file (or file descriptor on macOS/Linux) to assist with automated workflows. Note that whitespace is not stripped from the passphrase when read from a file. + +Reading the passphrase from a file: + +``` +chia --passphrase-file "~/.my_chia_passphrase" keys show +``` + +Reading the passphrase from another process (on macOS/Linux): + +``` +chia --passphrase-file <(echo -n 'my super secure passphrase') keys show +``` + +## Additional Notes + +On macOS and Windows, an option is available to save the passphrase to the OS-provided secure credential store (macOS Keychain or Windows Credential Manager). This option may help with automated workflows, but carries a risk that other processes may be able to read the saved passphrase without requiring user authorization. For this reason, it's recommended that users only save their passphrase if they fully trust their environment. + +To facilitate downgrading to a prior version of Chia, keys will be left intact in their old locations after migration (unless migrating from the command line, and the option to delete old keys was selected). + +If necessary, it's possible to temporarily disable passphrase support as well as usage of the new keyring. To disable passphrase and keyring support, set the `CHIA_PASSPHRASE_SUPPORT` environment variable to `false` and run Chia as you normally would. Once disabled, Chia will use the old location for key retrieval and storage. + +``` +export CHIA_PASSPHRASE_SUPPORT=false; chia start farmer +``` 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 new file mode 100644 index 00000000000..e5c18b66e8f --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/testnets.md @@ -0,0 +1,188 @@ +--- +title: Testnets +slug: /reference-client/install-and-setup/testnets +--- + +:::note + +Testnet 10 is the supported testnet. + +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](/installation) instructions.\ +If you want to run the Chia blockchain mainnet, use the [mainnet installation](/docs/reference-client/install-and-setup/installation.md) instructions. + +::: + +--- + +## Join the official testnet + +### 先决条件 + +- 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 + +```bash +# Initialize chia +chia init + +# Generate keys (if they have not already been generated) +chia keys generate + +# Configure Chia for the currently-active testnet +chia configure --testnet true +``` + +### (Opt) Download the official testnet db + +This step is optional, but it will speed up syncing with the testnet + +- Linux users: `wget https://databases.chia.net/file/chia-public-databases/blockchain_v2_testnet10.sqlite.gz` while in the directory (a v1 DB is also available, but no longer updated). +- Windows users: download it from [https://downloads.chia.net/testnet10/](https://downloads.chia.net/testnet10/) and move it to the db folder in the mainnet/ directory in the Chia root folder (i.e. \~/.chia/mainnet/db is the database directory). + +:::note + +_Make sure to unzip the database before continuing to the next step._ + +::: + +:::tip + +Prior to starting your node, it is recommended to delete `peers.dat`, located in `~/.chia/mainnet/db`. If you don't delete this file you might see `WARNING Invalid handshake with peer` in your log file. The reason for this is that peers.dat will contain mainnet peers, which are not running on the testnet. If you do see these warnings, there's no requirement to take further action -- they'll eventually stop appearing as your invalid peers are replaced with valid ones. + +::: + +### Start your node and connect to peers + +```bash +# 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` + +# Once the node is synced, you can check the wallet status +chia wallet show +``` + +### (Opt) Fund a testnet wallet + +```bash +# Get a testnet wallet address differentiated from mainnet wallet addresses by beginning with txch instead of xch +chia wallet get_address +``` + +Input your testnet wallet address into one of the faucets. If it says you are in the queue, it has worked. + +- Chia Official [testnet faucet](https://testnet10-faucet.chia.net/). +- Community developed and managed [testnet faucet](https://txchfaucet.com/). _Thank you to Steve Stepp for building and managing this faucet!_ + +**Funds will not appear in your wallet until you are fully synced to the blockchain.** + +--- + +## Dual farming mainnet and testnet + +_These instructions are tailored for Linux. A similar approach could likely be followed for MacOS._ + +在某些情况下，您可能希望在主网上耕种的同时，在其中一个测试网络上也进行耕种，而不会将它们从主网中移除。 This is doable with a bit of extra legwork to set up unique ports for the testnet chia installation. + +有几个设置的选项。 有几个设置的选项。 You can either ensure you have the CHIA_ROOT set to unique values for each instance you want to run, or else run the installations on separate users. These instructions will show setting a specific CHIA_ROOT. + +### Set Up mainnet installation + +For the mainnet installation, we will stick with the default ports and CHIA_ROOT, so these steps are essentially no different than the standard [installation instructions](/reference-client/install-and-setup/installation.md) + +### Set Up testnet installation + +:::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`. + +::: + +```bash +# Export the Chia root +export CHIA_ROOT ~/.chia/testnet + +# Initialize testnet +chia init + +# Configure Chia for the currently-active testnet +chia configure --testnet true + +# Edit the file `~/.chia/testnet/config/config.yaml` and set the following fields to the new port values. +# Use the ports listed or choose any you desire as long as they are different than the default values for mainnet. + +yq -i '.daemon_port = 55401' ~/.chia/testnet/config/config.yaml +yq -i '.ui.daemon_port = 55401' ~/.chia/testnet/config/config.yaml + +yq -i '.ui.port = 8802' ~/.chia/testnet/config/config.yaml + +yq -i '.farmer.port = 8547' ~/.chia/testnet/config/config.yaml +yq -i '.full_node.farmer_peer.port = 8547' ~/.chia/testnet/config/config.yaml +yq -i '.harvester.farmer_peer.port = 8547' ~/.chia/testnet/config/config.yaml + +yq -i '.harvester.port = 8548' ~/.chia/testnet/config/config.yaml +yq -i '.farmer.harvester_peer.port = 8548' ~/.chia/testnet/config/config.yaml + +yq -i '.wallet.port = 8649' ~/.chia/testnet/config/config.yaml +yq -i '.full_node.wallet_peer.port = 8649' ~/.chia/testnet/config/config.yaml + +yq -i '.full_node.rpc_port = 8800' ~/.chia/testnet/config/config.yaml +yq -i '.ui.rpc_port = 8800' ~/.chia/testnet/config/config.yaml + +yq -i '.farmer.rpc_port = 8571' ~/.chia/testnet/config/config.yaml + +yq -i '.harvester.rpc_port = 8572' ~/.chia/testnet/config/config.yaml + +yq -i '.wallet.rpc_port = 9456' ~/.chia/testnet/config/config.yaml + +# Start Chia +chia start farmer +``` + +### Swap between mainnet and testnet + +To swap between running commands for mainnet and running commands for testnet, you need to ensure your `CHIA_ROOT` is set properly before running any commands + +- Mainnet: `export CHIA_ROOT=~/.chia/mainnet` +- Testnet: `export CHIA_ROOT=~/.chia/testnet` + +--- + +## Create a local testnet for fast, private testing + +_These instructions are tailored for Linux. A similar approach could likely be followed for MacOS._ + +0. Stop all chia processes. Check that they have stopped with `ps -ef | grep chia` +1. Create a new chia root using `export CHIA_ROOT="~/.chia/my_testnet"`, then `chia init`. Don't forget to export CHIA_ROOT, or prefix your chia commands with `CHIA_ROOT="~/.chia/my_testnet"` if you want to run on my_testnet when starting a new terminal. +2. Create a new entry in config.yaml with a different [GENESIS_CHALLENGE](https://docs.chia.net/chia-blockchain/consensus/chains/challenges/#genesis-challenge), and reduced `DIFFICULTY_CONSTANT_FACTOR`. 2^67 constant factor is around 110PiB assuming a fast timelord. So if you have around 110GiB, you can set it to 2 ^ 47. Decrease SUB_SLOT_ITERS_STARTING to something like 2^23 if you are using a slow computer. Decrease PLOT_FILTER if you want to have more proof checks per signage point. +3. Make sure to add **my_testnet** to all places that need it, like network_overrides.config, and selected_network +4. Change the introducer URLs to point to localhost so you don't contact the real ones +5. Do `sh install-timelord.sh` +6. Run the system with `chia start all` +7. If you have installed the gui, run `(cd chia-blockchain-gui && npm run electron &)` + +You can generate a new genesis challenge by running python, and entering the following commands: + +```python +from secrets import token_bytes +print(token_bytes().hex()) +``` + +--- + +## Testnet support + +Join Our [Discord](https://discord.gg/chia) and jump into the #testnet channel for support + +--- 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 new file mode 100644 index 00000000000..aa0aa5c763c --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/install-and-setup/timelord-install.md @@ -0,0 +1,306 @@ +--- +title: Timelords +slug: /reference-client/install-and-setup/timelord-install +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::warning +**DO NOT** overclock ASICs, overclocking diminishes the life of the ASIC! +::: + +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). + +--- + +## 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.\ +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. +::: + +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. + - Two USB-C cables (one for power and one for data). Preferably USB-C to USB-C but we have successfully tested USB-A to USB-C without too much performance loss. + +Dependencies: + +- linux OS, our testing has been with Ubuntu 22 and newer +- git (if installing from source) +- ca-certificates curl gnupg (if installing from APT or if running an ASIC - RECOMMENDED) + +--- + +## Installing a Timelord + +:::info +Timelords execute sequential verifiable delay functions (proofs of time or VDFs), that get added to blocks to make them valid. This requires fast CPUs and a few cores per VDF. +::: + + +:::info +Use `chia-blockchain-cli` instead of `chia-blockchain` for CLI only version that does not have a GUI. +::: + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repository +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chia.list > /dev/null +sudo apt-get update + +# Install chia-blockchain +sudo apt-get install chia-blockchain + +# Launch timelord +chia start node timelord & +``` + + + + +The bluebox timelord must be installed from scratch following the instructions [here](/reference-client/install-and-setup/timelord-install#installing-a-timelord-from-source). + + + + +:::warning +**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). +::: + +#### ASIC Cluster Setup + +It is recommended to use three host machines for ASIC clusters in a setup similar to: + +``` + _____ ASIC 2 (ASIC software only, IP set to main machine) + / +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.\ +The additional ASIC hosts will only need the ASIC software installed (noted in the below install instructions). + +```bash +# Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +# Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +# Set up repositories (first is for chia and second is for the hw vdf repo, for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chia.list > /dev/null +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/chiavdf-hw/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chiavdf-hw.list > /dev/null +sudo apt-get update + +# Install chia-blockchain and ASIC repos (for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +sudo apt-get install chia-blockchain +sudo apt-get install chiavdf-hw + +# Launch the ASIC timelord services (for clusters verify the IP address is correct and launch with only 1 VDF for each) +hw_vdf_client --ip 127.0.0.1 8000 3 + +# Launch timelord services in chia (for clusters only the main machine should be running the node and timelord services) +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.\ +Detailed information about the hw_vdf_client parameters can be found [here](/reference-client/cli-reference/asic-hwvdf-cli). +::: + +```bash +# Download chia-blockchain (for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +git clone https://github.com/Chia-Network/chia-blockchain -b latest --recurse-submodules + +# Change directory +cd chia-blockchain + +# Install dependencies +sh install.sh + +# Activate virtual environment +. ./activate + +# Initialize +chia init +. ./activate + +# Install timelord +sh install-timelord.sh + +# Start timelord (skip this step and proceed below if installing a bluebox or ASIC timelord) +chia start node timelord + +# Bluebox timelord setup +Once you build the Timelord with `sh install-timelord.sh` in the virtual environment, you will need to make some changes to `~/.chia/VERSION/config.yaml`. +- In the `timelord:` section, set `bluebox_mode:` to `True`. +(Note: It is possible to run a bluebox timelord on a separate machine from your full node. If you wish to run them separately, make the change listed below on your full node machine.) +- In the `full_node:` section and set `send_uncompact_interval:` to something greater than 0. We recommend `300` seconds there so that your Bluebox has some time to prove through a lot of the un-compacted Proofs of Time before the node drops more into its lap. + +# Additional config.yaml change ONLY for running a bluebox timelord on a separate machine from full node +- In the config.yaml of your bluebox timelord, go to the 'timelord:' section under 'full_node_peers' and, modify the 'host' value from 'localhost' to the local IP of your full node (i.e. 192.168.1.3) + +## Start the daemon, timelord-launcher, timelord, and node for a Bluebox timelord + full node running on the same device +chia start node timelord + +## Start the daemon, timelord-launcher, and timelord for a Bluebox timelord connecting to a separate full node +chia start timelord-launcher-only timelord-only + +Note - The default settings may otherwise work but if the total effort is a little too much for whatever machine you are on you can also lower the `process_count:` from 3 to 2, or even 1, in the `timelord_launcher:` section. You know it is working if you see `VDF Client: Sent proof` in your logs at INFO level. + +# ASIC timelord setup: install the timelord repo, run the timelord-only chia service, and run the ASIC software +## Install packages +sudo apt-get update +sudo apt-get install ca-certificates curl gnupg + +## Add GPG key +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg + +## Set up hw vdf repository (for clusters the chia software is only needed on the main machine all other hosts need the hw vdf repo) +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/chiavdf-hw/debian/ stable main" | sudo tee /etc/apt/sources.list.d/chiavdf-hw.list > /dev/null +sudo apt-get update + +## Install ASIC repo +sudo apt-get install chiavdf-hw + +# Launch the ASIC timelord services (for clusters verify the IP address is correct and launch with only 1 VDF for each) +hw_vdf_client --ip 127.0.0.1 8000 3 + +## Launch the timelord-only chia service (for clusters only the main machine should be running the node and timelord services) +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.\ +NOTE - make sure to replace `USERNAME` with your system's username. + +```bash +# Create systemd service +sudo nano /etc/systemd/system/chiahw-vdf.service + +# Copy the data from below replacing USERNAME with your system's username +``` + +### Example ASIC systemd File + +```bash +[Unit] +Description=Chia HW VDF Service + +[Service] +Type=simple +ExecStart=/usr/bin/hw_vdf_client --ip 127.0.0.1 8000 3 +User=USERNAME +Group=USERNAME +LimitNOFILE=1048576 +LimitNPROC=1048576 +LimitCORE=infinity + +[Install] +WantedBy=multi-user.target +``` + +```bash +# Save and start the systemd service +CTRL+O # save the file +CTRL-X # exit the nano editor + +# Reload and start the systemd services +sudo systemctl daemon-reload +sudo systemctl enable chiahw-vdf.service +sudo systemctl start chiahw-vdf.service +sudo systemctl status chiahw-vdf.service +``` + +### Using the systemd Service + +Restart the ASIC systemd software: +`sudo systemctl restart chiahw-vdf.service` + +Stop the ASIC systemd software: +`sudo systemctl stop chiahw-vdf.service` + +Check status of the ASIC systemd software: +`sudo systemctl status chiahw-vdf.service` + +--- + +## Troubleshooting a Timelord + +For troubleshooting steps please refer to the documentation [here](/reference-client/troubleshooting/timelords). + +--- + +## Timelord support + +Join Our [Discord](https://discord.gg/chia) and jump into the #support channel for support + +--- + +## Timelord FAQ + +### What are the hardware requirements for running a Timelord? + +There are no specific requirements as timelords are a fastest wins process. This means that those with higher end hardware are more likely to generate Proofs of Time than those with lower end hardware. +Currently, a modern gaming PC with 8 cores and 8 GB of RAM is recommended when running an ASIC or Bluebox 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. + +### Can a Single ASIC Compete with an ASIC Cluster? + +The nature of timelords is to create three VDF chains, one can create the chains themselves in parallel (i.e. one on each ASIC) but one cannot break down the VDFs themselves to parallelize them. +This means that the ASIC cluster will always have an advantage but there are times when a single ASIC can reasonably compete. This almost always requires the block farming node to be closer in physical proximity to the single ASIC than to the ASIC cluster establishing a minor time advantage for the single ASIC + +### Can I Overclock the ASIC to Get More Performance or Higher IPS? + +While one can overclock the ASIC we very strongly recommend against doing such. Overclocking the ASICs will lead to diminishing longevity of the machine and only provides a minor increase in performance making it inefficient to overclock an ASIC. + +### What Voltage Should I Use for an ASIC Timelord? + +It is highly recommend to use the default `0.88` voltage. + +### What OS is Compatible with Running a Timelord? + +It is recommended to use a linux OS to run timelords as these are the most performant. +If running on a MAC, one can compile the chia repo from source and run the timelord services but this is currently only compatible with Intel chips and not compatible with the silicon chip. +Windows is not recommended, 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. + +### What System Resources are most Important for an ASIC? + +The single thread speed is one of the most important factors for having a faster ASIC. + +--- diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/moving-plots.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/moving-plots.md new file mode 100644 index 00000000000..aa13d813dd8 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/moving-plots.md @@ -0,0 +1,98 @@ +--- +title: 移动地块 +slug: /reference-client/plotting/moving-plots +--- + +地块以文件形式存储。 它们可以从一个目录移动到另一个目录，甚至可以移动到另一台机器(操作系统无关紧要)。 Back in 2021, plots took many hours to create with the original ChiaPoS plotter. A typical plotting process went something like this: A typical plotting process went something like this: + +1. ChiaPoS Phases 1-3: Create a plot on an SSD (1-8 hours) +2. ChiaPoS Phase 4: Move the new plot to an HDD (10-15 minutes) + +Repeat steps 1-2 until the HDD is full. Finally, restart the plotter manually, pointing to a new HDD. This was reasonable at the time -- when it took 8 hours to create a plot, waiting an extra 15 minutes for it to be moved wasn't a big deal. + +However, with the release of newer plotters such as BladeBit CUDA, it now only takes a few minutes to create a plot. If the plotting software waited for the plot to be copied to an HDD before creating the next plot, the plotter would be idle nearly 90% of the time! If the plotting software waited for the plot to be copied to an HDD before creating the next plot, the plotter would be idle nearly 90% of the time! + +Luckily, a few community members have created scripts to automate the plot-moving process. This page will show you how to use these tools. If you still prefer a manual process, we will cover that as well. This page will show you how to use these tools. If you still prefer a manual process, we will cover that as well. + +## Automated + +### Plow + +- [GitHub link](https://github.com/lmacken/plow) +- [Video tutorial from JM](https://www.youtube.com/watch?v=0xjqQ9paHq0) + +Plow is a Python script developed by Luke Macken. It will automatically move files from an SSD to multiple HDDs. As long as you supply the script with enough HDDs, the SSD will never become full. Instead, either the plotter, or possibly the local network's latency, will become the bottleneck. Plow allows you to create upwards of 100 TB of plots per day from a single machine. It will automatically move files from an SSD to multiple HDDs. As long as you supply the script with enough HDDs, the SSD will never become full. Instead, either the plotter, or possibly the local network's latency, will become the bottleneck. Plow allows you to create upwards of 100 TB of plots per day from a single machine. + +### Plotman + +- [GitHub link](https://github.com/ericaltendorf/plotman) + +Plotman, by Eric Altendorf, is another tool for automating the plot creation process. It comes with a plethora of features, including the automatic spawning of new plotting processes, moving plots, and monitoring each plotting job. It comes with a plethora of features, including the automatic spawning of new plotting processes, moving plots, and monitoring each plotting job. + +## Manual + +If you are only plotting a small farm, or if your plot times are greater than 15 minutes or so, then manually moving is a fine option. + +### 新目录 + +:::tip +To prevent the harvester seeing a large plot as incomplete while it is being moved, append `-mv` to the file extension before moving the file. 在文件移动完成之后，将其重新命名为原始文件扩展名。 +::: + +将地块移动到新目录后，必须将其添加到配置中。 + +如果是使用命令行，请运行以下命令以添加目录： + +```bash +chia plots add -d '/path/to/directory' +``` + +On the GUI, you can do this by going to the **Farmer** tab and clicking **Add Plots**. 选择新目录以添加它。 + +在完成这些步骤并重新启动耕种（farmer）软件后，新的地块应该就能看见了。 + +## 新机器 + +:::note +This will not work unless the farmer on the new machine has access to the same keys. +::: + +在新机器上安装Chia之后，需要导入先前农民使用的相同密钥。 + +如果是使用命令行，请运行以下命令以获取助记词（mnemonic）： + +```bash +chia keys show --show-mnemonic-seed +``` + +在GUI中，您可以通过注销并在钱包上点击选项按钮来完成此操作。 Click **Details** and reveal the seed phrase. + +接下来，通过GUI或使用以下命令在新机器上导入助记词： + +```bash +chia keys add 'mnemonic' +``` + +最后，您需要将地块移动到新机器并将该目录添加到配置中。 + +如果是使用命令行，请运行以下命令以添加目录： + +```bash +chia plots add -d '/path/to/directory' +``` + +On the GUI, you can do this by going to the **Farmer** tab and clicking **Add Plots**. 选择新目录以添加它。 + +在完成这些步骤并重新启动耕种（farmer）软件后，新的地块应该就能看见了。 + +## 检查地块 + +定期检查地块以确保它们未损坏是一个不错的主意。 + +可以通过运行以下命令来检查它们是否正常工作： + +```bash +chia plots check +``` + +这也可以通过在GUI中检查地块是否在列表中可见来完成。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-basics.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-basics.md new file mode 100644 index 00000000000..932c8181a39 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-basics.md @@ -0,0 +1,101 @@ +--- +sidebar_label: Basics +title: 生成地块基础知识 +slug: /reference-client/plotting/plotting-basics +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::note + +The [Beginner's Guide to Farming](/reference-client/getting-started/farming-guide) will walk you through the steps required to install Chia and create your first plot. You are recommended to follow it prior to getting into the concepts introduced in this section, reviewing our [plotting basics](https://www.chia.net/2021/02/22/plotting-basics/) helps guide users from a high level perspective. + +::: + +At the center of every Chia farm is a _farmer_, as well as at least one _harvester_. Each harvester keeps track of one or more _plots_ on the same computer. + +This section will give an overview of plots: what they are, how to create them, how to maintain them, etc. Later we'll delve deeper into the details. Later we'll delve deeper into the details. + +:::info + +The full node, farmer, and harvester processes can all be run from the same computer. This is the recommended setup for those new to Chia farming. Later, plots can be added or moved to remote harvesters as needed. This is the recommended setup for those new to Chia farming. Later, plots can be added or moved to remote harvesters as needed. + +::: + +## Description + +Plots are files that consist almost entirely of cryptographic data. Plots are files that consist almost entirely of cryptographic data. These files prove to the network that a computer is storing data, as part of Chia's Proof of Space consensus. + +The plotting process is computationally intensive. Depending on a number of factors, the plotting computer, CPU, GPU, RAM, and/or storage devices (such as SSDs) are heavily utilized. However, this process is only performed when _creating_ a plot. Afterward, plots can typically be _farmed_ for many years, during which the farming computer, as well as the HDDs that store the plots, will remain mostly idle. + +While it is possible to run a Chia farm from a high-end plotting machine, many farmers choose to use low-end systems in order to save money on electricity. For example, the minimum spec hardware to run a Chia farm is a Raspberry Pi 4 with 4 GB of RAM. As a result of these low requirements, Chia consumes less than 1% as much energy as Bitcoin, while preserving the same level of security. For more details, see chiapower.org. For example, the minimum spec hardware to run a Chia farm is a [Raspberry Pi 4](/reference-client/install-and-setup/installation#raspberry-pi) with 4 GB of RAM. As a result of these low requirements, Chia consumes less than 1% as much energy as Bitcoin, while preserving the same level of security. For more details, see [chiapower.org](https://chiapower.org/). + +:::info + +It is possible to run a node without any plots. It is possible to run a node without any plots. Your node will validate the network, but it will not be eligible to win any rewards. On the other hand, with a single plot, you can join a pool and collect regular (albeit small) rewards. On the other hand, with a single plot, you can join a pool and collect regular (albeit small) rewards. + +::: + +## Compressed plots + +In 2023, some major changes were made to the plotting process, mostly due to the introduction of "compressed" plots. + +:::info + +Technically, **all** Chia plots are compressed -- they consist almost entirely of random cryptographic data, so they cannot be made much smaller using lossless techniques. However, in order to simplify the descriptions, we'll use the following terms for the different types of plots: + +- **Uncompressed** -- Plots that are complete upon being created. Uncompressed -- Plots that are complete upon being created. Software capable of creating uncompressed plots includes the original ChiaPos, madMAx, and BladeBit RAM and disk. Nearly all plots created prior to 2023 are uncompressed. Nearly all plots created prior to 2023 are uncompressed. +- **Compressed** -- Plots that are incomplete upon being created. Compressed -- Plots that are incomplete upon being created. Software capable of creating compressed plots includes BladeBit CUDA and GigaHorse. Compressed plots were introduced to the official Chia software in version 2.0. Compressed plots were introduced to the official Chia software in version 2.0. + +::: + +### History + +Chia plots consist of seven tables, the format of which was defined in mid-2020. The reference plotter included with version 1.0 was ChiaPoS, which only used one CPU core, and which produced uncompressed plots. Chia plots consist of seven tables, the format of which was defined in mid-2020. The reference plotter included with version 1.0 was ChiaPoS, which only used one CPU core, and which produced uncompressed plots. When Chia's mainnet was launched in March 2021, all Chia plots were created with the ChiaPoS plotter. + +Later in 2021, the madMAx and BladeBit plotters were developed independently. These plotters fully utilized a plotting machine's resources, so they were significantly faster than the ChiaPoS plotter. For the first time, it became possible to create a plot entirely in RAM, thus eliminating the need for an enterprise SSD. However, these second-generation plotters still exclusively created uncompressed plots. + +By the end of 2022, it had become apparent that a form of "lossy" plot compression was possible. A few different competing techniques were being devised that involved omitting one or two tables, or some data held within, during the plotting process. The result was an incomplete plot, where the missing data could be added during the farming process. These techniques allowed plots to be 20-30% smaller than their uncompressed brethren, depending on how much data was omitted at the time of plotting. + +:::info + +There are two basic types of compression -- lossless and lossy. For a brief overview of the differences, see [this article](https://www.howtogeek.com/744381/lossy-vs-lossless-compression-whats-the-difference/). There are two basic types of compression -- lossless and lossy. For a brief overview of the differences, see this article. While compressed Chia plots don't actually use lossy compression, it still can serve as a useful analogy to how it works. + +::: + +Plot "compression" is possible because the data contained within a plot is deterministic. A plot's ID -- a 32-byte hash -- is all that is needed to determine the entirety of its contents. In other words, if you use the same ID (and k-value, as will be discussed later) to create plots on two different computers, the plots will be identical. It is therefore possible to generate any missing data on the fly. This, combined with other techniques such as brute-forcing a small number of bits, results in the plots being smaller. + +By mid-2023, most new Chia plots were being created using these "compression" techniques. Each individual plot earns the same rewards as an equivalent uncompressed plot. However, because the compressed plots are smaller, more of them fit on each disk. Farmers therefore earn extra income compared with using uncompressed plots. + +In 2024, we proposed a new proof format that would make it much more difficult to compress plots. This is an ongoing project, which will not be complete until the end of 2026 according to current estimates. For more info, see our section dedicated to the [new proof format](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction). + +### Tradeoffs + +As with most technologies, compressed plots come with tradeoffs. The fact that they are left incomplete upon being created means that they require more energy to be "completed" while farming. Luckily, the lower levels of compression only require a small amount of extra energy, while yielding 15% more rewards. As with most technologies, compressed plots come with tradeoffs. The fact that they are left incomplete upon being created means that they require more energy to be "completed" while farming. Luckily, the lower levels of compression only require a small amount of extra energy, while yielding 15% more rewards. On the other hand, plots using the highest levels of compression require more compute while farming, thus necessitating the use of a GPU. + +Chia's plot format was designed such that higher compression levels would yield linear gains in size, at a cost of an exponential increase in required computational power. Because of this tradeoff, it is unlikely that better techniques will emerge to compress plots by more than a few percent beyond their current levels. For deeper levels of compression to become viable, another table would need to be omitted. At that point, it would take longer for a farmer to finish a compressed plot than it would for a plotter to create an entire uncompressed plot. + +## K值大小 + +_k_, as detailed in the [plotting](/chia-blockchain/consensus/proof-of-space-1.0#plotting) section, is a constant value that describes the size of each plot. The minimum k value for Chia is 32, which corresponds to 108.8 GB (101.4 GiB) for uncompressed plots. With each increase in k, the plot size is approximately doubled, as are the resources required for creating the plot. For this reason, k32 is the most common size on the network, accounting for 98% of the netspace. + +:::info +k32 is the minimum plot size eligible for farming on Chia's **mainnet**. If you want to test plotting and/or farming on a **testnet**, then it is also possible to use k25. These plots are only around 660 MB apiece, so they can be created quickly on a laptop. +::: + +Although not required, plots larger than k32 may be created. There is not a great benefit to using larger plot sizes as the chance of winning is proportional to plot file size. For example, a k33 plot is twice as large as a k32 plot, and it wins twice as many rewards. There are advanced tactics to using a larger `k` value to reduce unused storage space or optimize drive idle states, but these won't be highly beneficial for the majority of people. + +### Compression Levels + +The level of compression you choose will be highly dependent on your farming setup. The level of compression you choose will be highly dependent on your farming setup. The good news is that even those using a Raspberry Pi for their harvesters will be able to take advantage of the lower levels of compression. Additionally, each step up in compression level requires an exponential increase in computing power, while yielding a linear decrease in plot size. For these reasons, those who are farming with a Raspberry Pi can yield 20% higher rewards by using compressed plots, while those using the most powerful GPUs will see a modest increase over the benefits obtained by the Pi. Namely, C9 plots yield 35% higher rewards than C0 plots. Additionally, each step up in compression level requires an exponential increase in computing power, while yielding a linear decrease in plot size. For these reasons, those who are farming with a Raspberry Pi can yield 20% higher rewards by using compressed plots, while those using the most powerful GPUs will see a modest increase over the benefits obtained by the Pi. Namely, C9 plots yield 35% higher rewards than C0 plots. + +The next page will detail the various types of hardware that can be used for creating Chia plots. Later, we'll discuss the specific compression levels, including the hardware required to yield each increase in farming rewards and the actual file sizes broken down by [k-size with compression levels](https://docs.chia.net/chia-blockchain/resources/k-sizes). + +## 如何获得帮助 + +If you are stumped about some aspect of plotting, farming, or Chia generally, we're here to help! + +- Get help on CNI's official [Discord](https://discord.gg/chia), in the `#farming-and-plotting` and `#support` channels. + +- Get more questions answered in the [plotting FAQ](/reference-client/troubleshooting/plotting-faq.md). 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 new file mode 100644 index 00000000000..1651b683545 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/reference-client/plotting/plotting-compression.md @@ -0,0 +1,107 @@ +--- +sidebar_label: Choosing a Compression Level +title: Choosing a compression level +slug: /reference-client/plotting/plotting-compression +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +If you opt to create compressed plots, you will need to decide on the level of compression. + +:::info + +You can mix and match plots with different compression levels. For example, you could have some C0, C3, and C7 plots on the same machine. Your harvester will handle this without issue. However, most users will likely choose to convert all of their plots to the same compression level. For example, you could have some C0, C3, and C7 plots on the same machine. Your harvester will handle this without issue. However, most users will likely choose to convert all of their plots to the same compression level. + +::: + +As a reminder, BladeBit CUDA and BladeBit RAM are plotters supported by CNI that are capable of creating compressed plots. Whenever we mention compression levels, we are referring to those defined by BladeBit. (Many people have also used the third-party GigaHorse plotter by madMAx. This plotter uses a similar nomenclature for its compression levels, but they have different definitions.) Whenever we mention compression levels, we are referring to those defined by BladeBit. (Many people have also used the third-party [GigaHorse](https://github.com/madMAx43v3r/chia-gigahorse) plotter by madMAx. This plotter uses a similar nomenclature for its compression levels, but they have different definitions.) + +The next sections list three methods to determine the compression level that will work best for your farm, starting with the most general and ending with the most specific for your own hardware. + +### Compression table + +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 | + +The right column (Min Spec Harvester) shows the minimum type of computer required for harvesting at each compression level, where: + +- `Pi 4` refers to Chia's minimum spec hardware, the [Raspberry Pi 4](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/) with 4 GB of RAM for CLI farming, or 8 GB for GUI farming. +- `Desktop CPU` refers to a power-sipping computer such as the [ASUS Chromebox](https://www.androidcentral.com/best-chromebox). +- `Fast CPU` refers to a computer with a higher-end CPU such as an Intel Xeon. +- `GPU` refers to a computer with an Nvidia CUDA-class GPU. The minimum amount of DRAM required is around 600-700 MB for C7 harvesting. For example, a GTX 1060 will work. + +:::info + +A few things to keep in mind regarding these recommendations: + +- The above table is meant as a general overview; it therefore assumes that your farm is somewhere from 500-1000 TiB. +- The more plots your farm has, the higher-end your harvester needs to be, all other factors being equal. + +::: + +### TCO spreadsheet + +In order to calculate your potential profits from farming at various compression levels, you can use [this spreadsheet](https://docs.google.com/spreadsheets/d/1k6c-OBDtggXqnEfOPdMmq3646puzvOD7dWojwCH2v3c). Simply make a copy of it, then fill in the constants according to your farm. As you will see from the spreadsheet, the compression level you will ultimately choose will depend on a number of factors, such as electricity cost and the size of your farm. + +### Max farm size estimator + +The third-party website [xch.farm](https://xch.farm/max-farm-size) has tables for estimating your farm's maximum capacity depending on your CPU/GPU setup. Be sure to pay attention to the `June 2024` column when planning your farm. If your harvester is capable of handling your desired number of plots listed in this column, you should be good to go until 2027 or later. + +### BladeBit Simulate + +The [standalone version of BladeBit](/reference-client/plotting/plotting-software#bladebit-standalone) comes with a simulator that will determine the maximum size of your farm. The basic idea is that you pass in a compressed plot (C1-C9) and it will calculate the maximum number of plots/space your current harvester can handle. + +See the [CLI reference](/reference-client/cli-reference/plotter-cli#simulate) for a list of options using the simulator. + +:::info + +The simulator's default values are typically fine, other than the filter size. For context, starting in June 2024 the plot filter will be reduced from 512 to 256. At this point, twice as many plots will pass the filter, so your harvester's workload will effectively double. You are recommended to use `-f 256` with the simulator to prepare for this event. For more information on the plot filter, see our [FAQ](/chia-blockchain/resources/faq#what-is-the-plot-filter-and-why-didnt-my-plot-pass-it). + +::: + +:::note + +It is a good idea to create plots of various sizes (for example, one C3, one C7, and one C9) and then run the simulator against each of them. This will help you to plan for how many harvesters to use, the type of hardware to acquire, etc. This will help you to plan for how many harvesters to use, the type of hardware to acquire, etc. + +::: + +The simulator's default mode will decompress your plot and then extrapolate your farm's maximum size, which should only take a few seconds. + +Example command using the default mode and a filter size of 256: + +```bash +bladebit simulate -f 256 +``` + +:::info + +The simulator will only work with compressed plots. + +::: + +The simulator can also be configured to run a real-time simulation against a farm of any given size. This will give you a much better idea of how your system will perform on mainnet. To activate this mode, use the following flags: This will give you a much better idea of how your system will perform on mainnet. To activate this mode, use the following flags: + +- `--power