Avatar
d0enakallešŸ‡āš” 2y ago

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?

Reply to this note

Please Login to reply.

Discussion

Avatar
mempool 2y ago

Thanks, investigating.

Avatar
mempool 2y ago

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)

https://github.com/bitcoin/bitcoin/blob/82ba0f80a0b56bb160c8be1fddd82dbbc4fb3947/src/policy/policy.h#L37

static constexpr unsigned int DEFAULT_BYTES_PER_SIGOP{20};

Avatar
d0enakallešŸ‡āš” 2y ago

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?