[Shipped] Privacy Version 2

Hi guys, we are working hard on the test and debug phase. The main problem is the backward compatibility with the current version on Mainnet and Testnet.

The integration with Portal will be delayed until July. The performance report will be released before next Monday (Jun 29, 2020)


Hi all,

We are finishing the implementation phase for privacy version 2. The majority of crucial barriers have been resolved. We are doing an automation test on devnet.

The summary of finished tasks is as follows:

  • All transactions version 2 (PRV and pToken)
  • Conversion transaction from version 1 to version 2 (PRV and pToken).
  • Backward compatible with old data (syncing fullnode testnet)

The pending tasks are as follows:

  • Benchmark transaction size and throughput
  • Fix bugs from QC team.

Good :heart::heart::heart:


Hi all, here are the new updates for privacy version 2.

We have passed all test cases on Devnet. Now is the time to integrate with pDex version 2 and merge with the optimized syncker from the Consensus team before deploying on Testnet.

With privacy version 2, we reduce 35% in terms of transaction size with one input and two outputs, and 58% on average.

Transaction throughput is also improved by around 11%-21%. The detail is provided in here.

Compare token transaction size between version 1 and version 2

Compare normal transaction size between version 1 and version 2


Don’t we already have one-time addresses when shielding coins?


Update for August:

  • Integrated with pdex ver 2
  • Internal audit code for privacy ver 2

Plan for September:

  • Introduce a new viewing key to encrypt amount of output coins with the full-node.
  • Implement Confidential asset feature

It’s only available for 60 minute then it switches…

I know. Isn’t that exactly what a one-time address is?


Currently, shielding a crypto asset uses an address from a pool of rotating addresses. If you view a deposit address in a block explorer, you will see other transactions days, weeks before yours. As Jerry notes, these addresses are only available to a user for 60 minutes during a deposit transaction. Addresses are then reused after a certain amount of time has passed to ensure deposits are properly credited.

A one-time address is exactly as it sounds. A one-time (use) address. Every deposit transaction will receive its own address. The address will never be reused again. Not by the original depositor nor any other depositor. This will solve the time window issue, as the address will remain “available” until a deposit is made (or presumably canceled by the user).


Right, so even though my COIN app can take 1-3 days I could then deposit it straight to incognito instead of going to KuCoin first, really cannot wait for that.

Not trying to pester. But I want to make sure I understand.
When I see one time address, I get excited thinking I would only need to give a person my address once regardless if it takes a week for my payment to arrive, that won’t matter because the address will not expire.

But then I’m informed, no it’s a one time address meaning it is used once and discarded, which makes me think, isn’t that what we already have?

So the one time address can be confusing, because some of us read that as permanent and others read that as temporary.

What you are telling me is that a one time address is actually both.
When OTA is introduced that address that I generate to deposit to will be permanently there for however long it needs to be causing no depositing issues with expiration, etc.
Then once used it will be immediately discarded, thereby securing me again??

1 Like

Correct. The address will not expire. You could give it to someone who then deposits to it one day, one week, one month, one year, etc later.

Currently, there is rotating pool of addresses which are reused for incoming deposits. The reuses are spaced far enough apart (think days/weeks) to preclude confusion on the Incognito side (usually). However it also means that the Incognito software is only looking for a change on the address during a very limited window. And even then, the software is only looking for a single change (single deposit) – hence the reason we cannot send twice to the same address, even within that very limited time window.

Almost. Think of the way your BTC wallet software (Ledger, Trezor, Electrum, Atomic, etc) works. When you generate a new receive transaction, the wallet software will automatically generate a new address for you to send coins to. The intent is for that address to be used for only that one receive transaction. However there is nothing that stops you from you reusing that address over and over. You give up some of anonymity and untraceability by reusing an address, but technically … there is nothing stopping you from doing so. It’s not recommended from a privacy perspective of course, but technically is possible.

With a one time address, you could give it out and reuse that address over and over. You would then be “linking” all of those transactions together. If one is determined as belonging to a KYC exchange, you will no longer have any plausible deniability “unlinking” all those separate endpoints. A properly used OTA provides that plausible deniability. A misused OTA is no different than the permanent single addresses that preceded them. So OTA can be both “temporary” and “permanent”. The former is the correct usage; the latter is a misuse. Both are technically possible. In both cases, addresses are not discarded. A proper OTA is only used once by the wallet software. The address is still valid, as it may contain usable UTXOs for a very long period of time, depending on how the wallet software chooses unspent transactions for a spending transaction. Research “coin control” and “UTXO management” for a deeper understanding.


I guess that you guys are talking about “temporary address” in the shielding process, right? That address is used to receive the deposit public coin (token) from a public chain like ethereum, bitcoin, binance, etc.

I think we are being confused about terminologies: “one-time address”: the new feature in privacy ver2 and “temporary address”: the rotate address which is reused for the shielding process.

Thank @Mike_Wagner or the obvious answer about “temporary address”.

I would like to make clear that:

This information is totally correct for “one-time address”.

In addition, you guys can check more detail about OTA here.


Have this gone live yet?

hi Semaj, CA is in the testing phase. This week, we will deploy a new Testnet for Privacy 2 that includes CA.


Glad to hear that.

I read receive addresses will be private, as in not visible, in the future, for transaction between Incognito addresses. Why is that needed? Wouldn’t it result in trouble?

When I ask 5 people to send me the same amount of coins coz we split a bill, how do I know who paid and who didn’t pay?

I consider my Incognito Address to be like my bank account number. There is no harm in people knowing my bank account number, nor is there any harm in other people’s bank account number showing up on my statement of account. This all, as long as they can’t use that number to check my bank account history.


Ask them to add their name to the memo field to identify themselves.


I knew that suggestion would come up, but you know how people are, they forget. In the described scenario it can be troublesome. Identifying payment by the account the money came from is foolproof.


Hi @Jamie,

The difference between your bank account and incognito address is that the bank account does not visible to the public. No one can view your bank account’s history except only you.

In the current version, we did not hide the identity of the receiver. So, anyone can listen to the network and monitor your address’s history.

Typically, some payment systems based on cryptocurrency require the sender must include a payment id for their transaction. @Mike_Wagner’s suggestion is one of the solutions. I think it up to the solution of the third party like Incognito wallet app.

From the chain side, we have a protocol for the sender to prove that this TxId was created by him. I think we will add it to an explorer like IncScan in the future.