Binding the onetime address key extensions to the address spendkey is a red herring

[jeffro256]

In appendix A.3 Enote Ownership Proof, the implementation paper states "Here we see that binding k^o_[g/x/u] to K allows enote ownership proofs to demonstrate a relationship between K and K^o." While this is technically true, it doesn't really mean anything and isn't a good reason to bind to the address spendkey, for two reasons. One, since we are providing s₁^sr outright, there is no way to prove that it was actually derived correctly and that the receiver would normally recover that enote if performing standard scanning. And two, if what we're attempting to prove here is that a spendkey K could know all g/x/u private key components (and thus spend) a onetime address K^o, then we could just provide the onetime address key extensions directly. That would make the proof [K, K^o, k^o_[g/x/u]]. This is a more generalized proof and may still be applicable even if we change the way the onetime address extensions are derived. The verifier would simply check K^o ?= K + k^o_g G + k^o_x X + k^o_u U. The reason why I bring this up is so that we can optimize the scanning process by not having the address key extensions bind to K_s^j (like in @tevador's Jamtis-RCT proposal).

P.S. Also, revealing s₁^sr might expose other enote information we wouldn't otherwise want to expose. It does expose the address tag under Jamtis currently, which is arguably not an issue since the prover/verifier already knows K_s^j, but it's worth considering.

[UkoeHB]

One, since we are providing s1sr outright, there is no way to prove that it was actually derived correctly and that the receiver would normally recover that enote if performing standard scanning.

This does not matter. The proof is only designed to show the relationship between K and Ko. It is not designed to show the recipient can recover the enote. You can think of it as proving a negative: no one except the owner of K can spend the enote.

Furthermore, notice this statement in the address ownership proof: "This proof must be a Σ-protocol, which in practice means binding to a custom message m_custom provided by the verifier. Without that binding, a proof could be reused by someone who is not the address owner." If you combine an enote ownership proof and an address ownership proof, then if the address ownership proof is constructed by signing Ko (as it should be, for that combination to have any significance), then for all intents and purposes we can assume the owner of K can recover Ko.

And two, if what we're attempting to prove here is that a spendkey K could know all g/x/u private key components (and thus spend) a onetime address Ko, then we could just provide the onetime address key extensions directly.

This would greatly weaken the proof, since you could just do key cancellation to get a valid K. It would become completely worthless without an address ownership proof, whereas the current proof at minimum shows Ko is derived from K.

[jeffro256]

The proof is only designed to show the relationship between K and Ko. It is not designed to show the recipient can recover the enote. You can think of it as proving a negative: no one except the owner of K can spend the enote.

This is exactly my point: this proof's point is that no one except the owner of K can spend the enote. The "relationship" between K and Ko (in this case the binding of the onetime key extensions) is irrelevant to whether or not K can spend Ko. To spend Ko, we need to know x, y, and z s.t. Ko = x G + y X + z U. It does not matter how we obtained those x, y, or z, though that method will usually be the Jamtis addressing protocol.

This would greatly weaken the proof, since you could just do key cancellation to get a valid K.

In what use case would you be not be asserting the value of K anyways? This proof is basically worthless as-is if you don't assert a value for K since I can generate a random address and send an enote to myself, which I can't prove that I don't own.

[UkoeHB]

It does not matter how we obtained those x, y, or z, though that method will usually be the Jamtis addressing protocol.

It does matter how we obtained them. If you generated them randomly and used key cancellation, then the proof means nothing. You can't actually call it a proof any more. If you really want to do this, then you need to propose that the proof must include an address ownership proof. I'm arguing with you because this is very important - you cannot design a 'conditional proof' that isn't actually a proof without the condition. It's all or nothing.

This proof is basically worthless as-is

The proof is used as a building block for other proofs: enote sent proof, reserved enote proof. And then the reserve proof builds on top of the reserved enote proof by adding address ownership.

[tevador]

FYI, Jamtis-RCT cannot bind the output key extensions to the address spend key because this would prevent e-note recovery for CryptoNote addresses. I don't want to complicate the specs with different derivations for each address type.

If needed, the e-note proof can be done by providing the key extensions and an index proof for K1.