'll add and rpc command to set percentage of block size reserved to prio transactions
then I would like to have a look at dust limit to reduce it, as I already told you in the past
(lowering the fee as much as possible is the main aim)
Description
Description
Event Timeline
Comment Actions
I am not sure why you suggest an RPC command? Why not just config?
This seems to be inconsistent with all the other policy configuration options, and I don't really see how the benefit of dynamic changes outweighs the cost of the added complexity.
If you want to move to a dynamic config model, shouldn't this be done for all tx policy config together?
Comment Actions
I guess that we need to weight if the added complexity justify the addition of the RPC command.
That complexity related to expose setter/getter for this particular conf via RPC is not much IMHO. In any case I agree that if we decide to take that route we could do the same for minrelaytxfee, limitfreerelay, blockmintxfee and maybe others.
One of the advantages of modifying such conf via RPC is that you don't need a full restart to make changes effective, this will save times. The latter in case of miners could be particularly helpful.
Comment Actions
Ok. I see the complexity is minimal, and the merits of the dynamic approach.
But I still think this is conflating two things. The current method for setting policy is through config (or cmd args). Adding a policy best adheres to this pattern for consistency
Allowing dynamic config would be nice but maybe better suited as different task? Where we could discuss whether we want a "reload_config" rpc, a "changeconfig(x,y)" rpc or indivudual "set_minrelaytxfee" etc rpcs.
Sure dynamic>static but a consistent UX is also important, and having a "set_high_prio_percentage" but a config for "blockmintxfee" is odd.
Comment Actions
100% agreed on having an a Task where to discuss about how to reload bitcoin.conf, be it via a RPC command reload_config or via a SIGHUP sent to bitcoind.
WRT the clash between blockprioritypercentage and blockmintxfee: hi prio transactions are not subjected to the blockmintxfee policy as long as there's still room in the reserved space they are added.
I have to say that the naming of all the params that define txns relay policy, txns mempool acceptance and txns selection to get included in the block template is a little bit messy/misleading to say the least. This is something we have inherited from Core. (not a good reason to not improve things thou)