It makes sense to introduce priority queue for specific types of transactions. F.e. in time of high traffic it would be preferable for witnesses to be able to include transactions that change blockchain parameters (like increasing max block size), because they can fix congestion that way. Also some operations are time sensitive, like account recovery or canceling "decline voting rights". However I'm against allowing wealthy users to use their basically unlimited RC to outbid normal users from transacting on blockchain. If we ever do something like this, it would have to be fee that burns actual Hive, not RC.
You are viewing a single comment's thread from:
Also, there's no consensus on which transactions are included so witnesses could certainly include their own transactions to e.g., change parameters, regardless of RC or other congestion.
They could, but there is a bit of difference between having to mess with the code and having the mechanism already coded in :o)
Fee seems fine although I'm not sure it should be HIVE directly, since 0.001 HIVE is kind of significant. For very cheap transactions with only modest congestion, you might want an even smaller fee. One way to do that would be to burn HIVE to receive a bunch of more granular fee credits you could use later.
I'm not sure it is that significant. New account tokens replace 3 HIVE fee and most recently they cost over 10T RC. Also most recently average custom_json is 400M RC. So a fee of 0.001 HIVE for a custom_json would be like paying only ten times more RC.
The price of HIVE could go way up!
Perhaps one could argue that with the price of HIVE going up a lot that usage of the blockchain would also go up and fees for using it also going up (even if only during congestion) is not a problem, but I don't think that is clear. They're not necessarily tied together.
We could use HBD to pay the fee though, 0.001 USD will likely never be a lot.