Lightning Network - Revision history

NotATether: Trampoline routing

2026-09-06T07:03:01Z

Trampoline routing

← Older revision		Revision as of 07:03, 6 September 2026
Line 41:		Line 41:

	Later variants use timeout trees, MuSig2 aggregates, and LSP-coordinated ceremonies so many users can share one UTXO while retaining unilateral exit. Factories amortize on-chain footprint compared with opening each channel separately. They do not remove the need for watchful online behavior or backups. Mainnet Lightning still overwhelmingly opens pairwise channels rather than large shared factories.		Later variants use timeout trees, MuSig2 aggregates, and LSP-coordinated ceremonies so many users can share one UTXO while retaining unilateral exit. Factories amortize on-chain footprint compared with opening each channel separately. They do not remove the need for watchful online behavior or backups. Mainnet Lightning still overwhelmingly opens pairwise channels rather than large shared factories.

			== Trampoline routing ==

			'''Trampoline routing''' is a Lightning technique that lets a spender outsource part of pathfinding to intermediate trampoline nodes. The spender builds a route only as far as one or more trampoline hops and embeds a smaller trampoline onion that names the next trampoline or the final destination. Each trampoline node, which maintains a fuller network graph, computes the missing segments and forwards the payment. The design targets lightweight and mobile wallets that cannot sync or search the entire public channel graph.

			The spender constructs an inner trampoline onion carried inside a normal BOLT 4 onion that only needs to reach the first trampoline. That node decrypts its layer, runs local pathfinding, and wraps a new outer onion for the next segment. A single trampoline learns the ultimate destination unless [[#Route blinding\|route blinding]] hides it. Using two or more trampoline hops restores privacy closer to full source routing. Feature bits 56 and 57 advertise trampoline in BOLTs pull requests 829 and 836. The proposal is not yet a merged BOLT. Production use has proceeded ahead of formal merge, notably in the Eclair and Phoenix stack, with later work in Electrum and LDK.

	== Glossary ==		== Glossary ==

NotATether: add Channel factory section (shared UTXO multiparty funding)

2026-09-06T03:33:47Z

add Channel factory section (shared UTXO multiparty funding)

← Older revision		Revision as of 03:33, 6 September 2026
Line 1:		Line 1:
	'''Lightning Network''' is a Layer-2 payment network built from bi-directional [[payment channels]] and [[Hashed Timelock Contracts]] (HTLCs). Payments can be securely routed across multiple peer-to-peer channels so that any peer can pay any other peer even if they do not have a direct channel.<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> Channel open, close, and (hopefully infrequent) dispute transactions settle on the Bitcoin blockchain. Intermediate payments stay off-chain.		'''Lightning Network''' is a Layer-2 payment network built from bi-directional [[payment channels]] and [[Hashed Timelock Contracts]] (HTLCs). Payments can be securely routed across multiple peer-to-peer channels so that any peer can pay any other peer even if they do not have a direct channel.<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> Channel open, close, and (hopefully infrequent) dispute transactions settle on the Bitcoin blockchain. Intermediate payments stay off-chain.

	== Key features ==		== Key features ==
	Key features of the Lightning Network include,		Key features of the Lightning Network include,

Line 35:		Line 35:

	A '''submarine swap''' is a trust-minimized atomic exchange between on-chain bitcoin and Lightning balance. Both legs are locked to the same payment hash. Revealing the preimage claims one leg and enables claiming the other. If either side aborts, timelocks return funds. The construction extends the [[Hashed Timelock Contracts\|HTLC]] pattern so value can move between layers without depositing coins with a custodian and without necessarily opening or closing a channel for the full amount. Swap-in locks on-chain coins and pays a matching Lightning invoice. Swap-out reverses the inventory roles. Timeouts are staggered for safe refunds. Atomicity does not remove fee-spike or privacy risk. [[Replace by fee]] may be needed near timeout. The provider can link the user's on-chain UTXO to that Lightning activity. Related cross-chain ideas appear under [[Atomic swap]].		A '''submarine swap''' is a trust-minimized atomic exchange between on-chain bitcoin and Lightning balance. Both legs are locked to the same payment hash. Revealing the preimage claims one leg and enables claiming the other. If either side aborts, timelocks return funds. The construction extends the [[Hashed Timelock Contracts\|HTLC]] pattern so value can move between layers without depositing coins with a custodian and without necessarily opening or closing a channel for the full amount. Swap-in locks on-chain coins and pays a matching Lightning invoice. Swap-out reverses the inventory roles. Timeouts are staggered for safe refunds. Atomicity does not remove fee-spike or privacy risk. [[Replace by fee]] may be needed near timeout. The provider can link the user's on-chain UTXO to that Lightning activity. Related cross-chain ideas appear under [[Atomic swap]].

			== Channel factory ==

			A '''channel factory''' is a multiparty off-chain construction that funds many Lightning-style [[Payment channels\|payment channels]] from one shared on-chain output. Participants cooperate to open, reallocate, and close channels among themselves without a separate funding transaction for every channel. The classic design is from Burchert, Decker, and Wattenhofer: an n-of-n funding outpoint anchors off-chain allocation transactions whose leaves are two-party channels. Cooperatively, the group can reshuffle balances with new off-chain signatures. Uncooperatively, any party can publish a pre-signed branch after timelocks.

			Later variants use timeout trees, MuSig2 aggregates, and LSP-coordinated ceremonies so many users can share one UTXO while retaining unilateral exit. Factories amortize on-chain footprint compared with opening each channel separately. They do not remove the need for watchful online behavior or backups. Mainnet Lightning still overwhelmingly opens pairwise channels rather than large shared factories.

	== Glossary ==		== Glossary ==

NotATether: add Submarine swap section (on-chain <-> Lightning HTLC)

2026-09-06T00:10:59Z

add Submarine swap section (on-chain <-> Lightning HTLC)

← Older revision		Revision as of 00:10, 6 September 2026
Line 31:		Line 31:

	A '''multipath payment''' (also called a multipart payment) splits one logical Lightning payment into several [[Hashed Timelock Contracts\|HTLC]]s that travel different routes. The receiver settles them together once their amounts sum to the intended total. The widely deployed form is Simplified Multipath Payments (SMP), also called base AMP: all parts share one payment hash and one preimage. An invoice that offers <code>basic_mpp</code> and a <code>payment_secret</code> can be paid with more than one HTLC. The secret binds parts to the invoice. The final-hop onion TLV carries the same <code>payment_secret</code> and <code>total_msat</code> on each part. Intermediate nodes forward each HTLC independently. If the set stays incomplete past a timeout, the receiver fails the parts with <code>mpp_timeout</code>. Shared hashes can correlate parts for observers. Original Atomic Multipath Payments use different hashes and remain less widely deployed.		A '''multipath payment''' (also called a multipart payment) splits one logical Lightning payment into several [[Hashed Timelock Contracts\|HTLC]]s that travel different routes. The receiver settles them together once their amounts sum to the intended total. The widely deployed form is Simplified Multipath Payments (SMP), also called base AMP: all parts share one payment hash and one preimage. An invoice that offers <code>basic_mpp</code> and a <code>payment_secret</code> can be paid with more than one HTLC. The secret binds parts to the invoice. The final-hop onion TLV carries the same <code>payment_secret</code> and <code>total_msat</code> on each part. Intermediate nodes forward each HTLC independently. If the set stays incomplete past a timeout, the receiver fails the parts with <code>mpp_timeout</code>. Shared hashes can correlate parts for observers. Original Atomic Multipath Payments use different hashes and remain less widely deployed.

			== Submarine swap ==

			A '''submarine swap''' is a trust-minimized atomic exchange between on-chain bitcoin and Lightning balance. Both legs are locked to the same payment hash. Revealing the preimage claims one leg and enables claiming the other. If either side aborts, timelocks return funds. The construction extends the [[Hashed Timelock Contracts\|HTLC]] pattern so value can move between layers without depositing coins with a custodian and without necessarily opening or closing a channel for the full amount. Swap-in locks on-chain coins and pays a matching Lightning invoice. Swap-out reverses the inventory roles. Timeouts are staggered for safe refunds. Atomicity does not remove fee-spike or privacy risk. [[Replace by fee]] may be needed near timeout. The provider can link the user's on-chain UTXO to that Lightning activity. Related cross-chain ideas appear under [[Atomic swap]].

	== Glossary ==		== Glossary ==

NotATether: add Multipath payment section (SMP / basic_mpp)

2026-09-05T23:58:16Z

add Multipath payment section (SMP / basic_mpp)

← Older revision		Revision as of 23:58, 5 September 2026
Line 27:		Line 27:

	'''Onion messages''' are a Lightning datagram mechanism specified in BOLT 4. A node sends a Sphinx-encrypted packet along a path of peers without attaching an HTLC. No channel capacity is reserved and no payment hash is required. The packet can carry application TLVs such as an invoice request. Recipients are usually reached through a [[#Route blinding\|blinded path]], so the sender need not know the destination node id. Feature bits 38 and 39 advertise <code>option_onion_messages</code>. A sender may include a blinded <code>reply_path</code> so the recipient can answer without learning the sender's node id. Forwarding is cheaper than HTLCs, so nodes rate-limit and may accept messages only from channel peers (<code>option_onion_messages_only_channels</code>).		'''Onion messages''' are a Lightning datagram mechanism specified in BOLT 4. A node sends a Sphinx-encrypted packet along a path of peers without attaching an HTLC. No channel capacity is reserved and no payment hash is required. The packet can carry application TLVs such as an invoice request. Recipients are usually reached through a [[#Route blinding\|blinded path]], so the sender need not know the destination node id. Feature bits 38 and 39 advertise <code>option_onion_messages</code>. A sender may include a blinded <code>reply_path</code> so the recipient can answer without learning the sender's node id. Forwarding is cheaper than HTLCs, so nodes rate-limit and may accept messages only from channel peers (<code>option_onion_messages_only_channels</code>).

			== Multipath payment ==

			A '''multipath payment''' (also called a multipart payment) splits one logical Lightning payment into several [[Hashed Timelock Contracts\|HTLC]]s that travel different routes. The receiver settles them together once their amounts sum to the intended total. The widely deployed form is Simplified Multipath Payments (SMP), also called base AMP: all parts share one payment hash and one preimage. An invoice that offers <code>basic_mpp</code> and a <code>payment_secret</code> can be paid with more than one HTLC. The secret binds parts to the invoice. The final-hop onion TLV carries the same <code>payment_secret</code> and <code>total_msat</code> on each part. Intermediate nodes forward each HTLC independently. If the set stays incomplete past a timeout, the receiver fails the parts with <code>mpp_timeout</code>. Shared hashes can correlate parts for observers. Original Atomic Multipath Payments use different hashes and remain less widely deployed.

	== Glossary ==		== Glossary ==

NotATether: add Onion messages section (BOLT 4, bits 38/39)

2026-09-04T04:45:02Z

add Onion messages section (BOLT 4, bits 38/39)

← Older revision		Revision as of 04:45, 4 September 2026
Line 23:		Line 23:

	Route blinding is a Lightning technique that hides the last hops of an onion path from the sender. The recipient chooses an introduction node and a path from that node to itself, then replaces each hop's node public key with a blinded key derived by ECDH. The sender builds a normal onion to the introduction point and attaches the blinded tail. Intermediate nodes in the tail learn only the next hop. They do not learn the destination's node id or unannounced channels. The construction is specified as part of BOLT 4. It is also called a blinded path.		Route blinding is a Lightning technique that hides the last hops of an onion path from the sender. The recipient chooses an introduction node and a path from that node to itself, then replaces each hop's node public key with a blinded key derived by ECDH. The sender builds a normal onion to the introduction point and attaches the blinded tail. Intermediate nodes in the tail learn only the next hop. They do not learn the destination's node id or unannounced channels. The construction is specified as part of BOLT 4. It is also called a blinded path.

			== Onion messages ==

			'''Onion messages''' are a Lightning datagram mechanism specified in BOLT 4. A node sends a Sphinx-encrypted packet along a path of peers without attaching an HTLC. No channel capacity is reserved and no payment hash is required. The packet can carry application TLVs such as an invoice request. Recipients are usually reached through a [[#Route blinding\|blinded path]], so the sender need not know the destination node id. Feature bits 38 and 39 advertise <code>option_onion_messages</code>. A sender may include a blinded <code>reply_path</code> so the recipient can answer without learning the sender's node id. Forwarding is cheaper than HTLCs, so nodes rate-limit and may accept messages only from channel peers (<code>option_onion_messages_only_channels</code>).

	== Glossary ==		== Glossary ==

NotATether: LN rewrite: lead, Key features, Routing, Route blinding, See Also

2026-09-04T02:54:58Z

LN rewrite: lead, Key features, Routing, Route blinding, See Also

← Older revision		Revision as of 02:54, 4 September 2026
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. 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>		'''Lightning Network''' is a Layer-2 payment network built from bi-directional [[payment channels]] and [[Hashed Timelock Contracts]] (HTLCs). Payments can be securely routed across multiple peer-to-peer channels so that any peer can pay any other peer even if they do not have a direct channel.<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> Channel open, close, and (hopefully infrequent) dispute transactions settle on the Bitcoin blockchain. Intermediate payments stay off-chain.

	== Key features ==		== Key features ==
	Key features of the Lightning Network ~~proposal~~ include,		Key features of the Lightning Network 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.
Line 10:		Line 10:
	* '''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.
	* '''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.		* '''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 is encrypted in a nested Sphinx packet (BOLT 4) 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 did not 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 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"/>

			== Routing ==

			A Lightning payment that crosses more than one channel is forwarded with a Sphinx onion packet as specified in BOLT 4. Each intermediary learns only the previous hop and the next hop. The sender chooses the path and encrypts nested per-hop payloads. Intermediaries do not learn the originator or the final destination unless they compare records.

			== Route blinding ==

			Route blinding is a Lightning technique that hides the last hops of an onion path from the sender. The recipient chooses an introduction node and a path from that node to itself, then replaces each hop's node public key with a blinded key derived by ECDH. The sender builds a normal onion to the introduction point and attaches the blinded tail. Intermediate nodes in the tail learn only the next hop. They do not learn the destination's node id or unannounced channels. The construction is specified as part of BOLT 4. It is also called a blinded path.

	== Glossary ==		== Glossary ==
Line 63:		Line 71:
	* [[Hashed Timelock Contracts]]		* [[Hashed Timelock Contracts]]
	* [[Off-Chain Transactions]]		* [[Off-Chain Transactions]]
			* [[LNURL]]
			* [[Lightning address]]
			* [[Ephemeral_anchor\|Ephemeral anchor]]
			* [[TRUC]]
	* [https://docs.lightning.engineering/community-resources/resource-list 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].

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 ==