# Bidirectional payment proofs

**URL:** <https://forum.grin.mw/t/bidirectional-payment-proofs/9175>\
**Category:** Research\
**Created:** [August 14, 2021, 8:09pm UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175 "2021-08-14T20:09:29Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\
**Post date:** [August 14, 2021, 8:09pm UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/1 "2021-08-14T20:09:29Z")

</div>

[This post](https://forum.grin.mw/t/eliminating-finalize-step/7621/106) already described the idea, but it was joined with other ideas which are completely unrelated. I thought it would be worth to present the idea as a separate thing which is why I described it here [Bidirectional payment proofs for Mimblewimble | grinvestigation](https://phyro.github.io/grinvestigation/bidirectional_paymentproofs.html).

This shows a way for parties to commit to another (hidden) arbitrary message at step2 which in this case is our payment proof.

I’m calling it bidirectional because it allows not only to prove the direction

```java
sender ------sent to------> receiver

```

but also

```java
sender <---received from--- receiver

```

NOTE: This is not a proposal. While I personally don’t think it’s more complicated than other payment proofs because it’s really just another message commitment, it’s unclear to me which payment proof method is best. It also has not been studied deeply by anyone else than myself so it could very well be insecure.

NOTE2: I’m not sure that replacing `f * Rr` with `Rr + f*G` would be secure, because both parties share the same `f`. In case one party didn’t add `f*G` the other could add `2f*G`. Whether that’s feasible or not and in which cases isn’t clear to me, so I’m scaling both nonce by `f` to avoid this situation.

---

<div class="post-metadata">

**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\
**Post date:** [August 17, 2021, 6:24am UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/2 "2021-08-17T06:24:32Z")

</div>

Yesterday, @tromp pointed that this bidirectional approach leaks some privacy, specifically, the exchange could demand proof of origin of coins you received. Since this bidirectional scheme means both parties have the same information it would mean that the receiver should always be able to provide this information.

That’s a great point and something I think we should protect against.

I believe both the early payment proofs and this bidirectional scheme suffer from this to some degree and I think there’s a simple fix for it. In the early payment proofs, instead of signing the `sender_addr`, the sender picks a random scalar `y` and computes a new, ephemeral address `ephemeral_addr = y*G`. The receiver can show this address, but since it’s a one-time address by definition, it shouldn’t leak anything. If the receiver shows the payment proof, the sender can simply say “nope, it wasn’t me”. On the other hand, if the sender wants to prove they paid, they can show `(Z, sig(Z, M), u)` where `Z` is a random curve point, sig is a proof of knowledge of private key for `Z`, `M` is the message we sign which can be the latest block hash or a message of choosing by the receiver, and `u` is a scalar such that `ephemeral_addr = Z + u*G`.

This should allow the sender to prove they paid while leaving the receiver with a random curve point.

I think it shouldn’t matter who the sender is, it should only matter whether the sender can prove they sent money to the receiver. In other words, we want the receiver to have an identity, but we might want to blind the identity of the sender.

_NOTE: We can use this same trick in the bidirectional scheme by using a random curve point instead of the sender\_addr._

_NOTE2: If the sender always generated a one-time address, then this could be our `ephemeral_addr`. The difference is on which curve we hold the ephemeral identities (ed25519 or secp256k1). In both cases, the payment proof would need to store some ephemeral private keys which were generated per transaction (unless we had derivations, but this complicates things and can again introduce a way to link things)._

---

<div class="post-metadata">

**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\
**Post date:** [August 17, 2021, 8:29am UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/3 "2021-08-17T08:29:31Z")

</div>

> [@oryhp](#):
>
> I believe both the early payment proofs and this bidirectional scheme suffer from this to some degree and I think there’s a simple fix for it.

The early payment proof promise doesn’t prove the identity of the payer. The receiver can put any arbitrary sender\_addr in there.  
And then have any arbitrary payer (e.g. himself) make a witnessing payment. That doesn’t prove that it was sender\_addr that paid…

---

<div class="post-metadata">

**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\
**Post date:** [August 17, 2021, 9:17am UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/4 "2021-08-17T09:17:49Z")

</div>

Yes, but they have a reference to the sender through sender\_addr. It can’t be proven that it wasn’t modified, but I think it can be assumed that most won’t modify it. So you sort of probabilistically leak the sender.

---

<div class="post-metadata">

**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\
**Post date:** [August 17, 2021, 11:18am UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/5 "2021-08-17T11:18:32Z")

</div>

> [@oryhp](#):
>
> So you sort of probabilistically leak the sender.

Leak to whom? And how? In what circumstance would 3rd parties get a hold of these payment proofs without the payer’s consent?

---

<div class="post-metadata">

**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\
**Post date:** [August 17, 2021, 11:25am UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/6 "2021-08-17T11:25:15Z")

</div>

In theory they could ask for a payment proof signature for an output you used. Though I’m wondering if this signature that the receiver provides to the sender is just “fire and forget”, meaning that the receiver doesn’t really have it stored.

---

<div class="post-metadata">

**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\
**Post date:** [August 17, 2021, 11:54am UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/7 "2021-08-17T11:54:02Z")

</div>

> [@oryhp](#):
>
> In theory they could ask for a payment proof signature for an output you used.

But that’s pretty useless since you can make up arbitrary such promise signatures on the spot.

This doesn’t seem like a good enough reason to complicate the promise.

---

<div class="post-metadata">

**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\
**Post date:** [August 17, 2021, 12:24pm UTC](https://forum.grin.mw/t/bidirectional-payment-proofs/9175/8 "2021-08-17T12:24:14Z")

</div>

You could, yes, but what users do on average is important. If 95% show the actual promise, out of 20 promises you have only 1 that lies. Not sure if it matters though. Perhaps I’m overthinking it. But if the receiver simply forgets about the promise they made (not store it anywhere), then you have the opposite probability where only 5% will have anything to show at all.