Works fine for a threshold key too. Other potential signers need to get "dealt" in after the key is established.

using schnorr sigs

proof of secret key is easy, and simple to use in practice and opens up a wide-range of use-cases with schnorr signatures.

the more i look at it, i would add a "considered harmful" label to it, and move on

actually that article seems very strange to me. the level of interactivity is unnecessary and the weakness of "r" parties being able to recover the key is bizarre. not sure what the goals are but i would never use that

non-interactivity was never a requirement for signing. it's ok to get a round of g*k commitments from the signers (k is their blinding factor). then a threshold schnorr sig is easy, you just apply the polynomial and get a consensus blinding factor, and use the same on on the partial-signatures you get. as far as the consensus public key, i just need the pubkeys of t signers, i can choose whatever polynomial i want after receiving the public keys. they don't need to know how they're being combined.

unfortunately, i can't use the shared secret "directly", because i'm using it to SIGN things (forced to by a protocol i have to comply with... even thought the signature is 'either alice or bob' ... which is fine in my application). which means i can't use a point. so i just use the X-coord as the new private key. i can hash it first, but that will slow things down a bit, and im not sure its necessary.

unfortunately that doesn't work with threshold setups or redistribution, both of which i need

ok, phrased it better: if you're not using new keys often, and you're using random iv's ... always use a long 192 bit random iv, don't use a short iv.

The only weakness i see is that bob can begin searching for weak public keys. But it's DLP-hard for him to forge a signature for weak keys he finds. There is a form of birthday attack i think, since he can vary both the signature and the public key, looking for intersections. But it's not any better than the typical attacks that render 256-bit EC keys as 128-bit strength.

it's probably easier to say "use n when dealing with private key operations", "use p when dealing with the x/y value operations"

seems like 16 bytes for a fully random IV is safer