131 lines
6.7 KiB
Markdown
131 lines
6.7 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, all of this implies lots of little things to be built: We would need an accounting system to manage the points, we would need some way to issue these points to the clients, who themselves would need some a way to store and manage their points. Further, there would need to some type of middleware to handle the exchanging of points for cash. Also there is a big question of security...could development staff - either intentionally or unintentionally - wind up giving away millions in points? Sure, Stacker News could just do all this themselves using SQL, but lets suppose that since they were clever boys & girls, so 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
|
|
|
|
So our client has 1 `StackerNewsDemo-1` token in their wallet (which for our purposes is our pretend airline mile token) and he wants to exchange that for L-BTC. How do we do that?
|
|
|
|
Obviously, 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*
|
|
|
|
Luckily, due to the additional OPCODEs in Liquid, it supports atomic swaps between assets. In fact, Blockstream has a tool to simplify using it (obviously the steps we do here manually with the tool would be automated within the server / client in production).
|
|
|
|
Obviously to do a swap, we will need another wallet, as you can't swap between the same wallet (you can refer to individual wallets in the swap-tool URL connect string by using the `http://user:password@localhost:7041/wallet/walletname` path)
|
|
|
|
In my case, I have 2 nodes each running `elementsd` server (Umbrel and another). So I will use that, 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-1 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
|
|
|
|
# Pegging Out
|
|
|
|
# Discussion
|
|
|
|
## Lightning Integration
|
|
|
|
## Using Liquid with BTC / LN
|
|
|
|
### 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
|
|
|