Some good progress has been made since my last memo Adding (More) Privacy To Dash. Let's dig in to some of the details.
Dash uses a library called secp256k1 originally developed as part of Bitcoin Core to do low-level elliptic curve operations. The curve has a very simple definition of y^2 = x^3 + 7. It is amazing that such a simple equation protects staggering amounts of wealth stored in private keys and that is part of the magic of elliptic curves. Why the weird name? Well firstly, mathematicians/cryptographers seem to be either very good or very bad at naming things. See the Infinite Monkey Theorem or the Hairy Ball Theorem for examples of the former. Unfortunately many elliptic curves seem to be examples of the latter, probably because cryptographers needed a naming system to document many different curves with descriptive (yet boring) names. secp256k1 is an acronym-ish for "Standards for Efficient Cryptography", prime field 256 bits, Koblitz curve type 1. Just think of secp256k1 as "the math that makes Bitcoin and just about every fork of Bitcoin work" and that is really all you need to know.
To implement Confidential Transactions (CTs), I have migrated Dash to use a fork of secp256k1 by the Elements Project which they call secp256k1-zkp. Yes, the zkp stands for zero knowledge proof. With that updated dependency I am now in the process of beginning to implement various Dash Core full node RPCs that do stuff with CTs, such as making a new CT address, making a new CT and broadcasting it to the network and validating CTs to make sure they follow all consensus rules. This is the meat of implementing DIP32 which can now be worked on because secp256k1-zkp is now being used. You can find more detailed information about this in the DIP32 Implementation Plan and read the actual current DIP32 here.
Just to be clear, Dash is not using the Elements Project directly, Dash will not be a sidechain or "asset" on their platform. Dash is simply using some code Elements wrote to make Confidential Transactions. The Dash blockchain with CTs will not depend on any Elements Project blockchain in any way, they will continue to be completely separate.
So what is the "zkp" part of secp256k1 you ask? It is what is called a "rangeproof", a zero knowledge proof that can prove that a number is in a certain range, without leaking information about what that number actually is. This means, for example, Alice can choose a secret number such as 67.93458 and then create a proof that it is in between 50 and 100 and then send that proof to Bob. Bob can verify the proof which tells him that Alice's secret number is between 50 and 100 but Bob knows nothing else about the number. This is essential for CTs because nodes on the network need to make sure that the amount being sent in a CT is valid without knowing what the number actually is!
It seems impossible to do at first but it is possible and rangeproofs are the necessary magic. You may have heard the term "Bulletproof" (a type of rangeproof) which is used inside Monero to accomplish the same exact thing, i.e. allow nodes on the network to validate the amount of a transaction is valid without knowing the exact amount. See this article from RareSkills for an in-depth mathematical dive into how Bulletproofs work and/or read the original paper.
What does it mean for an amount to be valid? For starters it means that the amount should not be negative, it should not be larger than the total supply and it should not be larger than can be stored by the code. This kind of "overflow bug" actually happened on Bitcoin mainnet in 2010, when somebody created over 184 billion BTC in a single transaction by exploiting a flaw in Satoshi's code. Additionally it means that the sum of the inputs minus the sum of the outputs and fee should be zero. You can understand this intuitively that the transaction should "balance", if 5 coins are being spent then *exactly* 5 coins should be going somewhere else, minus the fee.
-- Duke
November 2025