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


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

Few differences between Lightning Network and Liquid (An implementation of elements) mentioned in https://blog.liquid.net/six-differences-between-liquid-and-lightning/

  1. Transaction size: the size of payment each Lightning channel can process is limited by the size of the initial funding transaction used to set it up. This makes it less likely that, as transaction size increases, a complete pathway from buyer to seller will be found, making the Lightning Network less reliable for large transactions.

    There are no limits to the size of a transaction on the Liquid Network (technically 21 million BTC would be the limit!). A user can peg in as much BTC as needed and start transacting immediately. Recipients also do not need to engage in any channel preparation, they can receive as much as a sender can send. Since Liquid operates on its own blockchain, the number of transactions it can handle is subject to a blocksize limit Fees are currently very cheap (0.1 sats/vbyte for next-block confirmation), but as Liquid adoption grows fees are expected to increase which will make micro transactions unviable on-chain.

  2. Speed: Payments via the Lightning Network can be made almost instantly. Since Lightning payments do not require confirmation on the blockchain they can take place as quickly as an internet connection will allow: potentially allowing for millions of transactions per second.

    New Liquid blocks are produced at regular one-minute intervals—ten times faster than the average Bitcoin block—and two confirmations are required for a transaction to be considered settled. This means that Liquid transactions take around two minutes.

  3. Privacy: a degree of monitoring is still possible with Lightning since individual nodes can record the channel and direction information from transactions they are asked to process. While this method of surveillance has limitations, it still represents a privacy concern.

    In contrast, the Liquid Network’s protocol is designed so that the amount of funds and type of asset transferred are not revealed to anyone other than the sender and recipient. This is made possible by a cutting-edge cryptographic protocol developed by Blockstream called Confidential Transactions.

  4. Trust model: Liquid’s trust model is based on a federation consisting of 15 hardware security modules (HSMs) attached to host servers (known as functionaries). The functioning of the BTC:L-BTC two-way peg relies on two thirds or more of the Federation functionaries acting honestly.

LN privacy issues are also explained in https://abytesjourney.com/lightning-privacy/


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

Step-by-step payment routing through a Lightning Network

  • That's all correct, but I don't think this answers the question? It's just explaining part of internals of LN. – Pieter Wuille Feb 23 at 0:44

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 and here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.