Coinbase成熟期：分开已发行与可花费比特币

这里的coinbase指区块中的奖励交易，不是同名交易所。它创建的输出有共识成熟期。因此，一笔比特币奖励可以已经存在于链上，却尚不能被纳入指定高度的交易花费。

比特币区块链指南说明了coinbase输出的100区块成熟条件。研究时要结合输出创建高度和拟花费交易所在区块高度。这个工作表只检查共识资格，不推断矿工所有权、利润或卖出意图。

用区块高度，不用日历猜测

逐个记录未花费奖励输出的创建高度h。若拟在H高度区块纳入花费，必须满足H−h≥100，并同时满足其他有效性条件。H应定义清楚：当前链顶T的状态快照，与判断下一块能否纳入，并不是完全相同的问题。

如果检查下一块，采用H＝T＋1。按这个约定，创建于1000高度的输出，最早可在1100高度区块被花费。不能因为仪表盘把经过时间四舍五入为一天，就说1099高度已经可花费。规则数的是区块，不是小时。

数量也应与“流通”“流动”标签分开。数据商可能对矿工奖励使用自己的供应分类，而共识成熟性是更窄、可以复算的属性。私钥遗失属于另一种限制，不能从成熟条件推断。

假设虚构矿工拥有两个未花费奖励输出：1000高度创建3.2 BTC，1050高度创建3.3 BTC。金额是假设补贴与手续费合计，不代表当前真实区块奖励。

拟纳入高度	第一输出	第二输出	满足成熟条件金额
1099	未成熟	未成熟	0 BTC
1100	成熟	未成熟	3.2 BTC
1150	成熟	成熟	6.5 BTC

在两者全部成熟之前，6.5 BTC已经存在于虚构库存中；到1100高度，只有第一笔3.2 BTC通过此项条件。其他脚本和访问条件还要另查。“成熟”不能翻译成已经卖出、完全无限制或已进入交易所。

如果第一输出随后被花费，应从未花费库存中移除，不能永久留在成熟余额里。产生的新普通输出有自己的脚本与历史，不会仅因来源是挖矿奖励，就自动重新开始100区块成熟期。

建立未成熟未花费、已成熟未花费、已经花费三个桶。新奖励加入第一个桶，H推进后符合条件的转入第二个桶，实际花费从库存扣除。钱包转账不属于再次发行。

高度之外保留区块哈希。如果奖励区块从选定链中移除，旧输出不能继续按原高度留在库存。重跑时要删除或重新连接受影响记录。钱包展示的确认数可能采用不同表达习惯，应在边界高度逐项验证，而不是只看一句“100确认”。

如果进一步研究矿工可用资金，应在成熟调节后，再加入独立验证的托管、合同和钱包控制限制。数据商的可用余额若已排除未成熟部分，就不能再次扣除同一笔。最终明确是奖励库存、成熟调整金额，还是实际可访问余额。

这个日程只能解释一项限制何时满足，不能预测矿工资金需求、出售或价格压力。链选择改变、新的花费证据出现时，应重新计算。

奖励中的补贴与被纳入的手续费，如果支付在同一coinbase输出中，应按该输出一起检查成熟性。不能因为手续费原本来自已有比特币，就提前把费用部分算成可花。反过来，矿工另行收到普通转账，也不会只因收款人从事挖矿就变成coinbase奖励。分类应依据创建交易，而不是地址标签。

不是。本文专指比特币区块奖励输出的共识花费条件，与同名交易所无关。

不等于。出块间隔会变化，应使用创建高度及拟纳入高度，不承诺固定日历时间。