web/docs/liquid/liquid-part3.md
2024-02-06 08:09:05 -06:00

250 lines
18 KiB
Markdown

# DeepDive into Liquid: Part III - Advanced Asset Functions, Peg-Out, Discussion
This is a multipart DeepDive that will focus on the Liquid Sidechain. It will be released in 3 Parts:
* [Part I](https://stacker.news/items/399400): Overview, Installation, and first Peg-In
* [Part II](https://stacker.news/items/407806): Asset Creation and Configuration
* Part III (this): Advanced Topics and Peg-out
# Advanced Asset Topics
[In Part II](https://stacker.news/items/407806), we focused on issuing Assets. Now let's look at the ways you can *use* assets.
One of the most basic use-cases for a custom issued asset is to exchange it for something else. For purposes of discussion, let's assume that a company - say StackerNews Airline - wants to issue their clients "Air Miles" for each flight they take. The idea is clients will accrue these *points* and then be able to exchange them for either discounts off future flights or direct cash (ie. USD / BTC).
If we start thinking like a developer for second, this implies many things to build:
* An accounting system to manage the points
* A way to issue these points to the clients, who themselves would need some a way to store and manage their points
* Middleware to handle the exchanging of points for cash
* Security? How do we secure this? How to reduce fraud as much as possible?
Sure, Stacker News could just do all this themselves using SQL, but lets assume that since they were clever boys & girls, they wanted to do as little of the hard work as possible.
## Atomic Swaps
Liquid would make a great solution for this case. They could direct their users to download one of the existing Liquid wallets[^1] and use the Liquid sidechain as the "accounting system" for their asset.
Suppose our Customer has earned 1 SND token (which for our purposes is our pretend airline mile token) and now he wants to exchange that for L-BTC. How do we do that?
Luckily, in Liquid, Atomic Swaps are supported[^2]. In fact, [Blockstream has a tool](https://github.com/Blockstream/liquid-swap) to simplify using it[^3].
To do a swap we will need another wallet, as you can't swap between the same wallet (technically you can use the *same node* and use 2 different wallets on that node[^4]). In my case, I have 2 nodes each running their own `elementsd` server (Umbrel and my desktop). So I will use those, but you can use a single node by setting up multiple wallets and using distinct URL connect strings for each.
Before we start, let's look at state of our 2 wallets:
```
#Node1 - StackerNews Airline, Inc.
"balance": {
"bitcoin": 0.00131755,
"3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5": 8.00000000
}
#Node2 - The Customer
"balance": {
"bitcoin": 0.00010623,
"3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5": 1.00000000
},
```
The Blockstream Liquid Swap tool mentioned previously works both in CLI and GUI mode. So for this example we will use CLI for Node1 and GUI for Node 2.
The swap offer proposal is: StackerNews Airline (Node 1) is willing to accept a SND token and return to the client 2,300 sats (approx $1 USD currently). So Node1 makes the following proposal:
```
# Node 1 - StackerNews Airline, Inc.
$ liquidswap-cli -u http://$E_RPCUSER:$E_RPCPASS@localhost:7041 propose -o proposal.txt 3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5 1 6f0279e9ed041c3d710a9f57d0c02928416460c4b722ae3457a11eec381c526d 0.000023
```
This file was exported to `proposal.txt` and transferred to Node2 (the customer), which was then inspected:
![](1-part3-clientaccept.png)
We can see that this proposal matches our expectation (1 SND token in exchange for .000023 L-BTC). So Node2 accepts the proposal:
![](1b-part3-clientaccept.png)
The export `accepted.txt` file is transferred back to Node1 where it is finalized and sent.
```
# Node 1 - StackerNews Airline, Inc.
$ liquidswap-cli -u http://$E_RPCUSER:$E_RPCPASS@localhost:7041 finalize accepted.txt -s
{
"broadcast": true,
"txid": "e427ff20ee93b5c9fef74031492357f3fcb535ec834f2035918008d3de406808"
}
```
Now lets review the state our wallets post swap:
```
#Node1 - StackerNews Airline, Inc.
"balance": {
"bitcoin": 0.00129180,
"3e62af3c80c56ab6fec3d1e5646637152afebaf2a86ace075bbb7a88702e1fe5": 9.00000000
}
#Node2 - The Customer
"balance": {
"bitcoin": 0.00012656
},
```
|SWAP SUMMARY| Node 1 (Stacker News) | Node 2 (The Customer) |
|------------|-----------------------|-----------------------|
|Pre-Swap: SND| 8 | 1 |
|Post-Swap: SND| 9 | 0 |
|Pre-Swap: L-BTC| 131755 sat | 10623 sat |
|Post-Swap: L-BTC| 129180 sat | 12656 sat |
|TOTAL FEES PAID| 251 sat | 291 sat |
(NOTE: Obviously the workflow here is a little clunky with the back-and-forth Proposal/Accept/Finalize routine, but I wanted the steps to be transparent. In a production case this would be built into the service and client app such that the proposal and acceptance strings were automatically transferred between the parties.)
## Securities / Transfer Restricted / etc
Liquid supports more advanced features than just Swaps. These features involve the use of AMP (Asset Management Platform), which is an API that allows users to issue and manage digital assets on the Liquid Network.
Here are some of the features AMP enables:
|Asset Type | Description |
|-----------|-------------|
|Tracked Asset | Movement of assets are tracked by AMP. Even though the movements of the Asset are secured within Confidential Transactions (and thus private on the chain), the issuer can see. Ownership can be queried via point-in-time. |
|Transfer Restricted Asset | In addition to all the above features, once an asset is issued to a user, they are restricted from transferring it without specific approval from Issuer. Asset transfers are restricted based on user *Categories*. So for example you could create a Category of user named *Stacker News User* and restrict transfer of these assets only among that group |
By using one of the above concepts, this means AMP can be used in the following use-cases:
* Asset Holder Registry - Since AMP is notified of transfers, so it makes it possible for the Issuer to always know "who has what". Thus, although everything is confidential on the public blockchain (and even among the asset holders), the Issuer can still have visibility into this.
* Share / Ownership Vetting - Because point-in-time moves can be queried, its possible for the Issuer to calculate "how long has User A owned this asset". This enables concepts like "share vetting" (eg. you can only sell your shares after holding for 365 days)
* Paying Dividends - Since you can calculate point-in-time ownership, this makes it possible to use these assets to pay dividends (say for instance your company was to pay .01 BTC in dividends this month, and you calculated that User A held a share for 10 days and User B for 20 days. Thus, you could pay User A .0033 L-BTC and User B .0066 L-BTC)
A full demo of the security features would require their own DeepDive (hint hint). If you would like to read more or see tutorials you can visit [Liquid docs website](https://docs.liquid.net/docs/blockstream-amp-api-tutorial-in-python)
## Lightning Integration
There are two separate topics to go over with Liquid and Lightning. First is *L-BTC Lightning* (that is LN as a 2nd layer to Liquid). Secondly, the more familiar, how to interact with BTC Lightning from Liquid.
The first topic is [covered well by this blog post](https://medium.com/blockstream/getting-started-with-lightning-on-the-liquid-network-8b5682752ffe), effectively you use c-lightning and configure it to use `liquid` as its chain. Then you can open channels from your Elements node and send LN invoices that hold L-BTC (and presumably other assets). While this is interesting, there is no pressing use for it at the moment since we can *already send real BTC* over LN. However, it does highlight the essential "bitcoin nature" of Liquid -- L2's that work with Bitcoin also work with Liquid.
## Using Liquid with BTC / LN
What if you have no desire to create tokens, securities, etc...can you still make use of Liquid?
**Yes, probably one of the best ways to do that is to use it as a *staging area* for opening Lightning channels**. (In fact, both Blockstream Green and the newly announced AQUA both do that under-the-hood[^5]).
Ignoring inbound liquidity issues, lets just look at current pain points in setting up outbound LN channels:
* High fees to open / close
* High fees then force larger minimums for open / close
* Higher channel sizes then increases risk
Looking at this with regard to current fees illustrates the problem pretty clearly.
| | Channel Open Size | Total Fee (sats) | Effective Cost-Basis |
|-|-------------------|------------------|----------------------|
|BTC | 10,000 sat | ~ 12,500 sat | > 100% (NOT POSSIBLE) |
| | 20,000 sat | ~ 12,500 sat | 62.5% |
| | 50,000 sat | ~ 12,500 sat | 25% |
| | 100,000 sat | ~ 12,500 sat | 12.5% |
| | 200,000 sat | ~ 12,500 sat | 6.25% |
| | 500,000 sat | ~ 12,500 sat | 2.5% |
| L-BTC| 10,000 sat | ~ 158 sat | 1.5% |
| | 20,000 sat | ~ 168 sat | 0.8% |
| | 50,000 sat | ~ 198 sat | 0.4% |
| | 100,000 sat | ~ 248 sat | 0.2% |
| | 200,000 sat | ~ 348 sat | 0.1% |
| | 500,000 sat | ~ 648 sat | 0.1% |
You can see that it is *much cheaper* to use L-BTC. In fact its so cheap that its fine to open 25,000 sat channels...thus keeping our hot-wallet exposure risk quite low. (The above was calculated using boltz.exchange )
## Pegging Out
There are a few different solutions for peg-out, but sadly all require a 3rd party.
* Use a CEX (Bitfinex, Bull Bitcoin, Btcturk, BTSE)
* Bisq (defi)
* TDEX (defi)
* sideswap.io (defi)
* Use a wallet that integrates to one of the above (AQUA)
For my case, I will use sideswap.io as a demo.
![](4-part3-pegout.png)
```
$ sudo ~/scripts/app compose elements exec node elements-cli -rpcuser=$E_RPCUSER -rpcpassword=$E_RPCPASS -named sendtoaddress address="VJLGBLED..." amount=0.0011 fee_rate=0.1 assetlabel="bitcoin"
1bf3623924328b22e7b2ae1d7a9fd8bc2879d4cacabd9ba7e2fe0299fe26301e
```
![](4-part3-pegout3.png)
Total cost was about 5500 sats for the peg-out (obviously I waited until it was very cheap). Of that, 5150 sats on BTC layer / 246 on Liquid / 110 sats for sideswap.io service
# Final Discussion and Ideas
Each part of the Bitcoin ecosystem has its strengths and weaknesses, and often they overlap in rather confusing ways. I think it would be helpful to compare the various major initiatives. This is NOT about proclaiming *one is better than the other*, as you can see they each have their own strengths:
## Comparing eCash / Lightning / Liquid / BTC
|| Fedimint / eCash | Lightning | Liquid | BTC |
|-| ------| -------- | -------- | ---- |
|UTXO Model:| No UTXO. Bearer token | Your UTXO is in a multisig. | You own UTXO in sidechain | You own UTXO in mainchain |
|Redemption:| Depends on mint | No dependency (but requires fee) | Depends on 3rd party | No dependency |
|Online:| Must be online to verify eCash token | You must be online to receive. You must stay online (or hire watchtower) to secure channel state | Offline receive | Offline receive |
|TXN Time:| Instant transactions | Instant transactions | Fixed 2 min transactions | Variable ~10 min transactions |
|Fees:| No fees | Negligible fees (msat) | "Low" fees (~200 sats) | High fees (~12,500 sats)|
|Liquidity:| No liquidity management | Must manage liquidity (in/out) | No liquidity management | No liquidity management|
|Privacy:| Mints can aggregate and assemble transaction data | Nodes could aggregate and assemble transaction data | Confidential transactions | Public ledger |
|Counter-Party Risk: | Must vet each Mint | You choose channel partner | Known federation members | Sovereign |
| Frac Reserve Possible: | Yes | No | Verifiable Issues | No |
| Custody Options: | eCash wallet | Single Sig / Hot Wallet | Single Sig / Multi Sig / Hot Wallet / Cold Wallet / Hardware Wallet | Single Sig / Multi Sig / Hot Wallet / Cold Wallet / Hardware Wallet |
| TXN Value Size: | Tied to LN size, but theoretically unlimited | Typical is < 25,000,000 sat | Unlimited | Unlimited |
| Ideal Exposure Time: | days | weeks | months | years (forever) |
|Likely Threat:| Debasement or Mint rug | Loss of funds while offline | Federation censorship | Losing keys / non-spendable UTXO for fees
|Maturity: | 2023-2024 | 2018 | 2018 | 2009
## Building Your Own Federation
One of the biggest issues facing Liquid users is needing to trust the Federation members[^7]. One of the reasons why projects like Fedimint has gained in popularity is the idea of community-run mints. What if such a thing were possible with Liquid?
Well it is in theory. Elements can be used to create your own sidechain.
```
A brief sidebar about the name: **Elements** is the name node software and **Liquid** is the name of the chain. I mention this because its clear that Blockstream envisions a separation between the specific network and the software that runs it. Point being, you could create your own sidechain using Elements (maybe Plasma, in keeping with the elemental names?)
```
The basic process for creating your own sidechain would be:
* Install elements
* Wipe out sidechain data files
* Decide on node discovery ports and search methods (modify node seed list and ports in config)
* Set your sidechain name in config file (replace `-chain=liquidv1` option with custom name)[^8]
* Set your own n-of-m block signing method and set this config files [^9]
* Set your own n-of-m Peg-in script and set this in config file [^10]
* Set `initialfreecoins` to 0 in config file
* Set `defaultpeggedassetname` if you want it to be something other than bitcoin
* Set `initialreissuancetokens` to non-zero so you can issue default assets as peg-ins happen
* Provide config options to connect to BTC node to watch for pegins
In theory, you should now have your own federation on your very own sidechain.
## Final Questions and Thoughts
* Liquid is a good testing ground for new OPCODEs being considered for inclusion into BTC. This allows them to be real-world tested before they make it into BTC. For example many of the advanced OPCODEs that are argued for inclusion into BTC for Covenants / Vaults *already exist* in Liquid[^11]. This transforms Liquid into being something of a "Beta-test" chain for BTC.
* Given the above, proponents of Covenants could use this to help make their case for inclusion into mainchain BTC. The current debate has stalled in a chicken-egg style standoff. One side is saying: *Show us real world use-cases of this solving problems* and the other responding *we first need the OPCODEs to build these things*. A potential solution is for Covenant proponents to go build their use-cases on Liquid.
* Could Fedimints / eCash mints find ways to utilize custom sidechains based on Elements as a way to prove to users that they are not debasing eCash tokens via Frac Reserve? (record eCash issuance as asset issuances on federated sidechain?)
* Could the community spin up our own Federated version of Liquid?
* On **Federation Trusting**. The most hotly debated topic around Liquid is can we trust the Federation to not censure us? I think these are reasonable concerns (but largely overblown).
- The group Liquid Members includes some of the most traditionally pro-Bitcoin groups.
- Has there ever been a documented case of censorship in its 6+ year existence?
- Given Confidential Transactions, it seems to be fairly trivial to bypass any censorship attemps. Remember, not even Federation Members can know what is being transacted, nor what is held in any individual address.
* Lastly, let's mention the elephant in the room: *Liquid Derangement Syndrome*. A fair number of complaints against Liquid seem to not based on specific technical or security concerns, but almost seems political in nature. Could this just be hate against Blockstream from other corporate entities? Or is it a fear response, based on the perceived power Blockstream has in the industry? I'm not sure to be honest. There are tradeoffs with any L2, and it seems that Liquid offers a very nice balance of security & features for risk taken on. Liquid is not in competition with Bitcoin nor Lightning - rather it is a complimentary. The correct use of Liquid *helps* users utilize LN in smarter and more manageable ways. The Confidential Transactions, enhances privacy for BTC users in that they can "dip into" the sidechain to achieve increased security without needing to leave the Bitcoin ecosystem.
[^1]: BlockStream Green, AQUA, Anser (web wallet), Specter, Marina (web wallet)
[^2]: Atomic Swaps allow parties to exchange different tokens directly without the need for a 3rd party, eliminating most of the risk of fraud and counterparty default.In fact, Blockstream has a tool to simplify using it.
[^3]: Please `git clone` the repo and don't rely on the pre-compiled downloads in repo (they are out of date from source)
[^4]: You can specify to individual wallets in the swap-tool URL connect string by using the `http://user:password@localhost:7041/wallet/walletname` syntax
[^5]: They are using services like Boltz, which allows you to open Lightning Channels with L-BTC. NOTE: [BTCSessions did a great video/review](https://www.youtube.com/watch?v=5kNMJd-Ts2c) of how to use Liquid as a way to very cheaply onboard from fiat as cheap as possible. Summary is Fiat -> CEX -> BTC -> Liquid -> Boltz -> LN. Obviously if your CEX has a LN withdrawal option you don't need all these steps!)
[^6]: Right now fee rate is quite low at 30vb/sat, this figure could easily double or triple!
[^7]: Its worth noting that the Liquid Federation members - as a group - tends to be a collection the most pro-bitcoin focused comanies in the ecosystem.
[^8]: [https://github.com/ElementsProject/elements/blob/master/README.md](https://github.com/ElementsProject/elements/blob/master/README.md)
[^9]: [https://elementsproject.org/elements-code-tutorial/block-creation](https://elementsproject.org/elements-code-tutorial/block-creation)
[^10]: [https://elementsproject.org/elements-code-tutorial/sidechain](https://elementsproject.org/elements-code-tutorial/sidechain)
[^11]: Liquid has enabled OP_CAT, OP_CHECKSIGFROMSTACK (CSFS), OP_INSPECTCURRENTINPUT, OP_INSPECTINPUT, OP_INSPECTOUTPUT, OP_TAPTWEAK, OP_MUL64, OP_DIV64, OP_SCALARADD, and OP_SCALARMUL