「精通比特币」共读活动

[MBe3read]

前言

比特神教徒最近很忙。OpenAI 的宫斗大戏、Istanbul 之旖旎⻛光，都没法挪开他们朝向一本书的眼球 —— ”Mastering Bitcoin” 第三版。距第二版已六年，以太坊转成 PoS，零知识证明人尽皆知。比特币在众人眼里仍是备受尊敬的老古董，没有变化也无需变化——可这不是真的。Taproot，Schnorr Signature， RBF，CPFP， MAST —— 比特币日日新，学愈多知所知愈少（The more I learn, the more I realize how much I don't know）。谁敢说自己能「精通」比特币呢 —— 不断在学习罢了。

Bitcoin Optech 中文翻译小组不想被落下，早已分头阅读。读的过程中既有心得分享，也有困惑切磋。共读的种子已经种下，何不向更广阔的天地生长呢？如果你也感兴趣，不如一起「学习比特币」吧。

本次活动由 Bitcoin Optech 中文翻译小组、HashKey Capital筹备，原语里弄执行。距离上次共读活动已年半。世界天翻地覆，朋友散落东⻄，好在阅读仍让人宁静，比特币时钟仍未停息。

开始时间

即日起。

参与共读

这是一次开放式共读，理论上你只需要找到一本书，并开始阅读，当然能读完它更好。不过为了让阅读更有趣，获得更多收获，你也可以跟随以下指引报名本次活动：

1. 购买书籍 Mastering Bitcoin: Programming the Open Blockchain 3rd edition

   • 🌟 这本书不便宜，但物有所值。原语里弄认真考虑给予部分读者书款补贴。细则将在共读活动期间在此发布。如果你认真阅读了，就不是什么麻烦事。
   • 🔗 购书链接（第三版新增了 Taproot、RBF、P2C 等内容）

2. 登录 Github（或者先注册），在本贴点赞 🎉 表情即表示参与共读活动。

共读形式

📖 读

本次共读活动没有精细的计划，你可以随时开始并按照自己的节奏阅读。若你有一定的基础，推荐按照以下节奏阅读，这样可以和大家更好地交流。

本书包含 14 章，建议用两个月时间读完（2023/12～2024/01）：

• 2023/12：1 ～ 7 章
• 2024/01：8 ～ 14 章

🙋 问

讨论将在本帖进行，你可以在此贴礼貌地回贴提出与书籍相关的问题。“OP_QUESTION” 是一个公开的论坛，你可以在此讨论比特币的技术问题。这个名字来源于比特币的脚本系统。比特币脚本的操作码通常使用 “OP_” 作为前缀，并全部使用大写英文字母。

提问格式如下：

【书籍问题】- {章节} - {问题关键词}
具体问题描述

示例：
【书籍问题】- 第四章 -压缩公钥为什么不存储 y 值
在“Compressed Public Keys”一节，压缩公钥为什么不存储 y 值？这样可以确定 x 的正负，也就可节省一个符号位。可能是因为对 x 求立方根的计算量更大？

✏️ 写

你可以在任意平台书写发布读书笔记，期待你在此贴回复分享笔记链接。
分享格式如下：
【读书笔记】- {读书笔记标题} - {名字/昵称} + 链接

示例：
【读书笔记】-《精通比特币》读书笔记 - 小丁

💬 聊

计划举办两次研讨会，集中讨论大家提出的问题及感兴趣的话题。
详情请关注本页面更新。

⚠️ 为了论坛版面秩序，请大家按照模版格式在此贴回复，勿单独发贴。不尊重他人的言论及与书籍无关问题将会被及时清理。

新版介绍

有关新版著作的增补，详见合著者 David Harding 的文章。

如有有关共读活动的问题，请发送标题包含【共读活动】的邮件至 contact@primitiveslane.org

[MBe3read]

读书笔记索引

[andy1419168]

🎉

[MBe3read]

章节问题索引 A

[MBe3read]

章节问题索引 B

[MBe3read]

Placeholder

[hulatown]

【书籍问题】- 第四章 -压缩公钥为什么不存储 y 值

在“Compressed Public Keys”一节，压缩公钥为什么不存储 y 值？这样可以确定 x 的正负，也就可节省一个符号位。可能是因为对 x 求立方根的计算量更大？

[freeyao]

我认为主要是计算量的差异，但是具体的时间复杂度我没有找到准确的数据。
点压缩的最初想法是 Miller 在 1986 年[1]提出的，在这份 IETF 的草稿[2]中也提到，舍弃的“通常”为 y 坐标。

参见
[1] https://cr.yp.to/ecdh/patents.html
[2] https://datatracker.ietf.org/doc/html/draft-jivsov-ecc-compact

---

2024/01/07 更新
BIP-324 的文档说明[3]中也提到，在椭圆曲线上计算平方根比计算平方要困难，应该避免。

[3] https://github.com/dhruv/bips/blob/bip324/bip-0324.mediawiki#cite_ref-xonly_ecdh_11-0

[Esther-Guo]

【书籍问题】- 第二章 - 交易的输出项

Alice’s Tx2 contains two new outputs, one paying 75,000 satoshis for the podcast and another paying 20,000 satoshis back to Alice to receive change.

没太理解 tx2 中的 20,000 satoshis 的含义，看原文是找零的意思？找零为什么会作为该交易的输出项之一呢？

[Esther-Guo]

😅😅 原来下一节就有答案，唐突了 orz

[hulatown]

【读书笔记】-《精通比特币》读书笔记 - Jeffrey Hu

[hulatown]

【书籍问题】- 第十二章 -如果 2 个小时不出块是否有问题？

书里提到：节点不能接收未来 2 小时以外的区块
那么如果 2 个小时内挖不出来一个区块会发生什么或应该怎么处理？
或者应该这么理解：节点比较的基准是自己当前的实际物理时间（wall time）而不是前一个区块的时间？

[editor-Ajian]

这个 “未来 2 个小时以外的区块”，指的是时间戳大于本地时间 2 小时以上的区块，而不是比上一个区块的时间戳大 2 小时以上的区块。它并不是一种对出块间隔的共识限制。

准确来说，目前，这个 “本地时间” 的定义是 “网络调整时间”，是本地时间加上与 200 个随机对等节点的平均时间差值所得到的时间。
如果 Bitcoin Core PR #28956 得到适用，则意味着 ”本地时间“ 将不再考虑与对等节点的时间差值，回归到其字面含义。见 Optech Newsletter #284

[hulatown]

【书籍问题】- 第四章 - Bech32 地址为什么通常用小写

书里提到：Bech32 是大小写不敏感的，通常更倾向于用小写形式。但如果改成大写的话，做二维码会更节省空间。
所以问题是，为什么 Bech32 不更倾向于用大写形式？可能只是更符合阅读习惯？

[kurtpan666]

BIP 173 中有如下内容：

Uppercase/lowercase
The lowercase form is used when determining a character's value for checksum purposes.
Encoders MUST always output an all lowercase Bech32 string. If an uppercase version of the encoding result is desired, (e.g.- for presentation purposes, or QR code use), then an uppercasing procedure can be performed external to the encoding process.
For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of alphanumeric mode, which is 45% more compact than the normal byte mode.

Why not use an existing character set like RFC3548 or z-base-32? The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.

Bech32Chars 是去掉 "1", "b", "i", "o" 后的 ：qpzry9x8gf2tvdw0s3jn54khce6mua7l

基于此我认为，除了符合阅读习惯外，作者是在倾向于选择小写字符之后，再选用的遵循歧义最小化原则的字符集，以及规定的checksum的计算规则。

[berryjam]

感谢BTC-Study一直对区块链领域的知识无私分享，个人也参考过往第二版对精通比特币第三版进行了翻译：https://berryjam.gitbook.io/mastering-bitcoin-3rd/

[kurtpan666]

感谢翻译工作！

[hulatown]

感谢翻译工作！

[editor-Ajian]

【书籍问题】- 第四章 - Bech32m 为何失去了纠错能力？

在 “Bech32 地址” 一节中，作者介绍 Bech32 这种编码形式既能检错，也能纠错，也即不仅能提示出错了，还能告诉我们错在哪里了。
但 Bech32 也有一些问题，难以发现以 “p” 结尾的字符串的倒数第二个位置有无误插入 “q” 字符。因此人们提出了 Bech32m，它改变了编码算法中的一个常量。
但是，作者却说，“对于比特币地址，其作用仅限于错误检测，而不是错误纠正”。

从 Bech32 到 Bech32m，只是改变了一个常量，为什么就失去纠错能力了？