In the Rationale and alternatives section, there is a paragraph which now reads
The fee factor could be specified separately from the fee, but that requires a consensus change, namely masking the fee to only the least significant 64 - FEE_FACTOR_BITS , allowing the freed up most significant bits to be used for specifying the fee factor. The advantage of this separation is that even with higher fee factors, fees can remain a milligrin multiple, and thus the amounts that users deal with donât need too many digits for fractional grins. This can be considered a plus for wallet UX.
While the Future possibilities section has a new paragraph which reads
If we go with the alternative of a consensus changing fee mask, then this sets a precedent for stealing other masked out fee bits as a possible soft-forking mechanism. Suppose we limit fees to 40 bits, giving a maximum possible fee of 2^40 - 1 nanogrin, or approximately 1099.5 grin. (As a side effect, this limits the damage of fat fingering a manually entered fee amount.) This gives us 64-40 = 24 bits, of which we use FEE_FACTOR_BITS bits for fee factor, and leave the remainder available for future use. We can imagine a future soft-fork further constraining the validity of kernels, depending on the value of some of these bits. These restrictions can be either within the consensus model, or outside of it in the mempool and relay conventions, such as with the fee factors in this proposal.
Please let me know which option you prefer. Actually changing fees by a few nanogrins to specify a fee factor (no censensus change) or masking the fee to make room for a separate fee factor (consensus change and possible soft-forking mechanism).
Iâve read the RFC but still unclear to me what the fee factor is.
We fix some parameter FEE_FACTOR_BITS , possibly configured through grin-server.toml. If the least significant FEE_FACTOR_BITS of a fee have value f, then the total fees of the transaction containining this kernel must exceed the required minimum by a factor f+1, inclusive. We recommend a default value of FEE_FACTOR_BITS = 8. By linearity, aggregating transactions with the same specified fee factor will preserve their relay validity.
@tromp it is a nice improvement, more logical than the current system and more flexible.
I am quite certain there will be at least one more hardforks, so in that sence the fee factor could be changed in the hardfork itself to adjust for changes in the price of Grin.
Not sure about the masking out of the fee bits yet. In general I can see some benefits of having a soft fork method to allow putting more restrictions on kernel validity, e.g protect againt spam. It sounds most effective to simply do not allow these transactions to be relayed, so keep them out to avoid spamming of the network or the mempool. If a spammer cannot relay his spam transactions the problem is killed at the source.
Can you explain the part about the seperate fee factor bits setting a precedence of steeling some of the fee so I can better understand if this is a major problem? If it is not a big problem I think I favor the fee bit approach to allow putting flexible restrictions on kernel validity and avoid relaying them in the network. It sounds like the most future proof approach although slightly more complex.
That makes no sense. Fee factor is set by the transaction, just like the fee. E.g. a fee factor of 2 says âI am paying at least twice the minimum fee required for relaying this tx and that must remain true under any aggregation with other transactionsâ.
Fee factors are not about protecting against spam, but about prioritizing transactions when blocks are full.
Weâre not stealing fees, we are reducing the number of bits used to specify the fee and instead let them specify a fee factor, and leave some unused for now, to remain available for use in future soft-forks.
I ment this part about stealing fee bits.
About changing âfee factorâ at the hardfork, yaa, that does not make sence indeed. I though one option was to basically change the mimimum fee at the hardfork, but the fee factor is there anyhow. Anyhow, I think I misunderstood, I thought that the masking out of the Fee Bits allowed this space to be used to set other criteria, e.g. change the minimal fee based on how many bits the fee factor would take which can be used to protect agains spam simply by making transactions more expensive.
EpiphanyđŽ, o the âstealingâ was not about the fee, you mean more bits can be utilised to cary other information by âstealingâ them. Funny how my mind completely interpreted that wronglyđ
The proposal has been rewritten to not only adopt the consensus change, but also to replace the fee factor by a fee shift.
This 4-bit field specifies a (left) shift in the range 0âŚ15 to be applied to the minimal fee. So a transaction with a kernel specifying a fee shift of 3 should pay at least 2^3 = 8 times the minimal fee. In the most generous case, you could overpay fees by a whopping 2^15 = 32768 times.
Going up in steps of 2x guarantees that there will be plenty of aggregation opportunities even when blocks fill up and transactions specify various fee rates to get included early.
The latest rendered text can be found at