<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow noreferrer">BIP 112</a> goes over this:</p>
<blockquote>
<h3><a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#hash-time-locked-contracts" rel="nofollow noreferrer">Hash Time-Locked Contracts</a></h3>
<p>Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.</p>
<h3><a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#bidirectional-payment-channels" rel="nofollow noreferrer">Bidirectional Payment Channels</a></h3>
<p>Scriptable relative locktime provides a predictable amount of time to respond in
the event a counterparty broadcasts a revoked transaction: Absolute locktime
necessitates closing the channel and reopen it when getting close to the timeout,
whereas with relative locktime, the clock starts ticking the moment the
transactions confirms in a block. It also provides a means to know exactly how
long to wait (in number of blocks) before funds can be pulled out of the channel
in the event of a noncooperative counterparty.</p>
<h3><a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#lightning-network" rel="nofollow noreferrer">Lightning Network</a></h3>
<p>The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.<br><br>These channels are based on an anchor transaction that requires a 2-of-2
multisig from Alice and Bob, and a series of revocable commitment
transactions that spend the anchor transaction.  The commitment
transaction splits the funds from the anchor between Alice and Bob and
the latest commitment transaction may be published by either party at
any time, finalising the channel.<br><br>Ideally then, a revoked commitment transaction would never be able to
be successfully spent; and the latest commitment transaction would be
able to be spent very quickly.<br><br>To allow a commitment transaction to be effectively revoked, Alice
and Bob have slightly different versions of the latest commitment
transaction. In Alice's version, any outputs in the commitment
transaction that pay Alice also include a forced delay, and an
alternative branch that allows Bob to spend the output if he knows that
transaction's revocation code. In Bob's version, payments to Bob are
similarly encumbered. When Alice and Bob negotiate new balances and
new commitment transactions, they also reveal the old revocation code,
thus committing to not relaying the old transaction.</p>
</blockquote>
<p>from <a href="https://github.com/bitcoinbook/bitcoinbook#chapters" rel="nofollow noreferrer"><em>Mastering Bitcoin</em></a> (2<sup>nd</sup> ed.) ch. 12, § &quot;<a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc#routed-payment-channels-lightning-network" rel="nofollow noreferrer">Routed Payment Channels (Lightning Network)</a>&quot;:</p>
<p><a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc#routed-payment-channels-lightning-network" rel="nofollow noreferrer"><img src="https://i.sstatic.net/UMUze.png" alt="Step-by-step payment routing through a Lightning Network" /></a></p>

CC BY-SA 4.0
2021-02-23T00:44:28.550Z
That's all correct, but I don't think this answers the question? It's just explaining part of internals of LN.
Pieter Wuille
CC BY-SA 4.0
2021-02-23T00:43:24.510Z
2021-02-23T00:43:24.510Z
Geremia
<p>I don't think LN is very much linked to ElementsProject. Somehow they have similar intent: scaling bitcoin. However they do it in very different ways.</p>
<p>Elements is a federated sidechain, a somehow complete blockchain that bases parts of its security to a federation of entities that create blocks that pegs to the bitcoin blockchain every now and then. Being a separate blockchain, it can support different things than bitcoin: confidential transactions, assets, simplicity script, etc. Moreover, since blocks are created by the federation and there is no mining, blocktime can be a lot shorter (~1s), which leads to low fees and fast settlement.</p>
<p>Lightning Network instead does not rely on somewhat trusted entities to scale bitcoin. It aims to build a payment channel network as a layer on top of bitcoin, relying on it just for the settlement of controversies. It works somehow well, but it brings in quite a bit of complexity and it changes a bit the security model we were used with on the base layer. To keep funds safe, a LN node has to be &quot;always&quot; online or to delegate to external entities (called watchtowers) the job to keep an eye on the blockchain to protect your funds.</p>
<p>Interestingly, there is a nice project  under development that aims to bling most of Element's specific functionality on top of bare bitcoin and LN through the concept of client-side validation. You can find something more on RGB <a href="https://www.rgbfaq.com/faq/untitled" rel="nofollow noreferrer">here</a> and <a href="https://github.com/rgb-org" rel="nofollow noreferrer">here</a></p>

CC BY-SA 4.0
2021-03-11T10:19:55.990Z
2021-03-11T10:19:55.990Z
St3p
<p>How is the <a href="https://elementsproject.org/" rel="nofollow noreferrer">Elements Project</a>'s pegged sidechains concept similar to and different from the <a href="https://lightning.network/" rel="nofollow noreferrer">Lightning Network</a>'s payment channels concept?</p>

CC BY-SA 4.0
2021-02-22T22:18:47.527Z
Loosely related, but probably not a duplicate: https://bitcoin.stackexchange.com/q/101686/5406
Murch
<lightning-network><sidechains><micropaymentchannels><elements>
Pegged sidechain vs. Lightning Network?
Geremia
# Pegged sidechain vs. Lightning Network?

(Asked by: username_0 on 2021-02-22)

How is the [Elements Project](https://elementsproject.org/)'s pegged sidechains concept similar to and different from the [Lightning Network](https://lightning.network/)'s payment channels concept?

**Tags:** lightning-network, sidechains, micropaymentchannels, elements

> **Comments:**
> **username_1**: Loosely related, but probably not a duplicate: https://bitcoin.stackexchange.com/q/101686/5406  

---

## 2 answers

### Answer by username_0 on 2021-02-23. Score: 0

[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) goes over this:

> ### [Hash Time-Locked Contracts](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#hash-time-locked-contracts)
>
> Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.
>
> ### [Bidirectional Payment Channels](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#bidirectional-payment-channels)
>
> Scriptable relative locktime provides a predictable amount of time to respond in
> the event a counterparty broadcasts a revoked transaction: Absolute locktime
> necessitates closing the channel and reopen it when getting close to the timeout,
> whereas with relative locktime, the clock starts ticking the moment the
> transactions confirms in a block. It also provides a means to know exactly how
> long to wait (in number of blocks) before funds can be pulled out of the channel
> in the event of a noncooperative counterparty.
>
> ### [Lightning Network](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#lightning-network)
>
> The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.  
>   
> These channels are based on an anchor transaction that requires a 2-of-2
> multisig from Alice and Bob, and a series of revocable commitment
> transactions that spend the anchor transaction. The commitment
> transaction splits the funds from the anchor between Alice and Bob and
> the latest commitment transaction may be published by either party at
> any time, finalising the channel.  
>   
> Ideally then, a revoked commitment transaction would never be able to
> be successfully spent; and the latest commitment transaction would be
> able to be spent very quickly.  
>   
> To allow a commitment transaction to be effectively revoked, Alice
> and Bob have slightly different versions of the latest commitment
> transaction. In Alice's version, any outputs in the commitment
> transaction that pay Alice also include a forced delay, and an
> alternative branch that allows Bob to spend the output if he knows that
> transaction's revocation code. In Bob's version, payments to Bob are
> similarly encumbered. When Alice and Bob negotiate new balances and
> new commitment transactions, they also reveal the old revocation code,
> thus committing to not relaying the old transaction.

from [*Mastering Bitcoin*](https://github.com/bitcoinbook/bitcoinbook#chapters) (2nd ed.) ch. 12, § "[Routed Payment Channels (Lightning Network)](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc#routed-payment-channels-lightning-network)":

[![Step-by-step payment routing through a Lightning Network](https://i.sstatic.net/UMUze.png)](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc#routed-payment-channels-lightning-network)

> **Comments:**
> **username_2**: That's all correct, but I don't think this answers the question? It's just explaining part of internals of LN.  

---

### Answer by username_3 on 2021-03-11. Score: 0

I don't think LN is very much linked to ElementsProject. Somehow they have similar intent: scaling bitcoin. However they do it in very different ways.

Elements is a federated sidechain, a somehow complete blockchain that bases parts of its security to a federation of entities that create blocks that pegs to the bitcoin blockchain every now and then. Being a separate blockchain, it can support different things than bitcoin: confidential transactions, assets, simplicity script, etc. Moreover, since blocks are created by the federation and there is no mining, blocktime can be a lot shorter (~1s), which leads to low fees and fast settlement.

Lightning Network instead does not rely on somewhat trusted entities to scale bitcoin. It aims to build a payment channel network as a layer on top of bitcoin, relying on it just for the settlement of controversies. It works somehow well, but it brings in quite a bit of complexity and it changes a bit the security model we were used with on the base layer. To keep funds safe, a LN node has to be "always" online or to delegate to external entities (called watchtowers) the job to keep an eye on the blockchain to protect your funds.

Interestingly, there is a nice project under development that aims to bling most of Element's specific functionality on top of bare bitcoin and LN through the concept of client-side validation. You can find something more on RGB [here](https://www.rgbfaq.com/faq/untitled) and [here](https://github.com/rgb-org)


---

