In this section, you will learn how to use the Confidential Transactions feature of Elements.

All addresses in Elements are, by default, blinded using Confidential Transactions, which keep the amount and type of assets transferred visible only to participants in the transaction (and those they choose to reveal the blinding key to), while still cryptographically guaranteeing that no more coins can be spent than are available.

By default, when you create a new address in Elements using the getnewaddress command, it is created as a confidential address.

To demonstrate confidential transactions, we'll have e2 send itself some funds and then attempt to view the transaction from e1. This will demonstrate the confidential nature of transactions in Elements.

Every new address generated by an Elements node is confidential by default. We can demonstrate this by getting e2 to generate a new address.

e2-cli getnewaddress

Note that the address begins with 'e1'. This identifies it as a Confidential Address. Examining the address in more detail using the getaddressinfo command reveals additional details about the address.

e2-cli getaddressinfo <address>

You can see that there is a confidential_key property, which indicates that it is a confidential address.

The confidential_key is the public blinding key, which is added to the confidential address itself. This is the reason why a confidential address is so long.

It also has an associated unconfidential address. If you wish to use regular, non-confidential transactions within Elements, please send assets to this address instead of the one with the 'lq1' prefix.

We can now have e2 send some funds to the address it generated. This will later demonstrate that e1, as it is not one of the transacting parties, will not be able to view the transaction details.

e2-cli sendtoaddress <address>

Note the transaction ID. Confirm the transaction.

e2-cli -generate 101

Looking at the transaction, where e2 sent some funds to itself from the perspective of e2 itself.

e2-cli gettransaction <txid>

Scrolling up the transaction details, you can see that e2 can view the amounts sent and received as well as the asset transacted. You can also see the amountblinder and assetblinder properties, which are used to blind the details from other nodes not involved in the transaction.

To check the details of the same transaction from e1, we first need to get the raw transaction details.

e1-cli getrawtransaction <txid>

That returns raw transaction details. If you look within the vout section, you can see that there are three instances. The first two instances are the receiving and change amounts, and the third is the transaction fee. Of these three amounts, the fee is the only one in which you can see a value, as the fee itself is always unblinded within Elements.

What the first two VOUT sections show are "blinded ranges” of the value amounts and the commitment data, which acts as proof of the actual amount and type of asset transacted.

Even if we were to import e2's private key into e1's wallet, it would still not be able to see the amounts and type of asset transacted because it still has no knowledge of the blinding key used by e2. We'll prove this by importing the private key used by e2's wallet into e1's. First, we need to export the key from e2

e2-cli dumpprivkey <address>

Then import it into e1.

e1-cli importprivkey <privkey>

Now we can prove that e1 can still not see the values.

e1-cli gettransaction <txid>

Indeed, it shows 0 as the tx amount when it was actually 1.

To view the actual, unblinded value, we need the blinding key. To do this, we first export the blinding key from e2.

e2-cli dumpblindingkey <address>

Then import it into e1.

e1-cli importblindingkey <address> <blinding key>

Now, when we get the transaction details from e1.

e1-cli gettransaction <txid>

It shows that with the blinding key imported, we can now view the actual value of 1 within the transaction.

In this section, we've seen that the use of a blinding key hides the amount and type of assets in a transaction, and that by importing the right blinding key, we can reveal those values. In practical use, a blinding key may, for example, be given to an auditor, should there be a need to verify the amounts and types of assets held by a party. The Confidential Transactions feature of Elements also allows for “range proofs” to be performed. Range proofs can prove that an amount of an asset is held within a given range, without the need to expose the actual amount itself.

We have also seen that Confidential Transactions are optional, but enabled by default when a new address is generated.

That's it for this lesson; good luck on the quiz, and see you in the next one!