微支付通道

预设一个背景:

1. 现在的比特币网络每秒钟最多处理6到7笔交易，并且每笔交易还需要手续费。
2. 如果每天去咖啡店喝咖啡都用比特币来支付，那么每一笔交易产生的手续费可能比咖啡本身还贵。
3. 而微支付通道就是为了解决金融服务高频小额交易中存在手续费过高的问题产生的

运行机制

A和B存在一个比特币的微支付通道，A是消费者，B是店家

1. A生成一笔UTXO交易T_x1，交易到1个公共账号上面（这个公共账号同时需要A,B的公钥），解锁条件是A，B两人的签名（一般是多重签名），称Tx₁为锁定交易（Funding Transaction）。
   ps：这笔钱，需要A,B两个人同时出具私钥，才能把钱取出来。

2. A再生成一笔时延的UTXO交易T_x2，交易的输入是Tx₁，交易的输出是A的比特币地址，称Tx₂为赎回交易（Refund Transaction）。

3. A将Tx₂发给B，B将其进行签名发回给A，A再对Tx₂签名后将==Tx₁和Tx₂==发布在比特币网络上。

4. 此后每次进行实时支付时，A只需要生成一笔交易Tx_n（n>2），Tx_n的输入时最初的锁定交易Tx₁，交易的输出是A和B各自应得的余额分配，同时设置时延为Tx₁，Tx₁<T₀.（updated Transaction）

A对支付交易Tx_n签名后发给B，B不需要发布到链上。以后每次进行支付时，只需要更新这些链下的交易即可。当交易终止时，B把最近的一笔交易发布在链上即可获得自身应收的比特币。

---

巧妙之处

整个过程，我们会看到，只有Step1的Funding Transaction和Step4的Settlement Transaction会广播到网络上，1头1尾，2个交易。

---

如何避免B跑路，A的钱永远锁死在公共账号里面？

在step1里面，A把钱打到了1个公共账号上面。如果B跑了，A的钱不是永远提不出来了？

实际不是这样操作的：实际是，A会等到Step2里面，拿到Refunding Transaction之后，A才会把Step1里面的Transaction发给B，同时广播到网络上面。

Refunding Transaction就相当于A攒在手里的，B的把柄。A不用把这个交易广播出去，等到B跑路了，再拿出来广播到网络上。

---

如何避免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就不会被执行了。

---

如何避免B篡改交易内容，比如调大给自己的分成比例？

任何1笔交易里面，都是先让B签名，再返回给A，A再签名，再发给B。

每笔交易里面都有A,B的双重签名，B改了交易内容，和A的签名就对不上了，反过来，A改了交易内容，就和B的签名对不上了。

所以A,B都不可能更改篡改交易内容！！

---

如何防止A双花这笔钱？

在Step2里面，A拿到了Refund Transaction，A把这个交易广播到网络上，拿回这100元，再花到别处呢？

做不到。因为Refund Transaction有nLockTime，处于锁定状态。并且这个nLockTime > 后面的任何1笔updated Transaction的值。

---

微支付通道的缺点

上面说的微支付通道，解决了A给B转账的，大量小额交易问题，但它也有几个缺点：

（1）它是单向的，只能用来A给B转账。如果反过来，需要另外再建立1个B到A的通道。

（2）nLockTime的限制。假设B跑路了，A也要等到Refund Transaction的nLockTime到期了，才能拿回自己的钱；同样，假设A跑路了，B也要等到updated Transaction的nLockTime到期了，拿到属于自己的钱。

---

改进 --> 闪电网络