第13课 微支付通道（MicroPayment Channel) -- 迄今为止最透彻的讲解了

有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取原文。
或扫描如下二维码：

这1课很关键，微支付通道将是后面闪电网络、隔离见证的基础，微支付通道不能搞透彻，后面的闪电网络、隔离见证就更晕菜了。

问题的提出
在前面第3课 “区块链”到底长什么样？我们说过，现在的比特币网络每秒钟最多处理6到7笔交易，并且每笔交易还需要手续费。

如果买卖双方有大量的小额交易，微额交易，比如1个宽带提供商向外提供带宽服务，按小时付费。那大量的小额交易，不仅会让比特币网络负担沉重，而且手续费也不划算。

所以有人就提出了，在买卖双方，建立1个支付通道，专门支持双方的小额支付，不需要经过比特币网络。这个通道除了建立、关闭的时候，要和比特币网络通信，其他时间，都是双方点到点的通信。

问题的难点
我们知道，比特币网络至所以是可靠的、值得信任的，1个很重要的原因是因为每笔交易都是公开的，每1笔交易都是on-chain，都会得到网络上每个节点的认可，所以交易的任何1方没办法反悔、抵赖。

现在你要搞链下交易，off-chain Transaction，交易只有你们俩自己知道，没有了区块链网络这个信任的第3方，怎么保证交易的1方不会反悔、抵赖？

这个问题很有意思，接下来我们看看，微支付通道是如何解决这个问题的。

nLockTime
在第12课 nLockTime(CLTV)与Sequence number(CSV)，介绍了Transaction数据结构里面的1个关键属性。微支付通道的建立，必须依赖这个属性。下面就看一下这个过程是怎么建立的。

微支付通道建立过程
考虑如下场景：A是用户，B是一个数据提供商，B需要把1个100G的大数据文件发给A，价值是100元。

为了降低风险，A不想1次性把100元给B，而是每接收到1G的数据，给B支付1元。

那就需要100次的交易。现在看一下，微支付通道如何解决这个问题：

Step1:
用户A发起1笔交易，把100元打到1个公共账号上面（这个公共账号同时需要A,B的公钥，也就是前面所说的多重签名）。这笔钱，需要A,B2个人同时出具私钥，才能把钱取出来。这笔交易叫做保证金交易（Funding Transaction）。

Step2:
以此同时，用户A发起1笔退款交易（Refund Transaction）。这笔退款交易的输入，就是Step1里面的交易，其目的是把Step1里面的100元，再返回给用户A。这笔交易的nLockTime为一个>0的值，也就是该笔交易是Hold在那的，不会立即生效。
具体怎么做呢？ 用户A先把这笔交易发给B，让B用B的死钥签名（也就是写在scriptSig里面），再返回给A，A把这个Refund Transaction 攒在手上，这笔交易其实是A的一个保底的措施，保证前面的100元不会永远拿不回来。

Step3:
我们知道，在Step2的Refund Transaction里面，有2个输出：A，100元；B，0元。
现在把Step2的Refund Transaction拷贝1份，调整一下输出：A, 99元；B, 1元。也就是付给B1元。
然后A把这个交易发给B，B保留这个交易，不广播到网络上。

等A收到B的新的1G文件之后，重新调整输出，变成： A，98；B，2元。A,B重新签名，A再把这个交易发给B。

如此，不断继续下去：
A: 98，B，2；
A：97，B，3；
。。
A：1， 99。

这些交易，称为updated Transaction(或者叫做Commitment Transaction)，只会在A,B之间传递，不会广播到网络上。

Step4:
等A收到最后的1个G的文件，发起1个Settlement Transaction。这里交易里面，
A：0元， B：100元。
其nLockTime = 0，B收到这个交易，广播到网络上，交易立即生效，B收到100元。

微支付通道的巧妙之处
（1）整个过程，我们会看到，只有Step1的Funding Transaction和Step4的Settlement Transaction会广播到网络上，1头1尾，2个交易。

（2）如何避免B跑路，A的钱永远锁死在公共账号里面？
在第1步里面，A把钱打到了1个公共账号上面。如果B跑了，A的钱不是永远提不出来了？实际不是这样操作的：实际是，A会等到Step2里面，拿到Refunding Transaction之后，A才会把Step1里面的Transaction发给B，同时广播到网络上面。
Refunding Transaction就相当于A攒在手里的，B的把柄。A不用把这个交易广播出去，等到B跑路了，再拿出来广播到网络上。

（3）如何避免A跑路，B拿不到自己的钱？
在Step3里面，每个update Transaction，都有A,B共同的签名。如果A跑路了，B就把最新的update Transaction广播到网络上，该交易被执行，B就会拿到最新的钱。
update Transaction，就相当于B攒在手里的，A的把柄。
update transaction有个特点，每1次update transaction的nLockTime，都是逐级减小的，所以B把最新的update transaction广播到网络上之后，肯定会被最先打包，最先执行。先前其他的update transaction就不会被执行了。

（4）如何避免B篡改交易内容，比如调大给自己的分成比例？
任何1笔交易里面，都是先让B签名，再返回给A，A再签名，再发给B。
每笔交易里面都有A,B的双重签名，B改了交易内容，和A的签名就对不上了，反过来，A改了交易内容，就和B的签名对不上了。
所以A,B都不可能更改篡改交易内容！！

（5）如何防止A双花这笔钱？
在Step2里面，A拿到了Refund Transaction，A把这个交易广播到网络上，拿回这100元，再花到别处呢？
做不到。因为Refund Transaction有nLockTime，处于锁定状态。并且这个nLockTime > 后面的任何1笔updated Transaction的值。

说到这，我们就明白了，A,B如何做到在off-chain的情况下，保证双方都没办法反悔、抵赖交易：
A手上拿的有B的把柄，B手上拿的有A的把柄。任何1方中途中断，另我1方，把这个把柄广播到区块链网络，就可以执行合约，拿到属于自己的钱。

微支付通道的缺点
上面说的微支付通道，解决了A给B转账的，大量小额交易问题，但它也有几个缺点：
（1）它是单向的，只能用来A给B转账。如果反过来，需要另外再建立1个B到A的通道。
（2）nLockTime的限制。假设B跑路了，A也要等到Refund Transaction的nLockTime到期了，才能拿回自己的钱；同样，假设A跑路了，B也要等到updated Transaction的nLockTime到期了，拿到属于自己的钱。

这些问题都如何解决呢，这就要看接下来的“闪电网络”了。

相关链接：
《第12课 nLockTime(CLTV)与Sequence number(CSV)》
《第11课 账号被黑客盗取怎么办？ – 多重签名(MultiSig)与P2SH》
《第10课 交易安全性如何保证？ – scriptSig/scriptPubKey/Script Engine》