[{"data":1,"prerenderedAt":647},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fcore-tech\u002Flightning-network":3,"docs-surround-\u002Fdocs\u002Fcore-tech\u002Flightning-network":636},{"id":4,"title":5,"body":6,"description":539,"extension":628,"image":629,"meta":630,"navTitle":629,"navigation":631,"path":632,"seo":633,"stem":634,"__hash__":635},"docs\u002Fdocs\u002Fcore-tech\u002FLightning-Network.md","Lightning Network",{"type":7,"value":8,"toc":606},"minimark",[9,14,19,28,41,48,99,103,110,116,121,124,135,139,142,145,153,156,160,163,176,192,198,202,205,215,221,224,228,231,234,268,282,285,313,328,332,335,339,371,374,378,395,399,410,413,417,425,429,432,435,496,500,506,509,516,519,523,526,530,540,543,547,553,564,567,571,577,581,587,590,594,600,603],[10,11,13],"h2",{"id":12},"aka-laser-beam","a.k.a. Laser Beam",[15,16,18],"h1",{"id":17},"what-is-lightning-network","What is Lightning Network",[20,21,22,23,27],"p",{},"As in traditional blockchains (btc-alike), in Beam lightning network two (or more) users lock some funds, and then effectively transfer them ",[24,25,26],"em",{},"off-chain",". This has the following advantages:",[29,30,31,35,38],"ul",{},[32,33,34],"li",{},"Instant. No need to wait for transaction confirmation (after initial setup).",[32,36,37],{},"No transaction fee.",[32,39,40],{},"Hidden. The information about intermediate transactions is never broadcasted. The number of off-chain transactions, frequency and amounts are never revealed.",[20,42,43,44,47],{},"All the transfers are performed in the context of the ",[24,45,46],{},"Lightning channel",". Its lifetime consists of the following:",[49,50,51,67,81],"ol",{},[32,52,53,54],{},"Channel Open\n",[29,55,56,59],{},[32,57,58],{},"Users prepare and broadcast the transaction that consumes their inputs, and create a multi-signed output, which can be spent collectively.",[32,60,61,62,66],{},"At this point each user ",[63,64,65],"u",{},"already has a refund transaction",", which can be used to get the funds back.",[32,68,69,70],{},"Off-chain funds transfers (arbitrary number of times).\n",[29,71,72,75],{},[32,73,74],{},"Users agree on another partition of the locked funds, and generate newer refund transactions, with appropriate amounts to each, which is effectively equivalent to the funds transfer.",[32,76,77,80],{},[63,78,79],{},"Older refund transactions are revoked"," (more about this later). Nothing is broadcasted to the network.",[32,82,83,84],{},"Channel close.\n",[29,85,86,89,92],{},[32,87,88],{},"Each user any moment can broadcast the most recent refund transaction, to get the funds back.",[32,90,91],{},"All the users notice this, and the channel is considered closed.",[32,93,94,95,98],{},"In case the users cooperate and perform a ",[24,96,97],{},"graceful"," channel closure - it'd be faster, and with less fee (more about this later).",[15,100,102],{"id":101},"implementation-in-beam","Implementation in Beam",[20,104,105,106,109],{},"Since there are no scripts in MW, all the relevant functionality is implemented within the context of the transaction negotiation. This is called ",[24,107,108],{},"scriptless scripts",".",[20,111,112,113,109],{},"The actual negotiation flow is somewhat complex, but logically it can be split into separate ",[24,114,115],{},"building blocks",[117,118,120],"h3",{"id":119},"multisig-multisigned-utxo","MultiSig - multisigned UTXO",[20,122,123],{},"An UTXO created by several users, whose blinding factor consists of their blinding factor. Such an UTXO looks indistinguishable from others. The following operations can only be done collectively by all the users:",[29,125,126,129,132],{},[32,127,128],{},"Creating the UTXO (commitment + bulletproof)",[32,130,131],{},"Transaction that creates it (has as an output)",[32,133,134],{},"Transaction that spends it (has as an input)",[117,136,138],{"id":137},"relative-timelock","Relative timelock",[20,140,141],{},"This feature enables to create 2 dependent transactions, whereas the second one becomes valid only after the first one is already accepted in a block, and the block is mature enough. Means - there is a minimum enforced delay between the transactions.\nIt requires a special processing on the node side, and will be available after the planned Hard Fork 1.",[20,143,144],{},"Technically each kernel may optionally contain the Relative Lock info, which consists of:",[29,146,147,150],{},[32,148,149],{},"Kernel ID (hash) being referenced",[32,151,152],{},"Minimum maturity (height difference)",[20,154,155],{},"When such a kernel is encountered the node verifies if indeed the referenced kernel exists in the blockchain, and is mature enough.",[117,157,159],{"id":158},"refund-procedure","Refund procedure",[20,161,162],{},"Refund procedure consists of 2 transactions, which consume the locked funds and create the agreed user outputs.",[49,164,165,168],{},[32,166,167],{},"MultiSig.0 -> MultiSig.N",[32,169,170,171],{},"MultiSig.N -> Outputs.N\n",[29,172,173],{},[32,174,175],{},"Relatively time-locked w.r.t. transaction (1).",[20,177,178,179,183,184,187,188,191],{},"whereas ",[180,181,182],"code",{},"MultiSig.0"," represents the funds locked in the channel, ",[180,185,186],{},"MultiSig.N"," is an intermediate multisigned UTXO, and ",[180,189,190],{},"Outputs.N"," are all the outputs that users are supposed to get by the refund.",[20,193,194,195,197],{},"The transaction (2) is time-locked w.r.t. transaction (1). Means, after (1) was broadcasted, the ",[180,196,186],{}," becomes visible in the blockchain, but the transaction (2) can't be used immediately.\nAs we'll see this is important. In case a malicious user would try to use not the most recently agreed refund procedure, it gives a time window for the affected user to respond.",[117,199,201],{"id":200},"refund-revocation","Refund revocation",[20,203,204],{},"As we said, there is a way to revoke the refund procedure. This should prevent malicious users from trying to use an older refund procedure after a newer agreement was set.",[20,206,207,208,212,213,109],{},"In Beam in order to revoke the N-th refund procedure, the user ",[209,210,211],"strong",{},"reveals its blinding factor"," that was used for ",[180,214,186],{},[20,216,217,218,220],{},"Once the blinding factor was revealed the user won't be able to use the refund procedure. If it does, then after transaction (1) the ",[180,219,186],{}," becomes visible in the blockchain, and the peer can consume it immediately, because it knows the overall blinding factor. Just build and broadcast a transaction immediately that takes it as an input, and creates an output that belongs solely to it, i.e. punish.",[20,222,223],{},"This is why relative timelock is important.",[117,225,227],{"id":226},"multi-user-refund-procedure","Multi-user Refund procedure",[20,229,230],{},"Now let's see how 2 users (A)lice and (B)ob build and use their refund procedures. We'll study the case for 2 users, but it can easily be generalized for arbitrary number of users.",[20,232,233],{},"To build N-th refund procedure (A) and (B) negotiate to build the following transactions:",[29,235,236,244,252,260],{},[32,237,238,239],{},"Refund.N.A.1\n",[29,240,241],{},[32,242,243],{},"MultiSig.0 -> MultiSig.N.A",[32,245,246,247],{},"Refund.N.A.2\n",[29,248,249],{},[32,250,251],{},"MultiSig.N.A -> Outputs.N",[32,253,254,255],{},"Refund.N.B.1\n",[29,256,257],{},[32,258,259],{},"MultiSig.0 -> MultiSig.N.B",[32,261,262,263],{},"Refund.N.B.2\n",[29,264,265],{},[32,266,267],{},"MultiSig.B.A -> Outputs.N",[20,269,270,271,274,275,278,279,281],{},"So there are 4 transactions overall, all of them are built collectively. At the end ",[63,272,273],{},"each user has its own refund procedure",", with different intermediate ",[180,276,277],{},"MultiSig.N.X",", but the final ",[180,280,190],{}," are the same.",[20,283,284],{},"Note the following:",[29,286,287,294,301],{},[32,288,289,290,293],{},"The transaction (1) of each refund procedure is kept ",[209,291,292],{},"private",". Means - only (A) has the Refund.N.A.1, and only (B) has the Refund.N.B.1",[32,295,296,297,300],{},"The transaction (2) of each refund procedure is ",[209,298,299],{},"public",". Means - both (A) and (B) have Refund.N.A.2 and Refund.N.B.2",[32,302,303,304,307,308],{},"The order of transaction building is important. Both (A) and (B) should ",[209,305,306],{},"NOT"," complete their parts of transaction (1) for the peer, before they have the appropriate transaction (2).\n",[29,309,310],{},[32,311,312],{},"Otherwise a malicious user can just use the transaction (1) to lock the funds permanently.",[20,314,315,316,319,320,323,324,327],{},"So, the idea is that (A) and (B) have their own refund procedures, partly kept private. This separation is important, since in case they come to another agreement and create a newer refund procedures - they will need to ",[63,317,318],{},"revoke"," the older ones, which means the appropriate blinding factors of ",[180,321,322],{},"MultiSig.N.A"," and ",[180,325,326],{},"MultiSig.N.B"," must be revealed. As we already mentioned, using a compromised transaction (1) would lead to loss of funds. But, importantly, we must also guarantee that user that gets the revealed blinding factor can't initiate the compromised path on its own. This is the reason why the appropriate transactions (1) are private.",[15,329,331],{"id":330},"lightning-channel-from-the-building-blocks","Lightning channel from the building blocks.",[20,333,334],{},"Conceptually the lightning channel operates the following way:",[117,336,338],{"id":337},"channel-open","Channel open",[49,340,341,344,349,355,368],{},[32,342,343],{},"Users agree on how much funds each of them locks.",[32,345,346,347],{},"Create the ",[180,348,182],{},[32,350,351,352],{},"Build ",[180,353,354],{},"Refund.1",[32,356,357,358,361,362,364,365],{},"Create a transaction ",[180,359,360],{},"Inputs"," -> ",[180,363,182],{}," + ",[180,366,367],{},"Changes",[32,369,370],{},"Wait for confirmation",[20,372,373],{},"Of course the order is important. Users should not make (4) available before they have (3).",[117,375,377],{"id":376},"off-chain-funds-transfer","Off-chain funds transfer",[49,379,380,383,389],{},[32,381,382],{},"Users agree on newer partition of the locked funds.",[32,384,385,386],{},"Negotiate to build ",[180,387,388],{},"Refund.N",[32,390,391,392],{},"Revoke the previous ",[180,393,394],{},"Refund.N-1",[117,396,398],{"id":397},"graceful-channel-closure","Graceful channel closure.",[49,400,401,404],{},[32,402,403],{},"Users agree to close the channel gracefully.",[32,405,357,406,361,408],{},[180,407,182],{},[180,409,190],{},[20,411,412],{},"This scheme makes the withdrawal immediate. No timelocks are needed.",[117,414,416],{"id":415},"one-side-channel-closure","One-side channel closure.",[49,418,419,422],{},[32,420,421],{},"User decides to invoke its refund procedure (in case there's no cooperation)",[32,423,424],{},"User uses its latest refund procedure (all the others are revoked).",[117,426,428],{"id":427},"blockchain-status-monitoring-aka-watch-towers","Blockchain status monitoring (a.k.a. watch towers)",[20,430,431],{},"In addition to the voluntary actions, all the users should monitor the blockchain to detect if\u002Fwhen any of them made one-side actions.\nDepends on the agreed timelock (which is applied in all the relative locks of all the refund procedures) - the monitoring doesn't have to be for each new block. It can be once in many blocks as well.",[20,433,434],{},"Once a new block arrives and the user decides to check the status:",[29,436,437],{},[32,438,439,440,442,443],{},"Does ",[180,441,182],{}," present?\n",[29,444,445,448],{},[32,446,447],{},"Yes - channel is open. No further actions.",[32,449,450,451],{},"No\n",[29,452,453],{},[32,454,455,456],{},"Was the channel open already?\n",[29,457,458,461],{},[32,459,460],{},"No - we're still opening it (waiting for the 1st tx).",[32,462,463,464],{},"Yes - the channel is being closed!\n",[29,465,466,472],{},[32,467,468,469,471],{},"Find one of he ",[180,470,186],{}," that was created for the refund procedures.",[32,473,474,475],{},"Does it belong to the revoked refund?\n",[29,476,477,485],{},[32,478,479,480],{},"Yes - cheat attempt detected!!!\n",[29,481,482],{},[32,483,484],{},"Claim all the funds immediately.",[32,486,487,488],{},"No - valid withdrawal triggered\n",[29,489,490,493],{},[32,491,492],{},"Wait until the timelock expires",[32,494,495],{},"Broadcast the appropriate transaction (2)",[10,497,499],{"id":498},"code-design-minimizing-the-number-of-negotiation-roundtrips","Code design - Minimizing the number of negotiation roundtrips.",[20,501,502,503,505],{},"As we saw, each operation on the Lightning channel requires to prepare many different ",[24,504,115],{},", with dependencies. Some are literally dependent on each other (some of their results are needed by others), whereas for some there are artificial order restrictions to prevent malicious users from doing harm.",[20,507,508],{},"Nevertheless, many such negotiations may run in parallel. At least partially, up to the point where their dependencies come into play.",[20,510,511,512,515],{},"To allow this Beam code infrastructure allows the negotiations in terms of ",[24,513,514],{},"primitives",", each is responsible for a well-defined functionality (such as creating a MultiSig, or a transaction), each has an interface to load\u002Fstore the parameters and transfer the data to the peer.\nWhen those primitives are aggregated to create a more complex negotiation scheme - their inputs\u002Foutputs are \"re-routed\", to reflect their dependency.",[20,517,518],{},"By such the code remains relatively not too complex (readable), the dependencies are visible and can be verified, whereas on the other hand the negotiations effectively run in parallel, and each action is performed in a minimum number of negotiation roundtrips.",[15,520,522],{"id":521},"how-typical-negotiations-look","How typical negotiations look",[20,524,525],{},"Below are the real negotiations produced by our code.",[117,527,529],{"id":528},"multisig","MultiSig",[531,532,537],"pre",{"className":533,"code":535,"language":536},[534],"language-text","    A -> B 115 bytes\n         Partial Commitment\n         Bulletproof T1,T2\n    B -> A 155 bytes\n         Partial Commitment\n         Bulletproof T1,T2\n         Bulletproof TauX\n    B done\n    A done\n","text",[180,538,535],{"__ignoreMap":539},"",[20,541,542],{},"Overall 1 roundtrip, assuming both users get the commitment, but only A has the valid bulletproof",[117,544,546],{"id":545},"refund-one-sided","Refund, one-sided",[531,548,551],{"className":549,"code":550,"language":536},[534],"    A -> B 279 bytes\n         MultiSig.Partial Commitment\n         MultiSig.Bulletproof T1,T2\n         Tx-TLock.Excess Commitment\n         Tx-TLock.Nonce Commitment\n         Tx-Final.Excess Commitment\n         Tx-Final.Nonce Commitment\n    B -> A 1158 bytes\n         MultiSig.Partial Commitment\n         MultiSig.Bulletproof T1,T2\n         MultiSig.Bulletproof TauX\n         Tx-TLock.Excess Commitment\n         Tx-TLock.Nonce Commitment\n         Tx-TLock.Partial Kernel Signature\n         Tx-Final.Excess Commitment\n         Tx-Final.Nonce Commitment\n         Tx-Final.Partial Kernel Signature\n         Tx-Final.Partial Transaction\n    A -> B 925 bytes\n         Tx-Final.Partial Transaction\n    B -> A 52 bytes\n         Tx-TLock.Partial Transaction\n    B done\n    A done\n",[180,552,550],{"__ignoreMap":539},[20,554,555,556,559,560,563],{},"Overall 2 roundtrips. Note that B delays the completion of ",[180,557,558],{},"Tx-TLock"," for A until it gets and validates the ",[180,561,562],{},"Tx-Final"," from it.",[20,565,566],{},"Now let's see how the Lightning channel operations are negotiated.",[10,568,570],{"id":569},"lightning-channel-open","Lightning channel open",[531,572,575],{"className":573,"code":574,"language":536},[534],"    A -> B 591 bytes\n         MultiSig.Partial Commitment\n         MultiSig.Bulletproof T1,T2\n         Tx-Open.Excess Commitment\n         Tx-Open.Nonce Commitment\n         Exit-A.MultiSig.Partial Commitment\n         Exit-A.MultiSig.Bulletproof T1,T2\n         Exit-A.Tx-TLock.Excess Commitment\n         Exit-A.Tx-TLock.Nonce Commitment\n         Exit-A.Tx-Final.Excess Commitment\n         Exit-A.Tx-Final.Nonce Commitment\n         Exit-B.MultiSig.Partial Commitment\n         Exit-B.MultiSig.Bulletproof T1,T2\n    B -> A 1754 bytes\n         MultiSig.Partial Commitment\n         MultiSig.Bulletproof T1,T2\n         MultiSig.Bulletproof TauX\n         Tx-Open.Excess Commitment\n         Tx-Open.Nonce Commitment\n         Tx-Open.Partial Kernel Signature\n         Exit-A.MultiSig.Partial Commitment\n         Exit-A.MultiSig.Bulletproof T1,T2\n         Exit-A.MultiSig.Bulletproof TauX\n         Exit-A.Tx-TLock.Excess Commitment\n         Exit-A.Tx-TLock.Nonce Commitment\n         Exit-A.Tx-TLock.Partial Kernel Signature\n         Exit-A.Tx-Final.Excess Commitment\n         Exit-A.Tx-Final.Nonce Commitment\n         Exit-A.Tx-Final.Partial Kernel Signature\n         Exit-A.Tx-Final.Partial Transaction\n         Exit-B.MultiSig.Partial Commitment\n         Exit-B.MultiSig.Bulletproof T1,T2\n         Exit-B.MultiSig.Bulletproof TauX\n         Exit-B.Tx-TLock.Excess Commitment\n         Exit-B.Tx-TLock.Nonce Commitment\n         Exit-B.Tx-Final.Excess Commitment\n         Exit-B.Tx-Final.Nonce Commitment\n    A -> B 1968 bytes\n         Exit-A.Tx-Final.Partial Transaction\n         Exit-B.MultiSig.Bulletproof TauX\n         Exit-B.Tx-TLock.Excess Commitment\n         Exit-B.Tx-TLock.Nonce Commitment\n         Exit-B.Tx-TLock.Partial Kernel Signature\n         Exit-B.Tx-Final.Excess Commitment\n         Exit-B.Tx-Final.Nonce Commitment\n         Exit-B.Tx-Final.Partial Kernel Signature\n         Exit-B.Tx-Final.Partial Transaction\n    B -> A 977 bytes\n         Exit-A.Tx-TLock.Partial Transaction\n         Exit-B.Tx-Final.Partial Transaction\n    A -> B 52 bytes\n         Exit-B.Tx-TLock.Partial Transaction\n    B -> A 85 bytes\n         Tx-Open.Partial Transaction\n    B done\n    A done\n",[180,576,574],{"__ignoreMap":539},[10,578,580],{"id":579},"lightning-channel-update-funds-transfer","Lightning channel update (funds transfer)",[531,582,585],{"className":583,"code":584,"language":536},[534],"    A -> B 394 bytes\n         Exit-A.MultiSig.Partial Commitment\n         Exit-A.MultiSig.Bulletproof T1,T2\n         Exit-A.Tx-TLock.Excess Commitment\n         Exit-A.Tx-TLock.Nonce Commitment\n         Exit-A.Tx-Final.Excess Commitment\n         Exit-A.Tx-Final.Nonce Commitment\n         Exit-B.MultiSig.Partial Commitment\n         Exit-B.MultiSig.Bulletproof T1,T2\n    B -> A 1477 bytes\n         Exit-A.MultiSig.Partial Commitment\n         Exit-A.MultiSig.Bulletproof T1,T2\n         Exit-A.MultiSig.Bulletproof TauX\n         Exit-A.Tx-TLock.Excess Commitment\n         Exit-A.Tx-TLock.Nonce Commitment\n         Exit-A.Tx-TLock.Partial Kernel Signature\n         Exit-A.Tx-Final.Excess Commitment\n         Exit-A.Tx-Final.Nonce Commitment\n         Exit-A.Tx-Final.Partial Kernel Signature\n         Exit-A.Tx-Final.Partial Transaction\n         Exit-B.MultiSig.Partial Commitment\n         Exit-B.MultiSig.Bulletproof T1,T2\n         Exit-B.MultiSig.Bulletproof TauX\n         Exit-B.Tx-TLock.Excess Commitment\n         Exit-B.Tx-TLock.Nonce Commitment\n         Exit-B.Tx-Final.Excess Commitment\n         Exit-B.Tx-Final.Nonce Commitment\n    A -> B 1968 bytes\n         Exit-A.Tx-Final.Partial Transaction\n         Exit-B.MultiSig.Bulletproof TauX\n         Exit-B.Tx-TLock.Excess Commitment\n         Exit-B.Tx-TLock.Nonce Commitment\n         Exit-B.Tx-TLock.Partial Kernel Signature\n         Exit-B.Tx-Final.Excess Commitment\n         Exit-B.Tx-Final.Nonce Commitment\n         Exit-B.Tx-Final.Partial Kernel Signature\n         Exit-B.Tx-Final.Partial Transaction\n    B -> A 977 bytes\n         Exit-A.Tx-TLock.Partial Transaction\n         Exit-B.Tx-Final.Partial Transaction\n    A -> B 92 bytes\n         Reveal Previous Blinding Factor\n         Exit-B.Tx-TLock.Partial Transaction\n    B -> A 40 bytes\n         Reveal Previous Blinding Factor\n    B done\n    A done\n",[180,586,584],{"__ignoreMap":539},[20,588,589],{},"So, both channel open and funds transfer negotiations are completed in 3 full roundtrips, whereas all the dependencies are observed.",[15,591,593],{"id":592},"demo","Demo",[20,595,596,597],{},"There's a working demo of the Lightning channel in our codebase here: ",[180,598,599],{},"beam\u002Fnode\u002Flaser_beam_demo",[20,601,602],{},"Various scenarios are emulated, such as graceful channel opening and closure, one-side channel closure and appropriate user responses, and the cheat attempt and punishing.",[20,604,605],{},"The node used in the demo is the standard Beam node (no hacks, workarounds, or other tricks specifically for the demo), configured to generate fake PoW. All the broadcasted transactions and timelocks are fully validated.",{"title":539,"searchDepth":607,"depth":607,"links":608},2,[609,622,626,627],{"id":12,"depth":607,"text":13,"children":610},[611,613,614,615,616,617,618,619,620,621],{"id":119,"depth":612,"text":120},3,{"id":137,"depth":612,"text":138},{"id":158,"depth":612,"text":159},{"id":200,"depth":612,"text":201},{"id":226,"depth":612,"text":227},{"id":337,"depth":612,"text":338},{"id":376,"depth":612,"text":377},{"id":397,"depth":612,"text":398},{"id":415,"depth":612,"text":416},{"id":427,"depth":612,"text":428},{"id":498,"depth":607,"text":499,"children":623},[624,625],{"id":528,"depth":612,"text":529},{"id":545,"depth":612,"text":546},{"id":569,"depth":607,"text":570},{"id":579,"depth":607,"text":580},"md",null,{},true,"\u002Fdocs\u002Fcore-tech\u002Flightning-network",{"description":539},"docs\u002Fcore-tech\u002FLightning-Network","87ECtmF8OgOWnVW03dt1kgvfN5A38r7R3D7hEWQYKS0",[637,642],{"title":638,"path":639,"stem":640,"description":641,"children":-1},"Lelantus MW","\u002Fdocs\u002Fcore-tech\u002Flelantus-mw","docs\u002Fcore-tech\u002FLelantus-MW","Linkability is the Achilles' heel of MW.",{"title":643,"path":644,"stem":645,"description":646,"children":-1},"MW CLA","\u002Fdocs\u002Fcore-tech\u002Fmw-cla","docs\u002Fcore-tech\u002FMW-CLA","MW-CLA stands for Mimblewimble Confidential Lelantus Assets",1783006074237]