Transaction fees with Taproot script usage

Hey everyone, I have a question about fees, specifically the Virtual Size thing: So, let's say I'm working with a 3-of-5 signature setup that’s built on a 3-of-3 Huffman tree. If we only have one input and one output transaction, the first person to sign has to figure out the transaction fee. In my software, I ran a "simulation" where I "signed" all the branches, and here’s what I got for the Virtual Sizes: [203,203,203,203,211,211]. Now, if I switch to a 5-of-10 setup, the Virtual Sizes list looks like this: [252,293,325,349,373,381,413,445,469,493,501,525,549,573,581,597,621,629,645,653,669,693,725,749,773,781,805,829,853,861,877,901,909,925,933,949,965,989,1013,1021,1037,1061,1069,1085,1093,1109,1117,1141,1149,1165,1173,1189,1197,1205,1221,1229,1253,1285,1309,1333,1341,1365,1389,1413,1421,1437,1461,1469,1485,1493,1509,1525,1549,1573,1581,1597,1621,1629,1645,1653,1669,1677,1701,1709,1725,1733,1749,1757,1765,1781,1789,1805,1829,1853,1861,1877,1901,1909,1925,1933,1949,1957,1981,1989,2005,2013,2029,2037,2045,2061,2069,2077,2101,2109,2125,2133,2149,2157,2165,2181,2189,2197,2205,2221,2229,2237]. Since the first signer has to pick the transaction fee, we suggest going for the "biggest" numbers. So for a 3-of-5, that would be 211, and for a 5-of-10, it’s 2237, since we have no clue who will sign next. So, is that the right approach? Am I on the right track suggesting these higher values? The other option could be to pick any possible value, but if the final combination ends up having a Virtual Size equal to the max, then the transaction might not go through.

Higher values is a safer choice to prevent a situation where the fee is insufficient for a certain script path.

Or just concurrently sign multiple versions, and the last signer/proposer only completes and announces the one matching the signing set. The same mechanism can be used to sign for multiple fee rates since it can be useful to fee-bump without having to revisit all the signers.   That said, unless it's necessary for accountability to disclose which signer set signed, you construct a key distribution such that any of the 3-of-5 sets can sign the root directly-- which would minimize fees generally.

On the third point, you are saying to have a "standard" 3 of 5 MuSig1, the only problem is that you are disclosing "all" the members of the group (signers). As for the first item, it make sense :-) it didn't occur to me, but is doable, the only drawback would be the amount of information I would need to transfer into the PBST (custom), specially on cases with more than 5 participants. As a matter of fact, I would probably need one PSBT per combination fee. Interesting.. Thanks for your thoughts angelo