|
Title: Fees associated with Taproot script spend Post by: angelo1oc on March 17, 2025, 05:38:37 PM 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 Title: Re: Fees associated with Taproot script spend Post by: She shining on March 18, 2025, 07:49:48 AM Higher values is a safer choice to prevent a situation where the fee is insufficient for a certain script path.
Title: Re: Fees associated with Taproot script spend Post by: gmaxwell on March 19, 2025, 10:42:26 PM 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. Title: Re: Fees associated with Taproot script spend Post by: angelo1oc on March 20, 2025, 06:55:33 PM 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 |