So in trying to make an informed decision, regardless of how the vote comes to pass, I would find it tough to do so right now.
One of you is saying that there was no mistake in the emission formula, while the other is. I'm not asking which I should believe . . I'm asking for a way to verify this -- or at least one that doesn't rely on me just resting my personal opinion on either of you.
How can I get started on understanding the emission curve?
Topic: [ANN][MRO] Monero - an anonymous coin based on CryptoNote technology - page 7. (Read 23555 times)
April 24, 2014, 05:57:02 AM
April 24, 2014, 05:42:01 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins 
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.This is the point. The network that isn't supported by miners is useless. We have to ask them.
Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed.
I agree. Let's make two separate voting processes.
Merged mining will be turned on only in case 75% of hashpower will be supporting it. For me this is ok. If less we will not introduce it. Is this ok?
For emission schedule modification is 75% a good margin?
75% percent is probably a good margin for miners to approve just about any hard fork. With anything much less than that you are going to end up with a split.
Let's not forget though, non-miners have to approve too.
Do you mean non-miners as a forum users?
Not especially forum users. no. People running nodes that aren't mining still have to validate the blocks, otherwise you get a different kind of split. Or alternately if people don't like what the miners are doing they may simply stop using the coin. Miners are not the only stakeholders in a coin, just one important one.
There will soon be a web site, and other ways of communicating. Now the forum is pretty central, but that will likely not always be the case.
April 24, 2014, 05:39:36 AM
Everything is ok except the first argument: MM doesn't FORCE a MERGE of coins. It doesn't force and no merge will happen. You can continue to mine only one coin if you want. Any "parent" chain isn't required if you don't want to have it on your pc.
- In case we introduce a MM it still will be only an option but not a requirement.
- In case we introduce a MM each miner will decide himself which "parent" chain to use with MM: BCN or some other chain.
Actually this is more technical and less political issue. Looks like I need to explain this more.
- In case we introduce a MM it still will be only an option but not a requirement.
- In case we introduce a MM each miner will decide himself which "parent" chain to use with MM: BCN or some other chain.
Actually this is more technical and less political issue. Looks like I need to explain this more.
It is not only a technical issue. I understand that in a technical sense you can decline to merge mine, but in an economic sense you can not. Merge mining NMC with BTC is worth about 1%. Still most people do it, but not all.
We likely will not have a situation like that here, because there is no bitcoin with a value that far eclipses every other coin.
If NMC mining were say 10% or more of the value of BTC mining, then everyone would have to merge mine or they would not be able compete. Difficulty would go up due to the extra revenue received by the other miners (so they would buy more mining gear, because it is 10% more profitable), and then anyone who doesn't merge mine will lose money.
That is what I want to avoid.
April 24, 2014, 05:34:45 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.This is the point. The network that isn't supported by miners is useless. We have to ask them.
Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed.
I agree. Let's make two separate voting processes.
Merged mining will be turned on only in case 75% of hashpower will be supporting it. For me this is ok. If less we will not introduce it. Is this ok?
For emission schedule modification is 75% a good margin?
75% percent is probably a good margin for miners to approve just about any hard fork. With anything much less than that you are going to end up with a split.
Let's not forget though, non-miners have to approve too.
Do you mean non-miners as a forum users?
April 24, 2014, 05:33:31 AM
This way I don't see any disadvantage in merged mining. What disadvantages do you see in MM?
Merged mining essentially forces people to merge both coins because that is the only economically rational decision.
I do not want to support the ninja-premined coin with our hash rate.
Merged mining makes perfect sense for a coin with a very low hash rate, otherwise unable to secure itself effectively. That is the case with coins that merge mine with bitcoin. This coin already has 60% of the hash rate of bytecoin, and has no need to attach itself to another coin and encourage sharing of hash rate between the two. It stands well on its own and will likely eclipse bytecoin very soon.
I want people to make a clear choice between the fair launched coin and the ninja-premine that was already 80% mined before it was made public. Given such a choice I believe most will just choose this coin. Letting them choose both allows bytecoin to free ride on what we are doing here. Let the ninja-preminers go their own way.
Everything is ok except the first argument: MM FORCES a MERGE of coins. It doesn't force and no merge will happen. You can continue to mine only one coin if you want. Any "parent" chain isn't required if you don't want to have it on your pc.
- In case we introduce a MM it still will be only an option but not a requirement.
- In case we introduce a MM each miner will decide himself which "parent" chain to use with MM: BCN or some other chain.
Actually this is more technical and less political issue. Looks like I need to explain this more.
April 24, 2014, 05:31:17 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.This is the point. The network that isn't supported by miners is useless. We have to ask them.
Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed.
I agree. Let's make two separate voting processes.
Merged mining will be turned on only in case 75% of hashpower will be supporting it. For me this is ok. If less we will not introduce it. Is this ok?
For emission schedule modification is 75% a good margin?
75% percent is probably a good margin for miners to approve just about any hard fork. With anything much less than that you are going to end up with a split.
Let's not forget though, non-miners have to approve too.
April 24, 2014, 05:27:16 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.This is the point. The network that isn't supported by miners is useless. We have to ask them.
Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed.
I agree. Let's make two separate voting processes.
Merged mining will be turned on only in case 75% of hashpower will be supporting it. For me this is ok. If less we will not introduce it. Is this ok?
For emission schedule modification is 75% a good margin?
April 24, 2014, 05:18:42 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.This is the point. The network that isn't supported by miners is useless. We have to ask them.
Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed.
April 24, 2014, 05:18:18 AM
This way I don't see any disadvantage in merged mining. What disadvantages do you see in MM?
Merged mining essentially forces people to merge both coins because that is the only economically rational decision.
I do not want to support the ninja-premined coin with our hash rate.
Merged mining makes perfect sense for a coin with a very low hash rate, otherwise unable to secure itself effectively. That is the case with coins that merge mine with bitcoin. This coin already has 60% of the hash rate of bytecoin, and has no need to attach itself to another coin and encourage sharing of hash rate between the two. It stands well on its own and will likely eclipse bytecoin very soon.
I want people to make a clear choice between the fair launched coin and the ninja-premine that was already 80% mined before it was made public. Given such a choice I believe most will just choose this coin. Letting them choose both allows bytecoin to free ride on what we are doing here. Let the ninja-preminers go their own way.
April 24, 2014, 05:12:08 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.This is the point. The network that isn't supported by miners is useless. We have to ask them.
April 24, 2014, 05:09:46 AM
For the record I approve of the voting process.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
I suppose that merged mining as a possible option is a good idea as soon as nobody is forced to use it. MM is a possibility to accept PoW calculated for some other network. It helps to increase a security of both networks and makes it possible for miners not to choose between two networks if they want both:
- BCN only miners will continue to mine BCN
- BMR/MRO only miners will continue to mine BMR/MRO
- merge miners will mine both at the same time (now some of them mine BCN only and other - BMR only)
Important things to know about MM:
- MM doesn't imply that BMR is smaller or has a less hashpower. In case BMR will has more mining power than BCN it will simply accept less BCN blocks.
- MM doesn't force BMR users to have BCN chain on their HDD - BCN chain isn't neede to verify blocks
- MM doesn't require any specific parent chain. Miner decides himself which parent chain to use: BCN or any other chain supporting the same PoW method.
Actually the only change that goes with MM is that we are able to accept PoW from some other net with same hash-function. Each miner can decide his own other net he will merge mine BMR with. And this is still very secure.
This way I don't see any disadvantage in merged mining. What disadvantages do you see in MM?
April 24, 2014, 05:08:46 AM
For the record I approve of the voting process.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
You can always make your own fork if you do not agree with developer's position
April 24, 2014, 05:08:04 AM
When I command "start_mining ..." I get this message:
Error: mining has NOT been started: daemon is busy. Please try later
Error: mining has NOT been started: daemon is busy. Please try later
The daemon is likely still synching the blockchain
There is also a bug where sometimes this happens even when the blockchain is already synced. Typing "save" in the daemon process seems to fix it.
April 24, 2014, 05:02:25 AM
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
You are wrong TFT. The original announcement described the coin as having a reward curve "close to Bitcoin's original curve" (those are your exact words). The code as implemented has a reward curve that is nothing like bitcoin. It will be 86% mined in 4 years. It will be 98% mined in 8 years. Bitcoin is 50% mined in 4 years, and 75% in 8 years.
With respect TFT, you did the original fork, and you deserve credit for that. But this coin has now gone beyond your initial vision. It isn't just a question of whether miners are on bitcointalk or not. There is a great team of people who are working hard to make this coin a success, and this team is collaborating regularly through forum posts, IRC, PM and email. And beyond that a community of users who by and large have been very supportive of the efforts we've taken to move this forward.
Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split.
April 24, 2014, 04:56:47 AM
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.
April 24, 2014, 04:51:46 AM
For the record I approve of the voting process.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
April 24, 2014, 04:49:44 AM
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 if it is advertised as a bitcoin alternative with comparable emmision.
April 24, 2014, 04:47:43 AM
I know I am now going to get accused of being a pump and dumper by those too emotionally attached to this coin, but how can that be true when I have less than 500 coins? Or is it 250? Or will it be 125?
How about I just give you 250 coins? The idea here is to move forward and correct the error, not rip anyone off.
I don't want your coins and I'm not suggesting that anyone is trying to screw anybody, this is all about the perception of devs being able to take coins without any mandate - please try to take me seriously.
We don't agree that a reverse split amounts to "taking" coins. I also wouldn't agree that a regular forward split would be "giving" coins. It's an exchange of old coins with new coins, with very nearly the exact same value. There is a very slight difference in value due to the way the reward schedule is capped, but that won't be relevant for years or decades. Such a change is entirely reasonable to fix an error in a in coin that has only existed for a week.
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins
April 24, 2014, 04:41:45 AM
I know I am now going to get accused of being a pump and dumper by those too emotionally attached to this coin, but how can that be true when I have less than 500 coins? Or is it 250? Or will it be 125?
How about I just give you 250 coins? The idea here is to move forward and correct the error, not rip anyone off.
I don't want your coins and I'm not suggesting that anyone is trying to screw anybody, this is all about the perception of devs being able to take coins without any mandate - please try to take me seriously.
We don't agree that a reverse split amounts to "taking" coins. I also wouldn't agree that a regular forward split would be "giving" coins. It's an exchange of old coins with new coins, with very nearly the exact same value. There is a very slight difference in value due to the way the reward schedule is capped, but that won't be relevant for years or decades. Such a change is entirely reasonable to fix an error in a in coin that has only existed for a week.
April 24, 2014, 04:36:52 AM
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.
Okay, easy enough. AFAIK Bitcoin changes are being voted this way too, right?
Jump to: