Move ecip-1047.md to Deferred Status

[gitr0n1n]

2023 Update: This was accidentally observed on the network due to a large mining pool setting their default gas to this level. This prevented the development community from the ability to deploy Smart Contracts to Ethereum Classic briefly. Once observed, it was corrected and the mining pool set their gas limit to 8M.

Additionally over three years, seems stale and dated.

ECIP-1000
"ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years. Such a ECIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Last Call if it meets the criteria required as described in the previous paragraph."

#14
#253 (comment)

[meowsbits]

This is OK with me, although it seems weird for a type=Informational document to even be able to have Rejected|Accepted statuses in the first place. I'd appreciate further feedback on this before going ahead with formal acceptance.

[gitr0n1n]

This is OK with me, although it seems weird for a type=Informational document to even be able to have Rejected|Accepted statuses in the first place. I'd appreciate further feedback on this before going ahead with formal acceptance.

When reviewing for this, I felt the same way, but felt confined as this statement appeared to be my only clear option in the ECIP-1000.

ECIPs should be changed from Draft or Last Call status, to Rejected, upon request by any person, if they have not made progress in three years.

While looking at it a bit deeper the ECIP-1000 cites:

An Informational ECIP describes an Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum Classic community consensus or a recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice.

And our available statuses to signal the ECIP is no longer advisable are: Deferred, Rejected, Withdrawn, Replace, Final.

The ECIP editor may also change the status to Deferred when no progress is being made on the ECIP.

Maybe Deferred is more appropriate as this Informational ECIP is not recommended/advised, as it would restrict basic smart contract deployment for the dapp community and, thus, obsolete at this point. Does Deferred seem more appropriate to the other @ethereumclassic/ecip-editors ?

https://ecips.ethereumclassic.org/ECIPs/ecip-1000

[gitr0n1n]

Withdrawn status makes the most sense to me. I'm just not confident we, as ECIP editors following the ECIP-1000, have the authority to change to that specific Withdrawn status. I do see a clear statement that we may change to Deferred. In this case, Deferred refers to waiting for the author to confirm Withdrawn or redraft with a more accurate gas recommendation that is relevant to today's chain. Or perhaps this proposal will be Replaced by a more dynamic gas pricing solution to prevent needless bloat.

[IstoraMandiri]

Agree with Deffered for now.

The gas limit in theory makes sense, but as we have seen recently, in practice has negative outcomes particularly with complicating deployments.

Even some existing deployed contracts have embedded assumption of 1M+ transactions, and although I have argued in the past this were a bad assumptions, breaking them would likely to be considered to cause an unnecessary pain (and questioning Code is Law), unless addressing a critical problem with the protocol, which we don't appear to have currently.

Today, I probably wouldn't support capping the gas limit to 1M, not least for the sake of ossification.

[bobsummerwill]

See also https://ecips.ethereumclassic.org/ECIPs/ecip-1084

If we ever did decide to lock down gaslimit voting, I would not now suggest either of the formulas I suggested there, but an absolute fixed amount as Bitcoin has done.

Not less than 8MB though.

This 1MB "recommendation" would have no teeth anyway and makes no sense to keep around, imho.

Maybe contact Anthony and ask if he can withdraw it?

[gitr0n1n]

Pinging @pyskell on here as the provided contact. If we don't here anything, let's merge this in a few weeks.

[bobsummerwill]

I messaged @pyskell on Telegram and he said that he cannot even remember the issue.

"Yeah feel free to do what you want in that repo and to take me off of it"

I asked whether I could relay his consent and he said "sure".

So I would suggest that the Editors change the status to Withdrawn.