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.