The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf

-
Joseph Poon提出了闪电网络, 以比特币区块链为后盾,在链下实现真正的点对点微支付交易,区块链处理能力的瓶颈被彻底打破,时延、最终性、容量甚至隐私问题也迎刃而解。这是他的那篇英文原版论文。
consumer-level computer on a home broadband connection. By ensuring Chat lull validation can occur cheaply, Bitcoin nodes and niners will be able to prevent extreme centralization and trust, which ensures extremely low transaction fees While it is possible that Moore's law will continue indefinitely, and the computational capacity for nodes to cost-effectively compute multi gigabyte blocks may exist in the future, it is not a certainty To achieve much higher than 47, 000 transactions per second using Bitcoin requires conducTing transacTions olf the Bitcoin blockchain itself. It would be even better if the bitcoin network supported a near-unlimited num- bcr of transactions per sccond with cxtrcmcly low fccs for micropayments Many micropayments can be sent sequentially between two parties to en able any size of payments. Micropayments would enable unbunding. less trust and commodification of services, such as payments for per-megabyte internet service. To be able to achieve these micropayment use cases, how ever, would require severely reducing the amount of transactions that elld up being broadcast on the global bitcoin blockchain. While it is possible to scale at a small level, it is absolutely not possible to handle a largc amount of micropayments on the nctwork or to encompass all global transactions. For bitcoin to succeed, it requires confidence that if it were to become extremely popular, its current advantages stemming fro on decentralization will continue to exist. In order for people today to believe Chat Bitcoin will work tomorrow. Bitcoin needs to resolve the issue of block size centralization effects; large blocks implicitly create trusted custodians and significantly higher fees 2 A Network of Micropayment Channels Can Solve scalability "If a tree falls in the forest and no one is around to hear it does it make a sound? The above quote questions the relevance of unobserved events - nobody hears the tree fall, whether it made a sound or not is of no conse quence. Similarly, in the blockchain, if only two participants care about, an everyday recurring TransacTiOn, it's not necessary for all other nodes in Che bitcoin network to know about that transaction. It is instead preferable to only have the bare Inininun of informalion on the blockchain. By defer ring telling the entire world about every transaction, doing net settlement of their relationship at a later date enables Bitcoin users to conduct many transactions without bloating up the blockchain or creating trust in a cen tralized counterparty. An effectively trustless structure can be achieved by using time locks as a component to global consensus Currently the solution to micropayments and scalability is to offload the transactions to a custodial, whereby one is trusting third party custo ans to hold one's coins and to update balances with other parties. Trusting third parties to hold all of onc's funds creates counterparty risk and trans- action costs Instead, using a network of these micropayment channels, Bitcoin can scale to billions of transactions per day with the computational power available on a. modern desktop computer today. Sending many payments inside a given micropayment channel enables one to send large anounts of funds to another party in a decentralized manner. These channels are not a separate trusted network on top of bitcoin. They are real bitcoin transactions Micropayment channels[3 4 create a relationship between two par- ties to perpetually update balances, deferring what is broadcast to the blockchain in a single transaction netting out the total balance betweer those two parties. This permits the financial relalionships between lwo par ties to be trustlessly deferred to a later date, without risk of counterparty default. Micropayment channels use real bitcoin transactions, only electing to defer the broadcast to the blockchain in such a way that both parties can guarantee their current balance on the blockchain; this is not a trusted overlay network- payments in micropayment channels are real bitcoin com municated and exchanged off-chain 2.1 Micropayment Channels do Not Require Trust Like the age-old question of whether the tree falling in the woods makes a sound. if a ll parties agree that the tree fell at 2: 45 in the afternoon then the Lree really did fall at 2: 45 in the afternoon. Similarly, if both counterparties agree that the current balance inside a channel is 0.07 BtC to Alice and 0.03 btC to Bob, then that's the true balance. However, without cryptography, an interesting problein is created: Ifone's counterparty disagrees about the current balance of funds(or time the tree fell), then it is one's word against another. Without cryptographic signatures, the blockchain will not know who owns what If the balance in the channel is 0.05 btc to Alice and 0.05 brc to Bob. and the balance after a transaction is 0.07 brC to Alice and 0.03 btc to bob. the network needs to know which set of balances is correct Blockchain transactions solve this problein by using the blockchain ledger as a timestamping system. At the same time, it is desirable to create a sys tom which docs not actively usc this timcstamping systcm unless absolutely necessary, as it can become costly to the network Instead, both parties can commit to signing a transaction and not broadcasting this transaction. So if Alice and Bob commit funds into a 2 of-2 multisignature address(where it requires consent from both parties to create spends), they can agree on the current balance stale. Alice and Bob can agree to create a refund from that 2-of-2 transaction to themselves, 0.05 BTC to each. This refund is not broadcast on the blockchain. Either party may do so, but thcy may clcct to instcad hold onto that transaction, knowing that they are able to redeem funds whenever they feel comfortable doing so By deferring broadcast of this transaction, they may elect to change this balance at a future date To update thhe balance, both parties create a llew spend Iron the 2-of-2 multisignature address, for example 0.07 to Alice and 0.03 to Bob Without proper design, though, there is the timestamping problem of not knowing which spend is correct: the new spend or the original refund The restriction on timestamping and dates, however, is not as com plex as full ordering of all transactions as in the bitcoin blockchain. In the case of micropayment channels, only two states are required: the current correct balance, and any old deprecated balances. There would only be a single correct current balance, and possibly many old balances which are deprecated Thercforc, it is possiblc in bitcoin to devise a bitcoin script whcrcb all old transactions are invalidated, and only the new transaction is valid Invalidation is enforced by a bitcoin output script and dependent trans actions which force the other party to give all their funds to the channel counterparty. By taking all funds as a penalty to give to the other, all old transactions are thereby invalidated This invalidation process can exist through a process of channel con sensus where if both parties agree on current ledger states(and building new states), then the real balance gets updated. The balance is reflected on the blockchain only when a single party disagrees. Conceptually. this system is not an independent overlay network; it is more a deferral of state on the current system, as the enforcement is still occurring on the blockchain itself (albeit deferred to future dales and transactions) 2.2 A Network of channels Thus, micropayment channels only create a relationship between two parties Requiring everyone to create channels with everyone else does not solve the scalability problem. Bitcoin scalability can be achieved using a large network f micropayment channcls If we presume a large network of channels on the bitcoin blockchain and all Bitcoin users are participating on this graph by having at least one channel open on the Bitcoin blockchain, it is possible to create a near-infinite amount of transactions inside this network. The only transactions that are broadcasted on the Bitcoin blockchain prematurely are with uncooperative channel counterparties By encumbering the Bitcoin transaction outputs with a hashlock and timelock, the channel counterparty will be unable to outright steal funds and Bitcoins can be exchanged without outright counterparty theft. Fur ther, by using staggered timeouts. it's possible to send funds via multiple intermediaries in a network without the risk of intermediary theft of funds 3 Bidirectional Payment Channels Micropayment channels permit a simple deferral of a transaction stale to be broadcast at a later time. The contracts are enforced by creating a responsibility for one party to broadcast transactions before or after certain dates. If the blockchain is a decentralized timestamping system, it is possible to use clocks as a component of decentralized consensus[5 to determine data validity, as well as present states as a method to order events 6 By creating timeframes where certain states can be broadcast and later invalidated, it is possible lo create complex contracts using bitcoin transaction scripts. There has been prior work for Hub-and-Spoke Micro payment Channels 7 89(and trusted payment channel networks 10 11) looking at building a hub-and-spoke network today. However, Lightning Networks bidirectional micropayment channel requires the malleability soft fork described in Appendix a to enable near-infinite scalability while miti gating risks of intermediate node default By chaining together mulliple micropayment channels, it is possible to create a network of transaction paths. Paths can be routed using a bgP like systcm, and thc scndcr may designate a particular path to the recipient The output scripts are encumbered by a hash, which is generated by the recipient. By disclosing the input to that hash, the recipient's counterparty will be able to pull funds along the route 3.1 The Problem of blame in Channel creation In order to participate in this payment network, one must create a micro payment channel with another participant on this network 3.1.1 Creating an Unsigned Funding Transaction An initial channel Funding Transaction is created whereby one or both chan nel counterparties fund the inputs of this transaction. Both parties create the inputs and outputs for this transaction but do not sign the transaction The output for this Funding transaction is a single 2-of-2 multisigna turc script with both participants in this channel, henceforth namcd Alicc and Bob. Both participants do not exchange signatures for the Funding Transaction until they have created spends from this 2-of-2 output refund- ing the original amount back to its respective funders. The purpose of not signing the transaction allows for one to spend from a transaction which does not yet exist. If Alice and Bob exchange the signatures from the Fund ing Transaction without being able to broadcast spends from the Funding Transaction, the funds may be locked up forever if Alice and Bob do not cooperate(or other coin loss may occur through hostage scenarios whereb one pays for the cooperation from the counterparty) Alice and bob both exchange inputs to fund the Funding transaction (to know which inputs are used to determine the total value of the channel) and exchange one key to use to sign with later. This key is used for the 2-of-2 output for the Funding Transaction; both signatures are needed to spend from the Funding Transaction, in other words, both Alice and Bob need to agree to spend from the Funding transaction 3.1.2 Spending from an Unsigned Transaction The Lightning Network uses a SIGHASH-NOINPUT transaction to spend from this 2-of-2 Funding Transaction output, as it is necessary to spend from a transaction for which the signatures are not yet exchanged SIGHASH NOINPUT, implemented using a soft-fork, ensures transactions can be spent ron before it is signed by all parties, as transactions would need to be signed to get a transaction ID without new sighash fags Without SIGHASH NOINPUT, bitcoin transactions cannot be spent from before they may be broadcast -it's as if one could not draft a contract without paying the other party first. SIGHASH NOINPUT resolves this problem. See Appendix a for more information and implementation Without STGHASH NOINPUT, it is not possible to generate a spend Tron a Urallsaclion wilhout exchanging signatures, since spending the Fund ing Transaction requires a transaction ID as part of the signature in the child s input. A component of the Transaction Id is the parent's(Funding Transaction's) signature, so both parties need to exchange their signatures of the parent transaction before the child can be spent. Since one or both par ties must know the parents signatures to spend from it, that means one or both parties are able to broadcast the parent(Funding Transaction) before the child even exists. SIGHASH NOINPUT gets around this by permitting the child to spend without signing the input. With SIGIIASIl-NOINPUt the order of operations are to 1. Create the parent(Funding Transaction) 2. Create the children( Commitment Transactions and all spends fror the commitment transactions) 3. Sign the children 4. Exchange the signatures for the children 5. n the parent 6. Exchange the signatures for the parent 7. Broadcast the parent on the blockchain One is not able to broadcast the parent(Step 7)until Step 6 is com- plete. Both parties have not given their signature to spend from the funding Transaction until step 6. Further, if one party fails during step 6, the parent can either be spent to become the parent transaction or the inputs to the parent transaction can be double-spent(so that this entire transaction path is invalidated) 3.1. 3 Commitment Transactions: Unenforcible Construction After the unsigned(and unbroadcasted)Funding Transaction has been cre- ated, both parties sign and exchange an initial Commitment Transaction These Commitment Transactions spends from the 2-of-2 output of the Fund- ing Transaction(parent). However, only the Funding Transaction is broad- cast on the blockchain Since the Funding transaction has already entered into the blockchain, and the output is a 2-of-2 multisignature transaction which requires the agreement of both parties to spend from, Commitment Trans actions are used to express the present balance. If only one 2-of-2 signed Commitment Transaction is exchanged between both parties, then both parties will be sure that they are able to get their money back after the Funding Transaction cntcrs the blockchain. Both parties do not broadcast the Commitment Transactions onto the blockchain until they want to close out the current balance in the channel. They do so by broadcasting the present Commitment Transaction Commitment Transactions pay out the respective current balances to each party. A naive(broken) implementation would construct an unbroad- casted transaction whereby there is a 2-of-2 spend from a single transaction which have two outputs that rcturn all current balances to both channel counterparties. This will return all funds to the original party when creat ing an initial Commitment Transaction ding TX(F) 0. Alice 0.5 BTC 1. Bob.5 BIC No LockTime o山tput1 Alice can redeem 0.5 BTC from Bob can redeem 0.5 BTC from the Commitment Transaction the commitment transactio Figurc 1: A naive broken funding transaction is described in this diagram. The Funding Transaction(F), designated in green, is broadcast on the blockchain after all other trans- actions are signed. All ot her transactions spending from the funding transactions are not yet broadcast. in case the counterparties wish to update their balance. Only the Funding Transaction is broadcast on the blockchain at this time For instance, if Alice and Bob agree to create a Funding transac- tion with a single 2-of-2 output worth 1.0 BTC(with 0.5 BTC contribution from each), they create a Commitment Transaction where there are two 0.5 BTC outputs for Alice and Bob. The Commitment Transactions are signed first and keys are exchanged so either is able to broadcast the Commitment Transaction at any time contingent upon the Funding Transaction enter ing into the blockchain. At this point, the Funding Transaction signatures can safely bc cxchanged, as cithcr party is able to rcdccm thcir funds by broadcasting the Commitment ' Transaction This construction breaks, however, when one wishes to update the present ba lance. In order to update the balance, they must, update their Commitment Transaction output values(the Funding Transaction has al ready entered into the blockchain and cannot be changed) When both parties agree to a new Commitment Transaction and ex change signatures for the ncw Commitment Transaction, cithcr Commit- ment Transactions can be broadcast. As the output from the Funding Transaction can only be redeemed once. only one of those transactions will be valid. For instance, if Alice and Bob agree that the balance of the channel 10

1.23MB
Off-Chain比特币支付使用智能合同blockchain-thunder.zip
2019-07-19Wallet / Node 实施lightning.network P2P协议。该lightning.network协议使Off-Chain比特币支付渠道使用智能合同。该软件处于 alpha 状态,甚
4.6MB
lightning-network-paper.pdf
2020-04-18The Bitcoin Lightning Network: Scalable Off-chain Instant Payments 高清pdf,可用iPad批注
26.96MB
bitcoin-0.17.1-x86_64-linux-gnu.tar.gz
2019-09-25bitcoin-0.17.1-x86_64-linux-gnu.tar.gz 配上对应安装教程:https://blog.csdn.net/zs345048102/article/details/86
174KB
中本聪比特币创世论文(英文原版)比特币区块链白皮书 Bitcoin: A Peer-to-Peer Electronic Cash System
2018-02-14Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent di
184KB
2009 Bitcoin A Peer-to-Peer Electronic Cash System.pdf
2019-09-03Bitcoin: A Peer-to-Peer Electronic Cash System(Satoshi Nakamoto)
1.49MB
org.bitcoinj:bitcoinj-core:0.14.6.jar
2018-03-23该jar包为bitcoinj开发的基础包。bitcoinj库是比特币协议的Java实现,它允许它维护一个钱包并发送/接收交易,而不需要Bitcoin Core的本地副本。
14.51MB
bitcoin-0.20.0-win64-setup.exe
2020-07-11这是中本聪客户端,有需要的可以下载,我下载的时间是2020/07/11,版本如资源名称。
14.57MB
bitcoin-0.20.1-win64-setup
2020-11-28比特币官网钱包 官网下载太慢 帮有需要的同学节约一点时间,需要下载比特币帐本 大约200G左右。 和在现实生活中一样,你必须保护好自己的钱包。使用比特币可以轻而易举地在世界范围内转移资金,也让你完全掌
66.44MB
geth-windows-amd64-1.9.8-d62e9b28.exe
2019-11-30geth windows 环境搭建安装exe 通过执行 geth-windows-amd64-1.9.8-d62e9b28.exe 可在windows 64位机上运行EVM,搭建属于自己的私有区块链
474KB
Zerocoin- Anonymous Distributed E-Cash from Bitcoin
2016-11-16Zerocoin- Anonymous Distributed E-Cash from Bitcoin,ZCash
66KB
bitcoin-rpc包
2018-08-29java-bitcoin rpc所需的jar,有问题请联系我
15.75MB
bitcoin-0.19.0.1-win64-setup.exe
2019-12-04比特币官方客户端Bitcoin Core。 截至201912月最新版bitcoin-0.19.0.1
10.57MB
Mastering Bitcoin.pdf
2019-09-10Join the technological revolution that's taking the world of finance by storm. Mastering Bitcoin is
11.13MB
the-book-of-satoshi.pdf
2020-07-02通过中本聪留下的所有资料来介绍比特币诞生的来龙去脉以及对中本聪真实身份的揣测。 Have you, like the rest of the world, speculated as to the i
11.30MB
Mastering Bitcoin Unlocking Digital Cryptocurrencies 无水印pdf
2017-09-28Mastering Bitcoin Unlocking Digital Cryptocurrencies 英文无水印pdf pdf所有页面使用FoxitReader和PDF-XChangeViewer
14.13MB
bitcoin-0.16.1-win64-setup.exe
2019-07-03windows 64位的比特币钱包软件,直接双击即可安装,可以用于区块链学习
33.45MB
精通比特币Mastering-Bitcoin.pdf
2017-12-30精通比特币Mastering-Bitcoin.pdf 精通比特币Mastering-Bitcoin.pdf 精通比特币Mastering-Bitcoin.pdf
1.9MB
比特币客户端Bitcoin-Qt.zip
2019-07-17Bitcoin-Qt 是使用 Qt 开发的比特币客户端,目前该项目已经成为比特币官方的客户端,合并到比特币项目中,不再单独立项。 标签:Bitcoin
70KB
Bitcoin-mining-proxy.zip
2019-07-19Bitcoin-mining-proxy 是比特币挖矿机的多池、多 worker 代理,支持长轮询和故障转移 要求: Apache (2.2 or newer recommended). PHP 5.
3.37MB
Android-bitcoin-wallet.zip
2019-09-17Android-bitcoin-wallet.zip,用于Android设备的比特币钱包应用程序。独立的比特币节点,无需集中后端。,安卓系统是谷歌在2008年设计和制造的。操作系统主要写在爪哇,C和C
2.82MB
Blockchain Basics_A Non-Technical Introduction in 25 Steps-Apress(2017).pdf
2018-01-12This introduction answers the most important question that every author has to answer:Why should any
14KB
Magento-Bitcoin-Payment-Module.zip
2019-07-17Magento-Bitcoin-Payment-Module 是 Magento 的比特币支付模块。
-
学院
python办公自动化技巧
python办公自动化技巧
-
下载
课程设计综合最终材料.zip
课程设计综合最终材料.zip
-
下载
IPC/JEDEC-J-STD-035:非密封电子元件的声学显微镜法-英文完整版(17页)
IPC/JEDEC-J-STD-035:非密封电子元件的声学显微镜法-英文完整版(17页)
-
博客
JUC之Condition实现原理
JUC之Condition实现原理
-
博客
数学建模之流程图和数据可视化
数学建模之流程图和数据可视化
-
博客
Soul网关源码探秘《六》 - 插件链
Soul网关源码探秘《六》 - 插件链
-
下载
Scan.unitypackage
Scan.unitypackage
-
下载
极点五笔十周年.rar
极点五笔十周年.rar
-
博客
OutOfDirectMemoryError
OutOfDirectMemoryError
-
博客
【操作系统系列】完整文件系统实现
【操作系统系列】完整文件系统实现
-
博客
Soul 学习笔记之 数据同步websocket(六)
Soul 学习笔记之 数据同步websocket(六)
-
下载
matlab产生正弦波及.mif文件的程序-其它文档类资源
matlab产生正弦波及.mif文件的程序-其它文档类资源
-
下载
Xilinx-Artix-7系列FPGA-高速采集卡开发例程使用手册.pdf
Xilinx-Artix-7系列FPGA-高速采集卡开发例程使用手册.pdf
-
学院
ProBuilder快速原型开发技术
ProBuilder快速原型开发技术
-
下载
自己临时实用存储一下
自己临时实用存储一下
-
下载
Zhong Shi Ying Yu Zhi Jian (Bei - Ping Qia Mu.mobi
Zhong Shi Ying Yu Zhi Jian (Bei - Ping Qia Mu.mobi
-
博客
域名和安全
域名和安全
-
下载
NSL-KDD.zip(KDDCUP99改进版)
NSL-KDD.zip(KDDCUP99改进版)
-
学院
【2021】Python3+Selenium3自动化测试(不含框架)
【2021】Python3+Selenium3自动化测试(不含框架)
-
下载
FGX50p Linux拨号上网测试.txt
FGX50p Linux拨号上网测试.txt
-
下载
基于Android的备忘录源码
基于Android的备忘录源码
-
学院
Selenium3分布式与虚拟化
Selenium3分布式与虚拟化
-
博客
Python编程基础篇之基础语法
Python编程基础篇之基础语法
-
下载
华为Magic(HI3650V100方案)维修图PCB位置图(PDF格式)
华为Magic(HI3650V100方案)维修图PCB位置图(PDF格式)
-
学院
转行做IT-第5章 流程控制语句
转行做IT-第5章 流程控制语句
-
下载
傲梅轻松备份AOMEI_Backupper_v6.3.rar
傲梅轻松备份AOMEI_Backupper_v6.3.rar
-
下载
中文说明worldserver.conf
中文说明worldserver.conf
-
下载
2020牛客暑期多校集训营第六场题解.pdf
2020牛客暑期多校集训营第六场题解.pdf
-
学院
Cocos Creator游戏开发-连连看 (接入腾讯优量汇广告)
Cocos Creator游戏开发-连连看 (接入腾讯优量汇广告)
-
博客
sqli-labs教程——Less 11-20
sqli-labs教程——Less 11-20