[Shipped] Privacy Version 2 for Incognito

[hieutran]

Remark: This work will continue in the new proposal Privacy Version 2

What privacy problem are you solving?

There are 2 main problems that privacy version 2 strives to solve: privacy and performance.

Privacy:

• Currently, every Incognito user has a unique public address which they may distribute to other users, who can then send assets (PRV or pToken) to that address via transaction output. This can lead to several security risks as it could enable someone to track your incoming transactions, which goes against what Incognito Chain is trying to do.

• In addition, Incognito is a UTXO based ledger. As Incognito does not currently use one-time-addresses, it is possible to decipher addresses based on the number of outputs.

Performance:

• Incognito uses the sigma protocol to ensure transactions cannot be forged. This is complicated and not very efficient.

• The implementation of bulletproofs has some limitations. It can be hard to apply optimization techniques to improve performance.

What is the solution?

Privacy:

• To address the first problem, the public address is never directly used . Instead, a Diffie-Helman exchange key is applied to create a unique one-time-address for each transaction output. In this way, validators who know all users’ public addresses will not be able to identify which user received any given transaction output. Only the receiver, who can recover the private key with respect to the one-time-address, is able to spend the received output.

• One-time-address technique helps to solve the second problem. As no one can identify which user received any given transaction output, a transaction with more than one input will not reveal the real sender.

Performance:

• To boost performance, we aim to integrate Multilayered Linkable Spontaneous Anonymous Group (MLSAG) Ring Signature with the one-time-address technique. The MLSAG Ring Signature will help to boost the performance of the whole anonymization process.

• The new implementation of Bulletproofs will also be optimized to significantly improve performance.

Remarks:

Looking at current performance, verification time should improve. We also we hope that transaction size will decrease significantly.

What are the key results?

Deploy on main-net with improvements:

• Decrease a transaction size by 20-50%
• Increase transaction throughput by 10-20%

Who are you?

The project will be implemented by @hieutran and @anpham from the core team.

• @hieutran is a cryptography researcher. His research topics are applied cryptography, privacy preservation for outsourced data, and privacy blockchains.

• @anpham is a cryptography engineer. He is currently completing his degree at the University of Science, Ho Chi Minh City. His research topics are applied cryptography and searchable encrypted data. He also has experience as a Software Engineer.

Why do you care?

As stated above, the current version is not perfect in terms of security, privacy, and performance. We, as idealist cryptographers, will continue to refine our products till they reach the highest standards.

What’s your plan? What’s your schedule?

The project duration will be 4 months from March 01, 2020, to the end of June 2020. Details are as follows:

Timeline	Task	Status	Delivery
Mar 30	Core cryptographic functions	Done	Local
Apr 30	Support all transaction version 2	Doing	Devnet
May 30	Backward compatible with all transactions version 1	Doing	Devnet
Jun 30	Deploy Testnet		Testnet
Jul 30	Deploy Mainnet		Mainnet

What’s your budget?

Resource	Cost	Quantity	Monthly Cost
Cryptography engineer	1,000 PRV	2	2,000 PRV
Subtotal			2,000 PRV
TOTAL (x 4 months)			8,000 PRV

Is there an existing conversation around this idea?

Privacy Version 2

Objective: Launch privacy v2 Length: 3 months Key results: Ship one-time address Ship Multilayered Linkable Spontaneous Anonymous Group (MLSAG) Ring Signature Ship Confidential Assets Decrease transaction size by 20%-50% Increase transaction throughout by 10%-20% Detail Schedule: June: Continue to integrate with pDEX (1 - 7 Jun) Refactor and Optimized source code to decrease transaction size and increase transaction throughput (7 - 14 Jun) Integrate with Portal (15-30 Jun) July: Deploy Pr…

Is there anything else you would like the community to know?

Let us know what you think!

[hieutran]

Progress Update: March 07, 2020

Hi, everyone! In this post, we sum up the development activity this week:

We have finished the core cryptographic functions for the new privacy package. That includes:

1. Implement MLSAG protocol to replace for Sigma protocol. It is used to shield the sender.
2. Implement the one-time address feature.
3. Refactor Bulletproofs implementation.

We believe that with the new implementations, we are able to increase the performance for creating and verifying a transaction and reduce the transaction size. The benchmark for them will be released in the next week.

In the next week, we will design and implement the debug tool. It is very useful for debugging and testing the correctness of the core cryptographic functions.

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

[Jamie]

Looking forward to the improvement of transaction size.

[anpham]

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

[hieutran]

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

[anpham]

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.

[thaibao]

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

[hieutran]

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.

[thaibao]

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

[anpham]

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.

[thaibao]

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?

[hieutran]

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 ==================

[hieutran]

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 ==================

[thaibao]

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?

[hieutran]

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.

[hieutran]

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.

[hieutran]

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.

[ELDAD]

What is confidential asset???

[hieutran]

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.

[ELDAD]

Wow very cool, can’t wait for it