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

所需积分/C币:50 2018-03-07 09:43:13 2.93MB 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

...展开详情
试读 59P The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf
立即下载 低至0.43元/次 身份认证VIP会员低至7折
抢沙发
一个资源只可评论一次,评论内容不能少于5个字
  • GitHub

    绑定GitHub第三方账户获取
  • 分享精英

    成功上传11个资源即可获取
关注 私信 TA的资源
上传资源赚积分or赚钱
最新推荐
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf 50积分/C币 立即下载
1/59
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第1页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第2页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第3页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第4页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第5页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第6页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第7页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第8页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第9页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第10页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第11页
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.pdf第12页

试读结束, 可继续读6页

50积分/C币 立即下载 >