Page MenuHomePhabricator

add RPC command for percentage of blocksize
Open, Needs TriagePublic

Description

'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)

Event Timeline

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?

sickpig added a comment.Sep 21 2017, 16:15

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.

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.

sickpig added a comment.Sep 21 2017, 19:00

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)

This seems like a dupe of T87.