[ANN][MRO] Monero - an anonymous coin based on CryptoNote technology

[sussex]

You seem to forget what the function of this is: money.  As long as people find the privacy afforded to be favourable, it will have a usage and monetary value.  This is the whole point.

You seem to forget that people need to be able to trust their "money" also - this coin will have a reputation of devs literally taking money off people to "solve" technical  problems they don't necessarily understand and trying to hide that fact with flawed maths.

There is a danger that this coin will go the same way as Myriad, becoming nothing more than a technical exercise for miners and geeks without any possible real world usage. End users don't care about emission rates and algorithms but they do care about the contents of their wallets and whether the devs feel entitled to raid them - it could be seen as the behaviour of a centralised currency.

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? Also, if halving people's balances "has no real world effect" on people, how does not halving benefit me? You can't have it both ways, it makes a difference or it doesn't.

This biggest hurdle of crypto and mass adoption is it's perceived dodgy reputation - this move really doesn't help that image because it adds to the genuine fear, uncertainty and doubt that already exists. Ignore public perception of your coin at your peril.

[1714194762]

1714194762

[1714194762]

1714194762

[smooth]

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.

[thankful_for_today]

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?

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.

[sussex]

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.

[abit2slo]

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.

In case of hardfork that isn't supported by majority of miners the network will split into two nets with low-power fork and high-power not-forking branches. I don't think that this will be good for anybody.

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?

yes, idea is good. that's how cryptocurrency people should make decisions. i'm in!

[imready2rock]

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?

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?

[smooth]

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.

[thankful_for_today]

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

[x0rcist]

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?

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.

[smooth]

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.  

[thankful_for_today]

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?

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.

[smooth]

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.

[smooth]

When I command "start_mining ..." I get this message:

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.

[Garryashas]

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.  

You can always make your own fork if you do not agree with developer's position

[thankful_for_today]

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 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?

[thankful_for_today]

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.

[smooth]

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.

[smooth]

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.

[thankful_for_today]

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?

[smooth]

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.