Not gonna rogue-key Grin ~

As per some recent discussions due to the suggestion of using MuSig for Grin, we should probably look closely as possible on the possibility or not to proceed to rogue-key attacks on the kernel commitment while doing Grin transaction. As it has probably been fully studied by Grin OGs in the past, it is not possible to perform them in regular transactions. It also seems not possible to perform them in the use case whereby two users choose to fund a 2-2 output in order to do payment channels, making it unnecessary to change anything in Grin multisignature scheme.

For now, the standard key aggregation scheme of Schnorr signature is used to sign the kernel excess. Normally, trivial key aggregation (just adding keys together) is a fully insecure scheme, due to rogue-key attacks, but turns out to be fully secure for grin. Let’s see why in an example:

imagine a tx with one input P_in = v_in.H + X_in, and two outputs P_c = v_c.H + X_c the change output, and P_out, the recipient output.

The kernel excess of the sender is E_s = X_c - X_in.
Bob, the receiver could do a rogue-key attack on the excess and use a partial excess E_bob = r.G - E_s for some r of his choice so that the total excess is E = E_bob + E_s = r.G and that Bob can sign the excess E alone. But now, Bob has to choose his P_out so that the tx balances out, i.e:

P_out + P_c - P_in = r.G.

In particular, the value of his output must be equal to v_ out = v_in - v_c, such that we have P_out = v_out.H + X_out, where X_out must verify:

X_out + X_c - X_in = X_out + E_s = r.G, that is X_out = r.G - E_s.

Which means that we finally have: P_out = v_out.H + r.G - E_s.

But because Bob does not know the private key to the partial excess of the sender, E_s, Bob cannot know the blinding factor of P_out, and as a consequence cannot build a bulletproof for P_out, which in particular means that he cannot finalize the transaction and that his attack attempt fails here.

Now we can look at another technique that Bob could use. Instead, if Bob builds first an honest output, P_out = v_out.H + r._out.G for some r_out, then the partial excess of Bob is necessarily r_out.G, which is not a rogue key and which means that he needs the cooperation of the sender to build an (honest) signature to broadcast an honest transaction.

In another further post, I will try to attack the scheme where Bob and Alice try to fund a 2-2 outputs, show that it is not possible either to attack it, and hopefully it will convince everyone that our current multisig scheme is sufficient and that we dont need the fancy MuSig for Grin.


Case of funding a 2-2 output:

Let’s say that Bob and Alice agree to make a tx together to fund together a 2-2 output, with tx inputs:
P_a = v_a.H + X_a and P_b = v_b.H + X_b = v_b.H + r_b.G. And ignoring offsets.

At some point in time, Alice shares to Bob her partial excess E_a that verifies E_a = Y_a - X_a, where Y_a is the partial blinding factor of Alice in the 2-2 output P_out. Bob can sign alone the total excess E_a + E_b with E_b = r.G - E_a for some r.

Define Y_b the partial blinding factor of Bob in P_out. Bob needs that Y_b verifies

(Y_a + Y_b) - (X_a + X_b) = Excess = r.G,

in order that the tx balances out.

He also needs to know the private key to Y_a + Y_b in order that he can build the bulletproof alone for P_out. But, as per the balance equation, we have that

Y_a + Y_b = (r + r_b).G + X_a,

which Bob cannot know the private key to since he does not know the private key to X_a. We can see that Bob fails this rogue-key attempt when funding a 2-2 output with Alice.

If instead Bob tries to rogue-key the blinding factor of P_out, he must choose Y_b = r.G - Y_a for some r. Then he can build (dishonestly) a bulletproof for P_out without the help of Alice. But, In that case, the excess for the transaction is:

P_out - (P_a + P_b) = (r.G - X_b) - X_a, which Bob cannot sign alone as he does not know the private key to X_a.

The rogue-key attack is also not successful when Bob funds a 2-2 output with Alice


It is very difficult for an ordinary person and maybe I did not understand everything correctly, but I like it )

1 Like

OT: Should I try to see if we can install the math plugin?

1 Like

Ah yes, it can be useful for more readability when people are doing a bit of MW equations in the various posts. I tried a bit to make the “coding style” font change, which is pretty nice already, but it was failed attempt.
If you succeed to install it I could edit the post after, I think