Buy crypto anonymously on the Incognito pDEX   

How to prove to a 3rd party a particular transaction with a custom privacy token is mine.

#1

If person A sends a custom privacy token to person B, but A would like to prove that transaction from A to B occurred to a third person C, what is the best way to do this using the incognito or incscan.io explorers? Would memo text with a pgp key (or something else) have to be included or are there other simpler ways?

1 Like
#2

Hi @Socrates,
Currently, we cannot use memo text to prove the transaction occurred to C. Because C cannot view the amount transferred in the transaction. The only way is A will provide some secrets to compute coin commitment along with transaction detail and C can compare with the output coins to verify the correctness of the transaction.

3 Likes
#3

@hieutran Appreciate the response, but this is a situation where A doesn’t need to prove anything about the amount that was transferred, only that a transaction from A to B occurred and then afterwards A wants to prove to person C that A was indeed the one who sent a transaction to B (no amount, receive addr or coin type need be known), only that A is the real Sender of the transaction.

For example, person A could send the Transaction ID # to third person C as evidence, but this doesn’t prove person A is the sender of that transaction id# since anyone could have looked up the transaction ID# in the incscan explorer and copied it. Using the MEMO text, my question is: what kind of MEMO could person A, the sender, include that could help A prove later to a third-party C that the Transaction ID# truly belongs to A [ even if C cannot know the amount or the receiver] ?

Perhaps what I am really asking now as I try to clarify: What is the best way person A could prove that A is really the author of a particular MEMO text that is publicly visible in the chain explorers?

1 Like
#4
  1. Create a new keychain.
  2. A sends the funds to be sent from A to B, to the new keychain’s wallet.
  3. Send the funds from A to B.
  4. A and B send their addresses to C.
  5. A sends the read-only key for the new keychain’s wallet to C.
  6. C will be able to view the sending address and receiving address & other details, confirming a transaction occurred between A and B.

A new keychain & wallet are used to isolate the transaction history of A. If A sends the read-only key from an account with transaction history, C will be able to see those transactions too.

#5

Thank you. @Mike_Wagner I had not thought of using the read-only key precisely because it involved the whole history of that keychain wallet, not a single transaction, but creating a new keychain could isolate the transaction. Will consider this.

#6

Hi @Socrates, I got your point :slight_smile:

If only need to prove that A is the sender of transaction ID#, we have some ways. For example, A will sign a random message by his private key and then put it into the memo field. Anyone can use the public key of A to verify. The problem becomes harder if C wants to verify the amount in transaction ID#. As I mentioned above in this case, A must publish some secrets for auditing purpose

#7

Are you sure? To my understanding private keys and public keys work the other way around. Having your public key means I can encrypt a message that only you can decrypt with your private key.

It would help to know how this will be used, but looking at the answers so far, I am not sure the original poster is willing to reveal the details.

It could work the other way around. If C has an incognito account, he could supply his public key to A. A would then use that public key to encrypt some phrase, use that in the memo of the transaction to B, and tell C what the phrase is. No one will be able to read the decrypted phrase, but C.

But again, maybe there is an easier way to do this. We need more details for that.

1 Like
#8

Hi @Jamie,

Basically, we have two applications of an asymmetric cryptosystem: (1) digital signature scheme; (2) encryption scheme. You can read more here.

In this case, I think the best way is we will use (private_key, public_key) for the digital signature scheme. That means, with A’s public key, C is able to verify that the TxID belongs to A.

2 Likes