Thanks for the feedback, @cculianu .
I am almost persuaded by the “use a simple majority argument”, and it’s very likely I will modify the CHIP in that regard unless I receive strong arguments against it.
I think that voting up or down is too stateful and complicated.
We will have to disagree there, because I think the alternatives, except for a one-time reduction, still involve voting up or down and are in that regard, not significantly less stateful.
IF we were to go with a scheme like this, I would prefer we use 3 bits at least and just have a fixed array of 7 or 8 values for fee rates such as: 1 sat/KB, 5, 10, 50, 100, 500, 1000, . This covers just about anything anybody would want to do and is simpler to evaluate (all you need is the last 1008 headers).
You may need more than 1008 headers anyway since you might be into the start of a new period and you’d need not the last 1008, but (1008 + however many headers past the last vote evaluation you’re at)
Practically I don’t think it makes much difference, as I explained in the CHIP that SPV wallets could cache the last vote result and come with checkpoints (e.g. at checkpointed block X, the minfee was Y" which means they don’t need to evaluate all the fee changes since this CHIP is put into effect, but only since they’ve last been updated.
And up/down mechanism requires you to evaluate every fee rate that ever existed – meaning you need to download headers since the beginning of this scheme’s deployment if you wanted to evaluate the fee rate trustlessly. (After a year of deployment that would be over 50k headers!).
No in most cases for the reason of caching/checkpointing above.
Even for 50,000 headers: a “whopping” 4MB or less than 3 floppy disks (anyone remember the 1.44MB ones?)
This is not even a concern to me. Such software needs to obtain the headers anyway to decide on its chain to follow.
This data just falls out as a byproduct, and the calculation is dirt cheap and fast.
If you just have an absolute array you just need 1008 headers. This is much easier to evaluate for an SPV wallet. Also is less bugprone for devs.
That is an advantage of signaling for values in an absolute array, yes.
I think the complexity is not much less than simple up/down voting and therefore not really less bug prone.
But I may be convinced otherwise if I see a CHIP for it that has dramatically simpler proposed code etc.
Having a fixed array of values makes it very clear what the actual relay fee is without rounding errors and other things accumulating.
Yes, that is an advantage of a fixed fee table, you can just look up the new fee value without math.
This could really be a successful alternative to this CHIP. I invite anyone to specify it as such.
It’s easier to configure as well. Just set your node to a target and fire and forget.
Yet it also does not solve the undershoot/overshoot problem.
How do you configure 50 sats/kB?
You could configure it as a target as per @im_uname’s suggestion so that your node always votes “in the direction of 50 sat/kB”. Logically your node’s votes would oscillate around the target as long as it is not hit exactly, if the implementation does not make a choice to say “closer than X to the target value is good enough for me to vote ‘no change’”.
I view a target fee setting via parameter as proposed by @im_uname is a good interface suggestion for implementors of this CHIP.
What happens when the fee rate is 44 sats/kB? Does your node vote up?
Yes.
If it does it will overshoot. (To 55 sats/kB).
Yes.
If it votes “no change” it will forever be unhappy with the undershoot.
Maybe not. There can still be one or more fee walks that reach exactly 50 sat/kB and make your node supremely happy.
How long that may take exactly depends on the choices made by other network partipants, but it is not guaranteed to take forever.
A fixed array doesn’t have this problem.
Disagree. Taking your example array, if the user wants 200 or 250 sat/kB, that’s simply not a value they will ever be able to set or get.
The user has a set of choices he can make and he will know what to expect at the end based on the choice he made.
Half agree. Yes, they can make a choice, but I think an individual “voter” will have greater uncertainty about the outcome, since it can
be any of the values in the array, and not simply one of three choices (current fee or one of the new values computed for “up” or “down”).
As I understand your proposal with the fixed array, the outcome still depends on the choice of all others who generate blocks. And they can vote for any value in the array.
Overall it’s not a big problem as people will be able to see what votes come in over the time of the voting window, and can set their expectations accordingly.
So I’m not saying a fixed array scheme couldn’t work. Only that I think it makes its own set of tradeoffs, beginning with granularity and choice of values. And we can discuss those in details once someone makes a concrete proposal to that effect.
