[Shipped] Privacy Version 2 for Incognito

Progress Update: March 14, 2020

In this week, we have done:

  1. Debugging scripts to call GRPC and test throughly one-time address, MLSAG, Bulletproof.
  2. Designed and is integrating privacy version 2 with version 1. We have had difficulties in this task because we are trying to make the code maintainable and scalable for future version updates.

In the next week, we will try to integrate privacy version 2 with different packages within the Blockchain system such as RPC package, Blockchain package.

Thanks for reading our progress update! keep an eye on our repository here

4 Likes

In addition, please see the numbers and charts of benchmarks for core cryptographic functions here. The formal report will be updated later.

2 Likes

Progress Update: March 21, 2020

Hi everyone, I am @anpham of Incognito again. In the previous week, we have nearly integrated the new Bulletproof implementation and the MLSAG Ring Signature to improve the chain performance. However, we had some trouble with the database and need to fix it for compatibility between privacy ver1 with ver2.

In the next week, we will work on this problem and fully upgrade the chain’s performance. For upgrading privacy, we will integrate the one-time address to the chain in several weeks later after we have done with the performance.

Thank you for reading our progress update! Our work is open source and you can see our work here on branch dev/privacy-v2.

4 Likes

As we know, we need to process on old tx version and new tx version. So, with old tx version, we must change something when creating tx by random committee but our data can not retrieve public key from random commitment, I think we have some stuck here and suggesstion is contact @hungngo to understand about new db version or review for a refetching solution on DB when you feature’s deployed on network

3 Likes

Progress Update: March 28, 2020
Hi guys, it is me again with my weekly progress update.
In the previous week, we have done implemented the MLSAG Ring Signature with the new Bulletproof for normal transactions.
In the next week, we will test the implementation and also integrate it with special transaction types such as the staking reward, transaction with 2 different types of coin.
Thank you for reading our progress update! Our work is open source and you can see our work here on branch dev/privacy-v2.

2 Likes

To make sense testing for this proposal, from my suggestion, using dev-net and run with the latest code of DB ver2, create many tx ver1. After that, use those data of tx v1 and try to convert on tx v2. By this way, we have a good real test case, in here, we use data UTXO of tx ver1 to create tx ver 2

2 Likes

Progress Update: April 4, 2020

Hi guys, it is me again with my weekly progress update.

In the previous week, we followed @thaibao suggestion and managed to successfully deploy the txver2 (without onetime-address) locally on my machine.

In the next week, we will write unit tests to make sure there is no bug and try to code onetime-address.

Thank you for reading our progress update! Our work is open source and you can see our work here on branch dev/privacy-v2.

1 Like

How about transaction size of this ver.2 @anpham @hieutran? I think after improving bullet proof, we have a smaller tx size on this ver2, right?

Progress Update: April 12, 2020

This week we have finished the creation and send transaction version 2 for PRV and switcher to allow initialization a transaction with input coins version 1 and output coins version 2. In addition, these functions passed almost our unit tests.

However, the transaction size does not decrease significantly. Specifically, for a transaction with 1 input and 10 outputs, the size is decreased by 20% (from 5918 bytes to 4766 bytes). Due to this issue, we cannot start a one-time-address feature this week. This task will be moved a few weeks later.

Next week, we will continue working on the creation and send transaction version 2 for Tokens. We will also work on the optimization transaction size task. The following is a benchmark for transaction version 1 and transaction version 2.

Proof length in bytes = 5780
Signature length in bytes = 101
Signature public key in bytes = 37
-
Number of InputCoins:  1
InputCoin[0] length in byte = 110
Sum bytes of inputCoins = 110
-
Number of OutputCoins:  10
OutputCoin[0] length in byte = 264
OutputCoin[1] length in byte = 264
OutputCoin[2] length in byte = 264
OutputCoin[3] length in byte = 264
OutputCoin[4] length in byte = 264
OutputCoin[5] length in byte = 264
OutputCoin[6] length in byte = 264
OutputCoin[7] length in byte = 264
OutputCoin[8] length in byte = 264
OutputCoin[9] length in byte = 266
Sum bytes of outputCoins = 2642
-
Done ==================
Getting statistic of ./tx2.json
Proof length in bytes = 3561
Signature length in bytes = 615
Signature public key in bytes = 590
-
Number of InputCoins:  1
InputCoin[0] length in byte = 110
Sum bytes of inputCoins = 110
-
Number of OutputCoins:  10
OutputCoin[0] length in byte = 264
OutputCoin[1] length in byte = 264
OutputCoin[2] length in byte = 264
OutputCoin[3] length in byte = 264
OutputCoin[4] length in byte = 264
OutputCoin[5] length in byte = 264
OutputCoin[6] length in byte = 264
OutputCoin[7] length in byte = 264
OutputCoin[8] length in byte = 264
OutputCoin[9] length in byte = 266
Sum bytes of outputCoins = 2642
-
Done ==================
6 Likes

Progress Update April 17, 2020

This week we have finished the first step of optimized transaction size task (next steps will be done after one-time-address feature is available). Now the transaction size with one input and 10 outputs decreases by 30% (from 5918 to 4128 bytes).

Let me share a little bit about our result in this task. Currently, one of the heavy parts in a transaction’s proof is the proof of one-out-of-many algorithm. In privacy version 2, it will be replaced by a mlsag signature. With the new signature, for each input, the transaction’s proof reduces from 2000 KB to 450 KB. Thus, in case of more than one input, for example, 2 inputs, we can optimize approximately 60% of transaction size. That means we can reduce half of the current size at least.

Getting statistic of ./tx1.json
Proof length in bytes = 5780
Signature length in bytes = 101
Signature public key in bytes = 37
Getting statistic of ./tx2.json
Proof length in bytes = 3561
Signature length in bytes = 552
Signature public key in bytes = 15

In addition, we also have finished the task “create and send private transactions for tokens” but we did not test this feature.

Next week, I will work on the task “create no-privacy (mint and burn) transactions”. In the meantime, @anpham will work on one-time-address feature. Later, we have one week to test all features before deploying to dev net.

The following is the optimization result.

Getting statistic of ./tx1.json
**Proof length in bytes = 5780**
**Signature length in bytes = 101**
**Signature public key in bytes = 37**
-
Number of InputCoins:  1
InputCoin[0] length in byte = 110
Sum bytes of inputCoins = 110
-
Number of OutputCoins:  10
OutputCoin[0] length in byte = 264
OutputCoin[1] length in byte = 264
OutputCoin[2] length in byte = 264
OutputCoin[3] length in byte = 264
OutputCoin[4] length in byte = 264
OutputCoin[5] length in byte = 264
OutputCoin[6] length in byte = 264
OutputCoin[7] length in byte = 264
OutputCoin[8] length in byte = 264
OutputCoin[9] length in byte = 266
Sum bytes of outputCoins = 2642
-
Done ==================
Getting statistic of ./tx2.json
**Proof length in bytes = 3561**
**Signature length in bytes = 552**
**Signature public key in bytes = 15**
-
Number of InputCoins:  1
InputCoin[0] length in byte = 110
Sum bytes of inputCoins = 110
-
Number of OutputCoins:  10
OutputCoin[0] length in byte = 264
OutputCoin[1] length in byte = 264
OutputCoin[2] length in byte = 264
OutputCoin[3] length in byte = 264
OutputCoin[4] length in byte = 264
OutputCoin[5] length in byte = 264
OutputCoin[6] length in byte = 264
OutputCoin[7] length in byte = 264
OutputCoin[8] length in byte = 264
OutputCoin[9] length in byte = 266
Sum bytes of outputCoins = 2642
-
Done ==================
5 Likes

Hi @team,
We also know that one-time-address is a way to fully hide the info of the receiver. But in some scenarios, some tx with metadata need to processing some feature and maybe it no need privacy. So, if one-time-address is used in this case, it is still to make sure privacy is full or not?
That mean:
1/ 1st tx make transfering PRV A to B with privacy one-time-address to hide B
2/ B use output from 1st to make a non-privacy tx for a feature(dex, burn, stake …)

So B will be still showed on network, right?

1 Like

We know that some type of transactions on Incognito does not require privacy. For example, staking transaction or trading transaction.

By default, in version 2, a non-privacy transaction will only show the value that it transfers.

  • The sender is always hidden in a ring with decoy members.
  • The receiver is always a one-time address except for the burning address.

Any necessary information, such as the address in which receives return 1750 PRV in a stake transaction or receives exchanged token in a trade transaction, will be put inside the metadata info.

3 Likes

Progress Update April 24, 2020

This week, we worked on two tasks: one-time-addresses and non-privacy transactions.

Unfortunately, we had a problem with the flow of stake/unstake PRV in the mining process.

For version 2, the address which will receive the unstake PRV is a one-time-address. So the problem is, we need to define a protocol such that validators are able to confirm that the one who sends an unstake transaction is matched with someone who sent a stake transaction before.

We already worked with our teammates to solve this problem and found a solution.

Next week, we will continue to work on these two tasks.

2 Likes

Progress Update May 1, 2020

This week, we worked on two tasks: one-time-addresses and non-privacy transactions. We have already finished both of them and we are doing unit tests.

Next week, we will continue to work on unit tests and local tests before deploying to the dev-net.

In addition, we also work on confidential asset proposal. It is necessary because we need to make sure that it will compatible with the new privacy version.

1 Like

What is confidential asset???

1 Like

Hi @ELDAD, thanks for your question!

Currently, Incognito supports confidential transactions in which the amounts transferred are kept visible only to participants in the transaction.

The confidential asset is a new privacy feature that we would like to introduce in the near future. It will not only make transaction amounts private but also blind asset types.

2 Likes

Wow very cool, can’t wait for it

Progress Update May 8, 2020

This week, we finished the unit test phase for the one-time address feature. We also finished the discussion and review phase for the confidential asset proposal. The detail is provided here.

Next week we will work on the integration test for the one-time address feature and implement building block functions for the confidential asset.

Thank you for reading our progress update! Our work is open source and you can check our work here on branch dev/privacy-v2-ota.

3 Likes

Great work. pDEX has a higher requirement of scalability than other privacy cryptos (e.g. Monero, Zcash), so considering on trade-off between privacy and scalability is more important.
It would be great if you could carefully evaluate works from Monero Research Labs, Lelantus and MW. Maybe some of them fit pDex well.

3 Likes

Progress update May 22, 2020

Hi all, first we would like to apologize for the missing of the progress update last week. We are focusing on fix some critical bugs to privately transfer pTokens. Finally, they have gone away and now we have time to update our work :slight_smile:

1. Done with local test:
a. Create and verify PRV transfer transaction
b. Mint and burn pTokens
c. Create and verify pToken transfer transaction

2. Done without local test:
a. Stake and unstake transaction
b. Convert UTXO form version 1 to UTXO version 2

3. Work in progress:
a. Integrate with pDEX
b. Do local test for 2a and 2b

1 Like