还是想办法把尾插修好吧，不然万一碰到问题了你也没救砖的手段。

B 站又是哪个？

K40 就有过随机重启的问题，LineageOS 都为了这个打过内核补丁，屏蔽掉基带崩溃触发的 kernel panic 。不过有一说一这个毛病也并不是小米这一家有，同芯片平台的其他厂牌也有，可能算高通的锅吧。

原来楼主想要的是虚拟机……
不过一直不太明白安卓虚拟机的原理，好像有些是类似 fakeroot 那种，也有类似 gvisor 的

事件查看器里筛选出事件 id 1001 我记得就是蓝屏记录
bluescreenview 我记得也可以看到蓝屏 dump 里的一些信息

几小时一次……是什么代码？不会是 critical_structure_corruption 吧

PE 没用过。
我的红米 K40 刷的 LineageOS ，微信指纹之前已经整合了 soter 所以一直没问题，升级 LOS18.1 后因为 SELinux 阻挡有一阵子不能用，然后修了这个问题就好了。
支付宝指纹是更早修的，setprop 一个属性就好了。

另外 bitcoin core 默认是开启 RBF 的，而且以后 mempoolfullrbf 也要普及了，然后其实可以用 RBF 来追加手续费，相比直接找矿池加速一般会便宜不少。

除了一楼提到的矿池可能优先打包自己家的交易，矿工也是按照手续费除以 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 集合更新了，验证后续的区块就不需要再读取先前的区块了，所以老区块可以直接丢弃删除，这个就是实际上全节点执行的修剪。

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

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