Hey nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3 team,
several members of the German community are currently experiencing a bug in the fee prediction of their mempool-space instances in their own nodes (running version 2.4.0 or 2.5.0).
#m=image%2Fjpeg&dim=1080x1089&blurhash=%7CBA9v%40%5Dv%2C%2B-XbfEINyNGWH%24q%24a%24xxbxcNEozW%3Aai53E%3AI%5DNFV%3Fxcnhofob53EqETInRh%24-jEs%3BbW1Er%7Cs%3BSJobn-s.j%5Bj%3D%5Ekw%40n%24t7S5V%40R%2BWBbIaRbDocoMogWUoej%5BafRXW%2CoIjbn*X5o0WBoM%5ERoYjYsqWGWTR-j%5Ba%7E&x=cfa2f09ec1435006cb541cbcc60bd3c366e1ccdde794f2fb9af692ea6cee258f
There are many multisig + CPFP transactions with fees that are calculated in a wrong way (effective free rate seems to be wrong).
Here's an example:
https://mempool.space/tx/f3295be225f3307f9724cd565cad01b643131830ba0446caeaa612b6030384a3
Is there a way to fix this for us?
The linked transactions have a large number of sigops (241).
Default bitcoin core transaction selection treats sigop's as though they have a larger size than they do. This means that these transactions are treated as though they have a significantly lower fee rate (half in this case)
static constexpr unsigned int DEFAULT_BYTES_PER_SIGOP{20};
thank you very much for your reply, but I don't get how I should change that value exactly.
Is there a "one fits all" solution (like 10?) or does it depend on the amount of sigops in a specific transaction?
