主链（包括BTC、BCH和BSV）进行小微支付，有两个问题，第一是矿工费太贵，和支付金额下限太高。BTC就不用说了。一个理想的小微支付，应该是支持超小的金额和超低的矿工费，比如可以发送1聪的金额，1聪/笔交易。但现在比特币网络都有防尘攻击的设定，最小支付金额是546聪，矿工费为最小1聪/字节，一笔交易至少为225聪。
小微支付的第二个问题是会对网络积压太多的历史交易。小微支付必然是数量巨大，肯定会远远超过现在的主链上的支付数量。网络是需要保存所有的历史交易的，每笔交易都至少225字节，巨大的交易会对网络造成巨大的硬件需求。这可能会伤害去中心化。
对于确认时间，小微支付并不敏感，接受零确认就好了。
BTC+闪电网络还需要进一步发展才可能解决小微支付，本文不对此做过多的评价。
能否构建这么一个方案：
1，不发新的币，而是在现有的比特币（无论是BTC、BCH还是BSV）构建一种新的交易格式，专门用来完成小微支付。
2，小微支付的历史记录可以被裁剪。
我们额外构建一种特殊的交易，使用软分叉的方式进行更新。
现在假定，所有的协议规则下，包括了P2PKH和P2SH这两种交易格式（只是举例，还有很多其他交易格式，这里为了描述方便做了假设）。现在要增加一种新的交易格式P2MP（Pay to Micro Payment）。
P2MP专门用于微支付，使用新的地址格式，交易金额默认为小于等于10000sat，大于0sat，矿工费默认为固定的每字节0.01sat（现有的百分之一）。

微支付区块使用扩展区块的设计，扩展区块设计请参见《扩展区块Github文档中文翻译》
在微支付区块内部的转账，应该非常容易实现。难点在于如何实现从主区块支付到微支付区块，以及如何从微支付区块支付到主区块。
在主区块的末尾设计一笔特殊的收集所有从主区块支付到微支付区块的交易，我们称之为主区块尾部coinbase（这和区块头部的挖矿奖励coinbase交易相对应）。尾部coinbase交易的输入（input）为所有进入微支付区块的交易的输入；尾部coinbase交易的输出是一笔特殊的锁定脚本，这个脚本的公钥部分留空，签名部分设计为满足特定条件就为true。这样的输出就类似于一个任何人都可以花费的UTXO。
    主区块coinbase尾部交易输出：
    scriptPubKey:     留空
    scriptSig:      特殊条件为True
每一个主区块的最新高度里的尾部coinbase交易的输入，都要包含上一个区块的尾部coinbase交易的输出。
最新高度主区块尾部coinbase的输出金额=上一个区块的尾部coinbase交易输出金额+进入微支付区块的金额-离开微支付区块的金额-微支付区块交易的矿工费
微支付区块里的第一笔交易，输入是留空的，这个和主区块的挖矿coinbase交易是一样的，输出是对应着从主区块所有进入微支付区块交易的输出。
主区块的尾部coinbase交易和微支付区块的头部coinbase交易，就形成一个桥接，把主区块里的币转移到了微支付区块。
而从微支付区块要支付到主区块，则按上面的过程，反过来。
微支付区块是可以抛弃的。验证区块时，微支付区块的存在与否不会影响主区块的验证，但验证微支付区块必须要拿到对应的主区块才能完成验证。这样的设计下，任何一个主区块，，哪怕是抛弃了微支付区块，也不会影响合法性，这样就可以让完整节点抛弃掉微支付区块。
可抛弃式微支付区块，让微支付形成的历史交易数据不对主网形成成本压力。
微支付区块里的交易可以设定一个时间，比如过了10万个区块，节点可以抛弃掉微支付区块。
微支付区块甚至可以设计成是账户制。账户制不会产生大量的细碎UTXO，每一次支付都是修改余额，而不是像UTXO这样删掉原来的UTXO，再生成新的UTXO。账户制甚至可以植入一个虚拟机，像和EOS那样，让比特币网络真正使用智能合约。
从技术实现角度上读，扩展区块的代码已经写好了，是基础bitcoin core0.13写的。是在2017年写好的。在这套代码上修改成微支付扩展区块，应该没有太大的难度。
就目前的技术发展来说，BTC、BCH和BSV有可能实现类似的方案吗？在技术发展路线上，BTC主要发展闪电网络来解决微支付场景。BSV不支持在主链上大做修改。BCH到不会在技术路线上设限，但这个理念还是没人提起。
可能是我想多了。