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.