Eliminating finalize step ReLoAdEd

Research
10

This specific post is to briefly discuss ELS scheme without adding an additional curve point.

A scheme attempt was done on keybase on committing to X+R (X: excess, R: nonce) in order to try getting rid of the additional curve point. Unfortunately, a still complicated one and broken at its core.

I can try to propose a scheme similar to the one in OP or the previous one but where the initiator would draw their R_a and X_a and commit, through a unique challenge, to X + R where R_b + X_b is equal to z.G + B. Signature verification would be s.G = R + H(X + R, m).X.

The payment proof would be:

  • show that z.G + B = R + X – (X_a + R_a) .
  • show that z = H(d, R_a, X_a, B, U, amount, timestamp) .
  • show that U = u.G and that d = H(u.G) .

Let r_b and x_b be the nonce and excess secrets of the receiver for a first transaction. Let s_b be their partial signature.
Let r'_b and x'_b be the nonce and excess secrets of the receiver for a second transaction. Let s'_b be their partial signature.
We have:
z + b = r_b + x_b and z' + b = r'_b + x'_b, from which you can get an equation between r_b, r'_b, x_b, and x'_b.
s_b = r_b + e.x_b and s'_b = r'_b + e'.x'_b.
In total you get 3 equations for 4 unknowns, which is not in general solvable.

And, looking at the information arising from a unique transaction, you get 2 equations: z + b = r_b + x_b and s_b = r_b + e.x_b, with 3 unknowns (r_b, x_b and b), which is not solvable too.

So, maybe a scheme with an unique challenge (like we currently have) but committing to X + R, or more generaly f(X + R), where f is a function, would not leak private information. Determining if it is really secure is another story for sure.

The scheme is - on the paper - more fragile than the scheme described in OP, but haven’t demonstrated yet that it would be insecure. Maybe is it trivial to break it. I hope some will try to think about it and see where we could go with this if there is no obvious flaw. A first angle of study could be to try to apply all the attacks that were already discussed to this scheme, and see if it resists to them.

edit:
I quickly checked the attacks, and the one that may be applicable here is the attack about knowing the value of x_b - x'_b, which is described there Eliminating finalize step. To prevent it, similarly to the previous and broken scheme with the inflation attack, it would be necessary to verify the uniqueness of X + R for the whole blockchain in order to not have 2 times the same challenge, which prevents the attack. But even if we don’t verify uniqueness of this, it seems the attack may not apply as long as the receiver always chooses different tuples (r_b,x_b) for each transaction, so that x_b - x'_b could in fact not be calculated, even when two challenges are equal (i.e. e = e').
The inflation attack does not work for this scheme since X contributes to the challenge, unlike the first scheme. It does not mean that there are no new attacks, since the scheme is still quite different, with X_b + R_b being forced to be equal to "the receiver’s permanent address + z.G".