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

[thankful_for_today]

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.

[1714904927]

1714904927

[1714904927]

1714904927

[1714904927]

1714904927

[1714904927]

1714904927

[1714904927]

1714904927

[1714904927]

1714904927

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

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?

[smooth]

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.

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.

[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.

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.

[cocoakrispies]

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?

[smooth]

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?

The quote I posted "close to Bitcoin's original curve" is from the original announcement here:

https://bitcointalk.org/index.php?topic=563821.0

I think there was also some discussion on the thread about it being desirable to do that.

At one point in that discussion, I suggested increasing the denominator by a factor of 4, which is what ended up being done, but I also suggested retaining the block target at 2 minutes, which was not done. The effect of making one change without the other is to double the emission rate from something close to bitcoin to something much faster (see chart a few pages back on this thread).

[abit2slo]

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.

how are you gonna ask all the coin-people? it's impossible and useless.
miners are the main people in the net. 'cause if they don't like the changes and stop mining and supporting the net, coin will die at once. so kinda of "miners referendum" via hashrate power is enough.

[cocoakrispies]

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?

The quote I posted "close to Bitcoin's original curve" is from the original announcement here:

https://bitcointalk.org/index.php?topic=563821.0

I think there was also some discussion on the thread about it being desirable to do that.

At one point in that discussion, I suggested increasing the denominator by a factor of 4, which is what ended up being done, but I also suggested retaining the block target at 2 minutes, which was not done. The effect of making one change without the other is to double the emission rate from something close to bitcoin to something much faster (see chart a few pages back on this thread).

Yes, I see that sticking "close to BTC original curve" is the aim, and can make my own decision on whether or not which level of adhesion to that is desirable. I was wondering how to mathematically and graphically verify both claims . . and was looking for a way to measure.

For all I know right now, none of the emission comes close to anything BTC ever was . . so I've decided to construct a model of both emissions using my computer . . so that I may visually observe predicted emission%/time.

This is a very engaging discussion, you both make very valid points, and it's hard not to be torn in an instance like this. With TFT's claim that there was no mistake and yours that there is, I've no choice but to make graphs.

[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.

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.

how are you gonna ask all the coin-people? it's impossible and useless.
miners are the main people in the net. 'cause if they don't like the changes and stop mining and supporting the net, coin will die at once. so kinda of "miners referendum" via hashrate power is enough.

Full node operators have to approve as well, even if they don't mine, or the network breaks. Unless there is a lightweight wallet or a web wallet (which there isn't), then full node operators are everyone running a wallet.

Now in practice most of them are just going to download whatever software is on the official web site, which is fine. But if you do something a lot of them really don't like, they can refuse to upgrade and you can't force it on them, even with a majority of hash rate. Your blocks just wont' propagate to their nodes and all that hash rate might as well be mining a different coin.

[smooth]

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?

The quote I posted "close to Bitcoin's original curve" is from the original announcement here:

https://bitcointalk.org/index.php?topic=563821.0

I think there was also some discussion on the thread about it being desirable to do that.

At one point in that discussion, I suggested increasing the denominator by a factor of 4, which is what ended up being done, but I also suggested retaining the block target at 2 minutes, which was not done. The effect of making one change without the other is to double the emission rate from something close to bitcoin to something much faster (see chart a few pages back on this thread).

Yes, I see that sticking "close to BTC original curve" is the aim, and can make my own decision on whether or not which level of adhesion to that is desirable. I was wondering how to mathematically and graphically verify both claims . . and was looking for a way to measure.

For all I know right now, none of the emission comes close to anything BTC ever was . . so I've decided to construct a model of both emissions using my computer . . so that I may visually observe predicted emission%/time.

This is a very engaging discussion, you both make very valid points, and it's hard not to be torn in an instance like this. With TFT's claim that there was no mistake and yours that there is, I've no choice but to make graphs.

There is a graph here, on page 2 of this thread: https://bitcointalk.org/index.php?topic=582080.msg6365132#msg6365132

But don't let that discourage you from checking things out on your own. Independent checking can only help.

I'd like to see a graph like that one with bitcoin's curve overlaid.

[x0rcist]

The emmision is actually ~3 times more then bitcoin, BTC started with 50 per block (10 minute), we have atm ~17,5 coins per block (1 minute). This is 50 vs 175 per 10Min, so we are not even close to the Bitcoin emmision. Double the block time and we are close, bring the emmision to 21 and we are even closer. How to implement a proper way? I dont know but i know i will vote with hashing power to get this fixed, even if i'm gonna loose half of my coins.

[thankful_for_today]

I'm happy the Bitmonero attracts so much interest.
I'm not happy that some people want to destroy it.

Here is a simple a clear statement about plans: https://bitcointalk.org/index.php?topic=582670

We have two kind of stakeholders we have respect: miders and coin owners.

Before any protocol changes we will ask miners for agreement. No changes without explicit agreement of miners is possible.

We will never take away or discount any coins that are already emitted. This is the way we respect coin owners.

All other issues can be discussed, proposed and voted for. I understand that there are other opinions. All decisions that aren't supported in this coin can be introduced in any new coin. It's ok to start a new fork. It's not ok to try to destroy an existsing network.

[thankful_for_today]

The emmision is actually ~3 times more then bitcoin, BTC started with 50 per block (10 minute), we have ~17 coin per block (1 minute). This is 50 vs 170 per 10Min, so we are not even close to the Bitcoin emmision. Double the block time and we are close, bring the emmision to 21 and we are even closer.

Can you make a voting post on bitcointalk that will help us to understand what is the desired emission schedule?

[smooth]

I'm happy the Bitmonero attracts so much interest.
I'm not happy that some people want to destroy it.

Here is a simple a clear statement about plans: https://bitcointalk.org/index.php?topic=582670

We have two kind of stakeholders we have respect: miders and coin owners.

Before any protocol changes we will ask miners for agreement. No changes without explicit agreement of miners is possible.

We will never take away or discount any coins that are already emitted. This is the way we respect coin owners.

All other issues can be discussed, proposed and voted for. I understand that there are other opinions. All decisions that aren't supported in this coin can be introduced in any new coin. It's ok to start a new fork. It's not ok to try to destroy an existsing network.

Sounds like there's probably going to be another fork then. Sigh.

I guess it will take a few tries to get this coin right.

The problem with not adjusting existing coins is that it make this a premine/instamine. If the emission schedule is changed but not as a bug fix, then earlier miners got an unfair advantage over everyone else. Certainly there are coins with premines and instamines, but there's a huge stigma and such a coin will never achieve the level of success we see for this coin. This was carefully discussed during the team meeting, which was announced a day ahead of time, and everyone with any visible involvement with the coin, you included, was invited. It is unfortunate you couldn't make it to that meeting TFT.

[smooth]

The emmision is actually ~3 times more then bitcoin, BTC started with 50 per block (10 minute), we have atm ~17,5 coins per block (1 minute). This is 50 vs 175 per 10Min, so we are not even close to the Bitcoin emmision. Double the block time and we are close, bring the emmision to 21 and we are even closer. How to implement a proper way? I dont know but i know i will vote with hashing power to get this fixed, even if i'm gonna loose half of my coins.

Yes, but this coin slows down continuously, while bitcoin only slows down after 4 years. You are making the comparison at the very beginning of the 4-year period, when this coin has its highest reward. Looking at 3.9 years, the reward on this coin will have declined, but bitcoin will still be the same.

I think it still ends up being a little bit faster than bitcoin, but closer than your calculation suggests. As I said a few posts back, I'd like to see the graph with bitcoin overlaid for comparison.

[thankful_for_today]

I'm happy the Bitmonero attracts so much interest.
I'm not happy that some people want to destroy it.

Here is a simple a clear statement about plans: https://bitcointalk.org/index.php?topic=582670

We have two kind of stakeholders we have respect: miders and coin owners.

Before any protocol changes we will ask miners for agreement. No changes without explicit agreement of miners is possible.

We will never take away or discount any coins that are already emitted. This is the way we respect coin owners.

All other issues can be discussed, proposed and voted for. I understand that there are other opinions. All decisions that aren't supported in this coin can be introduced in any new coin. It's ok to start a new fork. It's not ok to try to destroy an existsing network.

Sounds like there's probably going to be another fork then. Sigh.

I guess it will take a few tries to get this coin right.

The problem with not adjusting existing coins is that it make this a premine/instamine. If the emission schedule is changed but not as a bug fix, then earlier miners got an unfair advantage over everyone else. Certainly there are coins with premines and instamines, but there's a huge stigma and such a coin will never achieve the level of success we see for this coin. This was carefully discussed during the team meeting, which was announced a day ahead of time, and everyone with any visible involvement with the coin, you included, was invited. It is unfortunate you couldn't make it to that meeting TFT.

We don't have to behave like Federal Reserve System and to change parameters just because meeting participants are ok about this.

But I'm ok about emission change in case majority will agree. I'm just against existing balance changes. Not because of my personal balance (in case we will change emission I will send 50% of my balance for giveaway) but because other people balances aren't to be changed without their own decisions.

[Djinou94]

Copy coin?

[smooth]

But I'm ok about emission change in case majority will agree. I'm just against existing balance changes. Not because of my personal balance (in case we will change emission I will send 50% of my balance for giveaway) but because other people balances aren't to be changed without their own decisions.

If you cut the rewards in half then the value of existing coins double. This is exactly the same as early adopters voting to grant themselves matching free coins, which close to the definition of a premine. You recognize this and that's why you are volunteering to donate 50% of your coins. I volunteered to do something similar during the meeting (there is a log somewhere so this can be verified). But a voluntary system like that won't work because there will likely be greedy short-sighted people who don't do it.

If we have a public donation process and we get virtually all the early adopter coins donated this way, then it could work. But if not then this will not work.

[thankful_for_today]

But I'm ok about emission change in case majority will agree. I'm just against existing balance changes. Not because of my personal balance (in case we will change emission I will send 50% of my balance for giveaway) but because other people balances aren't to be changed without their own decisions.

If you cut the rewards in half then the value of existing coins double. This is exactly the same as early adopters voting to grant themselves matching free coins, which close to the definition of a premine. You recognize this and that's why you are volunteering to donate 50% of your coins. I volunteered to do something similar during the meeting (there is a log somewhere so this can be verified). But a voluntary system like that won't work because there will likely be greedy short-sighted people who don't do it.

If we have a public donation process and we get virtually all the early adopter coins donated this way, then it could work. But if not then this will not work.

Emission formula can be changed the way that will not result in immediate halving block reward but still will change curve slope. This way previous coins will not be considered as instamine and curve will be much better. Actually the effect of such a change will be that block reward descrease speed will be a bit faster.  Is this a solution?

[smooth]

But I'm ok about emission change in case majority will agree. I'm just against existing balance changes. Not because of my personal balance (in case we will change emission I will send 50% of my balance for giveaway) but because other people balances aren't to be changed without their own decisions.

If you cut the rewards in half then the value of existing coins double. This is exactly the same as early adopters voting to grant themselves matching free coins, which close to the definition of a premine. You recognize this and that's why you are volunteering to donate 50% of your coins. I volunteered to do something similar during the meeting (there is a log somewhere so this can be verified). But a voluntary system like that won't work because there will likely be greedy short-sighted people who don't do it.

If we have a public donation process and we get virtually all the early adopter coins donated this way, then it could work. But if not then this will not work.

Emission formula can be changed the way that will not result in immediate halving block reward but still will change curve slope. This way previous coins will not be considered as instamine and curve will be much better. Actually the effect of such a change will be that block reward descrease speed will be a bit faster.  Is this a solution?

Sounds plausible, but I'm not sure. You still may end up with a lot of coins going to early adopters. If you don't cut the rewards quickly and significantly, then its more and more coins continuing to go to early adopters, making the problem worse. We considered increasing the cap as a solution, but that means exceeding the size of uint64 for atomic units. That seemed like a mess.

There are certainly all types of curves though. We can consider alternatives.