Warning about using the DKG output directly on-chain

[jesseposner]

Unlike MuSig2, the FROST group public key is not randomized. Therefore, a malicious party could add a script path to their polynomial during the DKG, and still provide a valid proof-of-knowledge and VSS. It is necessary that an unspendable script path be added as suggested by BIP341. It might be worth warning users in this BIP that they should not use the DKG output directly on chain for this reason.

[real-or-random]

Makes sense. This note could also touch upon how multiple subkeys can be generated in order to avoid key reuse. People will probably want to do this via tweaking anyway.

[real-or-random]

This note could also touch upon how multiple subkeys can be generated in order to avoid key reuse. People will probably want to do this via tweaking anyway.

Hm, this part should be captured via BIP32 public derivation like in MuSig2, so that's out of our scope. (We could still mention BIP32 for this part.)

---

It might be worth warning users in this BIP that they should not use the DKG output directly on chain for this reason.

Ideally, we would not only add a warning, but just fix the problem by always adding a tweak to the threshold pubkey output by the DKG.

This issue is related to the idea to let the DKG output only the polynomial, and not the threshold pubkey. (We should still provide a get_pubkey function or similar, which the caller can optionally use, and which would be responsible for adding the tweak mentioned above.)