资源描述：
The Bitcoin Lightning NetworkScalable O -Chain Instant PaymentsJoseph PworkThaddeus Dryjarxawsomnet.orgNovember 20, 2015DRAFT Version 0.5.9.1AbstractThe bitcoin protocol can encompass the global nancial transac-tion volume in all electronic payment systems today, without a singlecustodial third party holding funds or requiring participants to haveanything more than a computer using a broadband connection. Adecentralized system is proposed whereby transactions are sent overa network of micropayment channels a.k.a. payment channels ortransaction channels whose transfer of value occurs o -blockchain.If Bitcoin transactions can be signed with a new sighash type thataddresses malleability, these transfers may occur between untrustedparties along the transfer route by contracts which, in the event of un-cooperative or hostile participants, are enforceable via broadcast overthe bitcoin blockchain in the event of uncooperative or hostile partici-pants, through a series of decrementing timelocks.1 The Bitcoin Blockchain Scalability ProblemThe Bitcoin[1] blockchain holds great promise for distributed ledgers, butthe blockchain as a payment plat, by itself, cannot cover the world’scommerce anytime in the near future. The blockchain is a gossip protocolwhereby all state modi cations to the ledger are broadcast to all partic-ipants. It is through this \gossip protocol“ that consensus of the state,everyone’s balances, is agreed upon. If each node in the bitcoin networkmust know about every single transaction that occurs globally, that may1create a signi cant drag on the ability of the network to encompass allglobal nancial transactions. It would instead be desirable to encompass alltransactions in a way that doesn’t sacri ce the decentralization and securitythat the network provides.The payment network Visa achieved 47,000 peak transactions per sec-ond tps on its network during the 2013 holidays[2], and currently averageshundreds of millions per day. Currently, Bitcoin supports less than 7 trans-actions per second with a 1 megabyte block limit. If we use an average of 300bytes per bitcoin transaction and assumed unlimited block sizes, an equiva-lent capacity to peak Visa transaction volume of 47,000/tps would be nearly8 gigabytes per Bitcoin block, every ten minutes on average. Continuously,that would be over 400 terabytes of data per year.Clearly, achieving Visa-like capacity on the Bitcoin network isn’t fea-sible today. No home computer in the world can operate with that kind ofbandwidth and storage. If Bitcoin is to replace all electronic payments inthe future, and not just Visa, it would result in outright collapse of the Bit-coin network, or at best, extreme centralization of Bitcoin nodes and minersto the only ones who could a ord it. This centralization would then defeataspects of network decentralization that make Bitcoin secure, as the abil-ity for entities to validate the chain is what allows Bitcoin to ensure ledgeraccuracy and security.Having fewer validators due to larger blocks not only implies fewerindividuals ensuring ledger accuracy, but also results in fewer entities thatwould be able to validate the blockchain as part of the mining process,which results in encouraging miner centralization. Extremely large blocks,for example in the above case of 8 gigabytes every 10 minutes on average,would imply that only a few parties would be able to do block validation.This creates a great possibility that entities will end up trusting centralizedparties. Having privileged, trusted parties creates a social trap wherebythe central party will not act in the interest of an individual principal-agent problem, e.g. rentierism by charging higher fees to mitigate theincentive to act dishonestly. In extreme cases, this manifests as individualssending funds to centralized trusted custodians who have full custody ofcustomers’ funds. Such arrangements, as are common today, create severecounterparty risk. A prerequisite to prevent that kind of centralization fromoccurring would require the ability for bitcoin to be validated by a single2consumer-level computer on a home broadband connection. By ensuringthat full validation can occur cheaply, Bitcoin nodes and miners will be ableto prevent extreme centralization and trust, which ensures extremely lowtransaction fees.While it is possible that Moore’s Law will continue inde nitely, andthe computational capacity for nodes to cost-e ectively compute multi-gigabyte blocks may exist in the future, it is not a certainty.To achieve much higher than 47,000 transactions per second usingBitcoin requires conducting transactions o the Bitcoin blockchain itself. Itwould be even better if the bitcoin network supported a near-unlimited num-ber of transactions per second with extremely low fees for micropayments.Many micropayments can be sent sequentially between two parties to en-able any size of payments. Micropayments would enable unbunding, lesstrust and commodi cation of services, such as payments for per-megabyteinternet service. To be able to achieve these micropayment use cases, how-ever, would require severely reducing the amount of transactions that endup being broadcast on the global Bitcoin blockchain.While it is possible to scale at a small level, it is absolutely not possibleto handle a large amount of micropayments on the network or to encompassall global transactions. For bitcoin to succeed, it requires con dence that ifit were to become extremely popular, its current advantages stemming fromdecentralization will continue to exist. In order for people today to believethat Bitcoin will work tomorrow, Bitcoin needs to resolve the issue of blocksize centralization e ects; large blocks implicitly create trusted custodiansand signi cantly higher fees.2 A Network of Micropayment Channels CanSolve Scalability\If a tree falls in the forest and no one is around to hear it, doesit make a sound“The above quote questions the relevance of unobserved events |ifnobody 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 aneveryday recurring transaction, it’s not necessary for all other nodes in the3bitcoin network to know about that transaction. It is instead preferable toonly have the bare minimum of ination on the blockchain. By defer-ring telling the entire world about every transaction, doing net settlementof their relationship at a later date enables Bitcoin users to conduct manytransactions without bloating up the blockchain or creating trust in a cen-tralized counterparty. An e ectively trustless structure can be achieved byusing time locks as a component to global consensus.Currently the solution to micropayments and scalability is to o oadthe transactions to a custodian, whereby one is trusting third party custodi-ans to hold one’s coins and to update balances with other parties. Trustingthird parties to hold all of one’s funds creates counterparty risk and trans-action costs.Instead, using a network of these micropayment channels, Bitcoincan scale to billions of transactions per day with the computational poweravailable on a modern desktop computer today. Sending many paymentsinside a given micropayment channel enables one to send large amountsof funds to another party in a decentralized manner. These channels arenot a separate trusted network on top of bitcoin. They are real bitcointransactions.Micropayment channels[3][4] create a relationship between two par-ties to perpetually update balances, deferring what is broadcast to theblockchain in a single transaction netting out the total balance betweenthose two parties. This permits the nancial relationships between two par-ties to be trustlessly deferred to a later date, without risk of counterpartydefault. Micropayment channels use real bitcoin transactions, only electingto defer the broadcast to the blockchain in such a way that both partiescan guarantee their current balance on the blockchain; this is not a trustedoverlay network |payments in micropayment channels are real bitcoin com-municated and exchanged o -chain.2.1 Micropayment Channels Do Not Require TrustLike the age-old question of whether the tree falling in the woods makes asound, if all parties agree that the tree fell at 245 in the afternoon, then thetree really did fall at 245 in the afternoon. Similarly, if both counterpartiesagree that the current balance inside a channel is 0.07 BTC to Alice and 0.034BTC to Bob, then that’s the true balance. However, without cryptography,an interesting problem is created If one’s counterparty disagrees about thecurrent balance of funds or time the tree fell, then it is one’s word againstanother. Without cryptographic signatures, the blockchain will not knowwho owns what.If the balance in the channel is 0.05 BTC to Alice and 0.05 BTC toBob, and the balance after a transaction is 0.07 BTC to Alice and 0.03BTC to Bob, the network needs to know which set of balances is correct.Blockchain transactions solve this problem by using the blockchain ledgeras a timestamping system. At the same time, it is desirable to create a sys-tem which does not actively use this timestamping system unless absolutelynecessary, as it can become costly to the network.Instead, both parties can commit to signing a transaction and notbroadcasting this transaction. So if Alice and Bob commit funds into a 2-of-2 multisignature address where it requires consent from both parties tocreate spends, they can agree on the current balance state. Alice and Bobcan agree to create a refund from that 2-of-2 transaction to themselves, 0.05BTC to each. This refund is not broadcast on the blockchain. Either partymay do so, but they may elect to instead hold onto that transaction, knowingthat they are able to redeem funds whenever they feel comfortable doing so.By deferring broadcast of this transaction, they may elect to change thisbalance at a future date.To update the balance, both parties create a new spend from the2-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 notknowing 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 thecase of micropayment channels, only two states are required the currentcorrect balance, and any old deprecated balances. There would only be asingle correct current balance, and possibly many old balances which aredeprecated.Therefore, it is possible in bitcoin to devise a bitcoin script wherebyall 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 channel5counterparty. By taking all funds as a penalty to give to the other, all oldtransactions 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 newstates, then the real balance gets updated. The balance is re ected on theblockchain only when a single party disagrees. Conceptually, this system isnot an independent overlay network; it is more a deferral of state on thecurrent system, as the enforcement is still occurring on the blockchain itselfalbeit deferred to future dates and transactions.2.2 A Network of ChannelsThus, micropayment channels only create a relationship between two parties.Requiring everyone to create channels with everyone else does not solve thescalability problem. Bitcoin scalability can be achieved using a large networkof micropayment channels.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 onechannel open on the Bitcoin blockchain, it is possible to create a near-in niteamount of transactions inside this network. The only transactions that arebroadcasted on the Bitcoin blockchain prematurely are with uncooperativechannel counterparties.By encumbering the Bitcoin transaction outputs with a hashlock andtimelock, the channel counterparty will be unable to outright steal fundsand Bitcoins can be exchanged without outright counterparty theft. Fur-ther, by using staggered timeouts, it’s possible to send funds via multipleintermediaries in a network without the risk of intermediary theft of funds.3 Bidirectional Payment ChannelsMicropayment channels permit a simple deferral of a transaction state tobe broadcast at a later time. The contracts are enforced by creating aresponsibility for one party to broadcast transactions before or after certaindates. If the blockchain is a decentralized timestamping system, it is possibleto use clocks as a component of decentralized consensus[5] to determine datavalidity, as well as present states as a to order events[6].6By creating timeframes where certain states can be broadcast andlater invalidated, it is possible to create complex contracts using bitcointransaction scripts. There has been prior work for Hub-and-Spoke Micro-payment Channels[7][8][9] and trusted payment channel networks[10][11]looking at building a hub-and-spoke network today. However, LightningNetwork’s bidirectional micropayment channel requires the malleability soft-fork described in Appendix A to enable near-in nite scalability while miti-gating risks of intermediate node default.By chaining together multiple micropayment channels, it is possibleto create a network of transaction paths. Paths can be routed using a BGP-like system, and the sender may designate a particular path to the recipient.The output scripts are encumbered by a hash, which is generated by therecipient. By disclosing the to that hash, the recipient’s counterpartywill be able to pull funds along the route.3.1 The Problem of Blame in Channel CreationIn 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 TransactionAn initial channel Funding Transaction is created whereby one or both chan-nel counterparties fund the s of this transaction. Both parties createthe s and outputs for this transaction but do not sign the transaction.The output for this Funding Transaction is a single 2-of-2 multisigna-ture script with both participants in this channel, henceforth named Aliceand Bob. Both participants do not exchange signatures for the FundingTransaction until they have created spends from this 2-of-2 output refund-ing the original amount back to its respective funders. The purpose of notsigning the transaction allows for one to spend from a transaction whichdoes not yet exist. If Alice and Bob exchange the signatures from the Fund-ing Transaction without be
展开阅读全文