Confidential Transactions on Liquid

One of the main features of Liquid is its default use of Confidential Transactions. This privacy enhancing feature was first proposed by Adam Back in 2013 and later formalized by Gregory Maxwell, Andrew Poelstra, Adam Back, Mark Friedenbach, and Pieter Wuille.

Confidential Transactions on Liquid allows any two parties to transact without anyone else being able to view the asset (e.g. L-BTC, L-USDt) and amount transacted (not even the Liquid Federation members and functionaries can see this information). Although amounts and assets are confidential by default, the cryptography used on CT still retains the ability for nodes on the Liquid network to validate that the transaction does not inflate the supply of the asset being transacted.

The process by which the amount and type of asset being transferred are cryptographically hidden from everyone (except for the sender, receiver and those they choose to reveal such information to) is called ‘blinding’. Only the receiver alone can decrypt the amount sent in a transaction. However, the receiver has the option to share the private blinding key for a particular transaction with any third party in order for that party to be able to validate the amount and asset type.

Why use Confidential Transactions?

Liquid uses Confidential Transactions, which hides the amounts and asset types within transactions from all third parties. This information is only known by the parties involved in the transaction and other third parties they designate. Liquid transactions use confidential addresses that include a public blinding key and a base address. Only the receiver alone can decrypt the amount sent in a transaction. The receiver can share the private blinding key with any third party in order for that party to be able to validate the amount and asset type (shown below).

Liquid transactions include a transaction fee that is used as a denial of service protection mechanism. Transaction fees are a minimum value of 0.1 satoshi/vByte, but can rise if network congestion increases. Liquid transactions are larger than similar Bitcoin transactions due to “range proofs” that must be included in Confidential Transactions and are used to prove that no outputs are negative values.

The implementation of Confidential Transactions in Liquid has important limitations regarding the amounts of transactions that will be protected: amounts are only completely hidden up to a certain maximum. Starting in Elements 0.18.1.6, the default range proof size is 52 bits. This allows for transactions of amounts of 1 sat up to 2^52-1 sats to look identical. Since Elements does not allow any amount to be greater than 21 million 10^8 sats, all outputs will look identical. Earlier versions of Elements would automatically create larger range proofs for any transaction that required sending more than 687 10^8 sats of any asset, which would reveal that a large amount of the asset likely is being sent. Sending more than 21 million * 10^8 sats of an asset requires creating multiple outputs.

You can see how a confidential transaction appears on the Liquid blockchain here, the details of which are shown below. Expanding the details of the transaction on the Explorer will not show asset or amount details. This is how the transaction appears to everyone on the Liquid network, apart from the sender and receiver.

Unblinding a transaction

In some cases a Liquid user, might want to share the unblinded details of the transaction with a third party, such as an auditor or in order to prove transaction details to another network user.

You can read about how to unblind a transaction here. Although that uses an AMP asset as an example, the page has information that can be applied to any Liquid asset.

The image below shows the same transaction as above but with blinding factors applied and automatically unblinded by the Explorer. The unblinded output can be seen here. You can see that by using the Explorer to unblind the transaction the first output's asset and amount can be seen.

Confidential Transactions - additional resources

• An Every Day Guide to Confidential Transactions
• Elements Confidential Transactions are covered in the Elements Project tutorial.
• You can read about confidential assets in the original whitepaper.
• An Investigation into Confidential Transactions by Adam Gibson.
• Unblinding using AMP (as an issuer).
• Sharing an unblinding link from Blockstream Green.
• Using Libwally to unblind a Liquid transaction.

Asset Issuance on Liquid

Overview

Liquid allows for users to create and transfer other assets using a feature called Issued Assets. These assets can enable applications such as tokenized fiat, tokenized non-BTC cryptocurrency, digital collectibles, reward points and attested assets (e.g. gold coins). The obligations under an issued asset belong to the issuer and Liquid does not verify whether the underlying asset exists or is properly maintained (in contrast to the BTC peg-in procedures).

Asset ID and the Blockstream Asset Registry

Issued Assets in Liquid are given a unique identifier (64 hexadecimal characters) when created. This is the only identifying information of the Issued Asset explicitly recorded on the Liquid blockchain. Any additional human readable metadata to ease Issued Assets recognition at the UI level, can be committed to during the issuance, and is published on servers such as the Asset Registry. The metadata that can be linked to an asset can be:

• NAME The name of the asset as it will appear in the registry and applications that use asset registry data, such as the Blockstream Explorer. Length must be 5 to 255 ASCII characters.
• TICKER Optional field. The ticker you would like to assign to the asset or, in the case of a unique asset such as an NFT, a serial number or human-readable unique string. Length must be 3 to 24 characters. Valid characters are: a-z A-Z 0-9 . and -. If provided, ticker has to be unique when combined with the domain field. If the ticker is empty there is no such constraint.
• DOMAIN The domain that will be used to verify the asset. Must be a valid domain name format and only supports (sub)domain names, for example: example.com or sub.example.com. Do not include the http/s or www prefixes. To verify you control the entity domain name, you’ll need to place a file on your webserver. Note that serving the file with https is required, except for .onion hidden services. The file should be made available at https://<domain>/.well-known/liquid-asset-proof-<asset-id>, with the following contents: Authorize linking the domain name <domain> to the Liquid asset <asset-id>
• ASSET AMOUNT The amount to be issued. It is preferable to consider one satoshi unit as representing one asset. So to issue an amount of 100 of an asset, a value of 0.00000100 should be used. Please note that how this value is displayed within applications that use asset registry data is affected by the PRECISION field.
• TOKEN AMOUNT The amount of reissuance tokens to be created. It is preferable to consider one satoshi unit as representing one reissuance token, so a value of 0.00000001 will create 0.00000001 reissuance tokens and when viewed from Liquid Core it will also show as 0.00000001. When viewed from an app that uses satoshi sized units, such as the Blockstream Explorer it will show as 1. This field is not affected by the PRECISION field.
• PRECISION The precision used to display the asset amount within applications that use Liquid Asset Registry data, such as the Blockstream Explorer. Represents the number of digits after the decimal point, i.e. 0 for non-divisible assets or 8 for BTC-like divisible assets. See the examples below. The default is 0 and the maximum value is 8.
• PUBKEY Holds the public key value that goes into the issuer_pubkey registration data field. The code example derives this from a new address generated by a private key in the node’s wallet.dat file. For safety, this file should be backed up after running the script. Any ECDSA secp256k1 public key could be used in its place, which may be of use when the issuing entity is not the same as the entity running the script. You should ensure that, whatever PUBKEY value you use to set the registration data’s issuer_pubkey field, it is recorded somewhere and that the corresponding private key is backed up for potential future use in authorizing amendments to the registry data. Note that the script sets the PUBKEY variable’s value by calling getaddressinfo with a new address generated by the node’s wallet (line 52). The value of PUBKEY is then used to set the issuer_pubkey registration data field (line 64). The issuer_pubkey data field is used by the Asset Registry to verify ownership when removing or updating registry data in the future.
• COLLECTION An optional field to relate a group of uniquely issued assets, as is often helpful for a collection of NFTs. Length must be 1 to 255 ASCII characters. If sub-categorization is helpful, consider a convention such as a / delimiter, e.g. “Top-level-collection/Sub-collection”.

PRECISION examples:

• A PRECISION value of 0 for an ASSET AMOUNT of 0.00000100 will create 0.00000100 when viewed from Liquid Core and 100 when viewed in an app that uses the asset registry data, which shifts the decimal 0 places left from the sats value.
• A PRECISION value of 2 for an ASSET AMOUNT of 0.00000100 will create 0.00000100 when viewed from Liquid Core and 1.00 when viewed in an app that uses the asset registry data, which shifts the decimal 2 places left from the sats value.
• A PRECISION value of 8 for an ASSET AMOUNT of 0.00000100 will create 0.00000100 when viewed from Liquid Core and 0.00000100 when viewed in an app that uses the asset registry data, which shifts the decimal 8 places left from the sats value. This equates to BTC units.

The default is 0 and the maximum value is 8.

Please note that precision is not taken into account when displaying reissuance token amounts. So if you issue your asset with 1 reissuance token it will always show as 100 000 000 (the amount 1.00 in sats) via Blockstream Explorer and other apps using the registry. In Elements it will show as 1.00000000.

Each asset type can optionally be configured to allow reissuance by generating reissuance tokens when it is created. Assets in Liquid can also be also be verifiably destroyed by their owner to reduce the supply.

The reissuance tokens are used to prove authority and reissue more of the newly created asset at a later date. These tokens can be set up with a multisignature scheme generally described as being “m of n”. That means that the reissuance transaction requires a group of “m” keys in order to create new tokens.

Issued Assets can be used for many different purposes, but some of the most commonly requested ones include tokenized fiat, tokenized equities, and tokenized cryptocurrencies.

Use cases for Issued Assets on Liquid

Security Tokens

Liquid’s Issued Assets feature allows for the creation of tokens representing tradable financial assets, often referred to as securities. These securities can represent things like debt securities (bonds), equity securities ( stocks), or derivatives (futures, options, and swaps). The development of securities tokens on Liquid could involve the combination of smart contracts on chain or other off chain techniques. Issuers of security tokens on Liquid would benefit from Liquid’s security, reliability, privacy, and scalability.

Blockstream AMP is an asset management platform that allows users to issue and manage transfer restricted security tokens, assets or tracked assets on the Liquid Network. It works with Blockstream Green to enable the tracking and optional restriction of transfers between users.

Stablecoins (Tokenized Fiat)

In this scenario, fiat currency is deposited in a bank account and held in trust of an issuer. The issuer generates tokens in Liquid representing the amount of money in that account and distributes the tokens to the depositors of the account. If the owner of one of these tokens wishes to receive fiat currency in return for it, he may redeem through the issuer. The issuer can then destroy the token and maintain an equal supply of fiat currency and outstanding tokens. As more fiat currency is deposited into the account, additional tokens can also be issued by the issuer. The issuer can prove to any auditor or regulator that the amount of outstanding tokens always matches the balance of the bank account. Issuers can also choose to use the scripting feature of Liquid to comply with different regulations around the world without adding any artificial requirements to the functionaries.

Tokenized Cryptocurrencies

While Liquid supports Bitcoin through its Federation, other cryptocurrencies are not natively supported. Very few cryptocurrencies have the track record for stability and security as Bitcoin and it would be risky to include them as part of the consensus rules of the system. Instead, Liquid members can create a token that represents a collateralized cryptocurrency. These tokens can now be traded and settled between Liquid users with the same speed and privacy as Bitcoin and other Issued Assets. This approach also allows exchanges and traders to safely handle these assets without ever needing to support the underlying asset. This removes the amount of work needed to support extra blockchains and clients when supporting other assets. Owners of these tokens could then take the issued token and redeem it from the issuer. This opt-in model allows for users who wish to benefit to work with parties they trust to issue and secure the assets without requiring the entire federation to know about the asset.

Allowing Rapid Transfer of Funds

Using Liquid, exchanges may offer the ability for their users to quickly and privately deposit and withdraw funds. To do this, exchanges will hold a portion of funds on the Liquid Network. When a user wishes to deposit on an exchange, they will request a Liquid deposit address to be generated on their behalf by the exchange. The exchange will then generate a unique Liquid deposit address for this customer. The customer will then take this address to another exchange and request a Liquid withdrawal. The sending exchange will deduct the balance of the customer and send the funds through Liquid to the receiving exchange. When the transaction receives two confirmations, the receiving exchange can credit the user’s account without the risk of having a double-spend, typically in less than three minutes from when the original transaction was sent.

Institutional Traders

Without Liquid, traders must split their funds allocated on different exchanges in order to take advantage of advantageous situations that may emerge within markets. This leaves the trader open to the risk of losing funds on a compromised exchange, and limits the amount that can be traded due to the elongated process of moving funds to another exchange. Moving funds between an exchange can take over an hour, letting trade opportunities potentially slip away.

With Liquid, traders can hold their funds in their own wallet within Liquid and send very quickly to any exchange that supports Liquid deposits to trade within minutes. In this scenario, an exchange sees a trading opportunity at Exchange A and can quickly deposit in around 2 minutes onto an exchange. Once trading is complete, the trader can now move the funds back to their own Liquid wallet or to another exchange. Custodial risk is now moved from a single exchange to the entire Liquid federation.

Asset Issuance - additional resources

• The developer guide for Asset Issuance on Liquid is covered in the Elements Project tutorial.
• Blockstream's Liquid Asset Registry
• You can read about confidential assets in the original whitepaper.