txprepare does not use provided feerate argument correctly
#8164
Comments
|
It seems the feerate parameter is not well documented. |
|
OK, this is actually quite well documented, but perhaps not easy to find? https://docs.corelightning.org/reference/feerates#notes But indeed, our estimator is off. |
utxo_spend_weight(…) was assuming that witnesses always include a pubkey, but
that is not true of Taproot (key-path) spends. The effect was that wallet-
funded commands (e.g., withdraw, fundchannel, multifundchannel, etc.) were
overpaying on fees due to calculating Taproot input weights as 34 sipa greater
than they actually are.
Also as a consequence of the miscalculation, users who carefully select a set of
UTxOs to spend so as to avoid producing a change output would experience an
error when trying to spend them. As an example, I tried to spend a tiny 1390-sat
P2TR output to a new 1275-sat output at minimum feerate. The actual weight of
the transaction is 451 sipa, so the 115-sat fee yields a feerate of 255 sat/kw.
However, CLN refuses the transaction, claiming:
{
"code": 301,
"message": "Could not afford 1275sat using UTXOs totalling 1390sat with weight 485 at feerate 253"
}
The reported weight of 485 sipa is wrong, as it assumes the input will include a
34-sipa public key when in fact it will not.
This commit amends the bitcoin_tx_simple_input_witness_weight() and
bitcoin_tx_simple_input_weight(…) functions to take a parameter specifying the
scriptPubKey type of the spend. The implementation of the former is corrected so
that P2TR spends are not charged for a public key that they actually lack.
An enum type is introduced to enumerate the known scriptPubKey types, and a new
scriptpubkey_type(…) utility function is implemented to discern the type of a
given scriptPubKey. The existing is_known_scripttype(…) function is
reimplemented as an inline wrapper around the new function.
The default_lease_rates(…) function in plugins/funder_policy.c is amended so as
to state explicitly an assumption that it has been making: that the two inputs
it assumes for its default max weight calculation will not be Taproot inputs.
Fixes: ElementsProject#8164
Changelog-Fixed: P2TR inputs are assessed the correct weight in fee calculations.
The
txpreparefunction in Core Lightning does not seem to respect thefeerateargument provided by the user. Instead of constructing the transaction with the specified feerate, it appears to apply some internal logic that results in a different feerate being used.Additionally, the documentation for
txpreparelacks clarity regarding thefeerateparameter. It does not specify:-The expected format or units for the
feerateargument-Whether alternative feerate options (besides
"normal") are supported-How
txprepareprocesses the provided feerate and why the resulting transaction feerate differs from the inputSteps to Reproduce:
txpreparewith a specificfeerate, e.g.:Expected Behavior:
The transaction should be created with the feerate explicitly passed to
txprepare.Actual Behavior:
The resulting transaction has a different feerate from the one provided.
Additional Information:
-Core Lightning version: v25.02
-Logs and output from txprepare:
Notice in this example we passed in 4000 for the feerate but the resulting transaction has a feerate of 4288. (609sats /142vbytes).
Just to confirm my suspicions because the psbt was not signed, I signed the psbt and analyzed that and it has the same feerate:
Again, 609 sats / 142 vbytes = 4288 feerate
Would appreciate any clarification on how txprepare handles the feerate argument and whether this is an intended behavior or a bug.
The text was updated successfully, but these errors were encountered: