比特币内部怎样记账，钱包显示多少位小数，小额付款是否实用，是三个不同的问题。2009—2011 年，中本聪在邮件与论坛中分别谈过。以下按主题汇集相关原话。
金额要落在人们熟悉的范围里
2011 年，中本聪向 Mike Hearn 解释选择币量时的考虑，也谈到数字大小给人的直观感受。
我希望常见金额落在人们熟悉的范围内。如果动不动就用 100000 个单位，就不会让人觉得稀缺。大脑更擅长处理 0.01 到 1000 之间的数字。
内部保留八位，界面只显示两位
他先在邮件中说明内部的整数表示，后来又在论坛解释：界面上没有显示的小数位，内部仍然保留。
金额用 64 位整数表示，保留 8 位小数，所以 1 个币在内部表示为 100000000。如果通常的价格变得很小，仍有足够细的精度。
不过不用担心，目前还有 6 位小数没有显示，系统内部总共保留 8 位小数。界面显示 1.00，内部实际记录的是 1.00000000。如果未来出现大规模通缩，软件可以显示更多小数位。
移动小数点，金额不变
2009 年的邮件、2010 年的论坛回复和 2011 年的通信，都提出过调整显示单位。这里改变的是金额的写法，持有者的余额价值不会因此增加，也没有增发。
例如，如果 0.001 值 1 欧元，改变小数点的显示位置可能更方便：你如果有 1 个比特币，就显示为 1000，而 0.001 则显示为 1。
如果小数太小、使用起来不方便，我们可以调整小数点的显示位置。钱的总量不变，改变的只是逗号和小数点的位置约定。比如把小数点向右移动 3 位，原来的 1.00000 就会显示成 1,000.00。
如果它发展得特别大，小数点可以移动两位，让“分”成为新的币。
预留的精度，当时不急着用
2010 年 9 月，他不鼓励使用额外的小数位，并指出当时接收方的界面不会完整显示这些金额。这是对当时软件的说明。
我不建议使用那些额外的小数位。它们只是为将来预留的。
你说得对，高于 0.01 的金额仍然能带额外精度，但接收方看不到。UI 会向下舍入后显示。
微支付还要考虑处理成本
在讨论极小额交易与洪泛攻击时，中本聪把微支付的可行性与存储、带宽、客户端模式和手续费联系起来。下文的时间预期与 0.01 手续费，都是 2010 年的判断或设想。
忘了补充微支付有利的一面。虽然我认为 Bitcoin 目前对更小额的微支付不实用，但随着存储和带宽成本持续下降，它最终会变得实用。如果 Bitcoin 大规模流行，到那时也许已经是这样了。让这类微支付更实用的另一个办法，是实现纯客户端模式（client-only），并让网络节点集中到数量较少的专业服务器集群中。无论你需要多小面额的微支付，最终都会实用。我想 5 年或 10 年后，带宽和存储都会显得微不足道。
如果有人开始通过大量来回转账的垃圾交易对我们发动 DoS 攻击，你就需要开始支付 0.01 的最低手续费了。0.1.5 其实有过设置它的选项，但我为了减少困惑把它拿掉了。免费交易是件好事，只要大家不滥用，我们可以一直这样。
读完这几段原话
这些发言把单位、精度和成本分得很清楚：显示单位可以调整，金额不会凭空增加；内部有八位小数，不代表界面必须全部显示；能记录很小的金额，也不代表处理这笔付款没有成本。