> 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?

Yes exactly. The reason it's called coin tossing is that the resulting key is guaranteed to be uniformly random (in the random oracle model at least), so it's like tossing a fair 2^256 sided coin. This is not true in MuSig for example, where the aggregate key is not guaranteed to be from a uniform distribution against a malicious party (but still secure as an aggregate key).

> 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.

Right. Taking your example of a lightning channel, when you set it up I don't *think* there is a way to use the non-interactivity of MuSig to remove any rounds of communication to get to the starting state where there is a channel funding on-chain and both parties have a tx that spends from it which returns their funds. Doing coin tossing for the aggregate key as well as the aggregate nonce shouldn't lead to any extra rounds of communication. The downside of coin tossing is that it requires honest parties to sample their keys non-deterministically (or at least have a counter to avoid using the same key twice). 

> 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.

Counter³ to this is that, in the case of lightning, the aggregate key for a PTLC does not need to be chosen at payment time.  They channel members could simply use the "master" aggregate key they generated by coin tossing at the channel's inception and pseudorandomly randomise it every time they need a new joint key (so the keys do not look related to everyone else on the chain but you would effectively just be reusing the same public key).

Having said that if there is some advantage to using MuSig in some particular case I wouldn't hesitate to use it in combination with Taproot. I don't think the new assumption that I think you have to make wrt to the hash function really weighs up against most design considerations. In general, it is probably worth considering whether your protocol actually benefits from the non-interactivity MuSig gives in the key generation stage. If it doesn't due to the fact that it doesn't make signing anymore non-interactive, then coin tossing might be the answer.

LL