Pegged sidechain vs. Lightning Network?

Question

How is the Elements Project's pegged sidechains concept similar to and different from the Lightning Network's payment channels concept?

Answer 1

Although Lightning Network is completely different and maybe not best to compare both, things that are easier with Elements or only possible with Elements right now:

1. Issue assets: https://elementsproject.org/elements-code-tutorial/issuing-assets

2. Confidential Transactions (Amounts hidden)

3. Hardware Wallet for Liquid(An implementation of Elements)

4. Tether (USDt)

5. TDEX: Protocol to build decentralized exchange for trading assets issued on Liquid (An implementation of Elements)

6. Simplicity: https://github.com/ElementsProject/simplicity

7. Covenants: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 (Maybe soon possible on Bitcoin as well)

LN is also possible on an implementation of Elements: https://twitter.com/notgrubles/status/1355547472827834373

Answer 2

BIP 112 goes over this:

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

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

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 (2^nd ed.) ch. 12, § "Routed Payment Channels (Lightning Network)":