Fees associated with Taproot script spend

[angelo1oc]

Hi I have a question related fees ( basically Virtual Size):

When I use let's say 3-of-5 signatures embedded on a Huffman tree composed on 3-of-3, and assuming we have only one input transaction and one output transaction, the first user to sign will need to decide the "transaction fee", in the software I run a "simulation" were I "sign" all the branches, so I end with the following values for the Virtual Size:
[203,203,203,203,211,211].

If instead I'm doing a 5-of-10, this is the list of virtual sizes:
[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 user needs to decide the transaction fee, we are suggesting the user to use the "biggest" values, for a 3-of-5 would be 211, for a 5-of-10 would be 2237, since we don't know who from the rest of the users is signing next.

My question is, is this correct? I'm I correct in suggesting the higher values?
Because the alternative would be any posible value, but if turn out that the final combinations has a Virtual Size equal to the biggest one, then the transaction will never commit to the node.

Regards
angelo

[She shining]

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

[gmaxwell]

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.

[angelo1oc]

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