Lightning Network - Revision history

Kschieck: Update "see also" link for lightning lab's list of resources, as it seems it was moved.

2022-07-13T00:24:47Z

Update "see also" link for lightning lab's list of resources, as it seems it was moved.

← Older revision		Revision as of 00:24, 13 July 2022
Line 63:		Line 63:
	* [[Hashed Timelock Contracts]]		* [[Hashed Timelock Contracts]]
	* [[Off-Chain Transactions]]		* [[Off-Chain Transactions]]
	* [~~http~~://~~dev~~.lightning.community/resources/~~index.html~~ Lightning Lab's list of resources]		* [https://docs.lightning.engineering/community-resources/resource-list Lightning Lab's list of resources]
	* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].		* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].
	* [https://www.reddit.com/r/Bitcoin/comments/7pwna9/lightning_network_megathread/ Lightning Network Megathread on Reddit]		* [https://www.reddit.com/r/Bitcoin/comments/7pwna9/lightning_network_megathread/ Lightning Network Megathread on Reddit]

Jackpot mate: Reference was broken. Replaced it with an archive link.

2020-04-15T17:53:36Z

Reference was broken. Replaced it with an archive link.

← Older revision		Revision as of 17:53, 15 April 2020
Line 49:		Line 49:
	* '''Probabilistic Payment:'''<ref>[[Nanopayments]]<br>Bitcoin Wiki contributors<br>Retrieved 2016-04-17</ref> a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See ''PLIPP'' for a specific type of probabilistic payment possible within a Lightning channel.		* '''Probabilistic Payment:'''<ref>[[Nanopayments]]<br>Bitcoin Wiki contributors<br>Retrieved 2016-04-17</ref> a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See ''PLIPP'' for a specific type of probabilistic payment possible within a Lightning channel.
	* '''R:''' the variable commonly used<ref name="ln_pdf"/> in formulas to represent a ''pre-image''.		* '''R:''' the variable commonly used<ref name="ln_pdf"/> in formulas to represent a ''pre-image''.
	* '''Rebalance:'''<ref>[https://blockstream.com/2015/09/01/lightning-network/ The Lightning Network: What Is It and What's Happening?]<br>Rusty Russell<br>Retrieved 2016-04-17</ref> a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See ''bi-directional payment channels.''		* '''Rebalance:'''<ref>[https://web.archive.org/web/20160121161716/https://blockstream.com/2015/09/01/lightning-network/ The Lightning Network: What Is It and What's Happening?]<br>Rusty Russell<br>Retrieved 2016-04-17</ref> a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See ''bi-directional payment channels.''
	* '''Relative locktime:'''<ref name="bip68"/> the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure ''breach remedy transactions'' may be broadcast within a time period starting from when an old ''commitment transaction'' is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.		* '''Relative locktime:'''<ref name="bip68"/> the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure ''breach remedy transactions'' may be broadcast within a time period starting from when an old ''commitment transaction'' is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.
	* '''Revocable Sequence Maturity Contract (RSMC):'''<ref name="ln_pdf"/> a ''contract'' used in Lightning to revoke the previous ''commitment transaction''. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create ''breach remedy transactions'' for the previous commitment transaction. This property allows Lightning to support ''bi-directional payment channels'', recover from failed ''HTLC'' routing attempts without needing to commit to the blockchain, as well as provide advanced features such as ''PILPPs.''		* '''Revocable Sequence Maturity Contract (RSMC):'''<ref name="ln_pdf"/> a ''contract'' used in Lightning to revoke the previous ''commitment transaction''. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create ''breach remedy transactions'' for the previous commitment transaction. This property allows Lightning to support ''bi-directional payment channels'', recover from failed ''HTLC'' routing attempts without needing to commit to the blockchain, as well as provide advanced features such as ''PILPPs.''

Darosior: Corrected a typo

2019-07-19T09:41:05Z

Corrected a typo

← Older revision		Revision as of 09:41, 19 July 2019
Line 12:		Line 12:
	* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).		* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).
	* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivalent on Lightning]<br>Joseph Poon<br>''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.		* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivalent on Lightning]<br>Joseph Poon<br>''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.
	* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as ~~the ability~~ the ability to create time locks.		* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability to create time locks.
	* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.		* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.
	* '''Single-funded channels:''' when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network (whether because she can't reach him or because she doesn't have enough money in an existing channel), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more [[segwit]] virtual bytes to close the channel than he would had he received a non-Lightning direct payment.<ref name="dryja_directed_graph"/>		* '''Single-funded channels:''' when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network (whether because she can't reach him or because she doesn't have enough money in an existing channel), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more [[segwit]] virtual bytes to close the channel than he would had he received a non-Lightning direct payment.<ref name="dryja_directed_graph"/>

BTC10: adding channels value

2019-03-08T22:43:45Z

adding channels value

← Older revision		Revision as of 22:43, 8 March 2019
Line 1:		Line 1:
	'''Lightning Network''' is a proposed implementation of [[Hashed Timelock Contracts]] (HTLCs) with bi-directional [[payment channels]] which allows payments to be securely routed across multiple peer-to-peer payment channels.<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1]<br>Joseph Poon & Thaddeus Dryja<br>''Retrieved 2016-04-10''</ref> This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.		'''Lightning Network''' is a proposed implementation of [[Hashed Timelock Contracts]] (HTLCs) with bi-directional [[payment channels]] which allows payments to be securely routed across multiple peer-to-peer payment channels.<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1]<br>Joseph Poon & Thaddeus Dryja<br>''Retrieved 2016-04-10''</ref> This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other. As of March 2019, there were more than 37,000 channels carrying more than 764 bitcoins.<ref name="p2sh_data">[https://p2sh.info/dashboard/db/lightning-network?orgId=1&from=1514764800000&to=1550915801588 Lightning Network - Sum of channels value]<br>Lightning Network - Sum of channels value<br>''Retrieved 2019-03-08''</ref>

	== Key features ==		== Key features ==

Belcher: /* References */ Add to categories scalability and privacy

2019-02-15T19:52:34Z

References: Add to categories scalability and privacy

← Older revision		Revision as of 19:52, 15 February 2019
Line 74:		Line 74:

	[[Category:Technical]]		[[Category:Technical]]
			[[Category:Scalability]]
			[[Category:Privacy]]

Mercurytoxic: Typos

2019-01-03T06:16:48Z

Typos

Belcher: /* See Also */ Add link to LN megathread on reddit

2018-12-31T16:13:23Z

See Also: Add link to LN megathread on reddit

← Older revision		Revision as of 16:13, 31 December 2018
Line 65:		Line 65:
	* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]		* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]
	* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].		* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].
			* [https://www.reddit.com/r/Bitcoin/comments/7pwna9/lightning_network_megathread/ Lightning Network Megathread on Reddit]

	== References ==		== References ==

Danda: /* See Also */

2018-08-19T04:59:37Z

Harding: Undo revision 65501 by RunCPA (talk)

2018-06-25T21:47:44Z

Undo revision 65501 by RunCPA (talk)

← Older revision		Revision as of 21:47, 25 June 2018
Line 2:		Line 2:

	== Key features ==		== Key features ==
	Key features of the ~~[http://cryptodetail.com/lightning-network-reduces-blockchain-fees~~ Lightning Network] proposal include,		Key features of the Lightning Network proposal include,

	* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.		* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.

RunCPA at 14:56, 25 June 2018

2018-06-25T14:56:56Z

← Older revision		Revision as of 14:56, 25 June 2018
Line 2:		Line 2:

	== Key features ==		== Key features ==
	Key features of the Lightning Network proposal include,		Key features of the [http://cryptodetail.com/lightning-network-reduces-blockchain-fees Lightning Network] proposal include,

	* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.		* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.

← Older revision		Revision as of 06:16, 3 January 2019
Line 9:		Line 9:
	* '''Channels can stay open indefinitely:''' as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.		* '''Channels can stay open indefinitely:''' as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.
	* '''Rapid cooperative closes:''' if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.		* '''Rapid cooperative closes:''' if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.
	* '''~~Outsourcable~~ enforcement:''' if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.		* '''Outsourceable enforcement:''' if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
	* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).		* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).
	* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" ~~Equivilant~~ on Lightning]<br>Joseph Poon<br>''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.		* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivalent on Lightning]<br>Joseph Poon<br>''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.
	* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.		* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.
	* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.		* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.
Line 26:		Line 26:
	* '''Breach Remedy Transaction:'''<ref name="ln_pdf"/> the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using <code>OP_CSV</code>. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).		* '''Breach Remedy Transaction:'''<ref name="ln_pdf"/> the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using <code>OP_CSV</code>. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).
	* '''Channel''' (Lightning channel<ref name="ln_pdf"/>, payment channel<ref name="spillman_channel">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Anti DoS for tx replacement]<br>Jeremy Spillman<br>Retrieved 2016-04-17</ref>) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.		* '''Channel''' (Lightning channel<ref name="ln_pdf"/>, payment channel<ref name="spillman_channel">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Anti DoS for tx replacement]<br>Jeremy Spillman<br>Retrieved 2016-04-17</ref>) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.
	* '''Commitment Transaction:'''<ref name="ln_pdf"/> a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The '''Initial Commitment Transaction'''<ref name="ln_pdf"/> is the first of these transactions; it records the ~~inital~~ balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a ''funding transaction'' for a new channel under the cooperative conditions necessary to create an ''exercise settlement transaction''.		* '''Commitment Transaction:'''<ref name="ln_pdf"/> a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The '''Initial Commitment Transaction'''<ref name="ln_pdf"/> is the first of these transactions; it records the initial balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a ''funding transaction'' for a new channel under the cooperative conditions necessary to create an ''exercise settlement transaction''.
	* '''Contract:'''<ref name="szabo_smart_contracts">[http://szabo.best.vwh.net/smart_contracts_idea.html The Idea of Smart Contracts]<br>Nick Szabo<br>Retrieved 2016-04-17</ref> an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a ''smart contract''.		* '''Contract:'''<ref name="szabo_smart_contracts">[http://szabo.best.vwh.net/smart_contracts_idea.html The Idea of Smart Contracts]<br>Nick Szabo<br>Retrieved 2016-04-17</ref> an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a ''smart contract''.
	* '''CSV:''' (<code>OP_CheckSequenceVerify</code>, <code>OP_CSV</code>)<ref name="bip68"/> a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See ''relative locktime.''		* '''CSV:''' (<code>OP_CheckSequenceVerify</code>, <code>OP_CSV</code>)<ref name="bip68"/> a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See ''relative locktime.''

← Older revision		Revision as of 04:59, 19 August 2018
Line 64:		Line 64:
	* [[Off-Chain Transactions]]		* [[Off-Chain Transactions]]
	* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]		* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]
			* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].

	== References ==		== References ==