除了一楼提到的矿池可能优先打包自己家的交易，矿工也是按照手续费除以 vBytes 虚拟字节数来排序决定优先打包哪些交易的。

交易所这种，一笔交易可以给很多个用户发币，也就是所谓的 batching 批量发币。二楼 @touzi 说的应该就是这个意思吧。
这种情况下打个比方就像拼车一样可以省钱。本来发 N 笔交易需要 N 个输入 N 个找零输出额外占字节数，如果合并成一笔交易，那其中 N-1 项输入和找零输出的开销就都省去了。

自己的钱包一般没这个条件。

而且其实对于 SPV 来说，它是盲信算力、没有验证交易合法性（是否符合规则）。单单是防篡改本身其实并不是问题，Merkle 树已经搞定了。怕的是多数算力故意打包违反规则的交易（比如偷币、造币）。

@realpg 实际上因为可以开启修剪，所以存储并不是不可回避的瓶颈，被认为真正难以回避的瓶颈是带宽（因为要全部下载一遍所有区块）

关于钱包需要扫描区块找出与自己相关的交易这一点，其实可以借助 block filter index 大幅加速区块扫描速度，甚至 P2P 扫描（从别的节点下载区块）。

BIP157/158 本来就是轻钱包协议，而且其实 Bitcoin Core 已经实现了服务端、其他不少钱包则是已经实现了客户端，只不过是 Bitcoin Core 自己还不能利用它加速扫描或者减轻（或者说转移，也就是走 P2P ）自身的存储负担。

block filter index 这个也算是一种折衷：一个极端是傻扫区块，特别慢特别低效（原先 BIP37 就是因为这个理由淘汰的，甚至认为可以 DoS ），另一个极端是像区块浏览器那样虽然可以秒速得到结果，但索引很大。block filter index 就是速度相对比较快，占硬盘也不太大。

@LnTrx 不知道你说的硬分叉指什么，如果是换算法的话还是要人为干涉吧。

@beyondsoft 只需要维护好 UTXO 集合就不需要读取老区块（老区块读取验证过一次里面的交易就可以丢弃），这一点和 Merkle 树无关。

算力方面，确实和带宽 /存储方面一样存在本质问题，但也提出了缓解办法。如果说矿机都物理托管了，那基本没办法了。但如果只是加入矿池的话，其实我记得这几年也有提出新的挖矿协议，像 stratumV2 、betterhash 之类，印象里可以让矿工在加入矿池的同时也连接自己的全节点验证交易，而不是盲目执行矿池下发的任务。但毕竟矿工只是想赚钱，切到新协议的动机貌似不太强烈。

另外“当前所有帐户余额”也就是 UTXO 集合其实也是有提出 UtreeXO 等办法来大幅缩减存储空间需求的，当然也有代价，我记得就是运行时需要消耗更多带宽。

如果问是不是可以让全节点不要从头下载整条链，只从最近某个时间点开始下载，理论上可以，但跳过不下载不验证=盲信，所以有一定争议，不过我记得其实最近几年 BTC 也在搞 assumeutxo 。

另外如果发生了“链重组”，也就是出现了新的、积累工作量更多（而不是单纯“更长”）的链，然后每一个全节点就需要各自回滚撤销旧链的交易、转头跟随新的链，那么很显然如果重组掉的区块太多（也就是太深）那也会无米之炊。但比特币运转至今极少发生比较深的链重组。我记得只有很多年前出现软件故障的时候发生过比较深的重组，即便如此也只影响了几十个区块，也就是几个小时内容的账本。现在开启修剪限制最少需要保留 550MB 的区块，即便每个区块 2MB ，按每天约 144 个区块也是差不多 2 天的量了。

网络里总得有节点保存下完整的账本，否则新节点就彻底无米之炊没办法从头下载验证了。

（如果问是不是可以各自只保存一小部分，然后让新节点自己拼起来，我估计也可以，但一直以来貌似都没实现这个功能，可能实际意义不大或者可能存在一些问题）

比特币的修剪不是白皮书里的修剪，白皮书里的修剪基本没什么现实意义。

实际上全节点会维护一个 UTXO 集合数据库，里面相当于是“每一个账户当前的余额”，然后一个个区块就相当于一页页账本也就是“转账记录”，根据 UTXO 集合可以验证下载回来的区块（是否花掉了不存在的币、是否花掉了不属于自己的币），验证完成后再更新 UTXO 集合的内容。
只要 UTXO 集合更新了，验证后续的区块就不需要再读取先前的区块了，所以老区块可以直接丢弃删除，这个就是实际上全节点执行的修剪。

所以说开启修剪的全节点其实也是验证过完整的账本，并且有能力持续跟进更新并验证新区块的。

但很显然删掉的区块没办法恢复，所以开启修剪后就没办法帮助新上线的节点从头下载验证。

@jworg BIP44/49/84/86 等规定了几个 purpose 的含义，SLIP44 里有登记 coin_type ，address_index 在 BIP44 里也有 gap limit 约束。
不过这些很显然都不可能有强制约束力。

@SuperXRay 啊，如果你的意思是“在云相册里找到了另一个完全不一样的助记词”那就和我 19 楼说的完全无关。我在 19 楼说的是不小心搞错一两个单词这种。

@SuperXRay 云相册……额，有些钱包会反复劝诫用户不要这么做来着。

另外这其实也涉及 BIP39 另一个被诟病的地方，就是它的 checksum 太短了，12 单词只含有 4bit ，输错的时候有 1/16 的几率会把错的当成对的。24 单词有 8bit ，相对好了一些。

BTC 这边 BIP44/49/84/86 分别规定了 1/3/bc1q/bc1p 开头的 P2PKH/P2SH-P2WPKH/P2WPKH/P2TR 这几种地址类型的 derivation path 。
但其实 BIP44 诞生貌似比较晚，之前有钱包已经用了不符合 BIP44 的 path ，比如 bread wallet 。

而且还有其他钱包开发者制订的新助记词格式和 BIP39 共用同一套单词表，而且没有回避 BIP39 的校验规则。有比较小（但仍然可观）的几率会出现本来生成的不是 BIP39 ，但也能当 BIP39 用的助记词。

印象里这个问题闹地蛮僵的，历史遗留是一方面，开发者意见不合且拒绝妥协是另一方面。

还有，BIP44 是有规定 gap limit 的，也就是在某个位置（比如第 4 个地址）继续往后推导后续地址的个数是有限制的。这也很容易理解，因为你恢复钱包的时候，只给了一个助记词，又没告诉钱包软件你用过的是第 xx-xx 号地址，所以只能靠预先约定一个限制。
但实际上貌似挺多时候都可能超过这个限制（比如有些钱包软件无视这个限制，或者自己用 ian coleman 的工具之类自己推算）。还是满蛋疼的。

“同一个助记词不需要重新备份 [和] 修改即可支持新币种”——改正一下

基本没用过 metamask ，不过忍不住想挖个坟

BIP39 本身只是助记词标准，它被很多开发者抵制（是的，尤其是 bitcoin core 这边）的一大原因就是：
它只是一个 seed ，不包含或者说涉及后续的 derivation path 。

这个设计的好处就是同一个助记词不需要重新备份会修改即可支持新币种，
或者同一币种的新地址类型，比如：BTC 这边主要 3 种常用的，1 开头的 P2PKH 、3 开头的 P2SH-P2WPKH 和 bc1q 开头的 P2WPKH ，以后 bc1p 开头的 P2TR 也会越来越多。

@jiyan5 会降频（ throttle ）的。
之前还用过一个软件 throttlestop ，目的和你想的相反是阻止降频。