比特币专题汇总减半、ETF、挖矿、钱包、转账与风险等主题，构成围绕比特币的完整内容集群，帮助你由浅入深地理解比特币的运作与生态。
共 942 篇 · 第 11 / 95 页
v29.0 起，比特币核心提供两段式历史对账：scanblocks 先圈出可能相关的区块，getdescriptoractivity 再把每个区块拆成 spend 与 receive 事件列表，带金额、出处 prevout、脚本和确认高度，未确认活动靠字段省略来标识。它不需要常驻索引，但帮助文本明说可能跑上几分钟。本文按 v31.1 源码拆解两组必填参数、返回结构与超时处理。
读区块高度的 BIP 34 压入、挖池 extranonce、版本滚动，以前要把 verbosity 2 的整个交易数组拖回来，v31.0 起 getblock 在 verbosity 1 就返回 coinbase_tx 对象：version、locktime、第一个输入的 sequence、scriptSig 十六进制和单元素见证栈共五个字段。本文按 v31.1 源码逐字段拆解这张精简档案能查什么、不能查什么。
assumeUTXO 快照同步期间，比特币节点内部同时存在快照链与回填验证链两本账，getblockchaininfo 只汇报活动一条，getchainstates 会把全部链状态按工作量排列列出：各自的进度、难度、缓存拆分，以及标记快照血统的 snapshot_blockhash 和补课完成的 validated 布尔值。本文按 v31.1 源码给出双账阶段的监控判据。
比特币核心 v31.0 里，节点收到区块或区块头时并不直接入库，还要先看调用方有没有做过反消耗战的工作量检查。本文拆解 min_pow_checked 参数的三种取值路径、GetAntiDoSWorkThreshold 留 144 个区块余量的算法，以及 too-little-chainwork 为什么不会连累你的对端被处罚。
重复广播同一笔交易时，比特币核心 v31.0 不一定去磁盘上追根究底，而是先拿这笔交易自己会产生的输出点去问一遍内存缓存，命中就直接返回冲突类的 txn-already-known。本文讲清这条快路径的判定顺序、它只查缓存带来的覆盖面缺口，以及它与输入缺失类报错在处置动作上的分工。
父交易还没到，和引用的输出已经被别人花掉，在比特币核心 v31.0 里共用同一个拒绝代号 bad-txns-inputs-missingorspent。本文从源码出发说明节点为什么不做区分、TX_MISSING_INPUTS 如何让交易获得留在孤儿交易库的资格，以及钱包和自建服务应按什么顺序排查这一类广播失败。
带相对时间锁的交易进不了内存池，节点给的代号是 non-BIP68-final。比特币核心 v31.0 的判定函数直接用链顶高度加一作为参照，因为内存池里放的应该是下一个块就能采纳的交易。本文对照区块层的 bad-txns-nonfinal，讲清绝对锁与相对锁两套代号的分工，以及写相对锁时最容易贴错边界的地方。
比特币核心 v31.0 在标准性检查里逐项核对见证区的形状：币基交易跳过、空见证放过、非见证脚本不许带见证、P2WSH 有脚本长度与栈项数量上限、Taproot 的附项一律视为非标准。撞上任一条就返回 bad-witness-nonstandard。本文按源码分支列出判据，并给出排查这类失败时最省时间的顺序。
比特币核心 v31 把内存池的条数与体积限额从祖先后代链换成交易簇，随之而来的是新代号 too-large-cluster。它在源码里出现在四处，返回类别分为交易级策略与整包策略两种，处置动作完全不同。本文对齐新旧参数、默认值与硬上限，并解释为什么这项检查必须放在替换登记之后。
链顶切换后节点会主动向邻居通报新块，但比特币核心 v31.0 给这件事设了上限：一次最多八个区块哈希，超了就依靠对端自己的同步机制。本文沿源码讲清通告数量是怎么截断的、为什么初始同步阶段完全不中继、队列里为什么要反向插入，以及 headers 消息与 inv 公告两种通告形式的分工。
