There should be a limit on how much gas can be expended in 1 block, to prevent an attacker creating a block that takes too long to evaluate.
What if the owner of a contract submits the MAX GAS PRICE he is wiling to pay? The contracts with the highest willingness to pay are executed first. The node executes contracts until either
All contracts are executed
OR
The limit is reached
If #2 then those contracts with the lowest willingness to pay will not be executed. The executed contracts will be charged the max gas price of the marginal contract, i.e. the last contract before the limit was reached determines the price,
If #1 then perhaps a hard coded (low) minimum gas price should apply.
This limit will be determined based on benchmarks.
I support this, but keep in mind that down the road there may be a situation similar to the 1MB block debate. Why not have a temporary (one year?) window where those who are given the right to shut down EVM altogether also have the right to adjust this limit?
P.S. The formula I submitted earlier in this thread will ensure that the AVERAGE amount of computations per block is steady The auction principle suggested here makes sure the TOTAL per block never exceeds the limit.
I actually had a conversation with Robby about the block gaslimit and ābiddingā on priority through a set gasprice, letās move that one here: EVMPARTY: Gaslimit per block
I think we can risk it on pushing a dynamic limit discussion down the line for ~1 year and settle on a fixed limit for now, thereās less things at stake for us on that limit than for example on the 1mb block limit (we donāt have to consider block relaying resulting in centralization).
I just read through this thread. And Iāll weigh in again.
Most comments here are in favor of burning XCP for gas. But many point out that burning XCP will incentivize hoarding and will cause people not to spend XCP on smart contracts.
I think most of us agree that we want Counterparty to be used more. If more people that use the protocol, then everyone wins. So, the question for me is what is the best way to incentivize people to use Counterparty more?
My belief is that both the protocol and XCP will become more useful when smart contracts are released. Since smart contracts canāt use bitcoin directly, XCP will emerge as the currency of choice for payment.
I believe that if smart contracts are useful, people will use them and burn the XCP as a cost of doing business. And if they arenāt useful, then the price of gas wonāt matter.
So in summary I think burning XCP for gas works. I think it is the simplest solution that makes sense.
If we can lower the gas price over time to prevent the XCP supply from running out, I donāt see any reason not to do it.
Regarding XCP running out, I donāt think this is really an issue because, as with bitcoin, it is divisible to 8 decimal places.
The real challenge is ensuring that the gas cost to XCP rate remains dynamic enough to adjust to the supply without confusing or causing dissent among users. The key to both of those things is predictability. IMO the gas cost parameter should be defined once upon the release of the EVM with the intention that the algorithm for determining gas/xcp will never need to be altered.
The first thing that comes to mind as the simplest solution to the āXCP running outā problem is to set a gas rate thatās directly proportional to the remaining supply with the lower limit set to 0.00000001 XCP and rounding to the nearest 8 decimal places.
Hereās an example:
Using the following algorithmā¦
If the initial setting is 1 GAS = 0.1 XCP at 2,624,584.58 total XCP supply then the formula would beā¦
Might make sense to use this with a step function so that the gas price changes in preset increments rather than changing slightly every block for cleaner gas calculations and presentation.
