Incognito Whitepaper: Incognito Mode for Cryptonetworks

Introduction: A Platform of Decentralized Privacy Coins ▾

Today, anyone can send BTC, ETH, and thousands of other cryptocurrencies to another party without going through a financial institution [Nakamoto, 2008; Buterin et al., 2014]. For those who value privacy, these cryptocurrencies come with a big tradeoff. Transactions are recorded on public ledgers, displaying amounts involved, inscribing virtual identities of their senders and receivers. Given the choice, we strongly believe that very few people will willingly disclose their crypto financials to the entire world.

The inherent lack of privacy to cryptonetworks today is a real and present threat to the entire crypto space.

Existing solutions like Monero, Zcash, and Grin introduced their own version of cryptocurrencies that focus on privacy, based on CryptoNote [Van Saberhagen, 2013], Zerocash [Sasson et al., 2014], and Mimblewimble [Jedusor, 2016] respectively.

Incognito takes a different approach, based on the premise that people don’t want a new cryptocurrency with privacy. What they really want is privacy for their existing cryptocurrencies: incognito mode for any cryptocurrency.

Incognito is designed so users don’t have to choose between their favorite cryptocurrencies and privacy coins. They can have both. They can hold any cryptocurrency and still be able to use it confidentially whenever they want. Privacy needs to be ubiquitous, inclusive, and accessible.

Figure 1. Incognito as a privacy hub. It is interoperable with other cryptonetworks via shielding and unshielding processes , which allow cryptocurrencies like BTC and ETH to go incognito and back.

First, we proposed a solution to shield any cryptocurrency such as BTC, ETH, and USDT. In effect, any cryptocurrency can now be a privacy coin. Both shielding and unshielding processes are carried out via a decentralized group of trustless custodians. Once shielded, transactions are confidential and untraceable. To provide privacy, we employed the linkable ring signature scheme, homomorphic commitment scheme, and zero-knowledge range proofs.

Second, we presented a solution to scale out a privacy-focused cryptonetwork by implementing sharding on privacy transactions and a new consensus based on proof-of-stake, pBFT, and BLS. Transaction throughput scales out linearly with the number of shards.

Currently, with 8 shards active, Incognito can handle 100 TPS. And with a full deployment of 64 shards, Incognito can handle 800 TPS – a significantly higher number than that of other privacy blockchains, which usually can only handle less than 10 TPS.

Incognito launched its mainnet in November 2019 as a privacy-protecting, high-performance cryptonetwork to deliver incognito mode for other cryptonetworks like Bitcoin and Ethereum. As of February 2020, it has 8 shards powered by over 1,000 validators and has confidentially processed over $1.4M worth of crypto in 74 different currencies such as BTC, ETH, and USDT.

Shielding Cryptocurrencies: Turning Any Cryptocurrency Into a Privacy Coin ▸

Trustless Custodians: A Decentralized Approach to Cryptocurrency Custodianship ▸

Sending Cryptocurrencies Confidentially: Ring Signature, Homomorphic Commitment, and Zero-Knowledge Range Proofs ▸

Privacy at Scale with Dynamic Sharding ▸

Consensus: A Combination of iPoS, Multiview-PBFT, and BLS ▸

Multiview PBFT ▸

Incognito Software Stack: Navigating the Incognito Source Code ▸

Incognito Performance ▸

Network Incentive: Privacy (PRV) ▸

User-Created Privacy Coins ▸

Use Cases: Privacy Stablecoins, Privacy DEX, Confidential Crypto Payroll, and more ▸

Highway: an Upgrade to Incognito Network Topology ▸

Incognito Mode for dApps on Ethereum ▸

Future Work: Smart Contracts, Confidential Assets, Confidential IP, and more ▸

Conclusions, Acknowledgments, and References ▸

69 Likes

Had no idea the whitepaper was so succint and accessible.

Thunderous Applause!

6 Likes

It’s bitcoin white paper style :), but with many details in links

7 Likes

THK @dungtran for info! :face_with_monocle:

4 Likes

I love the diagram @dungtran as the saying goes ‘a picture says a thousand words’.
But as more coins are supported this diagram is going to get bigger :smiley:

2 Likes

We’ve updated the white paper:

  1. Incognito POS: a scalable and secure POS
  2. Multiview-PBFT: a new approach for implementing Practical BFT which totally removes the complexity of view-change in Tendermint implementation.
  3. Dynamic committee size
  4. Dynamic sharding
  5. New validator life cycle
5 Likes

Hi Incognito Community, I see that Network Explorer/Incscan show that the maximum supply of PRV is 100,000,000. Is this set in stone? Is there a possibility that the maximum supply will increase in the future?

2 Likes

That is set in stone. It will take 40 years to mine it.

4 Likes

Very informative and concise to the point. I love the diagram, the duality of the cryptocurrencies within Incognito. Thanks.

7 Likes

@dungtran I like the simpleness of this White-paper. I really want to know more about how these primitives are employed in Incognito, do you have any technical documents (or implementation specs)?

1 Like

You could find more information here https://github.com/incognitochain/incognito-chain/wiki. Some of on going works/discussions can be also found in this forum. e.g Dynamic Committee Size at Dynamic committee size and dynamic sharding: implementation phase

2 Likes

Thanks, @dungtran.

2 Likes

Hey @dungtran, I believe I found something weird in this spec document:
image

Google gives me this.

3 Likes

:laughing: :laughing: :laughing:

3 Likes

Thank you @Semaj, we’ll update the spec.

2 Likes

Hi @dungtran, I went through the documents you sent me and have some questions regarding the burning address.

  1. Why do we force the burning address to be in shard 0? Is there any reason behind this?
    image

  2. I know that burning addresses are used for locking tokens, however, there are two burning addresses on the Incognito repo, which are

// burning addresses
const (
	burningAddress  = "15pABFiJVeh9D5uiQEhQX4SVibGGbdAVipQxBdxkmDqAJaoG1EdFKHBrNfs"
	burningAddress2 = "12RxahVABnAVCGP3LGwCn8jkQxgw7z1x14wztHzn455TTVpi1wBq9YGwkRMQg3J4e657AbAnCvYCJSdA9czBUNuCKwGSRQt55Xwz8WA"
)

Do these two addresses serve different purposes?

2 Likes

And also, the link in the reference is dead.

Reference
https://github.com/incognitochain/incognito-chain/blob/dev/master/utility/generateburnaddress.go
2 Likes

Hi @Semaj,

Why do we force the burning address to be in shard 0?

We just randomly pick the address, it happens to be in shard 0.

there are two burning addresses on the Incognito repo

The first burning address is generated by a random seed, it’s hard for community to verify. Then we change to the burningAddress2 which is generated from a fixed seed. Source code is at https://github.com/incognitochain/incognito-chain/blob/production/utility/generateburnaddress.go

1 Like
  1. The spec says that index is the minimum positive integer number such that the last byte of output is zero (it will make sure that burn address belongs in Shard 0), so I think it was intended.
  2. As I run the scripted in the provided link, the generated burning address is 12RxahVABnAVCGP3LGwCn8jkQxgw7z1x14wztHzn455TTVpi1wBq9YGwkRMQg3J4e657AbAnCvYCJSdA9czBUNuCKwGSRQt55Xwz8WA.
    There may be a case such that some people know the private key corresponding to the burning address 15pABFiJVeh9D5uiQEhQX4SVibGGbdAVipQxBdxkmDqAJaoG1EdFKHBrNfs. In that case, they can spend funds locked in this address.
    The nature of Incognito is privacy by default, which means that even if someone did the thing, it will not be detectable. Does Incognito implement any mechanism to prevent coins from a burning address to be spent?
1 Like

We publish the source code to create the burning address and making sure that nobody (including us) could find out the private key from this public address. Since Incognito shields the sender address, validators won’t know whether sender’s address is a typical address or a burning address or any special addresses, i.e. there is no mechanism to prevent coin sent from a specific address.

1 Like