Re: [bitcoin-dev] Hash function requirements for Taproot

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning LL,

Thank you very much for this work, it seems quite interesting.

> 5. You can completely circumvent this result by using coin-tossing rather than MuSig for the key generation protocol. In most cases this doesn't even add any extra rounds of communication since you are doing 3-round coin tossing to choose the R values for the signatures that spend from the joint output anyway. You can just toss your public keys in parallel.

I am uncertain what you mean here by "coin-tossing".
From the comparison to MuSig, I imagine it is an interactive key generation protocol like this:

* Everybody generates fresh keypairs.
* Everybody sends the hash of their pubkey to everyone else.
* After receiving a hash of pubkey from everyone else, everybody sends their pubkey to everyone else.
* They add all their pubkeys to generate the aggregate key (and if using Taproot, use it as the internal key).

Is that correct?

In any case, the comparison to MuSig signing appears to imply interactive key generation.
The advantage of MuSig is that it requires no interactivity for key generation of n-of-n (I am told it requires interactivity to generate k-of-n).

However, it can generally be pointed out that, before you put anything into an n-of-n, you would damn well sure want to have *some* assurance that you can get it out later.
So in general you would need coordination and interaction anyway to arrange getting into an n-of-n in the first place.

On the other hand, it would be best to have at least some minimum of privacy by always interacting over Tor and having a Tor .onion address, which has absolutely horrid latency because human beings cry when peeling onions.
So in general reducing the latency by reducing communication rounds is better in general.
Counter to this, assuming you use an n-of-n in an offchain protocol of some sort, the number of communication rounds to generate the aggregate key may be dwarfed by the total number of communication rounds to create signatures to update the offchain protocol.
Counter counter to this is that one plan for reducing communications rounds for creating signatures during offchain operation is to (haha) use a Taproot with an n-of-n internal key and a tapscript that has n `OP_CHECKSIG` operations, so that for normal operation you just toss individual signatures at each other but at termination of the offchain protocol you can do the heavy MuSig-style signing with the n-of-n aggregate key.

Regards,
ZmnSCPxj