@howellzhu 关键是内录音频。这个 screenrecord 看上去是完全没有声音的。LOS 自带录屏好歹还能麦克风录音。

我上面说这些不是说 HD 钱包有安全问题——恰恰相反，相比使用单个私钥，我还是推荐使用 HD 钱包。
我的意思是，如果用了 HD 钱包，那就不要闲着没事干把私钥倒来倒去。

中本聪的白皮书里就说了，比特币地址虽然匿名，但是交易记录公开可追溯，所以可以通过地址用一次就换掉来一定程度上扰乱追溯、保护隐私。（后来还有了 coinjoin 混币等手段）

为了方便管理（一堆私钥，漏了任何一个没备份，上面如果有币都会丢），所以才有了确定性钱包，也就是从一个种子推算出所有的私钥和地址。

这样只要把 [种子] 备份好了，就把整个钱包备份好了。

现在用的一般是 HD （分层确定性）钱包，由 BIP32 定义，它也是从一个 [种子] 推算出所有东西，但它还可以分层次管理，父级密钥可以派生出子密钥。

如果楼主不想用 HD 钱包，只使用单个私钥，那安全性方面没啥问题，但是隐私方面不太好，因为比特币的交易记录公开，这样就更方便追溯了。（要说“把公钥哈希一次来抗量子计算机”，这其实只是个传说，实际上靠不住）
如果你每次收款都换新地址，每次转出时也都换新的找零地址，那追溯起来就会稍微麻烦一些。
可见，这个隐私保护很鸡肋，很多时候可以从金额等特征来猜测、分辨哪个是找零地址，所以一般都说比特币的隐私性差。

还有，就是手动操作单个私钥时，容易犯一些后果严重的低级错误。
比如导入 Bitcoin Core 钱包后，进行转出操作，这个时候找零地址会是新生成的地址，而不是导入的那个地址。有人因为安全强迫症，执行转出操作后就格式化了硬盘，结果发现自己小心呵护的那个私钥上已经没币了，币都跑到 [新生成的] 找零地址上了，然而这个 [新生成] 的私钥已经被抹掉，所以就是永久丢币。

HD 钱包还存在固有的一个弱点：主公钥（ xpub/ypub/zpub 开头）本身不能推导出私钥，但是主公钥+单个子私钥=主私钥=所有子私钥。
Bitcoin Core 为了规避这个问题，生成地址时用的都是强化派生（ hardnened derivation ），这样就不会有这种“一漏漏一大片”的风险，但是代价就是没办法再使用 xpub 主公钥直接推导出收款地址，也就是说，要做“冷热分离”（联网钱包不含私钥，只能监视；离线钱包负责保存私钥、签名交易）就比较麻烦、困难，HD 钱包提供的“换地址方便”这个好处很大程度上消失了。

我刚刚扫了一眼 GitHub 上有关的 issue 讨论，开发者还说“BIP39 没有钱包创建日期”——哎，怎么说呢，无论是 Bitcoin Core 全节点钱包，还是 schildbach 这个 BIP37 协议的 SPV 轻钱包，它们的工作原理都是非常低效的：需要重新扫描动辄几十上百 GB 的区块链账本，才能找回交易历史。BIP37 只不过是把这个扫描工作推给了网络中的全节点而已。
Electrum 钱包的服务器就不是这样，Electrum 服务器建立了更完备的索引，空间换时间，所以它才可以秒开、快速同步。
但愿以后 BIP157/158 完全在 Bitcoin Core 上实现可以缓解这个问题。BIP157/158 生成的索引只占几 GB 的空间，可以说是取了一个折衷。

比特币的助记词一直都是一个很混乱的局面，除了 BIP39 还有 aezeed、Electrum 2.0 等很多种互不兼容的助记词格式。
Bitcoin Core 的“核心开发者”对 BIP39 方案看不惯，各种挑毛病，“一致反对实现”，哪怕那么多年过去《精通比特币》里说的还是 BIP39，而且用得最多的还是 BIP39。

而且，Bitcoin Core 自带的钱包功能，以及楼主用的这个 schildbach 钱包，都是压根不提供助记词的，顶多只有一个 xprv 主私钥。

我个人比较喜欢用的钱包是 Electrum，不过 Electrum 的手机版好像不能导入 BIP39 助记词，而且它不给 3 开头的隔离见证地址，要么是 bc1 开头的原生隔离见证地址，要么是 1 开头的传统地址。（实际上导入 yprv 开头的 BIP49 HD 主私钥就可以生成 3 开头的隔离见证地址，但是这么搞稍微有点麻烦，最好用 Ian Coleman 的 BIP39 工具离线操作）。
而且有一说一，Electrum 之前出过几次影响比较大的安全漏洞，尤其是钓鱼漏洞，有不少受害者，而且只要还有人用旧版，他们就仍然受威胁。
比特派钱包比较友好，用的是 BIP39 助记词，多币种。不过它不开源，而且一直都不支持 RBF 直接追加手续费“插队”，他们一直在卖矿池提供的“加速器”，实际上还是插队，而且比较贵。

@brainzhang 这个 schildbach 钱包貌似没有助记词……

其实可以用 www . google . cn / generate_204

@memorybox 还有，你在 11 楼说的第一种情况，说实话我没懂。在两个分叉的链一样长的情况下，也就是 n=0，这应该还是属于胶着状态啊，貌似还不能就此断定是谁赢了吧。

@memorybox 即便不谈 SPV，只谈全节点（它具有独立完整验证区块链账本能力），在这方面也是有一定争议的。当年闹 2X 的时候，2X 那边的 btc1 全节点就改掉了“隶属于 Core 阵营”的几个默认种子节点，因为他们害怕这几个默认的种子节点在分叉发生后会起到类似于日蚀攻击的作用。

@memorybox 我前面说了白皮书里的“硬盘空间回收”不可行，但我没说 SPV 不可行，我只是说 SPV 会盲目跟随多数算力。
实际上，有一个讽刺的事实，就是虽然“盲目跟随多数算力”看上去对安全性 /稳定性存在威胁，但是，如果 SPV 客户端能够联系得上多数算力、进而能够找到多数算力支持的链、并跟随这条链，这反倒还算是去中心化的体现——否则的话，SPV 可以说就是依赖了某种权威，这样很显然就不是去中心化了。

@memorybox 有些大区块党貌似很抗拒“全节点拒收非法链”这个概念，不过，我也没说这里的“全节点”非得是用户手里的那种一点点算力都没有的全节点啊，至少矿池还是要跑全节点的对吧，那矿池也要面对一样的问题。

@memorybox
BCH 分裂为 SV 和 ABC 那件事，我不太了解细节，不过我印象里，那不算是真正的算力战，双方仅仅是在投入更多算力来防守而已；只是很多观众眼中，根据“最长链规则”，是“谁长谁正宗”，所以看上去就像是一场恶战了。

PS：最长链规则，准确地讲应该是“积累挖矿工作量最大规则”而不是最长链规则，否则的话，任何人都可以利用早期的挖矿低难度来轻轻松松爆出超长的攻击链；只不过比特币是每 2015 个区块才调整一次难度，在同一个难度调整周期内，确实是“最长链规则”。

为什么我要这么说呢？因为我前面就说了，不管一个攻击者有多少算力、他的链有多长（积累了多少挖矿工作量），如果这条链违反了现有的规则，那全节点会直接把它拒收（忽视）掉。
所以，如果你要攻击对方，你的攻击链必须得符合对方的规则，这样对方才会被迫吃下你的炮弹，然后这颗炮弹才会爆炸、起到破坏作用——比如，通过双重支付来变相实现偷币，或者是通过拒绝打包任何正常交易来让这个币暂时停摆。

至于“一条链上不断积累的算力可以为这条链的权威性背书”，或者说“掌控算力足够大的一方随时都可以用 51%攻击掐死敌对的另一方”，这都是后话了。要说“权威性”，这是韭菜的主观判断；要说“随时都可以 51%攻击”，那又回到刚刚的结论了——如果你要攻击对方，你的攻击链必须得符合对方的规则。

@memorybox 我 4 楼的意思其实是说，虽然现在的系统绕开了这个坑，但绕开这个坑也是付出了代价的：全节点只能从创世区块开始，完整下载一遍奔着 300GB 去的区块链账本。
然后，在 6 楼，我就从这个点展开说了一下比特币社区的分歧：大区块党认为，只要把“最终余额”的 hash 也写到区块里，就可以让新节点跳过历史，直接从最近的状态开始；小区块党就不这么认为，他们认为这个“最终余额的 hash”是不能像完整区块链那样自证清白的，这样做就是让矿工掌控了整个系统。

@memorybox
这个问题本来就不影响现在的系统。这是一个早就已经被绕开的老坑。我也没有说这个问题会影响现有的系统，应该是我的表述让你产生了误解。

“把本来没花掉的币修剪掉”，这个不一定是无害啊，如果一个挖矿出块的全节点为了偷懒跳过了完整历史区块，只下载了这种恶意“断章取义”的修建版历史区块，那别人眼中完全正常的交易，在他眼里就变成“花掉不存在的币”的非法交易了，网络中就要产生不一致了。

至于“已经花掉的币”，它的交易本来就在 Merkle 树里啊。

币圈外批评“trustless”的角度，大概有这么几个：
1.链上信息如果涉及现实世界，那就无法保证真伪。
2.软件出 bug 几乎无法避免，更不用说可能被插入后门。
3.说到后门的话，从操作系统到 CPU，到编译器，再到各种加密算法，甚至是币圈软件自身的“开源代码”本身，都无法保证绝对没有后门，我们都是信任着这些东西。

币圈内，大区块党，批评“trustless”，貌似就不这么说了，他们只是会强调“中本聪本来就是让矿工掌控比特币的，用户本来就是要信任矿工不作恶的”。

@memorybox #12
再逐条回复一下：

“1. 验证 Merkle 树的合法性”

SPV 并不需要验证整棵 Merkle 树。

“2. 通过 Merkle Root 验证其所在 block header 的合法性”

反了，先验证 block header 是否合法，然后才能用这个 block header 里的 Merkle root 验证 Merkle proof，再用 Merkle proof 验证一笔交易是否进链、（再结合后面接了几个 block header 即可验证）有了几个确认。

“3. 轻节点通过其自带的 check point HASH 值，以及接收到的其他全节点广播的最近的 block header 验证此 block header 合法性”

理论上，checkpoint 并不是必要的。区块链最大的特色就是能“trustless”（无需信任），或者说，能“自证清白”。一个区块头里的各种信息，无论是前一个区块的 hash，还是是否满足挖矿难度，再有就是时间戳是否符合规则，都是可以独立完成验证的，一个节点或用户不需要询问任何人，自己就可以得出结论。
但是，你还是得能联系得上至少一个诚实的节点，如果你周围所有的节点都是恶意的，也就是日蚀攻击这种情况，那你就面临被蒙蔽 /欺骗 /攻击的风险。

@memorybox #11 你还提到了“沉浸”在恶意节点中——据我所知，“日蚀攻击”（ eclipse attack ）就符合你说的这种情况。这一般只是被视为比特币协议的一个弱点（貌似还算是根本性的弱点），和是不是私有链 /中心化无关。

如果你还对我说的“Merkle 树裁剪不可行”有疑惑，那我再说一下：
按照通常的逻辑，“交易历史记录”和“最终余额”，这两个东西，是迥然不同的吧。
但是，中本聪的白皮书里，把“交易”直接定义成了“币”，然后又说“可以利用交易被编织成 Merkle 树这个特点来进行裁剪、回收硬盘空间”。按我的理解，他就是想“交易历史记录”和“最终余额”合为一体。但稍微想一想，就会发现这里有问题。

@memorybox checkpoint，这个是开发者人为指定的，所以很显然是中心化的。
Bitcoin Core 的 checkpoint 基本上算是被弃用了，上一个检查点还是 2014 年的。
不过，checkpoint 有关的代码并不是完全没用了，一是可以对付低难度垃圾区块头 DoS 攻击，二是用来加速同步的 assumevalid，开发者说过，它和 checkpoint 共享同一套代码。
assumevalid 是指定一个区块 hash，在此之前的脚本（以及数字签名）验证全部都认定为有效，跳过检查验证。这大概就是为什么 Bitcoin Core 全节点在从头同步的时候，大部分时间都只让一个 CPU 核心满载，只有同步到最近的区块时，CPU 才开始满载。
虽然 assumevalid 也是开发者人为指定的，但是它并没有 checkpoint 那种“禁止回滚”的特性，assumevalid 是允许 51%攻击回滚的。而且，用户可以改配置参数来关掉这个功能。