An important fondation for GRIN transactions will be Payment Proof made mandarory. It will disable the ability of receivers to deny receipt of payment.
For that David @david has created this solution through this RFC which I believe has been implemented in GRIN:
It seems to me that the solution doesn’t prevent any party to pretend having received fund through a given kernel with a given amount from different (fake) senders addresses, enabling the ability to make many “receiver” proofs for a given kernel. Also the sender could artificially make different payment proofs with many different (dishonest) receiver addresses that he makes up. This can probably create problems.
My proposed fix is that payment proofs include proof-of-signature-of-kernel in the payment proof, making it not possible to people that have not signed the kernel to claim receipt or spend of fund for this kernel.
We can achieve that by requesting that the payment proof for the receiver incorporates a simple signature with its partial excess as public key and including its receiver address and the total excess in the message for this signature
The sender should also do the same for his partial excess and prove that he signed it, while committing to his address, total excess, and receiver address.
We can verify that the sum of the two partial excesses sum to the total excess that is being committed to.
The point of the payment proof is to prove to the receiver that you sent the funds to them. It’s signed by the private key of the receiver’s (slatepack) address. A receiver with a known slatepack address cannot deny receiving the funds as long as the following conditions occur:
The kernel is confirmed on chain.
The signature that commits to the kernel and amount validates against the known slatepack address.
As long as those conditions occur, then a receiver cannot deny receiving the funds.
While I agree, payment proofs could be created that pretend to prove that the funds were sent to a different address (that you control), that is not a problem a payment proof is meant to solve. We’re not trying to prevent people from claiming false ownership. Payment proofs only need to prevent the receiver from falsely claiming they never received the funds.
If you care to prove you were sent funds, that’s already quite simple to do: Just prove ownership of the output in the transaction.
This method has the same scalability, it is also two signatures, just with the partial excesses as public keys. And are proof of knowledge of the partial excesses, so yes it is a bit different.
But if the current method can resolve all relevamt conflicts then we are good.
Is there a way to trick the assumption: A receiver with a known skatepark address? In court cases for example
It seems like the solution with directly using the partial excesses as public keys allows to not use that assumption. We can also think of the receiver wants to prove that the sender sent him coins for this kernel.
Depending if the activity is illicit (drug, sex workers, etc, for example) different payment proofs with different strengths might be interesting to have to avoid people creates problems to other people.
In fact, at some point, due to grin doing payment proofs being attained through offchain protocol , we might think on how to create different payment proofs (by package) for different usecases.
Might be a usecase of interactivity in grin: the possibility to offer different payment proofs alllowing to prove, or not, different things according to if the tx is legal activity or illegal activity, and so on and so forth. People would agree on which payment proof they use. In any case, it would be helpful first probably to be able to opt out easily from payment proofs in some cases as well (illegal activities)
Are you sure you can really do that and that it is quite simple?
Sure you can prove that you own outputs that are in the same block of the kernel, but I have the impression that nothing can ensure to people that those outputs belong to the considered transaction.
Not even talking about the merkle proofs and stuff that you would have to have.