The fix fees proposal at https://github.com/mimblewimble/grin-rfcs/pull/63
includes an option of making it a consensus change.
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).