Skip to content

Commit

Permalink
Fix linter issues
Browse files Browse the repository at this point in the history
  • Loading branch information
@psgreco
psgreco committed Aug 8, 2023
1 parent bfe344c commit adbdb3d
Showing 1 changed file with 43 additions and 43 deletions.
86 changes: 43 additions & 43 deletions doc/elements-confidential-transactions.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
This document provides an overview and introduction to
the Confidential Assets implementation in Elements. A list of relevant
RPCs is provided as well as a list of references providing further
information.
information.

A working knowledge of Bitcoin and Elements, familiarity with Elements
Remote Procedure Calls (RPCs), and some knowledge of the cryptography
Expand All @@ -15,14 +15,14 @@ used in Bitcoin are assumed.
## Overview of Confidential Assets

Using Elements, the sender of a transaction can hide the amounts and
types of assets in a transaction’s outputs, in such a way that:
types of assets in a transaction’s outputs, in such a way that:

1. Only the sender and receiver of the transaction can see the actual
amounts and types of assets.
2. A verifier can prove that all assets coming out of a transaction
went into it.
went into it.
3. The amounts and assets of the outputs may be revealed to a third
party, by the receiver or by the sender.
party, by the receiver or by the sender.

This feature is called Confidential Assets. To create a confidential
assets transaction, the recipient generates a Confidential Address and
Expand All @@ -34,10 +34,10 @@ transaction's outputs at will. The unblinding process is called
"rewinding", or "rewinding the range proof", and requires the private
blinding key of the confidential address. Either the sender or a
receiver may also share a blinding key with a third party, enabling
them to view, but not to spend, the transaction's outputs.
them to view, but not to spend, the transaction's outputs.

Confidential Assets transactions do not conceal the transaction ids or indexes on
the inputs (the transaction graph is public, as it is with Bitcoin).
the inputs (the transaction graph is public, as it is with Bitcoin).

A Confidential Transaction must also include an explicit (unblinded)
fee output, paid in the sidechain's default asset (L-BTC for Liquid).
Expand Down Expand Up @@ -75,7 +75,7 @@ having to see the actual value.
When assets are blinded in a transaction, a verifier cannot see which
input assets are sent to which outputs. A Surjection proof [^2] allows
a verifier to prove that an output’s asset appears in at least one
input, without revealing the actual asset type. In other words, the
input, without revealing the actual asset type. In other words, the
mapping from input assets to the output asset must be an "onto" function, or a
"surjection". Every blinded transaction output has a Surjection
proof.
Expand Down Expand Up @@ -123,14 +123,14 @@ possible to send more than 21 million in any one unconfidential output. The ran
proof parameters are not part of consensus, and may be overridden and
adjusted using the `ct_bits` elements configuration parameter. Reducing
the number of bits will reduce the size of a transaction, and also
reduce the maximum provable value of any output.
reduce the maximum provable value of any output.

An Elements range proof is a Borromean ring signature [^4] over
possible values of each digit in the base 4 representation of an
output value. Each digit requires the storage of 4+1 elliptic curve
points. Not including a fixed size header for the range proof, the
space required for a range proof in Elements is approximately 80 bytes
per bit of precision (default 52).
per bit of precision (default 52).

The [secp256k1-zkp range proof implementation](https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/include/secp256k1_rangeproof.h)
supports a maximum range of 64 bits. A range proof supporting a 64 bit
Expand Down Expand Up @@ -159,12 +159,12 @@ A confidential address combines a segwit address and a public blinding
key into a single checksummed string. This address format is called
"blech32" and is based on the "bech32" format that was introduced for
segwit. Liquid production addresses use the prefix "lq1". Liquid
regtest (elementsregtest) addresses use the prefix "el1".
regtest (elementsregtest) addresses use the prefix "el1".

By default, the Elements RPC `getnewaddress` will return a
confidential address. A non-confidential segwit address and a public
blinding key may be combined with the RPC `createblindedaddress` to
create a confidential address.
create a confidential address.

See the python script [../test/functional/test_framework/liquid_addr.py](../test/functional/test_framework/liquid_addr.py)
for a reference implementation of blech32 addresses.
Expand All @@ -173,7 +173,7 @@ for a reference implementation of blech32 addresses.
## Workflow Considerations

The steps for manually creating a confidential transaction using
Elements RPCs are as follows:
Elements RPCs are as follows:

1. `createrawtransaction` – adds inputs and outputs to an empty
transaction. Any outputs using confidential addresses will be blinded.
Expand Down Expand Up @@ -202,45 +202,45 @@ zero-valued output.
An asset issuance creates a non-zero amount of a new asset, and zero
or more reissuance token that may be used to create more of the same
asset at a later time. Reissuance tokens are also called "inflation
keys".
keys".

In Elements, there are four types of transaction inputs:

1. "typical" inputs that spend UTXOs
2. coinbase inputs
3. peg-ins
4. asset issuances/reissuances.
4. asset issuances/reissuances.

An asset issuance input defines the ID of a new asset, some non-zero amount
of the asset to be issued, and zero or more reissuance tokens. While
the ID of the asset must be explicit (it is a property derived
from the issuance itself), the amount of the asset issued and the
number of reissuance tokens may be blinded in the input.
number of reissuance tokens may be blinded in the input.

An asset reissuance input issues an additional amount of an existing
asset. The ID of the asset being reissued cannot be blinded, but the
amount of additional asset being created can be blinded in the input.
amount of additional asset being created can be blinded in the input.

The range proofs for an input's issuance and reissuance amounts are
stored in the input witness.
stored in the input witness.

The non-fee outputs of an issuance transaction, as in any transaction
in Elements, may be blinded. There will be at least one output for the
new asset, an explicit (unblinded) output for the transaction fee, an
optional change output, and optionally at least one output for
reissuance tokens.
reissuance tokens.

See the elements transaction format document
[elements-tx-format.md](./elements-tx-format.md) for more information.

The private key used to blind the amount of an issuance or reissuance
input may be revealed or imported into an Elements wallet, using the
RPCs `dumpissuanceblindingkey` or `importissuanceblindingkey`,
respectively.
respectively.

In summary, the id of an issued or reissued asset is always explicit,
but the issued amounts and destinations may be blinded and kept
confidential.
confidential.


## Partially Signed Elements Transactions (PSET)
Expand All @@ -249,21 +249,21 @@ Partially Signed Bitcoin Transactions (PSBT) is a document standard
that allows multiple parties to construct and sign a bitcoin
transaction offline, before broadcasting it. Elements expands on PSBT
to provide support for assets and confidential transactions, with
Partially Signed Elements Transactions (PSET).
Partially Signed Elements Transactions (PSET).

Several Elements RPCs provide support for working with PSETs. Note
that the PSET RPCs in Elements retain "psbt" in their names of RPCs
adapted from Bitcoin core.
adapted from Bitcoin core.

A description of PSET is outside the scope of this document. Please
see [pset.mediawiki](./pset.mediawiki) for more information.


## Elements RPCs

RPCs that are directly related to Confidential Transactions are listed
here in the groups listed in the Elements help text. Note that some raw
transaction RPCs appear in the Wallet section. See the Elements RPC help
RPCs that are directly related to Confidential Transactions are listed
here in the groups listed in the Elements help text. Note that some raw
transaction RPCs appear in the Wallet section. See the Elements RPC help
for details on parameters and invocation.


Expand Down Expand Up @@ -306,7 +306,7 @@ Blinds the outputs of a raw transaction (as might be created by
`rawblindrawtransaction`
Blinds the outputs of a raw transaction (as might be created by
`createrawtransaction`). This RPC requires that all blinding factors be
provided explicitly.
provided explicitly.


### Wallet - Keys and Addresses
Expand All @@ -315,28 +315,28 @@ provided explicitly.
By default, generates a confidential address encoded as blech32 (see
"Confidential Addresses" section above). The public key is embedded in
the address along with the ScriptPubKey. A confidential address is a
tuple (confidential_key, unconfidential address).
tuple (confidential_key, unconfidential address).

`getaddressinfo`
Displays the (public) confidential and unconfidential properties of an address.

`dumpblindingkey`
Reveals the private blinding key for a confidential address. A
third-party will need this key to unblind transactions (see
"Third-party Unblinding" below).
"Third-party Unblinding" below).

`dumpissuanceblindingkey`
Reveals the private blinding key that was used to blind the amounts on
an issuance input. This key is required when using reissuance tokens.
an issuance input. This key is required when using reissuance tokens.

`dumpmasterblindingkey`
Reveals the wallet's master blinding key from which all blinding keys for generated addresses are derived. See SLIP-007.

`importaddress`
A confidential address may be imported at any time. However, in order
to unblind outputs for a confidential address, it is necessary to also
import the blinding key for that address' public blinding key
(called "confidential_key" in the RPC help).
import the blinding key for that address' public blinding key
(called "confidential_key" in the RPC help).
See the `importblindingkey` RPC.

`importblindingkey`
Expand All @@ -345,7 +345,7 @@ Imports the private blinding key associated with an address.
`importissuanceblindingkey`
Imports a private blinding key that may be used to unblind the amounts
on an issuance input or to reissue additional amounts of an asset (using
reissuance tokens).
reissuance tokens).

`importmasterblindingkey`
***Use with caution!*** Importing a master blinding key into a wallet will
Expand All @@ -371,10 +371,10 @@ A third-party may be granted the ability to unblind the amounts and
assets in a confidential transaction, without being able to spend the
transaction’s UTXOs. Using Elements, the third-party would create a
"watch-only wallet" for the addresses in question, and import the
private blinding keys for those addresses.
private blinding keys for those addresses.

Let's suppose that Alice has sent a confidential transaction to
Bob. Bob wants Victor to be able to see what and how much was sent.
Bob. Bob wants Victor to be able to see what and how much was sent.

Victor, with Bob’s help, creates a watch-only wallet in Elements:

Expand All @@ -388,19 +388,19 @@ Victor, with Bob’s help, creates a watch-only wallet in Elements:

Once the blinding key is imported, the Elements wallet will treat the
Confidential address address as watch-only, and its outputs will be
visible in transaction details and in the wallet balance.
visible in transaction details and in the wallet balance.

Please note that if Bob reuses an address A, Victor will also be able
to see the amounts and values in any transaction sending to A.
to see the amounts and values in any transaction sending to A.

Alternatively, a watch-only wallet may import the master blinding key
of another wallet. The watch-only wallet would then be able to view
the UTXOs for any confidential address created by the original
wallet.
wallet.

Anyone with the blinding key for an output's confidential address can rewind
Anyone with the blinding key for an output's confidential address can rewind
the rangeproof for the output, and reveal the blinding factors and actual amounts and
assets that were committed to.
assets that were committed to.

Please see the [Elements Project
tutorial](https://elementsproject.org/elements-code-tutorial/advanced-examples)
Expand All @@ -412,7 +412,7 @@ for examples of how to unblind with Elements.
An Elements wallet has a "master blinding key", from which all
blinding keys for that wallet are deterministically derived. A
blinding key for an address is generated as `HMAC_SHA256(master
blinding key, <address ScriptPubKey>)`. See SLIP-0077 [^6].
blinding key, <address ScriptPubKey>)`. See SLIP-0077 [^6].

Each confidential address has an associated confidential_key, which is
a public key embedded in the address and used by the sender to create
Expand All @@ -424,7 +424,7 @@ key" for the address.

See
[contrib/assets_tutorial/assets_tutorial.py](../contrib/assets_tutorial/assets_tutorial.py)
for examples of using confidential transactions with assets.
for examples of using confidential transactions with assets.

See
[test/functional/feature_confidential_transactions.py](../test/functional/feature_confidential_transactions.py)
Expand Down Expand Up @@ -462,9 +462,9 @@ Wuille, Greg Maxwell. *Bulletproofs: Short Proofs for Confidential
Transactions and
More.* https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8418611
Retrieved 2023-03-08.

6. SLIP-077 Proposal for wallet blinding key
derivation. https://github.com/satoshilabs/slips/blob/master/slip-0077.md
derivation. https://github.com/satoshilabs/slips/blob/master/slip-0077.md


## See Also
Expand Down

0 comments on commit adbdb3d

Please sign in to comment.