Welcome to the first article of this new Particl Explained series. This series will explain some of the technical aspects of the Particl platform in a way that everybody can understand. These articles should give you a good base knowledge of the more technical features of the platform and can serve as pointers when explaining a feature to a new community member or user of the platform.
Particl is a privacy-focused cryptocurrency with varying levels of anonymity. In fact, using two different privacy protocols, users of the PART coin can choose between 3 types of transactions (public, blinded, anonymous) when making payments to other people or to addresses they own. Each of these transaction types carries its own level of privacy as well as its own set of properties.
This article will break down each of these transaction types and go into more details about them, explaining why and when you should use them. Privacy transactions on Particl should have no secret for you anymore after reading this!
Table of Content (Click Me)
- PUBLIC TRANSACTIONS
- BLINDED TRANSACTIONS (CT)
- ANONYMOUS TRANSACTIONS (RingCT)
- Ring Signatures (MLSAG)
- How to Make an Anonymous Transaction (RingCT) on Particl Desktop
- Keeping a Good Level of Privacy
- STEALTH ADDRESSES
- CT + RingCT Together = INFINITE POSSIBILITIES
- Privacy level: Low
- Transaction cost: Low (~0.000346 PART)
- Segwit: Yes (Reduces transactions weight by ~20%)
- Trusted setup: No
- Programmable outputs: Yes
By default, when not manually selecting any privacy protocol to obfuscate your transactions on the blockchain, transactions are sent out as “public transactions”. And because Particl is based on the Bitcoin codebase, they are recorded on the blockchain the same way you would expect Bitcoin transactions to be recorded.
Contrary to what a lot of people claim, Bitcoin is not anonymous. In fact, it is quite the contrary. Bitcoin transactions (and Particl transactions, by proxy) are what we call pseudonymous transactions and they are pretty transparent. Instead of each transaction being tied to a personal identity, it is instead tied to an alphanumerical pseudonym composed of various different numbers and characters.
While that is probably enough to protect your data from uninterested parties, the advent of solid blockchain analysis tools and protocols makes it way too easy for any curious and motivated party to start digging into the blockchain and tracking users. That becomes dramatically easier the moment you make a payment to any service that ties addresses to identities (exchanges, payment processors, vendors, etc.).
For this reason, the Particl team has implemented two different privacy protocols that make currency transactions hidden on the blockchain. Both of these protocols do not require any trusted setup and have common denominators, but also have different purposes within the Particl platform as well as different levels of privacy.
Blinded Transactions — Confidential Transactions (CT)
- Privacy level: Medium (Transacting amounts are hidden)
- Transaction cost: Medium (~0.001962 PART)
- Segwit: Yes (Reduces CT transactions weight by ~48%)
- Bulletproofs: Yes (Reduces range proofs size by ~70%)
- Trusted setup: No
- Programmable outputs: Yes
- Whitepaper: https://elementsproject.org/features/confidential-transactions/investigation
Blinded transactions are currency transactions that have their transacting amounts hidden on the blockchain and only known by the two transacting parties (the sender and the receiver). This type of transaction uses the Confidential Transactions (CT) privacy protocol which cryptographically guarantees that no more coins can be spent than are available. It uses a zero-knowledge proofing method that does not require any trusted setup or direct interaction with the party.
This privacy protocol is entirely trustless, meaning that it doesn’t require any trusted setup and doesn’t require the assistance of any intermediary to process transactions. The problem with privacy protocols requiring so-called “trusted setups” is that they require a one-time setup that involves the generation and use of master keys. Users then need to put trust in whoever generated those keys to destroy them right after they are done setting up the protocol, otherwise, those keys could be used to create an unlimited amount of coins and do so without anyone noticing it.
To prove and ensure that amounts being sent and received are positive and the correct ones, Confidential Transactions use what we call a rangeproof. In other words, a rangeproof is able to determine that the amount of coins sent in a given transaction is between two values, but it’s not able to tell exactly what that amount is.
A rangeproof is a cryptographic protocol used to verify that a payment amount is positive or zero, without actually revealing the amount transferred in the transaction. Without rangeproofs, the amounts in a transaction could be set so large that it would be considered a negative number, thus allowing coins to be generated out of thin air. An attacker could add a negative amount output and another different output, generating extra coins. The negative output would make the commitments still sum to zero.
The downside with rangeproofs is that they are quite heavy on the blockchain. Their size scales linearly with the number of outputs in a transaction and the bits in the proof’s range. In fact, due to their heavy nature, rangeproofs take up the majority of a blinded transaction’s size.
This inconvenient reality means anyone looking into using the protocol will have to execute bigger transactions than regular, public ones. A bigger transaction not only means higher fees, but it also means that the size of the blockchain grows exponentially along with usage. In other words, it gets more inconvenient to run the blockchain as more and more CT transactions get recorded on it.
This scalability issue is one of the main reasons why the Particl team has refrained from moving its RingCT implementation onto Particl’s mainnet. Because this project has a long-term vision in mind, it was preferred to wait until a proper solution to this scalability problem was found. And then came Bulletproofs.
- Whitepaper: https://eprint.iacr.org/2017/1066.pdf
- Report from Quarkslab audit into Particl’s implementation of Bulletproofs: https://blog.quarkslab.com/resources/2019-07-05-audit-particl-bulletproof-mlsag/particl_audit_report.pdf
Bulletproofs is a new generation of rangeproofs that scale logarithmically rather than linearly. In its whitepaper, they are referred to as non-interactive zero-knowledge short proofs. In simple terms, Bulletproofs is a groundbreaking improvement over regular rangeproofs as they reduce their size by around ~70%. And, because rangeproofs make up for the majority of a CT transaction size, it in turn reduces transaction fees and the space they take on the blockchain by the same ratio.
Fun fact: The term “Bulletproofs” was coined by Shashank Agrawal when he described the new type of rangeproof as “short like a bullet, with bulletproof security assumption”.
Anonymous Transactions — RingCT
- Privacy level: High (Transacting amounts and participants are hidden)
- Transaction cost: Medium to high, depending on the number of mixins used in the ring signatures or the size of the rings
- Transaction cost for low privacy setting: ~0.003232 PART
- Transaction cost for high privacy setting: ~0.009032 PART
- Segwit: Yes (Reduces transaction weight by ~47%)
- Bulletproofs: Yes (Reduces rangeproofs size by ~70%)
- Trusted setup: No
- Programmable outputs: No
- Whitepaper: https://eprint.iacr.org/2015/1098.pdf
Anonymous transactions, or Anon transactions, as referred to in Particl Desktop, take privacy to the next level by not only hiding the transacting amounts but also the identity of the transacting parties (the sender and the receiver). This type of transaction uses the RingCT privacy protocol, a protocol made popular by Monero but adapted to work with the Bitcoin codebase by the Particl team. This allows the platform to benefit from the industry-leading privacy protocol that is RingCT but still leverage the security, stability, and developer community of Bitcoin. In other words, RingCT on the Bitcoin codebase is like having your cake and eating it too. The good, without the bad.
Good examples of this include RingCT being able to be used, with the help of special scripts, on atomic swaps, decentralized applications (i.e. Particl’s Open Marketplace), the Lightning Network, and etc. It also enables RingCT to be directly linked to CT transactions so that it can reach full programmability, as we’ll see later in this article.
Just like blinded transactions, which use the CT protocol, anonymous transactions are entirely trustless and don’t rely on any sort of trusted setup. It’s important to note that RingCT transactions are also a bit bigger than Confidential Transactions, although not by a big margin. This is due to the addition of ring signatures (MLSAG) into the mix.
Fun fact: RingCT was initially implemented on top of the Cryptonote codebase (Monero). The Particl team is the first team to ever develop a custom implementation that could work on any other codebase, in this case, the Bitcoin codebase.
Ring Signatures (MLSAG)
- Report from Quarkslab audit into Particl’s implementation of MLSAG: https://blog.quarkslab.com/resources/2019-07-05-audit-particl-bulletproof-mlsag/particl_audit_report.pdf
Multilayered Linkable Spontaneous Ad-Hoc Group Signatures (MLSAG), or ring signatures, is the Ring part of RingCT. It is a type of digital signature that is performed by many outputs at once within a given group of RingCT outputs (represented by Anon balances, on Particl Desktop). It is then impossible for any observer to tell which of the participating outputs within that signature is the output actually sending out the transaction.
Wikipedia describes ring signatures as follow: “A ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys. Therefore, a message signed with a ring signature is endorsed by someone in a particular group of people. One of the security properties of a ring signature is that it should be computationally infeasible to determine which of the group members’ keys was used to produce the signature.”.
In RingCT’s case, the digital signature used to execute a transaction could have originated from any member of the ring group. Users put some of their funds within an Anon balance. Funds held within an Anon balance are used to execute RingCT transactions. Before a transaction is executed, the protocol anonymously signs it by using other RingCT outputs as decoys and produces a signature that, when verified, looks like it could have been initiated by any of the owners of the RingCT outputs used by the ring group. It is not possible to know who really made the transaction because it could be anyone that has an output that’s being used by the ring group as a decoy.
This effectively anonymizes all values contained within a transaction— the amount transferred as well as both the transaction’s sender and receiver. It also arms transacting parties with a very strong plausible deniability (1, 2).
How to Make an Anonymous Transaction (RingCT) on Particl Desktop
On Particl Desktop, it is possible to pick the number of members you want to have within the ring group you’re going to use to anonymize your transactions. On the client, this is referred to as NO. OF RING SIGS.
What it means is simple, for every input used to generate your transaction, a number of other outputs will be used to create a digital signature that could have been signed by any of the 24 participants. In the screenshot just above, the value 24 is selected. This means 23 fake outputs, and 1 real one (the sender of the transaction) will be used to obfuscate the transaction (if it only has 1 input). If the transaction uses 3 inputs, it means 3 signatures, one for each input, with 3 different ring groups of 24 participants each, will be generated in order to execute the transactions. This may sound complicated, but don’t worry, Particl Desktop does everything for you and makes RingCT transactions as easy to send as any other type of transaction.
To make a RingCT transaction, simply go into your Send/Convert tab, choose the Anontransaction type, click the Advanced Options, and use the PRIVACY LEVEL (NO. OF RING SIGS) slider that appears at the bottom left corner of the page. The value you pick will be equal to the number of ring members that will be part of your ring group. In reality, you can just leave the slider untouched and use the default level of privacy (8 ring members). This represents a good balance between privacy and cost.
Note: The more inputs are consumed to execute a RingCT transaction, the more expensive it gets, but also the more private it is. Also, the more ring members (RING SIGS) is selected before executing a transaction, the more expensive it gets, but also the more private it is. If you don’t care about the cost of a transaction and just want maximum privacy, form transactions with as many ring members as possible and with as many inputs as possible.
Keeping a Good Level of Privacy
As a general rule of thumb and in theory, RingCT gets more private as more people convert their public balances into Anon balances, thus creating more Anon outputs to be used by ring groups for RingCT transactions. That’s because RingCT relies on other people’s outputs to plausibly deny which output actually signed a transaction, and the more RingCT outputs there are to sign transactions, the stronger the privacy and plausible deniability aspect of RingCT gets.
But, while outputs are randomly picked from any Anon outputs in the chain, they’re most often picked from the most recent RingCT transactions. The reason the protocol behaves this way is in response to this research paper which demonstrates that real inputs can be guessed to be the most recent ones if all the “mixins” are much deeper in the chain and haven’t had transactions for a while.
For this reason, it is recommended that all users keep with them an Anon balance which can be automatically put to use by the network (at no fee to the users, of course). Additionally, it is also recommended that users transact as much as possible with Anon transactions so that it can contribute to enhancing the entire network’s privacy. Note that none of this is required in order to execute a RingCT transaction, but the more people do it, the stronger and more resilient it becomes for everyone.
This is also one of the main reason why Particl’s Open Marketplace is going to use RingCT transactions, by default, on all marketplace transactions. The best way to increase the RingCT pool is through transactional activity and actual usage of the technology, so making it default on what will become the platform’s main application is only logical and will go a long way into making Particl’s RingCT protocol a very solid one.
Additionally, Particl allows anyone to use stealth addresses instead of regular, public addresses. Stealth addresses are one-time addresses that increase privacy because only the owner of a stealth address can tell if an output belongs to it or not. What is meant by “one-time address” is that a stealth address can receive payments many times, but each time, it generates a new ‘one-time address’ for that output/transaction.
Without knowing the private key of an address, an observer won’t be able to link and guess which outputs match which stealth address. This helps in protecting the identity of the receiver of a transaction.
On their own, stealth addresses probably aren’t enough to protect transactions information from any well-funded and motivated observer (i.e. state actor), but when combined with stronger privacy protocols such as CT or RingCT, it provides yet another layer of privacy for the user.
As it currently stands, blinded (CT) and anon (RingCT) transactions can only be executed to stealth addresses.
CT + RingCT Together = Infinite Possibilities
Both privacy protocols have their own pros and cons, but one of the most notable differences between the two Particl implementations is the fact that CT has programmable outputs while RingCT does not. What that means is that RingCT, as is, simply cannot be used within smart-contracts. What that does not mean, however, is that it cannot be used within decentralized applications. How is that possible, if RingCT cannot be used in smart-contracts? This is one of the big reasons why Particl keeps both CT and RingCT protocols on its network instead of just one of them.
In fact, because CT transactions have programmable outputs, they can be used in smart-contracts and then easily be linked to RingCT transactions. The benefit of Particl’s implementation is that the outputs can be spent from RingCT to CT for anything requiring a script, and then be sent back to RingCT.
The best example to illustrate this concept is with Particl’s Open Marketplace. It is a private-by-default marketplace that uses RingCT to completely anonymize marketplace transactions. What few people know is that the marketplace actually uses a combination of RingCT (the transaction) and CT (the smart-contract) for its escrow system, not RingCT.
That’s because the marketplace’s escrow system is based on smart-contract functionality, thus requiring transactions to have programmable outputs (hence why it uses CT). However, to interact with the smart-contract, users need to send a RingCT transaction to it, which the marketplace then automatically converts into a CT transaction for the duration of the escrow. Once it gets released by the two transacting parties, the transaction is finalized as a RingCT transaction.
A RingCT output is converted to a CT output which in turn forms the inputs of the escrow contract. When the escrow is ready to be released or refunded, it will directly be released to a RingCT output.— Kewde, Particl Developer and OMP Library Author
This is just one example of how RingCT can be given its full potential and leverage the Particl and Bitcoin ecosystems using its CT counterpart. The same sort of technique can be applied to integrate RingCT into other protocols or services such as atomic swaps, the Lightning Network, other decentralized applications, and etc.
If you liked this article, share it wide and beyond and stay tuned as more Particl Explained articles will be posted on particl.news in the future.
The Particl team