中本聪的错误：比特币产量减半为什么是32次？
在24号文章（《摩根大通CEO吉米·戴蒙质疑比特币2100万枚上限的道理和错误》刘教链，2023.1.24）里介绍和引用了比特币源代码中关于减半的代码片段：
代码结束
为了方便阅读和理解，笔者给每行代码添加了行号，并在每行代码的下方逐行添加了解释。
这里面有一个小细节，不仔细看可能就忽略过去了，仔细看了可能会产生困惑。
这个问题就是，比特币总共减半多少次？64次？还是32次？
我们经常听到的说法就是比特币总共要经过32次产量减半。每次间隔大约4年，那么挖矿时间总共就是(32 + 1) * 4 = 132年。
从2009.1.3开始，挖矿132年，到2141年初就采光了，也就是说，不再有额外的区块奖励或者叫区块补贴了。
自此之后，矿工将必须依靠用户交易转账支付的手续费来维持矿机的运行。比特币将达到其设计发行总量上限，不再增发。
这就是坊间传说的2140年是比特币最后一个挖矿年的由来。
但是深究一下代码，发现代码里写的减半数上限，居然并不是32（或者说33），而是64：
如果减半数大于等于64
这又是怎么回事呢？
说到这里要提到一个很有趣的往事。第05行和第06行代码其实在中本聪的原始代码里是没有的。
是的，中本聪在这里犯了一个编码上的错误。换句话说，他在这里留下了一个bug。一个240多年以后才会出现的bug。
这些小细节也向我们表明，中本聪是人，不是神。
如果大家对C++中的右移位运算符的规则有所了解的话，就会知道，当右移位的位数超过了被操作的整数的总位数之后，它就会开始循环了。
也就是说，当移位数增加到65的时候，第10行 nSubsidy >>= 65 会相当于 nSubsidy >>= 1，也即是回到了当初的第一次减半后25个BTC的区块奖励。
这显然是个今天不会发生，但是未来如果不加以修复就会导致共识崩溃的万分重要却又相当不紧急的bug。
好在比特币的开源是一个无比明智的决定。
比特币的社区开发者ditto-b等人发现了这个bug。
2014年3月14号，他提交了修复方案。（https://github.com/bitcoin/bitcoin/pull/3842 ）
从当时的交流中，我们还能看到更多不为人知的小插曲。
Wladimir van der Laan (laanwj)，今天bitcoin-core代码维护的领导者，针对这个bug修复方案提问说，看起来右移位32次以上就会归零了，超过64看起来也是安全的吧。
他@了当时还在负责领导代码维护工作的Gavin Andresen (gavinandresen)，也就是中本聪的衣钵传人，说，我们会合并这个方案还是不合并呢？看起来代码是安全的，但是我不想自作主张。
后面其他多位开发者指出了他的错误：C++右移位操作是会循环移位的。这会给今天的代码阅读者造成错觉，以为比特币是循环无限增发的；并且会给未来的人们造成可能的bug，因为随着时间的推移，大家可能越来越难以就修复bug达成一致意见。
最终大家决定采纳这个修复方案。
好了，插曲讲完了。
问题的答案，往往就隐藏在明面的文字里。
Wladimir van der laan已经指出来了这个答案，那就是比特币减半代码这里隐藏的有效减半数，其实只有32次。
匆匆忙忙的中本聪，没有做任何边界条件的检查。这是几乎每一个写过程序代码的人都曾经犯过的错误，只是程度大小不同罢了。
那么为什么说有效减半数只有32次呢？
因为：（1）比特币的起始区块奖励是50个BTC；（2）BTC的最小精度是1亿分之一，也就是后人所谓的“1聪”；（3）比特币代码中，整数是用64位二进制来表示的。
50个BTC用整数表示就是：50 * 1亿 = 50 * 100000000 = 5000000000 聪。
5000000000用二进制表示就是100101010000001011111001000000000。这个数只有33位。
这意味着，补齐到64位正整数最高位都要填充0，也就是这个样子：
0000000000000000000000000000000100101010000001011111001000000000
当130多年过去，2140年比特币的矿工们又高高兴兴地挖了一整年矿之后，2141年初比特币第33次产量减半，这个数字向右移33位，就会变成0。也就意味着不再有新的区块奖励了。
比特币永久停止增发，总量达至设计上限约2100万枚BTC。
这就是比特币32次有效减半的真实原因。