BIP48 我搜了一下，好像并不是真正官方分配的 BIP 提案号码？只是 Trezor 等钱包用来指代一种多重签名的 HD 路径之类的协议吧。（话说助记词格式大战还不涉及多重签名呢，多重签名貌似也是没有统一的标准）

可能很多年前币圈里 BTC 对其他山寨币的态度还不是很坏，于是 BIP39 结合 BIP44 能一个助记词搞定多个币种，这个功能还是蛮有市场的。
现在呢……BTC 圈子自己都经常自称 toxic maximalist，对山寨币是很排斥的，于是支持多币种反倒还可能成为一种原罪（笑）。

个人看法，Electrum 为了抵制 BIP39，自己把 BIP39 又魔改出来一种长得很像、技术上也存在混淆的助记词格式（英文单词表是一模一样的同一份，而且还有千分之一到百分之一量级的概率会生成出“二义性”的助记词，按照 BIP39 和 Electrum 的 checksum 检验规则都是有效的），美其名曰是“解决 BIP39 设计上缺失标准 HD 派生路径的问题”（ Electrum 规定了一套版本号系统，这个版本号是通过类似虚荣地址挖矿的方式嵌入到助记词里的，然后版本号就和他们规定的标准 HD 派生路径绑定了），实际上这不仅没有解决问题，反而让整个生态更混沌，让问题更恶化。

另外……我也忍不住想放个暴论：其实我（而且貌似不只是我一个人？）经常感觉，可能 HD 钱包本身就是过度设计的产物，只是听起来很好很强大很厉害，但实际上带来的隐私性好处还是很有限的（而且大多数用户应该都会把 xpub 直接交给钱包服务器，这样一来地址一用一换的隐私优势至少在钱包服务器面前是荡然无存的），反倒是大大增加了钱包的复杂度。

抵制 BIP39 最大的理由，其实也是它最大的功能特点：一个种子就可以支持所有的币种，包括像 BTC 的 N 种不同地址格式，未来出现更多新币种 /新地址格式也不怕，所以 BIP39 助记词是“一劳永逸”的，一个备份可以一直用下去。

这确实很方便，但另一方面，这样不限制种子的用途，就会带来混乱。

具体来说，从 HD 种子派生出收款和找零地址，需要指定一个“派生路径”——找错了派生路径，就会生成之前没用过的陌生地址，于是就会出现“欸，这个助记词上面有币啊，怎么导入到钱包里余额是 0 呢”的问题。

更蛋疼的是，貌似 BIP44 这个规定标准派生路径的规范，出现时间又比 BIP39 迟了不少。
有些钱包，比如 bread，在 BIP44 出来之前就开始用 BIP39 了，所以 bread 的 HD 派生路径到目前为止仍然是和 BIP44 不兼容的，简单说，就是 bread 导入到其他 BIP39/44 的钱包里，BTC 这个币种一般会出现余额为零、交易记录为空、地址全是没见过的陌生地址这个问题，反之亦然。

BIP39/44……对比特币来说出现确实不早，但也早就不是啥新鲜玩意了吧，不是“近两年”才出现的啊。

BIP39 规定的是 HD 种子助记词（严格来说是助记词单向哈希成种子，并不能混为一谈，不过这里不要在意那么多细节）的标准，现在也是“事实上的标准”，但是很多开发者，尤其是 Electrum，那么多年以来都一直抵制 BIP39 。

有些其他的币种也把 electrum 的代码给 fork 过去了……但和 electrum 官方没啥关系。

@wangkun025 electrum 是 BTC 单币种的

@KillPaul BCH 当然可以，但是 BCH 后来不是又分出来 BSV 么，这个需要注意一下，要拆分，避免重放。
（而且分出 BSV 后我记得又搞出 BCHABC 和 BCHN，现在的 BCH 是 BCHN，BCHABC 虽然是原来的领衔开发者搞的，但现在存在感就比较稀薄了）
为了防止导入私钥折腾钱包的时候出岔子，可以把高价值的币先转到安全的地方（新的、备份好的钱包），然后再折腾低价值的币。

（至于 nLocktime，没记错的话是这样：两种币的区块高度一般是存在差异的，其中一种挖的比另一种“快一些”、区块高度攒到更高。于是就可以在发出交易时设定 nLocktime，nLockTime 根据数值大小有两种解读方式，数值比较大就当作 UNIX 时间戳解读，比较小就当作区块高度解读，在指定高度之前交易不能打包。所以就可以设定一个相对现在很近的未来的 nLockTime，然后“跑得快”的 A 币先挖到指定的高度，可以打包确认，这样就把 A 币转到 X 地址； B 币因为“比较慢”，同一时间还没挖到指定的高度，交易还不能在 B 币网络打包，所以就可以再发一笔只转账 B 币交易，把 B 币转到 Y 地址）

（啊，关于 coinbase 重放保护……其实这里也并不存在什么“纯度”，两种币还是两种币，问题只不过是 A 币的交易同时在 B 币上也有效，然后也得到打包确认了而已。分叉后新挖出来的 A 币（ coinbase 币），在 B 币那边肯定是不存在的，所以才有 coinbase 重放保护这么一说。其实要避免重放、分离两种币，未必需要是矿工新挖出来的币，只要是 A 币这边认为合法、B 币那边认为不合法的交易都可以实现重放保护。“混入”A 种 coinbase 币的交易，后续肯定也都“继承”一样的性质。如果是用了其他手段来拆分，比如用 nLockTime 分别把 A 币和 B 币转入不同的两个地址 X 和 Y，那很显然 X 地址上只有 A 币、Y 地址上只有 B 币，后续同样也“继承”了这个已经分开的状态）

走不同 HD 推导路径其实是派生出了不同的新钱包，钱包之间当然是可以互相转账的，只不过转账后，很显然，该是钱包 1 交易记录还是钱包 1 的，钱包 1 的交易记录很显然不会跑到钱包 2 上。

HD 推导与文件夹不同的是，文件夹里的东西可以移动，HD 推导路径里的地址、余额、交易记录很显然是不能“移动”的。

HD 推导路径可以大致想象成像文件夹路径一样，找错路径，就会推导出和之前不同的地址，于是就看不到正确的余额和交易记录（一般是变成余额 0 、交易记录空白）。

1.bread wallet 是 BIP39 助记词，但 HD 推导路径不是 BIP44/49/84 （貌似是因为这些标准产生其实比 bread wallet 用 BIP39 还迟），这个需要注意。

2.分叉出来的两个币当然都继承原来的余额。
分叉前，同一个地址收到的币，现在变成两种币，这个很正常；
主要是分叉后产生的交易可能有问题。
这里有个概念“重放保护”，简单说就是分叉出来的其中一种币修改交易格式，故意破坏兼容性，然后才能井水不犯河水——否则，就会产生问题：A 币的交易会有意无意地跑到 B 币的网络里，然后 A 币和 B 币的矿工（未必是同时！所以也可以用 nLockTime 来避免重放、实现拆分）都各自打包到 A 链和 B 链里面。简单说，本来只想转账 A 币的，一不小心把 B 币也给转账了。
BCH 对 BTC 做了重放保护，所以 BTC 和 BCH 分离问题不大。主要是 BCH 后来分出 BSV 的时候没做重放保护，不过 BCH 的 Schnorr 签名功能应该可以起到重放保护的作用。（因为 BSV 那边拒绝实现 Schnorr 签名功能，只有 BCH 那边有这个功能；除了这个使用不兼容的功能，以及上文提到的 nLockTime 之外，还有一个办法就是找矿工要 coinbase 交易挖出来的“纯”币，分叉后的 coinbase 交易肯定是“纯”的币，所以混入“纯”A 币的交易在 B 币那边一定是非法的，不会被重放）

我印象里 ACINQ 公司的 Phoenix 钱包缓解了闪电网络的一些问题，比如备份无法一劳永逸——那就让服务器帮你备份；再比如通道管理麻烦，单方面出资打开通道后一开始不能收款——那就让服务器那边出资开通道，没有通道就现场开一个，而且链上还是零确认的时候就允许用户花掉通道里的资金。

Phoenix 这个“纯闪电网络钱包”算是很傻瓜了，差不多就是开箱即用，而且也仍然算是去中心化的，而不是中心化托管。

但是我记得 Phoenix 仍然不能真正实现离线收款，仍然是在手机上开了一个后台服务，有收款过来的时候就把 app 拉起来，这个有点遗憾。

@iloveayu 这……和我国应该没啥关系吧……我国对比特币的态度应该还是那样，虽然根本上还是认为比特币属于一种虚拟商品（所以在这个意义上合法，这方面我记得是有判例的），但给公众营造的印象还是“非法，别碰”，而且采取各种手段进行打击。

楼上有提到闪电网络（ lightning network ）……怎么说呢……
我的观点是这样：有一说一，闪电网络局限性蛮大的……不然的话 BTC 一直那么堵，秒速确认不拥堵的闪电网络为啥还一直不火呢……也就真爱粉会感觉“诶，秒速确认啊，不错不错，能用，甚至还蛮好用”；一般人感觉大概率是“什么辣鸡玩意儿，麻烦陷阱那么多，还动不动就失败，这压根不能用啊”。
（我之前就这么说过，现在也没改变看法，但最近我也没有非常关注这一块，也许有些信息没看到？）

我又去翻了一下 Malmi Martti 的博客文章，里面提到：
Sharing of static files in a peer-to-peer network is old and proven technology. However, maintaining and querying decentralized indexes — big dynamic datasets — is easier said than done.

其实我楼上提到的图片来源问题，是可以用以图搜图来解决的，归根到底还是要靠索引。
但是，Malmi Martti 在这里直接就说，去中心化的索引很难做……哎……

对于这个索引难题，Iris 貌似采取了最简单粗暴的做法：把所有东西在用户的设备里保存下来（额）
这……怎么说呢……

越攒越大的微信数据不就是让人头疼么……

（继续往后读，貌似 Malmi Martti 又提到这个其实是基于 Web of Trust 的 cluster 的，不过我不是很懂，貌似就是说，你关注 /信任了哪一群人，就把这群人之前发的所有东西下载回来，然后自己做一个索引？这样不能说没有好处，首先是隐私，本地看了啥不会在云端留下记录；其次是可以离线查看；但是劣势也很明显啊，那就是存储空间焦虑症啊）

我刚刚产生的一些想法：
1.如果一个人从中心化平台搬家了，他之前的发言记录、关注列表、收藏列表等等，应该可以无痛迁移过来（我看楼主貌似有考虑到无痛迁移问题，但不知道有没有考虑到从其他平台迁移过来的时候能不能无痛）；
2.这个人可以在去中心化新平台继续发帖，然后他不应该陷入自娱自乐的尴尬处境，所以，他新发的内容仍然需要被发送到中心化老平台，所以，那些停留在中心化老平台的懒癌用户仍然可以收到推送。
3.既然两个平台都可以看到一样的东西，那也应该有个机制能管理这个问题。贴吧里就有众所周知的图片被二压“绿化”，而且不知道原始来源的问题，为什么会产生这些问题，可以说归根到底是因为人懒，懒得去折腾保留原图原画质，也懒得去溯源。很多时候甚至还无法溯源。这方面也许还需要一个类似 wiki 这样人为标记维护的机制。