微支付通道

前面写了闪电网络，了解闪电网络之前需要先了解微支付通道，之前没有写，现在补充一下。

 微支付通道建立过程

考虑如下场景：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到期了，拿到属于自己的钱。

 

 

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