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.

Who are you?

@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:

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:

Implement MLSAG protocol to replace for Sigma protocol. It is used to shield the sender.

Implement the one-time address feature.

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.

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.

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

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.

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

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.

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.

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.

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 …)

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.