Clarify one sided payment rules

[SWvheerden]

Description

RFC 201, for tari script, laid out a way to do one-sided payments. This RFC clarifies the calculation of the blinding factor k_b to ensure there is nothing left over to think about by explicitly typing out how to calculate it using Diffie-hellman.

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Feature refactor (No new feature or functional changes, but performance or technical debt improvements)
• New Tests
• Documentation

Checklist:

• I'm merging against the development branch.
• I ran cargo-fmt --all before pushing.
• I ran cargo test successfully before submitting my PR.
• I have squashed my commits into a single commit.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.

[sdbondi]

LGTM

[sdbondi]

Not super necessary, but might be clearer to be 100% specific.
i.e.
The sender calculates k_b = k_Ob * K_Sb, and the receiver calculates k_b = K_Ob * k_Sb

[hansieodendaal]

Agreed

[stringhandler]

How does the receiver know the value though?

[hansieodendaal]

The value must be sent out of band.

[stringhandler]

if the value is sent out of band, why not send the whole commitment out of band? Isn't the purpose here to not do out of band?
"This information can be obtained with need to communicate with the sender"

[stringhandler]

This doesn't seem to solve the problem of not communicating with the sender

[hansieodendaal]

Clarification of the Diffie-Hellman exchange is great.

Discussion:
Maybe we should add a short discussion about how the one-sided payment receiver can expect payments, but not exactly how much it would be, without communicating out of band with the sender. If the value of the payment is not known, the commitment cannot be opened without huge amounts of computing power.

One option is to know who will pay you and to provide them with a short identification string for one-sided payments, for example, an account number, that would be embedded as the proof message in the Bulletproof range proof.

• Sender(s) knows
  • Receiver public wallet key
  • Tari one-sided payment script variants that would be accepted by the receiver
  • Unique sender proof message, e.g. an account number
• Receiver knows
  • Sender(s) public rewind key(s)
  • Sender(s) public wallet key(s)
  • Unique sender proof message

The receiver can then scan the blockchain for payments and open the commitments using the following method:

• Scan all UTXOs for all acceptable payment script hashes; there would only be a few at most, and if the script resolves when inserting the receiver public key, it is for the receiver.
• With those identified UTXOs, do Bulletproof rewinding with the range of registered sender public rewind keys. If the proof message matches, the rewound value is more than likely the correct value of the commitment.
• Test opening of the commitment:
  • Use the Diffie-Hellman exchange with corresponding public wallet key to derive the commitment's spending key and the value obtained from Bulletproof rewinding
  • If the commitment can be opened, it comes from the identified sender

[stringhandler]

@hansieodendaal seems ok, but if the sender rewind keys are public, can't anyone just read all the values? Why not just include the value in metadata? Or maybe encrypt the value and then add it to the metadata?

[hansieodendaal]

The sender's public rewind key is not common knowledge; it has to be shared out of band, and will only be shared with specific parties. The sender can also at any time change the rewind key or use more than one.

Although additional information can be added as metadata, we get up to 23 bytes worth of data for free that can be embedded in the Bulletproof rewind proof message.

As you suggested, adding the value as encrypted metadata would also be feasible because the opening of the commitment can be tested with the decrypted value and all registered one-sided payment sender public keys. If the correct value was encrypted, the commitment can be opened.

[SWvheerden]

Would using the blinding factor of the utxo or a derived key of that for the rewind key not solve the problem?

[sdbondi]

I'm not very familiar with the RP rewinding maths but would it not be possible to add the value to the range proof using the Diffie-Hellman key k_b or perhaps Hash(k_b) as the rewind blinding key? As part of scanning you would need to derive the DH key for each UTXO and attempt to rewind.

This makes the problem of obtaining the value the same problem as "how do we efficiently/effectively scan for new one-sided payments?".

[sdbondi]

@SWvheerden Beat me to it 😆

[hansieodendaal]

Would using the blinding factor of the utxo or a derived key of that for the rewind key not solve the problem?

This is a very good idea yes (@SWvheerden and @sdbondi) [using Hash(k_b)], as the sender will not want to share their own private rewind key (pvt_rewind_key). In this way, the sender could still use their own private blinding key (pvt_blinding_key) and keep it secret.
(See Bulletproof rewinding for context)

[hansieodendaal]

We know now have ...

[stringhandler]

Suggested change

	Because this is a secret key known by Alice and Bob and no one else. We hash this key as a new key, (\\( k_{rewind} = Hash(k_{Ob}) \\). We know have a rewinding secret key for use in bulletproof rewinding. And now
	Because this is a secret key known by Alice and Bob and no one else. We hash this key as a new key, (\\( k_{rewind} = Hash(k_b) \\). We know have a rewinding secret key for use in bulletproof rewinding. And now

[hansieodendaal]

Suggested change

	we can encrypt the value (\\( v \\) inside of the bulletproof rewinding, allowing Bob to unlock his payment without revealing any information publicly.
	we use the standard Bulletproof rewinding scheme to encrypt the value (\( v \) inside the Bulletproof range proof,, allowing Bob to unlock his payment without revealing any information publicly. (See [Bulletproof rewinding](https://github.com/dalek-cryptography/bulletproofs/issues/335) for context)).

[stringhandler]

Should be "We now use the standard...". Don't need to start a sentence with "And"

[SWvheerden]

Do we have a link explaining it in our own repo, not Dalek's?

[hansieodendaal]

We can always update it later when we have documented it ourselves.

[hansieodendaal]

I would add something like this:

---

In summary, receiving party scanning the blockchain for one-sided payments therefore involves:

• Scan all UTXOs trying to unlock the payment script hashes; if the script resolves when inserting the receiver public key, it is for the receiver.
• With those identified UTXOs, do Bulletproof rewinding with the range of registered sender public rewind keys ((( k_{rewind}G ) as per above). If the proof message matches, the rewound value is more than likely the correct value of the commitment.
• Test opening of the commitment using the value obtained from rewinding and the spending key from the Diffie-Hellman exchange; if the commitment can be opened, it is intended for the receiver.

[stringhandler]

Don't agree with point 2. Point 2 should be rewound using the hash of the blinding factor

[hansieodendaal]

**Edit: ** Strike that We equate the private rewind key to the hash of the blinding factor. Bulletproof rewinding is done with the public rewind key, not the private rewind key.

Please see the explanation below.

[stringhandler]

Suggested change

	Because this is a secret key known by Alice and Bob and no one else. We hash this key as a new key, (\\( k_{rewind} = Hash(k_{Ob}) \\). We know have a rewinding secret key for use in bulletproof rewinding. And now
	Because this is a secret key known by Alice and Bob and no one else. We hash this key as a new key, (\\( k_{rewind} = Hash(k_b) \\). We know have a rewinding secret key for use in bulletproof rewinding. And now

[stringhandler]

Should be "We now use the standard...". Don't need to start a sentence with "And"

[stringhandler]

Don't agree with point 2. Point 2 should be rewound using the hash of the blinding factor

[stringhandler]

Seems like this refactor has reverted to some previous errors

[hansieodendaal]

LGTM