Buy crypto anonymously on the Incognito pDEX   

Incognito Whitepaper: Incognito Mode for Cryptonetworks

#8

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
7 Likes
#9

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?

3 Likes
#10

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

6 Likes
#12

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

9 Likes
#14

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

2 Likes
#15

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

4 Likes
#16

Thanks, @dungtran.

3 Likes
#17

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

Google gives me this.

image
image2590×376 35.6 KB

4 Likes
#18

:laughing: :laughing: :laughing:

4 Likes
#19

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

3 Likes
#20

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?

4 Likes
Privacy?
#21

And also, the link in the reference is dead.

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

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

3 Likes
#23
  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?
3 Likes
#24

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.

2 Likes
#25

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

2 Likes
#26

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.

3 Likes
#27

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.

2 Likes
#28

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.

4 Likes
#29

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.

2 Likes