本文共11806?字
推荐阅读时间?30?分钟
TL；DR
闪电网络是集大成者，是天时地利人和的产物
闪电网络的前辈们或多或少都需要对BTC底层进行改动，导致他们始终无法良好运行
现在为人们所熟知的是BasisofLightningTechnology
19年以后闪电网络基础设施日益成熟，后续的发展围绕优化和生态建设为主
提到闪电网络，绝大多数人对它的了解还只是听过这个名字，或者稍微了解多一些的人知道它的一些基本原理。但是我们需要思考一个问题：闪电网络的概念是一夜成名的还是集大成者？哪怕仅凭直觉来看，我们也认为是后者。但是，它集成了哪些大成？在它之前的那些设想为什么没有发展起来？这就需要我们回顾下闪电网络的发展历史。而从闪电网络的组成中，我们不难发现，它的核心是paymentchannel和由此组成的paymentnetwork。那么，我们今天就再次回顾下这些值得被铭记的英雄。
PaymentChannel——BTC代码里的种子
闪电网络集的大成之一就是支付通道。这个从直觉上理解也没有什么问题。毕竟想要组成点对点的支付网络，首先要解决的是点对点之间的支付问题。
支付通道的核心思路就是在两个比特币账户之间建立一个通道，这两个地址的余额关系只用他们两个人知道就好，并不需要上链，一直到双方愿意结算的时候广播一笔交易到链上即可。
之所以说它是现在闪电网络的”种子“，是因为它的理念和BTC诞生一样早。在Bicoin0.1版本就包含了支付通道的代码草稿,即允许用户在交易被网络确认前更新这笔交易。
图片来源：https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434
当然，通过这个代码构建的方案还很初级，不过中本聪后来跟bitcoinj开发者MikeHearn私聊了更多支付通道的细节，并且在2013年，Hearn公开了中本聪对支付通道的解释
图片来源：https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/13/
总结起来就是：如果一个交易还在交易池中没有被打包，应该可以让用户发送一个新的交易，这个交易的序列号应该比旧交易的序列号要高，矿工就应该优先打包序列号高的交易。这样就能让一个人不停的给另一个人发送交易，更新序列号，矿工只用打包序列号最大的交易即可。
同时，这里面涉及的一些概念，诸如：
nLocktime，BTC交易里的一个字段。任何包含了这个字段的交易，如果该字段的值是一个有意义的值，比如1000个区块，，那么该交易只能在1000个区块后才能被打包。
signaturehash
……
启发一堆大佬开启了后续的一系列尝试。
Hashcoin——第一个可用支付通道的构想
但是我们可以发现在这份初级的解释中，很难避免双花的问题，也就是很难做到无需信任。假设支付通道中的某个用户和矿工合谋让区块确认一个对自己有利的旧交易，那么就可以让别人蒙受损失，自己和矿工受益。
所以，基于这个问题，在2011年7月4日的时候，Bitcointalk的用户”hashcoin“设计了一种双层结构的支付通道，核心思想就是要求提交多签交易以及具有互相依赖的有效时间锁交易。如果一个参与者消失了，另一个参与者可以在时间锁解锁后取走支付通道里的所有资金。我们可以看一下具体的过程，以明确这个想法的伟大之处以及对后面一系列解决方案的影响。
比特币闪电网络节点数量为32,536个 同比增长3.21%:金色财经报道，1ML网站数据显示，比特币闪电网络（LightningNetwork）的节点数量为32,536个，同比增长3.21%；通道数量为84,857个，同比增长2.4%；网络容量为3,330.71BTC，同比增长1%。[2022/1/10 8:37:00]
图片来源：
https://bitcointalk.org/index.php?topic=25786.msg320931#msg320931
我们可以发现，Hashcoin用了非常巧妙的一个思路，让支付通道里的接收者先签署一个可以花费双方支付通道里output的交易B，然后再由双方签署支付通道的output交易A。而期间支付者想要支付钱给接收者时只用更新交易B，最后在hash锁到期前接收者广播序列号更大的交易B，完成结算。
这个思路最优秀的一点在于解决了双方不再合作的时候，支付通道里的钱无法取出的问题。因为想要开启一个通道，势必要先签署允许通道内资金转出的交易，才会签署转入资金的交易。
但是这个构想的缺点在于：
整个通道是单向的。只能A给B或者B给A，反过来就得另外新开通道，很不方便。
不知道接受者是谁的情况下，怎么使用支付通道。
nlocktime只能证明在未来有可能花费一个output，但是并没有证明在到期之前不可能花费这笔output。
由于当时BTC的hash方法需要签名，所以想要完成交易B就需要先有交易A的资金输入才行，这就形成了一个悖论。这也是当时较为出门的BTC延展性问题。
而且更为重要的是hashcoin只是一个设想，并没有去尝试实现。
JeremySpilman的支付通道
直到2013年4月，JeremySpilman搞了一个类似于hashcoin的概念，并且写了一份概念验证代码。由于当时Jeremy提出的这个想法是通过比特币开发邮件组描述的，所以并没有一个明确的名字。后来经由MikeHearn(上面公开中本聪对支付通道描述的人)优化，以及bitcoin核心贡献者，blockstream联合创始人，MattCorallo(ChaincodeLabs，由BTC开发者组成的专门建设BTC的实验室)等人的努力下，于2013年6月27日宣布把这个概念加入到了bitcoinj，同样是由MikeHearn创建）中。
图片来源：https://gist.github.com/jspilman/5424310
但是我们可以发现，hashcoin的几个缺点依旧没有被解决。
好在nLocktime的问题在2014年11月10日的BIP-0065提案中被解决，通过软分叉的形式加入新的OPCODE字段——CHECKLOCKTIMEVERIFY.?允许交易在某个时间点前不可使用。
具体的改动就不说了，总之就是加入这个字段使得这种单向支付通道在理论上变的可用。
双向支付通道的提出
关于BTChash方法的问题我们暂时不论。但是单向支付的问题是可以在不动底层的前提下进行优化的。在2014年10月7日，AlexAkselrod第一次提出了双向支付通道的提案。核心思路是引入递减时间锁，可以让接收者有限次的发送资金给发送者。虽然这个方案一直没有被实现过，但是我们依旧可以看下当时Alex的思路是什么。
闪电网络节点数量已达13766个:金色财经报道，据1ML.com数据，目前，支撑网络的节点数量达到13766个，相较30天前数据，环比上涨2.89%；通道数量为36453，相较30天前数据，环比下降2%；闪电网络承载能力目前为1061.24BTC，约合1108.79万美元。[2020/9/10]
图片来源：https://bitcointalk.org/index.php?topic=814770.msg9185225#msg9185225
可以看到基于这个提案的讨论围绕的是依靠nLocktime来进行支付角色的转换。举个例子来说，假设Alice和Bob构建了一个双向支付通道。由Alice向Bob支付。假设Alice向Bob转了1BTC,同时在这个交易上标记nLocktime为1000，那么Bob可以反向向Alice支付BTC，但是Bob发起的这笔交易nlocktime会从1000开始递减，比如是999，并且Bob发起的每笔交易都会减少nLocktime，所以Bob最多只可以发起1000笔交易。
至此，除了BTC本身延展性的问题外，Paymentchannel的基础已初步完成。
PaymentNetwork——拓展paymentchannel的必经之路
上面paymentchannel的历史基本说完，接下来，我们就应该看paymentnetwork了。回顾下上面的Paymentchannel，会发现整个支付通道的设想都是在两人之间进行交互的。但是，如果A和B有一个支付通道，B和C有一个支付通道，那么是不是可以让A直接对C进行支付呢？所以，在第一个支付通道提出之后，一些大佬们已经在考虑offchain的Paymentnetwork。其中不乏像PetterTodd和GavinAndresen这样的BTC核心开发者。那么，它们都是怎么去做的呢？
早期想法
和paymentchannel类似，在实践之前，Paymentnetwork已经诞生出很多想法。其中比较出名的想法就是来自于BTC核心开发者群里的PetterTodd于2013年2月23日提出的Fidelity-bondedbanks:decentralized,auditable,private,off-chainpayments，GavinAndresen于2012年7月4日提出的Off-the-chaintransactions，以及CornéPlooy于2011年7月13日提出的AproposalforfastPOStransactionswithBitcoin
有关前两个大佬提议的具体讨论可以在下面的链接里找到。但是从设计理念来说，两者的思路是非常相像的：基本都是引入一个半可信的中间人，实现一个链下支付网络的功能。PetterTodd在这个基础上加入了隐私的概念，而Gavin的思路则是纯粹解决支付的问题。
图片来源：https://bitcointalk.org/index.php?topic=146307.0
图片来源：http://gavintech.blogspot.com/2012/07/off-chain-transactions.html
但是，针对出现最早的Plooy的方案，我们有必要单独说下。它的思路更加符合我们对于paymentnetwork里的network的定义。
闪电网络节点数量已达13177个:金色财经报道，据1ML.com数据，目前，支撑网络的节点数量达到13177个，相较30天前数据，环比上涨2.12%；通道数量为37460，相较30天前数据，环比上涨1.4%；闪电网络承载能力目前为997.39BTC，约合948.08万美元。[2020/7/23]
图片来源：https://bitcoinmagazine.com/technical/history-lightning-brainstorm-beta
黑色箭头是标准的BTC转账流程示意，但是Plooy在此基础上加入了红色箭头的部分，这部分就是off-chain结算网络的精髓部分。整个流程大致如下：
buyer发起一笔交易给seller。
同时buyer会将这笔交易发布到BTC网络，进行常规的6789的确认步骤。
买方还会在此基础上发送交易到一个“快速验证网络”中
该“快速验证网络中”的节点将根据原有数据快速验证该交易。
快速验证网络将会在几秒钟内将初步检测结果告知seller。
最终结算还是通过经典BTC网络进行验证。出现双花问题，将由快速验证网络中的节点赔偿seller损失。
由上图可以看到，Plooy的思路就是在传统的BTC网络上搭建一层快速结算的网络。那么这里面的核心就在这层快速结算网络上。而出现双花等问题造成的损失由于是由快速结算网络中的节点支付，这就要求有明确的追责机制。在Pooly的设计中，这种追责制度是根据第5步里seller接收到的验证节点签名来进行追责的。这就说明快速验证网络中的节点不是和BTC节点一样是随机链接的，而是只有当两个节点互相信任的时候才会建立链接，然后就可以一层层的去追责，最终追踪到终端buyer头上。同时也因为这个追责制度要求终端买家在加入快速验证网络的时候必须先付款。
可以看到Plooy的思路还是会落在信任上。并不是完全的无需信任。不过在2011年就提出这种设计，很了不起。同时也为后续的几个真实落地的项目提供了很好的参照。
AmikoPay——闪电网络的前身
和hashcoin一样，Plooy一开始也并没有具体的去落地，但是期间一直在有人去尝试改进这个想法，其中包括BTC核心开发者和GregoryMaxwell以及RyanFugger(Ripple创始人)等人。最终，在2012年7月22日，一篇?CombiningBitcoinandtheRippletocreateafast,scalable,decentralized,anonymous,low-trustpaymentnetwork(draft1)?的文章宣布了AmikoPay的诞生。
AmikoPay可以看成是Plooy落地的尝试。但是在这版草稿中，没有用到PaymentChannel的东西，导致整个网络依旧需要信任：如果某个用户拒绝与另一个用户结算余额，后者没有任何办法。虽然在2013年1月15日发布了第二版的草稿，但是其内容并没有很大的改动。
后续AmikoPay一直在做改动，最终设计出了一套无需信任的解决方案，但是鉴于当时的BTC本身编程模型的限制，类似的方案难以实现，需要对BTC做”一定“的改动,最终不了了之。AmikoPay最后一次更新自己的roadmap进度是在2016年6月：
如果对AmikoPay有更多的兴趣，除了本文中附带的超链接外，还可以点击他们主页进行详细的了解：https://cornwarecjp.github.io/amiko-pay/
但是，就如同上面写的一样，AmikoPay本身并没有很好得结合Paymentchannel的优点，所以给了其他人一些机会，最终变成了前浪。
结合支付通道和支付网络的其他方案
虽然AmikoPay这一派系并没有很好得结合支付通道的设计，但是，早在2012年的时候就有人提出过结合两者的思路。2012年7月5日，MeniRosenfeld在bitcointalk上提出了一个想法，Trustless,instant,off-the-chainBitcoinpayments，在Hashcoin的基础上加入了中继人的角色，形成由支付通道组成的简单支付网络。这样使用只需要和“中继人”建立支付通道，再通过中继人链接其他用户。这里需要注意的是，中继人的角色同样不会控制任何人的钱包，只负责通道的建立。同时允许中继人竞争上岗，进一步分散资金，哪怕出现什么问题也只会损失小部分资金。当然，这一样需要用户信任中继人。
声音 | 江卓尔：闪电网络违背产品及经济规律，失败是命中注定的:金色财经报道，江卓尔刚刚发微博称，闪电网络违背产品&经济规律，失败是命中注定的，扩容之争后的实践证明，Core党输得一塌糊涂，BTC继续在1.2MB的位置堵着，唯一能拿来撑脸面的就是BTC币价领先于BCH。但币价领先是靠什么？靠Core路线正确么？不是。靠Core控制开发权抢到了比特币的名字，靠比特币巨大的品牌惯性而已。如果比特币按中本聪的计划扩容了大区块，那发展该有多好，能减少多少用户堵得欲仙欲死的痛苦，能少流失多少用户？所有Core党都不敢回答一个噎死问题：普通电脑能跑几MB区块？那个狙击手被我噎了3年后，终于憋出一个：3MB。我信你个鬼，自己不看看普通电脑跑1MB区块基本就是空载，大区块几十MB的压力测试都做过N轮了。就算是3MB，下一个噎死问题就是：那为什么反对扩2MB？普通电脑都能跑3MB，2MB有什么中心化问题？假装没看到质问，不敢回答，你们的良心不会不安吗？还是你们根本就没有良心？难怪会去消费粉丝乞讨带血的钱。Core党注定会被钉在历史的耻辱柱上。[2019/11/30]
当然，类似的想法在过去的几年里一直断断续续的出现。比如提到很多次的Pettertodd在2014年12月的BTC开发者邮件组里提到过类似的概念，甚至在更早的2013年，AlexAkselrod就提出过类似的草案并且还在稍晚的2014年公布了测试代码。。Bitpay也在2015年发布了类似概念的“Impulse”白皮书和实际落地方案，当然也有类似于Strawpay这种公司做了Stroem，等等。
我们可以认为上述的各个方案，无论是AmikoPay还是Impulse还是Storem都是可以实现闪电网络的那些功能的。但是，他们要不需要对BTC做出“较大”的改动或者需要在某些方面进行妥协。所以，这些人在那个年代想出这些方案并且去尽力实现已经非常厉害了，但是还不够，必须要有更为天才的人能够在BTC限定的框框内展露才华。
剑来！———闪电网络正式登场
前面诸多英雄豪杰已成云烟，但是遗留的问题依旧需要解决。那么在主角登场前，我们再来看看目前的支付网络和支付通道遗留的问题是什么。
如何做到无需信任？
如何对BTC网络的改动最小？
而这第一个问题本质上来说都是因为第二个问题才导致没有一个较好的解决方案。那么问题就变成了，如何在BTC编程模式的限制下，实现无需信任的BTC高效支付网络。
前面已经有很多的技术积累，加上2015年BTC社区关于扩容的讨论日渐火热，所以我们发现很多重要的突破的都是在那一年诞生。其中，一篇苏黎世理工的论文《AFastandScalablePaymentNetworkwithBitcoinDuplexMicropaymentChannels》于2015年晚期发布。这篇论文的解决方案重度依赖于时间锁来作为通道有效性的“倒计时装置”，以及一种叫做“无效树”的密码学技巧来作废陈旧的通道交易。这也成为了后来闪电网络赖以为生的技术原型。而这篇论文的两个作者ChristianDecker和RogerWattenhofer后来都加入了blockstream。
天时、地利、人和，三者不得，虽胜有殃——《孙膑兵法·月战》
2015年的BTC扩容逐渐火热，此曰天时。前面众多技术积累和那篇论文提出的两个关键设计，为闪电网络铺平道路，此曰地利。
那么，天时地利有了，只差一个人和。或许这就是主角吧，在2015年即将结束的时候，BTC核心开发者之一的大佬GregoryMaxwells总结了最近一段时间有关BTC扩容的讨论，里面奶了闪电网络一口。而他当时就是blockstream创始团队成员之一。有关Maxwells的成就，大家可以看一个科普：https://academy.bit2me.com/en/who-is-gregory-maxwell/
总之，对于闪电网络来说，天时地利人和凑齐，下面就是它表演的时间了！。
那么接下来，我们就来看下lightningnetwork是怎么做到比前辈优秀的？我们将从两个角度的优化来看待它。
Paymentchannel
闪电网络将双方的timespan扩充到无限。只要双方愿意，这个channel可以一直存在。而此前的paymentchannel方案需要在nlocktime到期前关闭
双向支付而且是无限次的。
Paymentnetwork
动态 | 闪电网络承载能力突破500个BTC:据1ml.com数据显示，闪电网络节点和通道数量呈现持续上升趋势。目前，支撑网络的节点数量已经达到4783个，在过去的30天中上涨了14.04%，而通道数量目前达到15794个，在过去的30天中上涨了26.80%。闪电网络承载能力已经突破500个BTC，目前达到个507.45BTC，相当于191万4942美元。[2018/12/26]
利用HTLC，将Channel连在一起，形成网络。这个东西是什么意思呢？其他它包含两个“或”关系的条件。
创建一个条件支付，比如A给B一笔钱，需要B解出一道题才能花费里面的钱。即收款方揭露一个信息，提供有这个信息的证明才能花这笔钱。严格一点的定义是：哈希秘钥锁定，基于hash的单向性，可以把一个密文的哈希值放入交易的输出当中充当哈希密文锁，也就是必须得输入该哈希值对应的密文才能解锁脚本中的比特币。例如，例如Alice收到了一笔2BTC转账，但是对方设定了哈希值锁定，所以Alice必须得到交易方的密文，同时配合自己的密钥签名才能签署交易，花费其中的BTC转给Bob。
等到规定的时间结束，才能花费里面的钱。在此之前交易并不生效，无法执行。严格一点的定义就是在交易脚本里面设置时钟，必须要等设定时间之后，才能用地址的私钥签名解锁地址里的比特币。例如Alice收到了一笔2BTC转账，但是对方设定了1000个区块之后才能解锁，所以Alice必须等待1000个区块之后才能用自己的私钥签署交易,花费其中的BTC转给Bob。
那么闪电网络具体是怎么做的呢？我们在前面的设计中也知道，如何保证双方记账的诚实是闪电网络需要解决的难题。这里就涉及两个东西:?
如何知道是谁作恶
作恶如何受到惩罚
这时候，我们就需要看下闪电网络在paymentchannel的几次转账是如何进行。具体的过程和原理大家可以去参阅白皮书。
今天主要讲的是历史，所以对于原理我就概括下：假设A和B构建了一个闪电网络通道，对于每次的交易，实际上会产生4个交易证明：
记录在A账本的转账记录
记录在B账本的转账记录
记录在A账本用来作废前一笔交易的记录
记录在B账本用来作废前一笔交易的记录
我们可以看到，这4个证明实际上分为两类。但是需要注意的是A和B的账本记录的同一类交易证明是不同的。
假设A给B转了一个BTC，现在总的账本是A:4B:6,这时候在A的账本和B的账本记录的对于BTC分配的内容是一致的，不一致的是为了区分在作恶情况时知道是谁发送的恶意交易，所以在构成交易的其他信息上做了文章。假设又发生了一笔交易，A又转了1BTC给B，此时的交易记录应该是A:3B:7,但是A想作恶，抢先把上次一交易发送到了链上，这时候闪电网络有意思的设计来了，A发送的这个交易里，B的6个BTC是能被B立刻取走，但是A的4个BTC必须等哈希时间锁到期后才能取走，通过这种方式给了受害人反应时间。
这时候，用来作废前一笔交易的记录就派上用场了。假设B发现了A的恶意行为，他可以马上把最新的交易记录和作废前一笔交易的记录发送到链上。由于此前A已经把4，6这个交易发到链上，B可以马上取回自己的6个BTC，然后这个作废前一个记录的作用就是可以让B马上或得原本需要等待时间锁到期的A的4个BTC，也就是相当于整个channel里10个BTC都归了B，A受到了惩罚。
而对于将不同的channel链接成网络的事情，用到了上面的HTLC。
假设A要通过B给C转账。这个过程可以简单概括为：
C哈希一个密文给A，A构建一个交易给B，但是这笔交易需要B拿到C的密文才能解锁，如果到期内没有解锁，则钱退给A。
然后B构建一个交易给C，同样需要C的密文C才能解锁交易。这样，C一旦拿到钱，B也就知道了C的密文，也就能拿到A的钱。
闪电网络的大概过程就是这些，只是大概提一下，有需要的话后面可以详细讲讲。我们继续讲闪电网络的进化史。
几个实现的具体方案
既然白皮书有了，那么就是实现的问题了。我们之前讲过的BTC可塑性问题。针对这个问题，闪电网络白皮书里提到了signaturehash-withoutinput的形式去解决，但是最终没有成功，反而是利用了后来的sigwit达到了一样的目的。
而且，不仅如此，由于第一版白皮书包含很多技术概念，很少能有人能彻底理解。但Linux系统内核长期开发者RustyRussell学习了这份白皮书后，大家的基础认识提高了一大截。在2015年初的系列博客中，Russell为更广泛的读者“翻译”了这份白皮书。在同年3月，Russell应邀加入了Blockstream，开发了第一个闪电网络的实现：C-lightning。后来，Blockstream的ChristianDecker也加入了Russell；其他人也为这个开源项目做了贡献。
此后不久，一家名叫ACINQ的小公司加入闪电网络的研究中，在2017年3月22日宣布用Scala写出了自己的闪电网络协议——eclair。
但是，我们熟知的闪电实验室呢？嗯，他们是在2016年1月由闪电网络白皮书的两个作者Poon和Dryja成立的。后来大家就知道了，他们做了LND。并且16年底Dryja离开闪电实验室去了MIT的数字货币计划，做了类似LND的LIT。
同时，因为延展性的问题，著名的挖矿公司Bitfury将lnd分叉并且权衡了延展性问题，做了一个哪怕不需要解决BTC延展性问题也能用的闪电网络。但是现在这个项目停滞了。
再后来，Blockchain开发了一个叫Thunder的简化版闪电网络，在牺牲“无需信任”的前提下，推出了实际意义上最早的闪电网络—Thunder的alpha版本。虽然现在也没声音了。
可以发现，当时的闪电网络各式各样，那么每到这个时候，总会有一个会议来规范大家，让大家的东西可以互通。这个会议就是2016年10月举办的ScalingBitcoinMilan三次会议。在这个会议上，各个项目方达成了互操作的一致性，产生了一个叫“BOLT”的闪电网络协议规范。所以说，闪电网络白皮书是理论上的第一，BOLT才是我们今天所知的、实际上的闪电网络的基础。
迈向可用性
至于另一条故事线，就是围绕btc延展性而展开了。从之前PetterTodd在2015年提出的CLTV,到相对时间锁的实现，一直到后来segwit的升级，最终让闪电网络正式进入应用阶段。而正式使用闪电网络的第一个例子，就是在segwit测试网,segNet部署不到半年后的2016年10月，blockstream的Decker就用c-lighting从Russell手上买了一只“猫”
图片来源：https://blog.blockstream.com/en-blockstream-lightning-first-strike/
这也被称为?“闪电网络的第一次闪击”。
然后就是2017年1月，LND推出了alpha版本。一直到17年夏天，隔离见证正式激活。blockstream在3个月后宣布了第一笔BTC主网闪电网络交易，11月，LightningLabs做了第一笔跨区块链的闪电网络交易。12月，来自Blockstream、LightningLabs和ACINQ的开发团队宣布他们已经通过了互操作性测试。
到了这一年的末尾，越来越多的闪电通道打开。到了12月，开发者AlexBosworth用闪电网络通道向支付处理商Bitrefill支付了自己的手机账单：这是闪电网络上最早一批把比特币当钱来用的交易之一。
又过了一个月，Blockstream开设了一个网上商店，让人可以用比特币来购买实体商品——虽然c-lightning实现还只是beta版本。2018年2月，在闪电网络仍处在alpha阶段时，比特币世界的传奇人物、以“比特币买披萨”趣事闻名世界的LazloHanyecz宣布自己使用闪电网络买了披萨。
图片来源：http://eclipse.heliacal.net/~solar/bitcoin/lightning-pizza/
后面的故事就属于顺风顺水了。各种闪电网络方案纷纷落地，相关生态也日渐完善。关于闪电网络到目前为止个人觉得重要的历史事件也就是这些。
总结
第一个总结：天才的聪明才智总是这么的“不值钱”。
如果稍微看下下闪电网络白皮书的两个作者的相关事迹就能得出第二个结论：天才总是会搞事情。
两人的主要成就如下：
ThaddeusDryja，做过一个叫mirro的项目，点对点的交易系统，并且加入了predictionmarket的概念。同时也搞过一个PoW算法，是以太坊PoW算法ethash上线前的替代算法的前身：http://diyhpl.us/~bryan/papers2/bitcoin/meh/hashimoto.pdf。
另一个作者，JosephPoon，还是plasma的作者之一。在BTC提出了基于channel的闪电网络，在以太坊提出了基于链的plasma。同时也做了handshake(https://handshake.org/)，继承了namecoin思想的项目。当然，割没割人就不在我们的讨论范围内。
最后，附上我们整理的闪电网络相关大事件时间线：
图片来源：CYC整理
文献参考：
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
https://bitcoinmagazine.com/technical/history-lightning-brainstorm-beta
https://voltage.cloud/blog/bitcoin-lightning-network/life-of-lightning/
https://en.wikipedia.org/wiki/Lightning_Network
https://bitcointalk.org/index.php?topic=146307.0
http://gavintech.blogspot.com/2012/07/off-chain-transactions.html
https://bitcointalk.org/index.php?topic=28565.msg359408#msg359408
http://www.ultimatestunts.nl/bitcoin/ripple_bitcoin_draft_1.pdf
https://bitcointalk.org/index.php?topic=91732.msg1010405#msg1010405
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/006988.html
https://en.bitcoin.it/wiki/User:Aakselrod/Draft
https://www.strawpay.com/docs/stroem-payment-system.pdf
https://tik-old.ee.ethz.ch/file//716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
https://montreal2015.scalingbitcoin.org/
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://lightning.network/lightning-network-paper.pdf
https://github.com/mpegavi/bitcoincn/blob/master/%E6%AF%94%E7%89%B9%E5%B8%81%E9%97%AA%E7%94%B5%E7%BD%91%E7%BB%9C%E7%99%BD%E7%9A%AE%E4%B9%A6%EF%BC%9A%E5%8F%AF%E6%89%A9%E5%B1%95%E7%9A%84%20off-chain%20%E5%8D%B3%E6%97%B6%E6%94%AF%E4%BB%98%EF%BC%88%E4%B8%AD%E6%96%87%EF%BC%89.pdf
https://github.com/ElementsProject/lightning
https://bitcoinmagazine.com/technical/segwit-or-not-bitfury-ready-lightning-successful-bitcoin-main-net-test
https://medium.com/@ACINQ/eclair-0-2-alpha1-is-out-3caaff242567
https://github.com/blockchain/thunder
https://github.com/lightning/bolts/blob/master/00-introduction.md
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。