Re: [ANN][MRO] Monero - an anonymous coin based on CryptoNote technology
Hello!
It is very good that you've created this thread. I'm ok about renaming.
But I can't agree with any protocol changes based only on decisions made by bitcointalk.org people. This is because not all miners are continiously reading forum.
Any decision about protocol changes are to be made by hashpower-based voting. From my side I will agree on such a decision only if more than 50% of miners will agree. Without even such a simple majority from miners such changes are meaningless.
Such a voting is easy to be implemented by setting minor_version of blocks to a specific value and counting decisions made after 1000 of blocks. Do you agree with such a procedure?
It is very good that you've created this thread. I'm ok about renaming.
But I can't agree with any protocol changes based only on decisions made by bitcointalk.org people. This is because not all miners are continiously reading forum.
Any decision about protocol changes are to be made by hashpower-based voting. From my side I will agree on such a decision only if more than 50% of miners will agree. Without even such a simple majority from miners such changes are meaningless.
Such a voting is easy to be implemented by setting minor_version of blocks to a specific value and counting decisions made after 1000 of blocks. Do you agree with such a procedure?
Seems alright to me. You should create a voting instructions tho, cause it's not looks like an easy process
In few days I will publish a code with merged mining support. This code will be turned ON only by voting process from miners. What does it mean:
- miners supporting merged mining are to update their nodes and miners. New miners will issue blocks with modified minor_version field indicating they are ready to accept AuxPoW blocks. But no AuxPoW blocks will be issued before 75% of last 1000 blocks will have a positive vote (a changed minor_version).
- miners not supporting will not update but will still be able to mine and accept blocks. In case of successful voting they will have to switch to new code. In case of voting failed they can stay on old version.
The same procedure is suitable for all other protocol changes.
Sounds fair enough for me to go with a system like this, the coin is still young so major changes wont have a really big impact atm. But still, i think the emmision fix is more important then the merged mining for now.
I'm not sure about not having really big impact argument. Now we have a support of a lot of people (see hashrate image below). In case a change is harmful from their point of view we will loose them either in form of not-upgrading (i.e. chain split) or in form of abandoning this coin.
Any order of issuing fixes is ok for me. I suppose that merged mining will be ready (from dev. point of view) before an emission fix.