Third-party verifiable transactions

[GandalfThePink]

There are several options to verify payments in second level solutions, but on the chain payment can only be proven involving both sender and receivers interaction.
But there is a simple option to allow verification at the base layer, requiring a wallet modification.

For a verifiable payment, the receiver needs to authenticate themselves. This is best done via the same key that is also used to sign the MimbleWimble transaction. The receiver request a payment of v coins to the 'public key' kG, resulting in the commit C = v L + kG.

The sender then prepares the transaction and enters the requested amount v plus the IP of the receiver (or communicates the slates in any other way). But in addition the sender also inputs the address kG.

The wallet now starts communication with the receiver and verifies that the receiver is in-fact using the key kG. If not the transaction is aborted and not finalised. Otherwise the transaction is passed to the chain as usual.

If needed the sender can now create a proof of payment. The third party knows kG as identification of the receiver. After revealing the amount v, the UTXO can be found and the payment confirmed.
In addition the kernel excess of that payment can be signed by the sender after subtracting kG, proving that the payment in question originated from the sender.

From a uses perspective the only addition is that a payment can have an address associated to it. And if it does proofs of payment can be created afterwards. At the chain level nothing changes and to any external party all transactions look exactly the same.

[bardarehkramat]

I still could not succeed in its implementation

[garyyu]

@GandalfThePink
Is this duplicated to #2652? (or honestly #2652 is duplicated to this one since this one is created earlier), or can we say #2652 is the exact solution for this issue 😄

If not, could you please describe a precise design? to explain for example:

1. But in addition the sender also inputs the address kG.

How the sender input this? where?

2. The wallet now starts communication with the receiver and verifies that the receiver is in-fact using the key kG.

How to verify the receiver?

3. If needed the sender can now create a proof of payment.

What this proof looks like? how to create it exactly? this is the key part.

4. The third party knows kG as identification of the receiver.

How the 3rd party know this kG belongs to the receiver?

5. After revealing the amount v, the UTXO can be found and the payment confirmed.

The UTXO can be found? I'm afraid it can't in some cases in case it's cut-through ed

[GandalfThePink]

This is not really a duplicate of #2652 since the verification process is different. My idea encrypts the verification into the transaction data, while in #2652 the verification is stored locally by the client.

But by putting all the required information on the chain, some privacy is lost and the proof becomes more complicated, because as you say, there may be cut-through or UTXO's can be spent. In these cases there are options, but just checking a kernel is far simpler.

They only advantage I can see for this method is that the proof can be reproduced even when the wallet is restored from seeds since no information must be stored at client side. But this seems a rather small advantage for all the extra complications. Only when we think that this is a very essential feature, this idea should be used.

I think we can therefore close this issue and I will try my best to be useful in the progress of #2652.