# Eliminating finalize step ReLoAdEd **URL:** \ **Category:** Research\ **Created:** [September 11, 2020, 8:50am UTC](https://forum.grin.mw/t/eliminating-finalize-step-reloaded/7817 "2020-09-11T08:50:27Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [October 7, 2020, 9:29am UTC](https://forum.grin.mw/t/eliminating-finalize-step-reloaded/7817/10 "2020-10-07T09:29:19Z")
_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](https://forum.grin.mw/t/eliminating-finalize-step/7621/44). 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`". --- _[View the full topic](https://forum.grin.mw/t/eliminating-finalize-step-reloaded/7817)._