`FrostKey::mul_tweak`

[irriden]

If we ask signers to return s!(r1 + (r2 * b) + lambda * x * c * mul_tweak) in Frost::sign, we can get a signature that is valid for the public key s * mul_tweak * G.

Any multiplicative tweaks would have to be applied before any additive tweaks.

Let me know if you would merge a PR that implements this, thank you!

[LLFourn]

Hi irriden,

I have been talking about going in a direction with "tweaking" that would tweak the secret shares as well as the public Frostkey. This means FrostKey would no longer "store" tweaks but would mutate the polynomial by the tweaks. In the case of addition this would mean just adding the value to the first coefficient. In the case of multiplication it would be multiplying the entire polynomial by the public scalar. You of course have to do the homomorphic operation to the shares as well. This would allow you to do what you want. What do you think?

What do you actually want this for out of interest.

[irriden]

Hello Lloyd thank you for your response.

I am hesitant to directly depend on the polynomial after the keygen step, because bip-frost-dkg does not yield the polynomial as one of its outputs.

I've been able to take the outputs of bip-frost-dkg, use them to construct a FrostKey, and then use the secp256kfun example code to sign. So far the point_polynomial field of FrostKey is just Vec::new() as this field is only used in verify_signature_share, which I do not need for now.

I am researching multisig lightning. In lightning the revocationpubkey for a specific commitment is derived using a multiplicative, followed by an additive tweak.

[LLFourn]

I am researching multisig lightning. In lightning the revocationpubkey for a specific commitment is derived using a multiplicative, followed by an additive tweak.

Oh ok weird lol -- why? I can put multiplication into the API that I am working on right now. I think it's sound from a security point of view. To be clear you wouldn't need to keep the polynomial in the new API -- you can tweak your secret share if you're a signer. verify_signature_share will be the thing that still needs it.

I'm guessing this is not "xonly" tweaking? The resulting point does not have its y coordinate dropped?

I am about to start working on making it possible to do bip-frost-dkg compatible ops for what it's worth.

[irriden]

Oh ok weird lol -- why?

Why the multiply-add tweak? Not sure why the multiplicative tweak is there, the additive tweak is there to ensure that the party can only punish once the counterparty has revealed the tweak scalar.

See here for details: https://github.com/lightning/bolts/blob/master/03-transactions.md#revocationpubkey-derivation

I can put multiplication into the API

Thank you!

To be clear you wouldn't need to keep the polynomial

Thank you for clarifying, yes I've forked secp256kfun and have been doing multiplicative (and additive) tweaks without the polynomial all good.

verify_signature_share will be the thing that still needs it.

Would you consider having verify_signature_share depend not on the polynomial, but on the public share of the corresponding signer, as in bip-frost-dkg ? Thank you.

I'm guessing this is not "xonly" tweaking?...

The resulting point can end up in the blockchain in a tapscript as part of an OP_CHECKSIG. So the answer is yes, the resulting point does have its y coordinate dropped. The current master calls conditional_negate on each of the terms of the individual signer's response. For the term lambda * x * c * mul_tweak, we conditional_negate lambda, so xonly tweaking seems to be taken care of already, am I missing something ? Thank you.

I am about to start working on making it possible to do bip-frost-dkg compatible ops

Does this mean that secp256kfun could soon be used to build a participant in a bip-frost-dkg session ?

[LLFourn]

See here for details: https://github.com/lightning/bolts/blob/master/03-transactions.md#revocationpubkey-derivation

Thanks. I wonder why that needed to be a multiplication.

verify_signature_share will be the thing that still needs it.

Would you consider having verify_signature_share depend not on the polynomial, but on the public share of the corresponding signer, as in bip-frost-dkg ? Thank you.

Hmmm I certainly could add an API for this -- weirdly enough we do have a verification_share method to get it but nothing to use it :facepalm:. The problem with verification shares is that their value changes when a key is tweaked. How do you handle this right now? Do you multiply the verification shares when you are doing a multiplicative tweak? Or is this being stored in some separate state and being patched up in the verification check. I feel like if we make a verification share based API it will be very error prone because there is yet another thing to keep track off the tweaks on.

Would having a method that allowed you to create the polynomial from the verification shares solve your problem? I am perhaps not fully understanding where you are getting these verification shares from. It sounds like you are not generating them with schnorr_fun.

It looks like I brought this topic up on the BIP a while a go: https://github.com/BlockstreamResearch/bip-frost-dkg/issues/8 I still think the BIP should also use polynomials in the API FWIW.

Does this mean that secp256kfun could soon be used to build a participant in a bip-frost-dkg session ?

Yes that's the plan in the sense that you'll be able to produce the messages in the protocol but the actual API for the library will be different from the BIP. e.g. we might not use verification shares.

[irriden]

If we can reconstruct the polynomial from the public verification shares, then my question about verify_signature_share depending on the polynomial is moot.

I asked because I am interested in the following: secp256kfun takes the output of bip-frost-dkg as an input, and then offers an API to 1) create signatures valid under public keys derived from additive and multiplicative tweaks on the original threshold_pubkey from bip-frost-dkg, 2) [low priority] do partial signature verification during the creation of such signatures.

Exactly how that is done I leave to you :)

Notably at the moment bip-frost-dkg does not output the polynomial, hence my initial concerns.

Reconstructing it internally during initialization from the verification shares to do tweaking and partial signature verification as you've described sounds great to me !