[Shipped] Privacy Version 2

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

No.

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

2 Likes

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.

3 Likes

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.

5 Likes

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.

2 Likes

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.

2 Likes

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

3 Likes

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.

2 Likes

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.

:slight_smile:

2 Likes

Thanks for your reply. Do you mean the sender address will still show up in the app but can not be monitored by “listening to the network”?

Or are you saying we completely rely on the memo to know whom the crypto came from?

I mean rely on the memo field. This field is open to use for multiple purposes. For example, the app can add an option for the sender to show his identity by using memo (e.g., ticked on checkbox), and only the receiver can view the identity of sender.

2 Likes

Update progress:

  • Privacy2 already deployed on Devnet.
  • App team is upgrading SDK and App based on Privacy2.
  • New backend coin service to boost app performance is testing.

We will release the instruction for the external builder to develop on Privacy2 soon!

7 Likes

Hi @hieutran,

Thanks for the updates!

A question for you: Will you deploy Privacy v2 on the actual Incognito testnet?

Hi @inccry, according to the plan, we will deploy privacy 2 on Testnet from early April.

1 Like

Will this affect the existing RPCs? If yes, which Github branch do you use for privacy v2? Thanks. @hieutran

Hi @abduraman,

Yes, some RPCs will be changed. We are developing on the branch: https://github.com/incognitochain/incognito-chain/tree/dev/privacy-v2

2 Likes