143 lines
7.6 KiB
Markdown
143 lines
7.6 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 usecases 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.
|
|
|
|
Liquid would make a great solution for this case. They could simple direct their users to download one of the existing Liquid wallets[^1] and use the Liquid sidechain as the "accounting system" for their asset.
|
|
|
|
## Atomic Swaps
|
|
|
|
In this case, let's 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?
|
|
|
|
We could build some type of webservice that had SQL databases and nodejs files that accept Asset A and then issued Asset B once received...however as we said our StackerNews crew is smart and therefore prefers to do *less hardwork*. Moreover all of the above lends itself to risk of fraud and counterparty default.
|
|
|
|
Luckily, due to the additional OPCODEs 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 (techically 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 point is this can be done one a single node by setting up mutliple wallets and using distinct URL connect strings.
|
|
|
|
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
|
|
},
|
|
```
|
|
|
|
For our example, we can assume that StackerNews Airline (Node 1) is willing to accept a SND token and return to the client 23,000 sats (approx $1 USD currently). So Node1 makes the following proposal
|
|
|
|
```
|
|
# 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 transfered to Node2 (the customer), which was then inspected:
|
|
|
|
|
|
|
|
|
|
We can see that this proposal matches our expectation (1 SND token in exchange for .000023 L-BTC). So Node2 accepts the proposal:
|
|
|
|
|
|
|
|
|
|
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) |
|
|
|------------|-----------------------|-----------------------|
|
|
|SND Pre-Swap| 8 | 1 |
|
|
|SND Post-Swap| 9 | 0 |
|
|
|L-BTC Pre-Swap| 131755 sat | 10623 sat |
|
|
|L-BTC Post-Swap| 129180 sat | 12656 sat |
|
|
|TOTAL FEES PAID| 251 sat | 291 sat |
|
|
|
|
|
|
## Securities / Transfer Restricted / etc
|
|
|
|
## Lightning Integration
|
|
|
|
There are two separate topics to go over with Lightning <-> Liquid. First is *L-BTC Lightning* (that is LN as a 2nd layer to Liquid). Secondly, the more familiar, using regular BTC LN 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 (more user friendly) AQUA both do that under-the-hood. They are using services like Boltz, which allows you to open Lightning Channels with L-BTC.
|
|
|
|
### Comparing eCash / Lightning / Liquid / BTC
|
|
|| 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 (might require fee) | Depends on Federation | No dependecy |
|
|
|Longevity: | Mint must survive | Channels will close at somepoint | Federation must survive | UTXO forever |
|
|
|Online:| Must be online to verify eCash token | You must be online to recieve. 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 | Neglible fees (msat) | "Low" fees (~200 sats) | High fees (~15,000 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 | Absolute public ledger |
|
|
|Federation: | Must vet each Mint | You choose channel partner | Known federation members | Soverign |
|
|
| Frac Reserve Possible: | Yes | No | Verifiable Issues | No |
|
|
|Likely Threat:| Debasement or Mint rug | Theft of funds while offline | Federation censorship | Losing keys / unspendable UTXO for fees
|
|
|Maturity: | 2023-2024 | 2018 | 2018 | 2009
|
|
|
|
## Building Your Own Federation
|
|
|
|
## Pegging Out
|
|
|
|
# Final Discussion and Ideas
|
|
|
|
|
|
|
|
[^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 |