Incognito Whitepaper: Incognito Mode for Cryptonetworks

dungtran · July 28, 2020, 7:35am

We’ve updated the white paper:

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

17Strife · July 31, 2020, 7:00pm

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?

Jamie · July 31, 2020, 7:04pm

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

jtamign · December 19, 2020, 7:02am

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

Semaj · February 17, 2021, 3:49am

@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)?

dungtran · February 17, 2021, 9:07am

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

Semaj · February 17, 2021, 9:37am

Thanks, @dungtran.

Semaj · February 20, 2021, 1:33pm

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

Google gives me this.

Ducky · February 20, 2021, 1:32pm

dungtran · February 21, 2021, 12:51am

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

Semaj · February 21, 2021, 9:28am

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

Why do we force the burning address to be in shard 0? Is there any reason behind this?
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?

Semaj · February 21, 2021, 9:36am

And also, the link in the reference is dead.

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

dungtran · February 22, 2021, 2:21am

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

Semaj · February 22, 2021, 9:48am

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.
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?

dungtran · February 22, 2021, 10:12am

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.

Semaj · February 22, 2021, 10:26am

So where I can find the source code to generate the burning address 15pABFiJVeh9D5uiQEhQX4SVibGGbdAVipQxBdxkmDqAJaoG1EdFKHBrNfs?

Semaj · February 22, 2021, 3:29pm

What I want to state here is that, it is possible that someone (who generated the burning address 15pABFiJVeh9D5uiQEhQX4SVibGGbdAVipQxBdxkmDqAJaoG1EdFKHBrNfs, who knows, right?) knows the corresponding private key. Thus, he/she can spend the coins belonging to this address.

hiennguyen · February 23, 2021, 2:54am

Hi @Semaj,

15pABFiJVeh9D5uiQEhQX4SVibGGbdAVipQxBdxkmDqAJaoG1EdFKHBrNfs
This is the old burning address that generated by this commit.
It’s just a random point on the elliptic curve. So, it returns different results for each execution. We can’t reproduce how to generate this burning address with this code.

Therefore, we upgrade the generation new burning address from the predefined seed as this code.

hieutran · February 23, 2021, 3:01am

Your concern totally makes sense and your solution is still possible. Basically, we can reject any transaction that used one of the inputs (including both the real one and fake ones) belonging to burning addresses 1 & 2. Because all output sent to the burning address is a no privacy transaction.

Semaj · February 23, 2021, 10:24am

The links do not help at all. If the code cannot generate the burning address, who knows if it is randomly chosen or someone just put it there. So basically, as a user, telling me to believe that no one knows the private key is like telling me to stop using blockchains.