---
dip-ct.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-ct.md b/dip-ct.md
index bba00f50..c5cda4ee 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -271,7 +271,7 @@ The Discrete Logarithm Problem (DLP) means that if `Q = d*G` (or `Q = G^d` in mu
### New consensus rules for CTs
-The activation of these new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals to activate this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP32) is mined, then these consensus rules will activate at `activation_height`, which we will call `heightCT` in this DIP. If the block height of the full node is less than `heightCT` then the following consensus rules will not be active. When the block reaches `heightCT` these rules will become active.
+The activation of these new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals to activate this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP23) is mined, then these consensus rules will activate at `activation_height`, which we will call `heightCT` in this DIP. If the block height of the full node is less than `heightCT` then the following consensus rules will not be active. When the block reaches `heightCT` these rules will become active.
* If height is at least `heightCT` and if at least one input of a CT is confidential, at least one of the outputs must also be confidential. This prevents metadata leaking about the exact amount in a confidential output. A confidential output may have an amount equal to zero.
* If height is at least `heightCT` and if all inputs are public, i.e. not confidential, the number of confidential outputs must be zero or greater than or equal to two, i.e. having all public inputs with a single confidential output is not allowed, as it leaks the metadata about exactly how much value is in the confidential output.
From 7389c2738b469e75a19a037edd202751e1005076 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Tue, 1 Apr 2025 20:51:46 -0400
Subject: [PATCH 65/92] Include version bytes in address
---
dip-ct.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dip-ct.md b/dip-ct.md
index c5cda4ee..d1f8996b 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -88,8 +88,8 @@ These new CT addresses require a different prefix to identify them as different
The exact structure of a CT address is as follows. It contains the following data:
- * Blinding key version byte
- * Address type version byte
+ * bkvb - Blinding key version byte
+ * atvb - Address type version byte
* salt (AKA public blinding key) . 32 byte random value
* When Alice sends a transaction to Bob, this public blinding key is used in an ECDH operation by Alice to transmit the actual amount and blinding key of a transaction to Bob
* Note that older Elements documentation called this a "scanning key"
@@ -122,7 +122,7 @@ To clarify, the public key can actually be stored in 32 bytes and one bit, becau
A bech32m encoded CT address can be then generated via
```
-address = bech32m( RIPEMD160( SHA256( salt + pk ) ) )
+address = bech32m( RIPEMD160( SHA256( bkvb + atvb + salt + pk ) ) )
```
where `+` denotes concatenation. This is described in more detail in the section "Legacy Addresses for P2PKH" of Chapter 4 of "Mastering Bitcoin". This assumes Confidential UTXOs will be stored in P2PKH format.
From 4404138fc7c4c623fec2b2a115b255922d5cab91 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Tue, 1 Apr 2025 21:01:13 -0400
Subject: [PATCH 66/92] Only the pubkey in an address is hashed
---
dip-ct.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-ct.md b/dip-ct.md
index d1f8996b..80eed99b 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -122,7 +122,7 @@ To clarify, the public key can actually be stored in 32 bytes and one bit, becau
A bech32m encoded CT address can be then generated via
```
-address = bech32m( RIPEMD160( SHA256( bkvb + atvb + salt + pk ) ) )
+address = bech32m( bkvb + atvb + salt + RIPEMD160( SHA256( pk ) ) )
```
where `+` denotes concatenation. This is described in more detail in the section "Legacy Addresses for P2PKH" of Chapter 4 of "Mastering Bitcoin". This assumes Confidential UTXOs will be stored in P2PKH format.
From 4b0aa434386f4e2cf2fdb6549652eb4d0c509509 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Tue, 1 Apr 2025 21:12:05 -0400
Subject: [PATCH 67/92] Give an example of what a confidential address looks
like
---
dip-ct.md | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/dip-ct.md b/dip-ct.md
index 80eed99b..4773ec88 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -125,7 +125,13 @@ A bech32m encoded CT address can be then generated via
address = bech32m( bkvb + atvb + salt + RIPEMD160( SHA256( pk ) ) )
```
-where `+` denotes concatenation. This is described in more detail in the section "Legacy Addresses for P2PKH" of Chapter 4 of "Mastering Bitcoin". This assumes Confidential UTXOs will be stored in P2PKH format.
+where `+` denotes concatenation. Since the salt is 32 bytes and the output of RIPEMD160 is 20 bytes, the above bech32m encoded address encodes 54 bytes of data. This is described in more detail in the section "Legacy Addresses for P2PKH" of Chapter 4 of "Mastering Bitcoin". This assumes Confidential UTXOs will be stored in P2PKH format.
+
+According to the above specification, a mainnet bech32m encoded Dash Confidential Address will look like this:
+
+```
+Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag77shanjag60ygcaax2g
+```
### Confidential transactions
From f1767da0736f74592f667d87c0e7c6dd66e05a67 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Mon, 7 Apr 2025 12:43:05 -0400
Subject: [PATCH 68/92] Add bech32 python to references
---
dip-ct.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/dip-ct.md b/dip-ct.md
index 4773ec88..627a37dd 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -133,6 +133,8 @@ According to the above specification, a mainnet bech32m encoded Dash Confidentia
Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag77shanjag60ygcaax2g
```
+The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a Human Readable Part of "Dash".
+
### Confidential transactions
A Confidential Transaction contains the following data :
@@ -338,6 +340,7 @@ https://github.com/satoshilabs/slips/blob/master/slip-0077.md
* "Algorithms of Quantum Computation: Discrete Log And Factoring" Peter W. Shor, http://cc.ee.ntu.edu.tw/~rbwu/rapid_content/course/QC/Shor1994.pdf
* "Shor's Algorithm" https://en.wikipedia.org/wiki/Shor's_algorithm
* Bech32m Spec https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
+ * Bech32 and Bech32m Reference Python implementation https://github.com/sipa/bech32/tree/master/ref/python
* DIP23 https://github.com/dashpay/dips/blob/master/dip-0023.md
* BIP9 https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
From 457fab76aebc410f52afd9009c959746db59bc40 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Tue, 8 Apr 2025 09:47:35 -0400
Subject: [PATCH 69/92] Add examples of regtest and testnet confidential
addresses
---
dip-ct.md | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/dip-ct.md b/dip-ct.md
index 627a37dd..c3b8d237 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -135,6 +135,19 @@ Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag7
The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a Human Readable Part of "Dash".
+Similary, a testnet Confidential Address example is:
+
+```
+TDash14nxdx2cxhvr30msmejddq77ae5w6mvkztqz86p084r959t60q46ry5jx6fd4hgjafwuh57y6shzckk8rpxtz8jgpchr5p
+```
+
+and a regtest Confidential Address would be:
+
+```
+RDash1arnq9xp6dzmaqnqw7865kqumxjxtzm3vvjm0w9d594zmufek5hl9xmzmwecpsa5eynm7evw85ssepsrqm5wg9ccyk050e
+```
+
+
### Confidential transactions
A Confidential Transaction contains the following data :
From ca38db4ab9d781202f39669419eafbd58ff01417 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Tue, 22 Apr 2025 10:00:25 -0400
Subject: [PATCH 70/92] Add consensus rules for confidentialAddressBalance
---
dip-ct.md | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/dip-ct.md b/dip-ct.md
index c3b8d237..c2906ebc 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -294,6 +294,17 @@ The Discrete Logarithm Problem (DLP) means that if `Q = d*G` (or `Q = G^d` in mu
The activation of these new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals to activate this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP23) is mined, then these consensus rules will activate at `activation_height`, which we will call `heightCT` in this DIP. If the block height of the full node is less than `heightCT` then the following consensus rules will not be active. When the block reaches `heightCT` these rules will become active.
+#### Consensus rules for blocks
+
+ * If height is at least `heightCT` then :
+ * then block header version must equal 5, else invalid
+ * new block header key `confidentialAddressBalance` must exist, else invalid
+ * `confidentialAddressBalance` must be a valid unsigned 64 bit integer (which stores values in satoshis not whole coin amounts)
+ * `confidentialAddressBalance` must equal the value of `confidentialAddressBalance` from the previous block plus the sum of confidential inputs minus the sum of confidential outputs, else invalid
+ * `confidentialAddressBalance` must be greater than or equal to 0, else invalid
+ * `confidentialAddressBalance` must be less than or equal to 1892000000000000, else invalid
+
+#### Consensus rules for transactions
* If height is at least `heightCT` and if at least one input of a CT is confidential, at least one of the outputs must also be confidential. This prevents metadata leaking about the exact amount in a confidential output. A confidential output may have an amount equal to zero.
* If height is at least `heightCT` and if all inputs are public, i.e. not confidential, the number of confidential outputs must be zero or greater than or equal to two, i.e. having all public inputs with a single confidential output is not allowed, as it leaks the metadata about exactly how much value is in the confidential output.
* If height is less than `heightCT` then Special Transaction type 10 is invalid
From db50a8f0e7b29a2fa605a49bf30f26c2da964b31 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Thu, 1 May 2025 10:57:12 -0400
Subject: [PATCH 71/92] Remove block header version changes
We now store confidentialAddressBalance in the Coinbase special transaction
---
dip-ct.md | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/dip-ct.md b/dip-ct.md
index c2906ebc..0f284d77 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -293,18 +293,14 @@ The Discrete Logarithm Problem (DLP) means that if `Q = d*G` (or `Q = G^d` in mu
### New consensus rules for CTs
The activation of these new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals to activate this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP23) is mined, then these consensus rules will activate at `activation_height`, which we will call `heightCT` in this DIP. If the block height of the full node is less than `heightCT` then the following consensus rules will not be active. When the block reaches `heightCT` these rules will become active.
+
+#### Consensus rules for transactions
-#### Consensus rules for blocks
-
- * If height is at least `heightCT` then :
- * then block header version must equal 5, else invalid
- * new block header key `confidentialAddressBalance` must exist, else invalid
- * `confidentialAddressBalance` must be a valid unsigned 64 bit integer (which stores values in satoshis not whole coin amounts)
+ * If height is at least `heightCT` then the Coinbase Special Transaction must have version >= 4, which contains the new field `confidentialAddressBalance` which is a uint64_t (8 bytes)
+ * `confidentialAddressBalance` must be a valid unsigned 64 bit integer (which stores values in duffs not whole coin amounts)
* `confidentialAddressBalance` must equal the value of `confidentialAddressBalance` from the previous block plus the sum of confidential inputs minus the sum of confidential outputs, else invalid
* `confidentialAddressBalance` must be greater than or equal to 0, else invalid
* `confidentialAddressBalance` must be less than or equal to 1892000000000000, else invalid
-
-#### Consensus rules for transactions
* If height is at least `heightCT` and if at least one input of a CT is confidential, at least one of the outputs must also be confidential. This prevents metadata leaking about the exact amount in a confidential output. A confidential output may have an amount equal to zero.
* If height is at least `heightCT` and if all inputs are public, i.e. not confidential, the number of confidential outputs must be zero or greater than or equal to two, i.e. having all public inputs with a single confidential output is not allowed, as it leaks the metadata about exactly how much value is in the confidential output.
* If height is less than `heightCT` then Special Transaction type 10 is invalid
From 87f4ded53318708e3bc1f05cddb50221bb21efb9 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sat, 3 May 2025 09:14:32 -0400
Subject: [PATCH 72/92] DIP32
---
dip-ct.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-ct.md b/dip-ct.md
index 0f284d77..43702b8a 100644
--- a/dip-ct.md
+++ b/dip-ct.md
@@ -1,5 +1,5 @@
- DIP: XXX
+ DIP: 32
Title: Confidential Transactions
Author: Duke Leto
Comments-Summary: No comments yet.
From 1da233fc34904e078e7aa187c9000fd6332ef38e Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Mon, 5 May 2025 09:29:27 -0400
Subject: [PATCH 73/92] Rename dip-ct.md to dip-0032.md
---
dip-ct.md => dip-0032.md | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename dip-ct.md => dip-0032.md (100%)
diff --git a/dip-ct.md b/dip-0032.md
similarity index 100%
rename from dip-ct.md
rename to dip-0032.md
From 71d67ddf665104d58ad42bfd7600cc42604cd580 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Mon, 5 May 2025 09:43:46 -0400
Subject: [PATCH 74/92] Add DIP32 to README
---
README.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/README.md b/README.md
index ad3f63f8..d38d7c0f 100644
--- a/README.md
+++ b/README.md
@@ -45,6 +45,7 @@ Number | Layer | Title | Owner | Type | Status
[29](dip-0029.md) | Consensus | Randomness Beacon For LLMQ Selection | Virgile Bartolo | Standard | Proposed
[30](dip-0030.md) | Consensus | Replay Attack Prevention and State Transition Nonces | Samuel Westrich | Standard | Proposed
[31](dip-0031.md) | Consensus | Platform Proof of Service | Ivan Shumkov, Pasta | Standard | Proposed
+[32](dip-0032.md) | Consensus | Confidential Transactions | Duke Leto | Standard | Proposed
## License
From 635f22977a2eb643d685f80f1b98b57e1bc61024 Mon Sep 17 00:00:00 2001
From: thephez
Date: Wed, 21 May 2025 17:07:33 -0400
Subject: [PATCH 75/92] style: lint fixes
---
dip-0032.md | 189 ++++++++++++++++++++++++++--------------------------
1 file changed, 93 insertions(+), 96 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index 43702b8a..0efbb604 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -16,7 +16,7 @@
1. [Conventions](#conventions)
1. [Prior Work](#prior-work)
1. [Consensus Protocol Changes](#consensus-protocol-changes)
-1. [Risks](#risks)
+1. [Risks](#risks)
1. [References](#references)
1. [Copyright](#copyright)
@@ -36,7 +36,7 @@ CoinJoin transactions leak large amounts of transaction metadata which is
accessible via public blockchain data and requires users to learn about various
details and advanced options to use it in a privacy-preserving way. The current
CoinJoin implementation also requires users to wait longer for
-increased privacy via more mixing rounds. Most users will have no idea how many rounds they should use or what the
+increased privacy via more mixing rounds. Most users will have no idea how many rounds they should use or what the
implications of this choice will be. This incentivizes users to use fewer mixing
rounds to save time, reducing their privacy as well as the privacy of
all users utilizing CoinJoins.
@@ -44,10 +44,11 @@ all users utilizing CoinJoins.
## Conventions
We will use these abbreviations:
- * BP - Bulletproof, a type of size-optimized rangeproof
- * BP+ - Bulletproof+
- * BP++ - Bulletproof++
- * CT - Confidential Transaction
+
+* BP - Bulletproof, a type of size-optimized rangeproof
+* BP+ - Bulletproof+
+* BP++ - Bulletproof++
+* CT - Confidential Transaction
## Scope
@@ -88,14 +89,14 @@ These new CT addresses require a different prefix to identify them as different
The exact structure of a CT address is as follows. It contains the following data:
- * bkvb - Blinding key version byte
- * atvb - Address type version byte
- * salt (AKA public blinding key) . 32 byte random value
- * When Alice sends a transaction to Bob, this public blinding key is used in an ECDH operation by Alice to transmit the actual amount and blinding key of a transaction to Bob
- * Note that older Elements documentation called this a "scanning key"
- * Note that this value is not hashed, it is stored unchanged as part of the CT address
- * pk . The compressed public key, a 33 byte secp256k1 curve point.
- * Note that a hash of the public key is what is actually included in the address
+* bkvb - Blinding key version byte
+* atvb - Address type version byte
+* salt (AKA public blinding key) . 32 byte random value
+ * When Alice sends a transaction to Bob, this public blinding key is used in an ECDH operation by Alice to transmit the actual amount and blinding key of a transaction to Bob
+ * Note that older Elements documentation called this a "scanning key"
+ * Note that this value is not hashed, it is stored unchanged as part of the CT address
+* pk . The compressed public key, a 33 byte secp256k1 curve point.
+ * Note that a hash of the public key is what is actually included in the address
Every confidential address contains a public blinding key used in ECDH. When Alice sends Bob a transaction, Alice chooses an ECDH ephemeral private key (the ConfidentialNonce in this DIP) and combines it with the public blinding key to derive a blinding seed.
When Bob receives a CT, they combine the public blinding key with the private blinding key (ConfidentialNonce) to derive the same exact seed used by Alice.
@@ -103,7 +104,7 @@ The reason this is possible is because curve operations are commutative, i.e. `A
To show that ECDH allows Alice and Bob to derive the same seed, we must show that the point on the curve `d_A*Q_B` is the same as `d_B*Q_A` :
-```
+```text
d_A*Q_B = d_A * d_B * G # definition of Q_B
= d_B * d_A * G # commutivatity
= d_B * Q_A
@@ -118,10 +119,9 @@ To clarify, the public key can actually be stored in 32 bytes and one bit, becau
The salt is 32 bytes because it is used to "blind" the x value of a (x,y) point on the curve which is 32 bytes. The compressed public key is 33 bytes (or 32 bytes and one bit) as described above and in the "Compressed Public Keys" section of Chapter 4 of "Mastering Bitcoin".
-
A bech32m encoded CT address can be then generated via
-```
+```text
address = bech32m( bkvb + atvb + salt + RIPEMD160( SHA256( pk ) ) )
```
@@ -129,39 +129,38 @@ where `+` denotes concatenation. Since the salt is 32 bytes and the output of RI
According to the above specification, a mainnet bech32m encoded Dash Confidential Address will look like this:
-```
+```text
Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag77shanjag60ygcaax2g
```
-The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a Human Readable Part of "Dash".
+The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a Human Readable Part of "Dash".
Similary, a testnet Confidential Address example is:
-```
+```text
TDash14nxdx2cxhvr30msmejddq77ae5w6mvkztqz86p084r959t60q46ry5jx6fd4hgjafwuh57y6shzckk8rpxtz8jgpchr5p
```
and a regtest Confidential Address would be:
-```
+```text
RDash1arnq9xp6dzmaqnqw7865kqumxjxtzm3vvjm0w9d594zmufek5hl9xmzmwecpsa5eynm7evw85ssepsrqm5wg9ccyk050e
```
-
### Confidential transactions
A Confidential Transaction contains the following data :
- * A 33 byte Pedersen commitment to the amount being transferred for each output
- * A BP rangeproof for each output that ensures the amount transferred is inside a certain interval between 0 and 2^N - 1
- * To support all potential value transfers between 0 and 21M the BP rangeproof needs N equal to 52
- * The exact size of the proof depends on the number of inputs and outputs
- * A fee output with an explicit amount and blank ScriptPubKey
- * A list of input UTXOs
- * A list of one or more outputs
- * These may be normal or Confidential outputs
+* A 33 byte Pedersen commitment to the amount being transferred for each output
+* A BP rangeproof for each output that ensures the amount transferred is inside a certain interval between 0 and 2^N - 1
+ * To support all potential value transfers between 0 and 21M the BP rangeproof needs N equal to 52
+ * The exact size of the proof depends on the number of inputs and outputs
+* A fee output with an explicit amount and blank ScriptPubKey
+* A list of input UTXOs
+* A list of one or more outputs
+ * These may be normal or Confidential outputs
-This DIP proposes using DIP-2 Special Transactions to store and implement Confidential Transactions. This means storing data in the `extra_payload` field of existing Dash transactions and Special Transaction `type` of 10, the currently next unused value of this field. If a transaction contains any non-Confidential inputs or outputs then that data is stored in normal (non-Special) transaction data. The following describes how the confidential inputs and outputs of a transaction can be stored via `extra_payload`.
+This DIP proposes using DIP-2 Special Transactions to store and implement Confidential Transactions. This means storing data in the `extra_payload` field of existing Dash transactions and Special Transaction `type` of 10, the currently next unused value of this field. If a transaction contains any non-Confidential inputs or outputs then that data is stored in normal (non-Special) transaction data. The following describes how the confidential inputs and outputs of a transaction can be stored via `extra_payload`.
#### Variable Length Integer (VarInt)
@@ -240,46 +239,46 @@ The following data structures have been adapted from the Elements Project Transa
| Length | Yes | Varies | `VarInt` | | |
| Value | | Varies | `hex` | Big-endian | Bulletproof which proves that the ConfidentialAmount is within the range of 0 and `2^52 - 1` |
-
#### Pedersen Commitments
A Pedersen commitment can be thought of as a sealed box which is tamper-proof and contains a secret. A physical example of this would be for Alice to seal a message `M` inside an envelope along with a peice of carbon paper, then getting Bob to sign the outside of the envelope, so that the carbon paper copies his signature onto the message `M`. Later on Alice can open the envelope and both Alice and Bob can be assured that the secret message `M` was not changed.
Mathematically a Pedersen commitment (written in additive notation) is defined as
-```
+```text
P(v,s) = v*G + s*Q
```
where
- * P(v,s) means P is a function of the variables v and s
- * v is a value to be committed
- * s is a salt AKA blinding factor
- * G and Q are elliptic curve points on secp256k1 both known to committer and verifier
- * The committer is the creator of a transaction
- * The verifier is any node which processes the transaction to see if it is valid
- * x*Y means multiplication of value x by curve point Y
- * In some references multiplication is implicit, i.e. x*Y = xY
-
-In multiplicative notation the above would be `P(v,s) = G^v*Q^s` where `^` denotes exponentiation. Both notations are describing the exact same equivalent mathematics where additive notation is using `+` as the group operator while multiplicative notation is using `*`. In additive notation `n*G` is equivalent to `G^n` in multiplicative notation.
+* P(v,s) means P is a function of the variables v and s
+* v is a value to be committed
+* s is a salt AKA blinding factor
+* G and Q are elliptic curve points on secp256k1 both known to committer and verifier
+ * The committer is the creator of a transaction
+ * The verifier is any node which processes the transaction to see if it is valid
+* x*Y means multiplication of value x by curve point Y
+ * In some references multiplication is implicit, i.e. x*Y = xY
+
+In multiplicative notation the above would be `P(v,s) = G^v*Q^s` where `^` denotes exponentiation. Both notations are describing the exact same equivalent mathematics where additive notation is using `+` as the group operator while multiplicative notation is using `*`. In additive notation `n*G` is equivalent to `G^n` in multiplicative notation.
Capital letters are curve points (P, G, Q, Y above) while lowercase letters are arbitrary integers (v, s and x above). Some references including the original paper by Pedersen use multiplicative notation. Additive notation is usually used with Abelian Groups, i.e. those where `A + B = B + A` or `A*B=B*A`. Given two points on the elliptic curve secp256k1 `G` and `Q`, we can add them in any order, which is to say `G + Q = Q + G`.
G and Q MUST be randomly chosen curve points such that the `d` in
-```
+```text
Q = d*G
```
is unknown, which is equivalent to
-```
+```text
d = Log Q
```
-is unknown. In multiplicative notation:
-```
+is unknown. In multiplicative notation:
+
+```text
Q = G^d
```
@@ -289,25 +288,24 @@ and taking the discrete logarithm with respect to `G` of both sides we get `Log
The Discrete Logarithm Problem (DLP) means that if `Q = d*G` (or `Q = G^d` in multiplicative notation) then while `d` does exist, it is computationally infeasible to calculate it. The security of Pedersen commitments is based on the hardness assumption that the DLP on appropriately chosen elliptic curves have no efficient algorithm to find a solution.
-
### New consensus rules for CTs
The activation of these new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals to activate this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP23) is mined, then these consensus rules will activate at `activation_height`, which we will call `heightCT` in this DIP. If the block height of the full node is less than `heightCT` then the following consensus rules will not be active. When the block reaches `heightCT` these rules will become active.
-
+
#### Consensus rules for transactions
- * If height is at least `heightCT` then the Coinbase Special Transaction must have version >= 4, which contains the new field `confidentialAddressBalance` which is a uint64_t (8 bytes)
- * `confidentialAddressBalance` must be a valid unsigned 64 bit integer (which stores values in duffs not whole coin amounts)
- * `confidentialAddressBalance` must equal the value of `confidentialAddressBalance` from the previous block plus the sum of confidential inputs minus the sum of confidential outputs, else invalid
- * `confidentialAddressBalance` must be greater than or equal to 0, else invalid
- * `confidentialAddressBalance` must be less than or equal to 1892000000000000, else invalid
- * If height is at least `heightCT` and if at least one input of a CT is confidential, at least one of the outputs must also be confidential. This prevents metadata leaking about the exact amount in a confidential output. A confidential output may have an amount equal to zero.
- * If height is at least `heightCT` and if all inputs are public, i.e. not confidential, the number of confidential outputs must be zero or greater than or equal to two, i.e. having all public inputs with a single confidential output is not allowed, as it leaks the metadata about exactly how much value is in the confidential output.
- * If height is less than `heightCT` then Special Transaction type 10 is invalid
- * If a block contains at least one CT then:
- * The new block header
- * If a block contains a CT then the associated bulletproof must have a size of at most 40 bits
- * This enforces a maximum limit on the amount of a confidential UTXO to be `2^40/10^8 = 10995.11627776 DASH`
+* If height is at least `heightCT` then the Coinbase Special Transaction must have version >= 4, which contains the new field `confidentialAddressBalance` which is a uint64_t (8 bytes)
+ * `confidentialAddressBalance` must be a valid unsigned 64 bit integer (which stores values in duffs not whole coin amounts)
+ * `confidentialAddressBalance` must equal the value of `confidentialAddressBalance` from the previous block plus the sum of confidential inputs minus the sum of confidential outputs, else invalid
+ * `confidentialAddressBalance` must be greater than or equal to 0, else invalid
+ * `confidentialAddressBalance` must be less than or equal to 1892000000000000, else invalid
+* If height is at least `heightCT` and if at least one input of a CT is confidential, at least one of the outputs must also be confidential. This prevents metadata leaking about the exact amount in a confidential output. A confidential output may have an amount equal to zero.
+* If height is at least `heightCT` and if all inputs are public, i.e. not confidential, the number of confidential outputs must be zero or greater than or equal to two, i.e. having all public inputs with a single confidential output is not allowed, as it leaks the metadata about exactly how much value is in the confidential output.
+* If height is less than `heightCT` then Special Transaction type 10 is invalid
+* If a block contains at least one CT then:
+ * The new block header
+* If a block contains a CT then the associated bulletproof must have a size of at most 40 bits
+ * This enforces a maximum limit on the amount of a confidential UTXO to be `2^40/10^8 = 10995.11627776 DASH`
## Risks
@@ -319,7 +317,7 @@ If the code which implements this DIP does not check the validation of the Bulle
### Quantum Computer Risk
-Another form of this inflation risk is a Quantum Computer (QC) attack. No publicly known QC currently exists which can attack Pedersen commitments but the system described in this DIP very well could be in use in the future when the threat of QC attacks against blockchains is real.
+Another form of this inflation risk is a Quantum Computer (QC) attack. No publicly known QC currently exists which can attack Pedersen commitments but the system described in this DIP very well could be in use in the future when the threat of QC attacks against blockchains is real.
An attack against Confidential Transactions described in this DIP involves calculating Discrete Logarithms to subvert the security of Pedersen Commitments. Using Shor's Algorithm on a Quantum Computer reduces the complexity of calculating a Discrete Log from an exponential time to a polynomial time algorithm. In this attack, the QC initially creates a valid Confidential Transaction, for example moving 1 DASH from a transparent address to a confidential address. Then the QC spends this confidential UTXO and creates another confidential UTXO with a different amount, say 21M DASH. If the QC is able to compute Discrete Logarithms then it will be able to change the amount being committed to without changing the Pedersen Commitment. This means that nodes on the network that verify the transaction will see it as valid, unaware that the transaction actually inflates the supply by an arbitrary amount, which is only limited by the maximum value allowed in the range proof.
@@ -327,42 +325,41 @@ To limit (but not avoid) the risk described above, DASH can limit the amount tha
For example, the currently in-progress BIP360 modification to Bitcoin describes a system to make Bitcoin resistant to QC attacks. It gives examples of many BTC addresses which contain 50 BTC each from early Bitcoin miners and shows that these addresses will most likely be the first objects of attack by QCs, since it equates to earning 50 BTC for calculating a single Discrete Logarithm. If the implementation of this DIP on DASH ensures that the value created in a single confidential UTXO is much less than the value of 50 BTC then it will ensure that QCs will attack Bitcoin before DASH confidential transactions.
-
## References
- * Original post about Confidential Transactions https://bitcointalk.org/index.php?topic=305791.0
- * RingCT https://eprint.iacr.org/2015/1098
- * BP https://eprint.iacr.org/2017/1066.pdf
- * BP+ https://eprint.iacr.org/2020/735
- * BP++ https://eprint.iacr.org/2022/510
- * BP++ CCS https://ccs.getmonero.org/proposals/bulletproofs-pp-peer-review.html
- * BP++ Audit by CypherStack https://github.com/cypherstack/bppp-review
- * Notes on how and why Bulletproofs work https://doc-internal.dalek.rs/bulletproofs/notes/index.html
- * libsecp256k1 https://github.com/bitcoin-core/secp256k1
- * libsecp256k1 Bulletproofs: https://github.com/BlockstreamResearch/secp256k1-zkp/tree/master/src/modules/rangeproof
- * Example of bulletproof API in libsecp256k1 https://github.com/guillaumelauzier/Bulletproofs-libsecp256k1/blob/main/src.cpp
- * Elements Transaction Format https://github.com/ElementsProject/elements/blob/master/doc/elements-tx-format.md
- * Elements Confidential Transactions https://github.com/ElementsProject/elements/blob/master/doc/elements-confidential-transactions.md
- * Elements Confidential Addresses https://elementsproject.org/features/confidential-transactions/addresses
- * "SLIP-0077 : Deterministic blinding key derivation for Confidential Transactions"
-https://github.com/satoshilabs/slips/blob/master/slip-0077.md
- * "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing" Advances in Cryptology 1991, Torben Pryds Pedersen https://link.springer.com/chapter/10.1007/3-540-46766-1_9
- * What Are Pedersen Commitments And How They Work https://www.rareskills.io/post/pedersen-commitment
- * Mastering Bitcoin, Chapter 4, Keys https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04_keys.adoc
- * secp256k1 "Standards For Efficient Cryptography" https://www.secg.org/sec2-v2.pdf
- * Curve25519, Daniel J Bernstein https://cr.yp.to/ecdh/curve25519-20060209.pdf
- * Cryptanalysis Of Number Theoretic Ciphers. Samuel S. Wagstaff, Jr. 2003
- * Pedersen Commitments https://www.zkdocs.com/docs/zkdocs/commitments/pedersen/
- * Inner Product Arguments https://dankradfeist.de/ethereum/2021/07/27/inner-product-arguments.html
- * An investigation into Confidential Transactions https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf
- * Zero To Monero 2.0.0, Sections 5.2 (Pedersen Commitments) and 5.5 (Range Proofs) https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
- * BIP360 "Pay to Quantum Resistant Hash" https://github.com/bitcoin/bips/blob/e6e72078084271cbba50d54c2d2a2b180daf8356/bip-0360.mediawiki
- * "Algorithms of Quantum Computation: Discrete Log And Factoring" Peter W. Shor, http://cc.ee.ntu.edu.tw/~rbwu/rapid_content/course/QC/Shor1994.pdf
- * "Shor's Algorithm" https://en.wikipedia.org/wiki/Shor's_algorithm
- * Bech32m Spec https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
- * Bech32 and Bech32m Reference Python implementation https://github.com/sipa/bech32/tree/master/ref/python
- * DIP23 https://github.com/dashpay/dips/blob/master/dip-0023.md
- * BIP9 https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
+* Original post about Confidential Transactions
+* RingCT
+* BP
+* BP+
+* BP++
+* BP++ CCS
+* BP++ Audit by CypherStack
+* Notes on how and why Bulletproofs work
+* libsecp256k1
+* libsecp256k1 Bulletproofs:
+* Example of bulletproof API in libsecp256k1
+* Elements Transaction Format
+* Elements Confidential Transactions
+* Elements Confidential Addresses
+* "SLIP-0077 : Deterministic blinding key derivation for Confidential Transactions"
+
+* "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing" Advances in Cryptology 1991, Torben Pryds Pedersen
+* What Are Pedersen Commitments And How They Work
+* Mastering Bitcoin, Chapter 4, Keys
+* secp256k1 "Standards For Efficient Cryptography"
+* Curve25519, Daniel J Bernstein
+* Cryptanalysis Of Number Theoretic Ciphers. Samuel S. Wagstaff, Jr. 2003
+* Pedersen Commitments
+* Inner Product Arguments
+* An investigation into Confidential Transactions
+* Zero To Monero 2.0.0, Sections 5.2 (Pedersen Commitments) and 5.5 (Range Proofs)
+* BIP360 "Pay to Quantum Resistant Hash"
+* "Algorithms of Quantum Computation: Discrete Log And Factoring" Peter W. Shor,
+* "Shor's Algorithm"
+* Bech32m Spec
+* Bech32 and Bech32m Reference Python implementation
+* DIP23
+* BIP9
## Copyright
From 642c3daf5c44ec50a6fe64467ecb1db8d2536a18 Mon Sep 17 00:00:00 2001
From: thephez
Date: Wed, 21 May 2025 17:12:16 -0400
Subject: [PATCH 76/92] docs(dip32): typo fixes
---
dip-0032.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index 0efbb604..ca04c8e1 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -106,7 +106,7 @@ To show that ECDH allows Alice and Bob to derive the same seed, we must show tha
```text
d_A*Q_B = d_A * d_B * G # definition of Q_B
- = d_B * d_A * G # commutivatity
+ = d_B * d_A * G # commutativity
= d_B * Q_A
```
@@ -135,7 +135,7 @@ Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag7
The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a Human Readable Part of "Dash".
-Similary, a testnet Confidential Address example is:
+Similarly, a testnet Confidential Address example is:
```text
TDash14nxdx2cxhvr30msmejddq77ae5w6mvkztqz86p084r959t60q46ry5jx6fd4hgjafwuh57y6shzckk8rpxtz8jgpchr5p
@@ -241,7 +241,7 @@ The following data structures have been adapted from the Elements Project Transa
#### Pedersen Commitments
-A Pedersen commitment can be thought of as a sealed box which is tamper-proof and contains a secret. A physical example of this would be for Alice to seal a message `M` inside an envelope along with a peice of carbon paper, then getting Bob to sign the outside of the envelope, so that the carbon paper copies his signature onto the message `M`. Later on Alice can open the envelope and both Alice and Bob can be assured that the secret message `M` was not changed.
+A Pedersen commitment can be thought of as a sealed box which is tamper-proof and contains a secret. A physical example of this would be for Alice to seal a message `M` inside an envelope along with a piece of carbon paper, then getting Bob to sign the outside of the envelope, so that the carbon paper copies his signature onto the message `M`. Later on Alice can open the envelope and both Alice and Bob can be assured that the secret message `M` was not changed.
Mathematically a Pedersen commitment (written in additive notation) is defined as
From f98c0837d2d9ad639b5eff2b1702c0dcd4e06884 Mon Sep 17 00:00:00 2001
From: thephez
Date: Mon, 9 Jun 2025 12:53:37 -0400
Subject: [PATCH 77/92] docs: apply suggestions from code review
---
dip-0032.md | 88 ++++++++++++++++++++++++++---------------------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index ca04c8e1..d372c03e 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -28,18 +28,17 @@ the amount being transferred.
## Motivation
-Currently Dash transactions can optionally use CoinJoin to increase the privacy of transactions but it
-leaves much to be desired. This is because CoinJoin is a non-custodial, multi-round CoinJoin process protocol which
-is based on amount obfuscation which leaves addresses as public data.
+Currently, Dash transactions can optionally use CoinJoin to increase the privacy of transactions, but it
+leaves much to be desired. This is because CoinJoin is a non-custodial, multi-round CoinJoin process protocol based on amount obfuscation, which leaves addresses as public data.
CoinJoin transactions leak large amounts of transaction metadata which is
accessible via public blockchain data and requires users to learn about various
details and advanced options to use it in a privacy-preserving way. The current
CoinJoin implementation also requires users to wait longer for
-increased privacy via more mixing rounds. Most users will have no idea how many rounds they should use or what the
-implications of this choice will be. This incentivizes users to use fewer mixing
-rounds to save time, reducing their privacy as well as the privacy of
-all users utilizing CoinJoins.
+increased privacy via more mixing rounds. Most users will have no idea how many rounds they should use or the
+implications of this choice. This incentivizes users to use fewer mixing
+rounds to save time, reducing their privacy and the privacy of
+all users utilizing CoinJoin.
## Conventions
@@ -52,55 +51,56 @@ We will use these abbreviations:
## Scope
-This DIP describes how CT can be implemented via the Dash Full Node,
-the implementation details of light wallet servers and clients and other nodes is out of scope.
+This DIP describes how CT can be implemented via the Dash Core Full Node.
+Implementation details of light wallet servers and clients, and other nodes are out of scope.
## Prior Work
There are many different types of CTs. The term originally was used in the context
of Bitcoin in 2013 and has grown to a research field with many flavors of CTs. Monero
-currently uses RingCT with Bulletproof+ optimizations and the purpose of this DIP is
+currently uses RingCT with Bulletproof+ optimizations, and the purpose of this DIP is
to decide exactly which kind of CT is appropriate for Dash. Monero first implemented
-RingCT in 2017 and then added Bulletproofs in 2018 which allow for an 80% reduction
-in size of transactions, reducing blockchain bloat as well as reducing transaction fees.
-A further improvement called Bulletproofs+ was completed in 2022 which further reduces
-transaction size by roughly 5-10% and improves speed by 10%. Yet another improvement
+RingCT in 2017 and then added Bulletproofs in 2018. Bulletproofs allowed for an 80% reduction
+in transaction size, reducing blockchain bloat and transaction fees.
+A further improvement called Bulletproofs+ was completed in 2022 which further reduced
+transaction size by roughly 5-10% and improved speed by 10%. Yet another improvement
called Bulletproofs++ is currently being worked on which further reduces transaction
size and speeds up runtime. Since BP++ is still being actively worked on and has not
-yet been merged into Monero and BP+ are still not widely used it is currently recommended for Dash to use BPs.
+yet been merged into Monero, and BP+ is still not widely used, it is currently recommended that Dash use BPs.
## Consensus Protocol Changes
-This DIP proposes a new transaction type as well as new address types and therefore is a consensus change.
+Since this DIP proposes a new transaction type and new address types, it is a consensus change.
## Overview
-To quote the original Bulletproof paper "Bulletproofs are zero-knowledge arguments of knowledge" i.e. they are a generalized mathematical tool that can be used in many different ways with many different cryptographic systems. In particular, they do not require a specific elliptic curve to be used with them. This is why various different systems can use Bulletproofs even though they use different elliptic curves. There exists a fork of libsecp256k1 called libsecp256k1-zkp which contains code to do Bulletproofs on the secp256k1 curve that the Dash community most likely will want to use.
+To quote the original Bulletproof paper, "Bulletproofs are zero-knowledge arguments of knowledge," i.e. they are a generalized mathematical tool that can be used in many different ways with many different cryptographic systems. In particular, they do not require a specific elliptic curve to be used with them. This is why various systems can use Bulletproofs even though they use different elliptic curves. A fork of libsecp256k1 called libsecp256k1-zkp contains code to do Bulletproofs on the secp256k1 curve that the Dash community most likely will want to use.
## Details
-This DIP documents how Dash can add CTs using Bulletproofs (BPs). The type of CT we propose using has two main parts, a signature and a Bulletproof. The Bulletproof (a type of range proof) proves that the signature is valid, in particular, that it's values are in between a certain valid range. This prevents an underflow or overflow of values that could be used to subvert the system. Bulletproofs are a type of Non-Interactive Zero Knowledge proof. They prove that the values are valid or invalid without leaking any information about the values themselves.
+This DIP documents how Dash can add CTs using Bulletproofs (BPs). The type of CT we propose using has two main parts: a signature and a Bulletproof. The Bulletproof (a type of range proof) proves that the signature is valid, in particular, that it's values are within a certain valid range. This prevents an underflow or overflow of values that could be used to subvert the system. Bulletproofs are a type of Non-Interactive Zero Knowledge proof. They prove that the values are valid or invalid without leaking any information about the values themselves.
### Confidential addresses (CT addresses)
-New Dash CTs will need a new type of address, a confidential address, to send and receive CT transactions. This means that the Dash full node will require new RPCs to create, validate, list and import confidential addresses. A prefix of `Dash` will be used for these addresses so they can easily be differentiated from other Dash addresses and from Confidential Addresses on other blockchains. These addresses will be new data in the wallet and the code which reads and writes the wallet to disk will need to also be updated to store and retrieve this data. The code which rescans blockchain history for transactions belonging to the current wallet will also need to be updated. To detect if a UTXO is owned by the current wallet, full nodes will use the Confidential Address public key along with the salt corresponding to that public key to inspect every UTXO to see if is an output owned by the wallet.
+New Dash CTs will need a new type of address, a confidential address, to send and receive CT transactions. Dash Core will require new RPCs to create, validate, list and import confidential addresses. A prefix of `Dash` will be used for these addresses so they can easily be differentiated from other Dash addresses and from Confidential Addresses on other blockchains. Since these addresses will be new data in the wallet, the code that reads and writes the wallet to disk must also be updated to store and retrieve this data. The code that rescans blockchain history for transactions belonging to the current wallet will also need to be updated. Full nodes will use the Confidential Address public key and the corresponding public key salt to inspect every UTXO and detect if the output owned by the current wallet.
-These new CT addresses require a different prefix to identify them as different from traditional Dash addresses and the prefix `Dash` is proposed for mainnet, `TDash` for testnet and `RDash` for regtest. This corresponds to the the Human Readable Part (HRP) of the bech32m encoded address.
+These new CT addresses require a unique prefix to distinguish them from traditional Dash addresses. The prefix `Dash` is proposed for mainnet, `TDash` for testnet and `RDash` for regtest. This corresponds to the human-readable part (HRP) of the bech32m encoded address.
The exact structure of a CT address is as follows. It contains the following data:
* bkvb - Blinding key version byte
* atvb - Address type version byte
-* salt (AKA public blinding key) . 32 byte random value
+* salt (AKA public blinding key) - 32 byte random value
* When Alice sends a transaction to Bob, this public blinding key is used in an ECDH operation by Alice to transmit the actual amount and blinding key of a transaction to Bob
* Note that older Elements documentation called this a "scanning key"
- * Note that this value is not hashed, it is stored unchanged as part of the CT address
-* pk . The compressed public key, a 33 byte secp256k1 curve point.
+ * Note that this value is not hashed; it is stored unchanged as part of the CT address
+* pk - The compressed public key, a 33 byte secp256k1 curve point.
* Note that a hash of the public key is what is actually included in the address
+
Every confidential address contains a public blinding key used in ECDH. When Alice sends Bob a transaction, Alice chooses an ECDH ephemeral private key (the ConfidentialNonce in this DIP) and combines it with the public blinding key to derive a blinding seed.
When Bob receives a CT, they combine the public blinding key with the private blinding key (ConfidentialNonce) to derive the same exact seed used by Alice.
-The reason this is possible is because curve operations are commutative, i.e. `A*B=B*A` , also known as Abelian. To show this is true, let Alice's keypair be denoted `(d_A, Q_A)` and Bob's keypair `(d_B, Q_B)` where `d_A` and `d_B` are private keys and `Q_A` and `Q_B` are public keys. The public keys are computed as `Q_A=d_A * G` and `Q_B=d_B * G` where G is a generator of the curve and the operation `x*G` means adding `G` to itself `x` times.
+This is possible is because curve operations are commutative, i.e., `A*B=B*A` , also known as Abelian. To show this is true, let Alice's keypair be denoted `(d_A, Q_A)` and Bob's keypair `(d_B, Q_B)` where `d_A` and `d_B` are private keys and `Q_A` and `Q_B` are public keys. The public keys are computed as `Q_A=d_A * G` and `Q_B=d_B * G` where G is a generator of the curve and the operation `x*G` means adding `G` to itself `x` times.
To show that ECDH allows Alice and Bob to derive the same seed, we must show that the point on the curve `d_A*Q_B` is the same as `d_B*Q_A` :
@@ -110,16 +110,16 @@ d_A*Q_B = d_A * d_B * G # definition of Q_B
= d_B * Q_A
```
-Therefore Alice and Bob can compute a shared secret `(x,y) = d_A*Q_B = d_B*Q_A` without ever actually transmitting the secret.
+Therefore, Alice and Bob can compute a shared secret `(x,y) = d_A*Q_B = d_B*Q_A` without ever actually transmitting the secret.
For HD wallets, a master 32 byte salt (blinding key) is stored from which all blinding keys for generated addresses are derived. A
blinding key for an address is generated as `HMAC_SHA256(master blinding key, )` . See the reference SLIP-0077 for more details.
-To clarify, the public key can actually be stored in 32 bytes and one bit, because a point on the curve is a pair of 32 byte numbers (x,y). If x is known, y is almost uniquely identified, since for each `x` there are two `y` values, for exactly the same reason why `x^2 = 4` has two solutions, +2 and -2 . Since secp256k1 is symmetric about the x-axis, one bit can be used to say if the y value is above or below the x axis.
+To clarify, the public key can actually be stored in 32 bytes and one bit because a point on the curve is a pair of 32 byte numbers (x,y). If x is known, y is almost uniquely identified since for each `x`, there are two `y` values. This happens for the same reason that `x^2 = 4` has two solutions, +2 and -2. Since secp256k1 is symmetric about the x-axis, one bit can be used to indicate if the y value is above or below the x-axis.
- The salt is 32 bytes because it is used to "blind" the x value of a (x,y) point on the curve which is 32 bytes. The compressed public key is 33 bytes (or 32 bytes and one bit) as described above and in the "Compressed Public Keys" section of Chapter 4 of "Mastering Bitcoin".
+The salt is 32 bytes because it is used to "blind" the x value of a 32 byte (x,y) point on the curve. The compressed public key is 33 bytes (or 32 bytes and one bit) as described above and in the "Compressed Public Keys" section of Chapter 4 of "Mastering Bitcoin".
-A bech32m encoded CT address can be then generated via
+A bech32m encoded CT address can then be generated via:
```text
address = bech32m( bkvb + atvb + salt + RIPEMD160( SHA256( pk ) ) )
@@ -133,7 +133,7 @@ According to the above specification, a mainnet bech32m encoded Dash Confidentia
Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag77shanjag60ygcaax2g
```
-The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a Human Readable Part of "Dash".
+The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a human-readable part of "Dash".
Similarly, a testnet Confidential Address example is:
@@ -152,8 +152,8 @@ RDash1arnq9xp6dzmaqnqw7865kqumxjxtzm3vvjm0w9d594zmufek5hl9xmzmwecpsa5eynm7evw85s
A Confidential Transaction contains the following data :
* A 33 byte Pedersen commitment to the amount being transferred for each output
-* A BP rangeproof for each output that ensures the amount transferred is inside a certain interval between 0 and 2^N - 1
- * To support all potential value transfers between 0 and 21M the BP rangeproof needs N equal to 52
+* A BP rangeproof for each output that ensures the amount transferred is within a certain interval between 0 and 2^N - 1
+ * To support all potential value transfers between 0 and 21M, the BP rangeproof N value must equal 52
* The exact size of the proof depends on the number of inputs and outputs
* A fee output with an explicit amount and blank ScriptPubKey
* A list of input UTXOs
@@ -164,8 +164,8 @@ This DIP proposes using DIP-2 Special Transactions to store and implement Confid
#### Variable Length Integer (VarInt)
-This data type is derived from Bitcoin, and allows an integer to be encoded with a variable length (which depends on the represented value), in order to save space.
-Variable length integers always precede a vector of a type of data that may vary in length and are used to indicate this length.
+This data type is derived from Bitcoin, and allows an integer to be encoded with a variable length (which depends on the represented value) to save space.
+Variable length integers always precede a vector of a data type that may vary in length and are used to indicate this length.
Longer numbers are encoded in little-endian.
| Value | Size | Format | Example |
@@ -229,7 +229,7 @@ The following data structures have been adapted from the Elements Project Transa
| Field | Required | Size | Data Type | Encoding | Notes |
| ----- | -------- | ---- | --------- | -------- | ----- |
-| Header | Yes | 1 byte | | | A header byte of `0x02` or `0x03` indicates a compressed elliptic curve point. With the least significant bit of the header byte denoting the least significant bit of the y-coordinate, and the remaining 32 bytes denoting the x-coordinate (big-endian). This point is not required to be on the curve. |
+| Header | Yes | 1 byte | | | A header byte of `0x02` or `0x03` indicates a compressed elliptic curve point. The least significant bit of the header byte denotes the least significant bit of the y-coordinate, and the remaining 32 bytes denote the x-coordinate (big-endian). This point is not required to be on the curve. |
| Value | | 32 bytes | `hex` | Big-endian | |
#### ConfidentialProof
@@ -241,9 +241,9 @@ The following data structures have been adapted from the Elements Project Transa
#### Pedersen Commitments
-A Pedersen commitment can be thought of as a sealed box which is tamper-proof and contains a secret. A physical example of this would be for Alice to seal a message `M` inside an envelope along with a piece of carbon paper, then getting Bob to sign the outside of the envelope, so that the carbon paper copies his signature onto the message `M`. Later on Alice can open the envelope and both Alice and Bob can be assured that the secret message `M` was not changed.
+A Pedersen commitment can be thought of as a sealed box which is tamper-proof and contains a secret. A physical example would be for Alice to seal a message `M` inside an envelope along with a piece of carbon paper, then get Bob to sign the outside of the envelope so that the carbon paper copies his signature onto the message `M`. Later, Alice can open the envelope and both Alice and Bob can be assured that the secret message `M` was not changed.
-Mathematically a Pedersen commitment (written in additive notation) is defined as
+Mathematically, a Pedersen commitment (written in additive notation) is defined as:
```text
P(v,s) = v*G + s*Q
@@ -260,9 +260,9 @@ where
* x*Y means multiplication of value x by curve point Y
* In some references multiplication is implicit, i.e. x*Y = xY
-In multiplicative notation the above would be `P(v,s) = G^v*Q^s` where `^` denotes exponentiation. Both notations are describing the exact same equivalent mathematics where additive notation is using `+` as the group operator while multiplicative notation is using `*`. In additive notation `n*G` is equivalent to `G^n` in multiplicative notation.
+In multiplicative notation, the above would be `P(v,s) = G^v*Q^s` where `^` denotes exponentiation. Both notations describe the same equivalent mathematics where additive notation is using `+` as the group operator while multiplicative notation is using `*`. In additive notation, `n*G` is equivalent to `G^n` in multiplicative notation.
-Capital letters are curve points (P, G, Q, Y above) while lowercase letters are arbitrary integers (v, s and x above). Some references including the original paper by Pedersen use multiplicative notation. Additive notation is usually used with Abelian Groups, i.e. those where `A + B = B + A` or `A*B=B*A`. Given two points on the elliptic curve secp256k1 `G` and `Q`, we can add them in any order, which is to say `G + Q = Q + G`.
+Capital letters are curve points (P, G, Q, Y above), while lowercase letters are arbitrary integers (v, s and x above). Some references, including the original paper by Pedersen, use multiplicative notation. Additive notation is usually used with Abelian Groups, i.e. those where `A + B = B + A` or `A*B=B*A`. Given two points on the elliptic curve secp256k1 `G` and `Q`, we can add them in any order, which is to say `G + Q = Q + G`.
G and Q MUST be randomly chosen curve points such that the `d` in
@@ -286,11 +286,11 @@ and taking the discrete logarithm with respect to `G` of both sides we get `Log
`d` is called the Discrete Logarithm of `Q` with respect to `G` (or the Discrete Logarithm of `Q` in base `G`). We use the notation `Log` instead of `log` to denote the fact that a discrete logarithm is a different function from the traditional logarithm denoted `log` . The function `Log` and `log` share the same types of properties and identities which is why `Log` is considered the discrete analog of `log`.
-The Discrete Logarithm Problem (DLP) means that if `Q = d*G` (or `Q = G^d` in multiplicative notation) then while `d` does exist, it is computationally infeasible to calculate it. The security of Pedersen commitments is based on the hardness assumption that the DLP on appropriately chosen elliptic curves have no efficient algorithm to find a solution.
+The Discrete Logarithm Problem (DLP) means that if `Q = d*G` (or `Q = G^d` in multiplicative notation), then while `d` does exist, it is computationally infeasible to calculate it. The security of Pedersen commitments is based on the hardness assumption that the DLP on appropriately chosen elliptic curves have no efficient algorithm to find a solution.
### New consensus rules for CTs
-The activation of these new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals to activate this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP23) is mined, then these consensus rules will activate at `activation_height`, which we will call `heightCT` in this DIP. If the block height of the full node is less than `heightCT` then the following consensus rules will not be active. When the block reaches `heightCT` these rules will become active.
+These new consensus rules will be activated according to BIP9/DIP23. Assuming that the network signals support for this hardfork and the Masternode Hard Fork Signalling Transaction (as defined in DIP23) is mined, these consensus rules will activate at an `activation_height` designated `heightCT` in this DIP. If the block height of the full node is less than `heightCT`, then the following consensus rules will not be active. When the block reaches `heightCT`, these rules will become active.
#### Consensus rules for transactions
@@ -317,13 +317,13 @@ If the code which implements this DIP does not check the validation of the Bulle
### Quantum Computer Risk
-Another form of this inflation risk is a Quantum Computer (QC) attack. No publicly known QC currently exists which can attack Pedersen commitments but the system described in this DIP very well could be in use in the future when the threat of QC attacks against blockchains is real.
+Another form of this inflation risk is a Quantum Computer (QC) attack. No publicly known QC currently exists that can attack Pedersen commitments, but the system described in this DIP very well could be used in the future when the threat of QC attacks against blockchains is real.
-An attack against Confidential Transactions described in this DIP involves calculating Discrete Logarithms to subvert the security of Pedersen Commitments. Using Shor's Algorithm on a Quantum Computer reduces the complexity of calculating a Discrete Log from an exponential time to a polynomial time algorithm. In this attack, the QC initially creates a valid Confidential Transaction, for example moving 1 DASH from a transparent address to a confidential address. Then the QC spends this confidential UTXO and creates another confidential UTXO with a different amount, say 21M DASH. If the QC is able to compute Discrete Logarithms then it will be able to change the amount being committed to without changing the Pedersen Commitment. This means that nodes on the network that verify the transaction will see it as valid, unaware that the transaction actually inflates the supply by an arbitrary amount, which is only limited by the maximum value allowed in the range proof.
+An attack against Confidential Transactions described in this DIP involves calculating Discrete Logarithms to subvert the security of Pedersen Commitments. Using Shor's Algorithm on a Quantum Computer reduces the complexity of calculating a Discrete Log from an exponential time to a polynomial time algorithm. In this attack, the QC initially creates a valid Confidential Transaction, for example, moving 1 DASH from a transparent address to a confidential address. Then, the QC spends this confidential UTXO and creates another confidential UTXO with a different amount, say 21M DASH. If the QC is can compute Discrete Logarithms, it can change the amount being committed to without changing the Pedersen Commitment. This means that nodes on the network that verify the transaction will see it as valid, unaware that the transaction actually inflates the supply by an arbitrary amount, which is only limited by the maximum value allowed in the range proof.
-To limit (but not avoid) the risk described above, DASH can limit the amount that can be stored in a single confidential UTXO. For example, instead of allowing the creation of a confidential UTXO of amount 21M, it could be limited to a value near 10K (the exact maximum value for the range proof must be a power of two minus 1). This would force an attacker to calculate roughly 2100 Discrete Logarithms instead of just one to inflate the supply by the same amount. Since calculating a Discrete Logarithm has a cost in time required and the most-likely substantial electricity needed to power the QC, this will drastically increase the cost of the attack and give other systems a higher Return-On-Investment for the attacker.
+To limit (but not avoid) the risk described above, DASH can limit the amount that can be stored in a single confidential UTXO. For example, instead of allowing the creation of a confidential UTXO of amount 21M, it could be limited to a value near 10K (the exact maximum value for the range proof must be a power of two minus 1). This would force an attacker to calculate roughly 2100 Discrete Logarithms instead of just one to inflate the supply by the same amount. Since calculating a Discrete Logarithm has a cost in time required and the most-likely substantial electricity needed to power the QC, this will drastically increase the cost of the attack and give other systems a higher return on investment for the attacker.
-For example, the currently in-progress BIP360 modification to Bitcoin describes a system to make Bitcoin resistant to QC attacks. It gives examples of many BTC addresses which contain 50 BTC each from early Bitcoin miners and shows that these addresses will most likely be the first objects of attack by QCs, since it equates to earning 50 BTC for calculating a single Discrete Logarithm. If the implementation of this DIP on DASH ensures that the value created in a single confidential UTXO is much less than the value of 50 BTC then it will ensure that QCs will attack Bitcoin before DASH confidential transactions.
+For example, the currently in-progress BIP360 modification to Bitcoin describes a system to make Bitcoin resistant to QC attacks. It gives examples of many BTC addresses which contain 50 BTC each from early Bitcoin miners and shows that these addresses will most likely be the first objects of attack by QCs, since it equates to earning 50 BTC for calculating a single Discrete Logarithm. If the implementation of this DIP on DASH ensures that the value created in a single confidential UTXO is much less than the value of 50 BTC, then it will ensure that QCs attack Bitcoin before DASH confidential transactions.
## References
From 3778d0e790c03f68c4ce94b37bc807619960b9d5 Mon Sep 17 00:00:00 2001
From: thephez
Date: Mon, 9 Jun 2025 13:35:47 -0400
Subject: [PATCH 78/92] docs: consistently capitalize
---
dip-0032.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index d372c03e..867ea80b 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -147,7 +147,7 @@ and a regtest Confidential Address would be:
RDash1arnq9xp6dzmaqnqw7865kqumxjxtzm3vvjm0w9d594zmufek5hl9xmzmwecpsa5eynm7evw85ssepsrqm5wg9ccyk050e
```
-### Confidential transactions
+### Confidential Transactions
A Confidential Transaction contains the following data :
@@ -191,9 +191,9 @@ The structure of `extra_payload` is :
| Field | Type | Size | Description |
| ----- | ---- | ---- | ----------- |
|numTxInputs| VarInt | varies | Number of confidential inputs|
-| txInputs| `Vector`| 33*numTxInputs bytes| Confidential transaction inputs |
+| txInputs| `Vector`| 33*numTxInputs bytes| Confidential Transaction inputs |
|numTxOutputs| VarInt | varies | Number of confidential outputs |
-| txOutputs | `Vector`| 33*numTxOutputs bytes| Confidential transaction outputs |
+| txOutputs | `Vector`| 33*numTxOutputs bytes| Confidential Transaction outputs |
| proof |ConfidentialProof| Varies | Confidential proof data |
# TxInput
@@ -323,7 +323,7 @@ An attack against Confidential Transactions described in this DIP involves calcu
To limit (but not avoid) the risk described above, DASH can limit the amount that can be stored in a single confidential UTXO. For example, instead of allowing the creation of a confidential UTXO of amount 21M, it could be limited to a value near 10K (the exact maximum value for the range proof must be a power of two minus 1). This would force an attacker to calculate roughly 2100 Discrete Logarithms instead of just one to inflate the supply by the same amount. Since calculating a Discrete Logarithm has a cost in time required and the most-likely substantial electricity needed to power the QC, this will drastically increase the cost of the attack and give other systems a higher return on investment for the attacker.
-For example, the currently in-progress BIP360 modification to Bitcoin describes a system to make Bitcoin resistant to QC attacks. It gives examples of many BTC addresses which contain 50 BTC each from early Bitcoin miners and shows that these addresses will most likely be the first objects of attack by QCs, since it equates to earning 50 BTC for calculating a single Discrete Logarithm. If the implementation of this DIP on DASH ensures that the value created in a single confidential UTXO is much less than the value of 50 BTC, then it will ensure that QCs attack Bitcoin before DASH confidential transactions.
+For example, the currently in-progress BIP360 modification to Bitcoin describes a system to make Bitcoin resistant to QC attacks. It gives examples of many BTC addresses which contain 50 BTC each from early Bitcoin miners and shows that these addresses will most likely be the first objects of attack by QCs, since it equates to earning 50 BTC for calculating a single Discrete Logarithm. If the implementation of this DIP on DASH ensures that the value created in a single confidential UTXO is much less than the value of 50 BTC, then it will ensure that QCs attack Bitcoin before DASH Confidential Transactions.
## References
From ca5682ad0d0a8ee09b895c93509adf41de2d8ba7 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Wed, 8 Oct 2025 12:14:14 -0400
Subject: [PATCH 79/92] Update dip-0032.md
Co-authored-by: thephez
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index 867ea80b..3cf0c837 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -218,7 +218,7 @@ NOTE: The hex encodings of hashes are byte-reversed, and so the bytes will need
The following data structures have been adapted from the Elements Project Transaction format:
-#### ConfidentialAmount
+## ConfidentialAmount
| Field | Required | Size | Data Type | Encoding | Notes |
| ----- | -------- | ---- | --------- | -------- | ----- |
From a63754a08c3ff30a1bdbb7f35b6e37721f76a686 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Wed, 8 Oct 2025 12:14:49 -0400
Subject: [PATCH 80/92] Update dip-0032.md
Co-authored-by: thephez
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index 3cf0c837..f1c9c55a 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -232,7 +232,7 @@ The following data structures have been adapted from the Elements Project Transa
| Header | Yes | 1 byte | | | A header byte of `0x02` or `0x03` indicates a compressed elliptic curve point. The least significant bit of the header byte denotes the least significant bit of the y-coordinate, and the remaining 32 bytes denote the x-coordinate (big-endian). This point is not required to be on the curve. |
| Value | | 32 bytes | `hex` | Big-endian | |
-#### ConfidentialProof
+## ConfidentialProof
| Field | Required | Size | Data Type | Encoding | Notes |
| ----- | -------- | ---- | --------- | -------- | ----- |
From 36b2431bcc1f98a549ed56c0411b672dd3b590bc Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 09:59:04 -0400
Subject: [PATCH 81/92] Fix typo
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index f1c9c55a..0eb0aee5 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -100,7 +100,7 @@ The exact structure of a CT address is as follows. It contains the following dat
Every confidential address contains a public blinding key used in ECDH. When Alice sends Bob a transaction, Alice chooses an ECDH ephemeral private key (the ConfidentialNonce in this DIP) and combines it with the public blinding key to derive a blinding seed.
When Bob receives a CT, they combine the public blinding key with the private blinding key (ConfidentialNonce) to derive the same exact seed used by Alice.
-This is possible is because curve operations are commutative, i.e., `A*B=B*A` , also known as Abelian. To show this is true, let Alice's keypair be denoted `(d_A, Q_A)` and Bob's keypair `(d_B, Q_B)` where `d_A` and `d_B` are private keys and `Q_A` and `Q_B` are public keys. The public keys are computed as `Q_A=d_A * G` and `Q_B=d_B * G` where G is a generator of the curve and the operation `x*G` means adding `G` to itself `x` times.
+This is possible because curve operations are commutative, i.e., `A*B=B*A` , also known as Abelian. To show this is true, let Alice's keypair be denoted `(d_A, Q_A)` and Bob's keypair `(d_B, Q_B)` where `d_A` and `d_B` are private keys and `Q_A` and `Q_B` are public keys. The public keys are computed as `Q_A=d_A * G` and `Q_B=d_B * G` where G is a generator of the curve and the operation `x*G` means adding `G` to itself `x` times.
To show that ECDH allows Alice and Bob to derive the same seed, we must show that the point on the curve `d_A*Q_B` is the same as `d_B*Q_A` :
From 21ee490fc1c2cd134c93ff6f7ed8768866d305f6 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 10:00:51 -0400
Subject: [PATCH 82/92] These items are variable size because they contain
variable sized scriptSigs
---
dip-0032.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index 0eb0aee5..93b6a620 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -191,9 +191,9 @@ The structure of `extra_payload` is :
| Field | Type | Size | Description |
| ----- | ---- | ---- | ----------- |
|numTxInputs| VarInt | varies | Number of confidential inputs|
-| txInputs| `Vector`| 33*numTxInputs bytes| Confidential Transaction inputs |
+| txInputs| `Vector`| varies | Confidential Transaction inputs |
|numTxOutputs| VarInt | varies | Number of confidential outputs |
-| txOutputs | `Vector`| 33*numTxOutputs bytes| Confidential Transaction outputs |
+| txOutputs | `Vector`| varies | Confidential Transaction outputs |
| proof |ConfidentialProof| Varies | Confidential proof data |
# TxInput
From 53a6adb0ec232ab0463863987d8b350a4d37c40c Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 10:16:34 -0400
Subject: [PATCH 83/92] Mention CoinJoin relying on masternode honesty
From comments by @virgileba
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index 93b6a620..a69c6736 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -29,7 +29,7 @@ the amount being transferred.
## Motivation
Currently, Dash transactions can optionally use CoinJoin to increase the privacy of transactions, but it
-leaves much to be desired. This is because CoinJoin is a non-custodial, multi-round CoinJoin process protocol based on amount obfuscation, which leaves addresses as public data.
+leaves much to be desired. This is because CoinJoin is a non-custodial, multi-round CoinJoin process protocol based on amount obfuscation, which leaves addresses as public data. It also relies on the majority of masternodes to be honest while the current specification does not, it relies only on the security of the cryptographic primitives used.
CoinJoin transactions leak large amounts of transaction metadata which is
accessible via public blockchain data and requires users to learn about various
From 4f28b20903b1bf562feff8c47dcc8c87157b3116 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 10:18:00 -0400
Subject: [PATCH 84/92] Update dip-0032.md
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index a69c6736..fbcc2a11 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -74,7 +74,7 @@ Since this DIP proposes a new transaction type and new address types, it is a co
## Overview
-To quote the original Bulletproof paper, "Bulletproofs are zero-knowledge arguments of knowledge," i.e. they are a generalized mathematical tool that can be used in many different ways with many different cryptographic systems. In particular, they do not require a specific elliptic curve to be used with them. This is why various systems can use Bulletproofs even though they use different elliptic curves. A fork of libsecp256k1 called libsecp256k1-zkp contains code to do Bulletproofs on the secp256k1 curve that the Dash community most likely will want to use.
+To quote the original Bulletproof paper, "Bulletproofs are zero-knowledge arguments of knowledge." They are a generalized mathematical tool that can be used in many different ways with many different cryptographic systems. In particular, they do not require a specific elliptic curve to be used with them. This is why various systems can use Bulletproofs even though they use different elliptic curves. A fork of libsecp256k1 called libsecp256k1-zkp contains code to do Bulletproofs on the secp256k1 curve that the Dash community most likely will want to use.
## Details
From 74f28e1080eac6da5e8931f02ee83f3ea7e32254 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 10:43:21 -0400
Subject: [PATCH 85/92] Add reference to Abelian Group wikipedia page
---
dip-0032.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/dip-0032.md b/dip-0032.md
index fbcc2a11..36c9ec8f 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -360,6 +360,7 @@ For example, the currently in-progress BIP360 modification to Bitcoin describes
* Bech32 and Bech32m Reference Python implementation
* DIP23
* BIP9
+* Abelian Group
## Copyright
From ecf645bc42122e56ca9c17681fdda3f3f470c929 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 10:47:03 -0400
Subject: [PATCH 86/92] VarInts were not introduced by Bitcoin
Noted by @virgileba
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index 36c9ec8f..84f62df8 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -164,7 +164,7 @@ This DIP proposes using DIP-2 Special Transactions to store and implement Confid
#### Variable Length Integer (VarInt)
-This data type is derived from Bitcoin, and allows an integer to be encoded with a variable length (which depends on the represented value) to save space.
+This data type allows an integer to be encoded with a variable length (which depends on the represented value) to save space.
Variable length integers always precede a vector of a data type that may vary in length and are used to indicate this length.
Longer numbers are encoded in little-endian.
From a965eb548762e5e65db08a4e49f192d88cc78a07 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 10:51:26 -0400
Subject: [PATCH 87/92] Clarify that x*Y is scalar multiplication
Noted by @virgileba
---
dip-0032.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dip-0032.md b/dip-0032.md
index 84f62df8..f33a3fd8 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -257,7 +257,7 @@ where
* G and Q are elliptic curve points on secp256k1 both known to committer and verifier
* The committer is the creator of a transaction
* The verifier is any node which processes the transaction to see if it is valid
-* x*Y means multiplication of value x by curve point Y
+* x*Y means multiplication of value x by curve point Y (scalar multiplication)
* In some references multiplication is implicit, i.e. x*Y = xY
In multiplicative notation, the above would be `P(v,s) = G^v*Q^s` where `^` denotes exponentiation. Both notations describe the same equivalent mathematics where additive notation is using `+` as the group operator while multiplicative notation is using `*`. In additive notation, `n*G` is equivalent to `G^n` in multiplicative notation.
From f5a91612c1a1d43e071d810e0d44a51bd8da191d Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 11:03:30 -0400
Subject: [PATCH 88/92] Update dip-0032.md
---
dip-0032.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index f33a3fd8..dd2ec2a4 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -302,8 +302,6 @@ These new consensus rules will be activated according to BIP9/DIP23. Assuming th
* If height is at least `heightCT` and if at least one input of a CT is confidential, at least one of the outputs must also be confidential. This prevents metadata leaking about the exact amount in a confidential output. A confidential output may have an amount equal to zero.
* If height is at least `heightCT` and if all inputs are public, i.e. not confidential, the number of confidential outputs must be zero or greater than or equal to two, i.e. having all public inputs with a single confidential output is not allowed, as it leaks the metadata about exactly how much value is in the confidential output.
* If height is less than `heightCT` then Special Transaction type 10 is invalid
-* If a block contains at least one CT then:
- * The new block header
* If a block contains a CT then the associated bulletproof must have a size of at most 40 bits
* This enforces a maximum limit on the amount of a confidential UTXO to be `2^40/10^8 = 10995.11627776 DASH`
From 1e85a37c5a47a2de01bd132682fab20fc1af6fa7 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Sun, 12 Oct 2025 11:27:28 -0400
Subject: [PATCH 89/92] BP range bound is currently N=40
---
dip-0032.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index dd2ec2a4..380ad680 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -153,7 +153,7 @@ A Confidential Transaction contains the following data :
* A 33 byte Pedersen commitment to the amount being transferred for each output
* A BP rangeproof for each output that ensures the amount transferred is within a certain interval between 0 and 2^N - 1
- * To support all potential value transfers between 0 and 21M, the BP rangeproof N value must equal 52
+ * To support all potential value transfers between 0 and 21M, the BP rangeproof N value would need to be equal to 52. Currently this DIP limits the size of CT outputs to just under 11000 DASH by requiring N=40.
* The exact size of the proof depends on the number of inputs and outputs
* A fee output with an explicit amount and blank ScriptPubKey
* A list of input UTXOs
@@ -237,7 +237,7 @@ The following data structures have been adapted from the Elements Project Transa
| Field | Required | Size | Data Type | Encoding | Notes |
| ----- | -------- | ---- | --------- | -------- | ----- |
| Length | Yes | Varies | `VarInt` | | |
-| Value | | Varies | `hex` | Big-endian | Bulletproof which proves that the ConfidentialAmount is within the range of 0 and `2^52 - 1` |
+| Value | | Varies | `hex` | Big-endian | Bulletproof which proves that the ConfidentialAmount is within the range of 0 and `2^40 - 1` |
#### Pedersen Commitments
From 89e07ff81898fc57a89ffa46890b140e7196c9c1 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Tue, 11 Nov 2025 06:09:48 -0500
Subject: [PATCH 90/92] Change prefix for confidential addresses to lowercase
This allows for smaller QR codes of addresses because case-insensitive encoding can be used
---
dip-0032.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index 380ad680..232cdfab 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -82,9 +82,9 @@ This DIP documents how Dash can add CTs using Bulletproofs (BPs). The type of CT
### Confidential addresses (CT addresses)
-New Dash CTs will need a new type of address, a confidential address, to send and receive CT transactions. Dash Core will require new RPCs to create, validate, list and import confidential addresses. A prefix of `Dash` will be used for these addresses so they can easily be differentiated from other Dash addresses and from Confidential Addresses on other blockchains. Since these addresses will be new data in the wallet, the code that reads and writes the wallet to disk must also be updated to store and retrieve this data. The code that rescans blockchain history for transactions belonging to the current wallet will also need to be updated. Full nodes will use the Confidential Address public key and the corresponding public key salt to inspect every UTXO and detect if the output owned by the current wallet.
+New Dash CTs will need a new type of address, a confidential address, to send and receive CT transactions. Dash Core will require new RPCs to create, validate, list and import confidential addresses. A prefix of `dash` will be used for these addresses so they can easily be differentiated from other Dash addresses and from Confidential Addresses on other blockchains. Since these addresses will be new data in the wallet, the code that reads and writes the wallet to disk must also be updated to store and retrieve this data. The code that rescans blockchain history for transactions belonging to the current wallet will also need to be updated. Full nodes will use the Confidential Address public key and the corresponding public key salt to inspect every UTXO and detect if the output owned by the current wallet.
-These new CT addresses require a unique prefix to distinguish them from traditional Dash addresses. The prefix `Dash` is proposed for mainnet, `TDash` for testnet and `RDash` for regtest. This corresponds to the human-readable part (HRP) of the bech32m encoded address.
+These new CT addresses require a unique prefix to distinguish them from traditional Dash addresses. The prefix `dash` is proposed for mainnet, `tdash` for testnet and `rdash` for regtest. This corresponds to the human-readable part (HRP) of the bech32m encoded address.
The exact structure of a CT address is as follows. It contains the following data:
From 1dc0cb71754b8d7e74e858bb9841d399badb5d0c Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Thu, 13 Nov 2025 05:54:39 -0500
Subject: [PATCH 91/92] Fix capitalization in bech32m address examples
---
dip-0032.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index 232cdfab..6c6d247a 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -130,7 +130,7 @@ where `+` denotes concatenation. Since the salt is 32 bytes and the output of RI
According to the above specification, a mainnet bech32m encoded Dash Confidential Address will look like this:
```text
-Dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag77shanjag60ygcaax2g
+dash1zqwumnhm5u2d5re9hk5mts8fs2kr8zjm5q4pw72h4pqm09yghunvy3z34rvxs0qduyd02v8hag77shanjag60ygcaax2g
```
The above address was generated with the bech32m reference Python implementation by encoding 54 bytes of random data with a human-readable part of "Dash".
@@ -138,13 +138,13 @@ The above address was generated with the bech32m reference Python implementation
Similarly, a testnet Confidential Address example is:
```text
-TDash14nxdx2cxhvr30msmejddq77ae5w6mvkztqz86p084r959t60q46ry5jx6fd4hgjafwuh57y6shzckk8rpxtz8jgpchr5p
+tdash14nxdx2cxhvr30msmejddq77ae5w6mvkztqz86p084r959t60q46ry5jx6fd4hgjafwuh57y6shzckk8rpxtz8jgpchr5p
```
and a regtest Confidential Address would be:
```text
-RDash1arnq9xp6dzmaqnqw7865kqumxjxtzm3vvjm0w9d594zmufek5hl9xmzmwecpsa5eynm7evw85ssepsrqm5wg9ccyk050e
+rdash1arnq9xp6dzmaqnqw7865kqumxjxtzm3vvjm0w9d594zmufek5hl9xmzmwecpsa5eynm7evw85ssepsrqm5wg9ccyk050e
```
### Confidential Transactions
From b2eef9f8fd50bcc00b484b456a6d36d1ad0c5591 Mon Sep 17 00:00:00 2001
From: Hush mirror <96895766+hushmirror@users.noreply.github.com>
Date: Thu, 13 Nov 2025 05:55:54 -0500
Subject: [PATCH 92/92] Update section headers in dip-0032.md
---
dip-0032.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dip-0032.md b/dip-0032.md
index 6c6d247a..9369a9bf 100644
--- a/dip-0032.md
+++ b/dip-0032.md
@@ -225,7 +225,7 @@ The following data structures have been adapted from the Elements Project Transa
| Header | Yes | 1 byte | | | A header byte of `0x08` or `0x09` indicates a blinded value encoded as a compressed elliptic curve point. With the least significant bit of the header byte denoting the least significant bit of the y-coordinate, and the remaining 32 bytes denoting the x-coordinate (big-endian). The point must be a point on the secp256k1 curve. |
| Value | | 32 bytes | `hex` | Big-endian | |
-#### ConfidentialNonce
+### ConfidentialNonce
| Field | Required | Size | Data Type | Encoding | Notes |
| ----- | -------- | ---- | --------- | -------- | ----- |
@@ -239,7 +239,7 @@ The following data structures have been adapted from the Elements Project Transa
| Length | Yes | Varies | `VarInt` | | |
| Value | | Varies | `hex` | Big-endian | Bulletproof which proves that the ConfidentialAmount is within the range of 0 and `2^40 - 1` |
-#### Pedersen Commitments
+### Pedersen Commitments
A Pedersen commitment can be thought of as a sealed box which is tamper-proof and contains a secret. A physical example would be for Alice to seal a message `M` inside an envelope along with a piece of carbon paper, then get Bob to sign the outside of the envelope so that the carbon paper copies his signature onto the message `M`. Later, Alice can open the envelope and both Alice and Bob can be assured that the secret message `M` was not changed.