What do you think about customizable RC costs set by users? Imagine fees on ETH but instead, it is RC as a fee. Essentially you are bidding to be the first included in the block.
You are viewing a single comment's thread from:
What do you think about customizable RC costs set by users? Imagine fees on ETH but instead, it is RC as a fee. Essentially you are bidding to be the first included in the block.
System such as in BTC/ETH is like an auction - wealthy always win. I very much prefer current system, where as long as one has the money (RC) even the poor guy can buy at the shop at predictable price (transact on blockchain) and it doesn't matter that the guy behind him in the queue is bathing in cash.
There are a few things mixed up here. I'll leave ETH out of it because that is somewhat more complicated (the block limit is variable) and it is close enough to just stick with BTC for simplicity, but with BTC the auction is the ONLY mechanism for allocating space, meaning "congestion" is effectively normal. When demand exceeds supply, the only solution is for the fees to become very high at which point the wealthy can push others out.
With RC, the pools also limit usage dynamically (if calibrated appropriately) meaning RC costs will increase and usage will decrease (because more and more accounts will be locked out of transaction periodically, or will need to reduce their usage to avoid hitting the cap). Therefore, any congestion should be only a short term transitional phenomenon (vs periods in BTC when fees have remained high for months, and could in theory be permanent), and much more muted in magnitude.
That being said, the wealthy can still win out with RC because if demand is high relative to resources, RC costs will go up and you would need a lot of HP to do much of anything.
I think some sort of priority mechanism either a multiplier or additive bonus makes sense. Some transactions have more of a need to get into a block quickly (or at all) compared to others.
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.
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.