[XMR] Monero Speculation

[smooth]

When - what date or what blockheight - would the tail emission kick in ?  

It is hard to know the exact date/block because it depends on penalties. Each block's reward is a function of the actual number of coins created so far.

It will kick in whenever the reward according to the formula would be less than 0.3 XMR (approx 0.9% annually), which is expected some time around year 8.

Why 0.9%?


Edit: I guess what I'm asking is, what is the actual formula for the tail emission, the resultant inflation year over year and why was that amount chosen?

The formula is "0.3"

The amount was chosen based on being a round number within and close to the <1% inflation maintenance reward specified in the ANN OP.

[xa4]

When - what date or what blockheight - would the tail emission kick in ?  

It is hard to know the exact date/block because it depends on penalties. Each block's reward is a function of the actual number of coins created so far.

It will kick in whenever the reward according to the formula would be less than 0.3 XMR (approx 0.9% annually), which is expected some time around year 8.

Why 0.9%?


Edit: I guess what I'm asking is, what is the actual formula for the tail emission, the resultant inflation year over year and why was that amount chosen?

The formula is "0.3"

The amount was chosen based on being a round number within and close to the <1% inflation maintenance reward specified in the ANN OP.

I found this on github

Code:

+#define FINAL_SUBSIDY_PER_MINUTE ((uint64_t)300000000000) // 3 * pow(10, 11)

Does this mean a constant block reward = 0.3XMR ?

[smooth]

When - what date or what blockheight - would the tail emission kick in ?  

It is hard to know the exact date/block because it depends on penalties. Each block's reward is a function of the actual number of coins created so far.

It will kick in whenever the reward according to the formula would be less than 0.3 XMR (approx 0.9% annually), which is expected some time around year 8.

Why 0.9%?


Edit: I guess what I'm asking is, what is the actual formula for the tail emission, the resultant inflation year over year and why was that amount chosen?

The formula is "0.3"

The amount was chosen based on being a round number within and close to the <1% inflation maintenance reward specified in the ANN OP.

I found this on github

Code:

+#define FINAL_SUBSIDY_PER_MINUTE ((uint64_t)300000000000) // 3 * pow(10, 11)

Does this mean a constant block reward = 0.3XMR ?

Yes. that's what it means, unless the block time target is changed higher or lower than one minute, in which case all rewards including that one will be scaled accordingly. That is the base reward, but there will still be penalties for having blocks that are >median so the actual reward may be lower (in fact this is one of several reasons it is necessary to have a maintenance reward).

[ArticMine]

When - what date or what blockheight - would the tail emission kick in ?  

It is hard to know the exact date/block because it depends on penalties. Each block's reward is a function of the actual number of coins created so far.

It will kick in whenever the reward according to the formula would be less than 0.3 XMR (approx 0.9% annually), which is expected some time around year 8.

Why 0.9%?


Edit: I guess what I'm asking is, what is the actual formula for the tail emission, the resultant inflation year over year and why was that amount chosen?

The formula is "0.3"

The amount was chosen based on being a round number within and close to the <1% inflation maintenance reward specified in the ANN OP.

I found this on github

Code:

+#define FINAL_SUBSIDY_PER_MINUTE ((uint64_t)300000000000) // 3 * pow(10, 11)

Does this mean a constant block reward = 0.3XMR ?

Yes. that's what it means, unless the block time target is changed higher or lower than one minute, in which case all rewards including that one will be scaled accordingly. That is the base reward, but there will still be penalties for having blocks that are >median so the actual reward may be lower (in fact this is one of several reasons it is necessary to have a maintenance reward).

So the tail emission is now defined in the code and protected by the proof of work. I was concerned about this but alas no more concern. Excellent!!

[eizh]

I really like Monero blocks being 1 min, I dont understand what it means negatively for mining but for the end user it means its fast! That being said I would not care if it was changed to a more "optimal" 2 or 3 min (with emission accordingly).

The perceived speed is just psychological since a 1 minute confirmation is worth half as much as a 2 minute confirmation for establishing consensus.

[smooth]

Yes. that's what it means, unless the block time target is changed higher or lower than one minute, in which case all rewards including that one will be scaled accordingly. That is the base reward, but there will still be penalties for having blocks that are >median so the actual reward may be lower (in fact this is one of several reasons it is necessary to have a maintenance reward).

I really like Monero blocks being 1 min, I dont understand what it means negatively for mining but for the end user it means its fast! That being said I would not care if it was changed to a more "optimal" 2 or 3 min (with emission accordingly).

Well you'd like lower right? If the state of technology gets there, lower might be a feasible optimum. In the current structure it really isn't, just something thankful_for_today did against the objections of everyone.

eizh: there are some ways that two one-minute confirmations are worth more than one two-minute confirmation, but it's not terrible significant when the overall hash rate is fairly low and especially once it is low enough for latancy to be significant. Discussed by Meni Rosenfeld here: https://bitcointalk.org/index.php?topic=260180.msg2781832#msg2781832

[ArticMine]

I really like Monero blocks being 1 min, I dont understand what it means negatively for mining but for the end user it means its fast! That being said I would not care if it was changed to a more "optimal" 2 or 3 min (with emission accordingly).

The perceived speed is just psychological since a 1 minute confirmation is worth half as much as a 2 minute confirmation for establishing consensus.

The key is that the faster confirmation of 1 min allows for a finer grade of security in the confirmation of transactions. So with 1 minute block a merchant can choose between 0min 0 (confirmations) 1 min (1 confirmation 2 min (2 confirmations0 etc while with a two minute block the merchant only has the choice of 0min (0 confirmations)  2 min (1 confirmation (Edit:close to) equivalent to the previous 2 confirmations) etc. This can be critical for certain applications such as XMR.TO. The trade off is orphan blocks, which depends to a large degree on network speed and latency.

[smooth]

I really like Monero blocks being 1 min, I dont understand what it means negatively for mining but for the end user it means its fast! That being said I would not care if it was changed to a more "optimal" 2 or 3 min (with emission accordingly).

The perceived speed is just psychological since a 1 minute confirmation is worth half as much as a 2 minute confirmation for establishing consensus.

The key is that the faster confirmation of 1 min allows for a finer grade of security in the confirmation of transactions. So with 1 minute block a merchant can choose between 0min 0 (confirmations) 1 min (1 confirmation 2 min (2 confirmations0 etc while with a two minute block the merchant only has the choice of 0min (0 confirmations)  2 min (1 confirmation equivalent to the previous 2 confirmations) etc. This can be critical for certain applications such as XMR.TO. The trade off is orphan blocks, which depends to a large degree on network speed and latency.

If you look at the analysis by Meni Rosenfeld and more recent work by others, the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other). That's probably something like 5-10 minutes (10 minutes was close when Bitcoin was designed and latency seems to have roughly dropped by half since). This assumes not using modified protocols such as "GHOST" which address the orphaning issue but create or don't address enough other problems that they aren't generally viewed as a desirable upgrade, yet.

[ArticMine]

...

If you look at the analysis by Meni Rosenfeld and more recent work by others, the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other). That's probably something like 5-10 minutes (10 minutes was close when Bitcoin was designed and latency seems to have roughly dropped by half since). This assumes not using modified protocols such as "GHOST" which address the orphaning issue but create or don't address enough other problems that they aren't generally viewed as a desirable upgrade, yet.

I am taking a look at the article. It does raise the question of where we expect network latency to go in the future, so a confirmation time that is sub optimal today could become optimal in the future.

[smooth]

...

If you look at the analysis by Meni Rosenfeld and more recent work by others, the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other). That's probably something like 5-10 minutes (10 minutes was close when Bitcoin was designed and latency seems to have roughly dropped by half since). This assumes not using modified protocols such as "GHOST" which address the orphaning issue but create or don't address enough other problems that they aren't generally viewed as a desirable upgrade, yet.

I am taking a look at the article. It does raise the question of where we expect network latency to go in the future, so a confirmation time that is sub optimal today could become optimal in the future.

Some part of latency is just literally the speed of light and that will never be a point-to-point distance in a decentralized system. Consider one minute when you want orphans to be <1%. That only allows a few hundred ms for propagation. That's really not too likely to ever happen. Algorithmic improvements that address the issue in a different way are more likely to yield success with lower block times, likely coupled with other methods such as payment channels or cosigning for actual fast transactions (one minute isn't even close to fast enough for point-of-sale purposes).

[smooth]

The issue with orphans isn't just lost hash rate, it that orphans represent a symptom of the failure of the network to stay in consensus.

The way orphans happen is the network splits into parts, and during that time both (or all if >2) parts have an equal length chain. Eventually the split is resolved "orphaning" one of the chains, but not until one or the other becomes decisively longer, which may be two, three or more blocks later (it always takes at least two). During this time not only is there a natural break in consensus but an attacker can piggyback on that (by opportunisticaly waiting until a fork naturally occurs, then starting the attack). So for example, if an attacker is trying to create a 6-block fork, but the network has already created a 3-block fork, the attacker need only create a 3-block fork on top of it). Selfish mining is a variation of this.

Also, in terms of mining centralization, non-trivial orphans are bad because they give an advantage to larger miners/pools. You won't ever orphan your own blocks so if you have 30% of the hash rate you will have at least 30% fewer orphans and be that much (3% in this case) more profitable than smaller miners/pools. With naturally thin mining margins that is an enormous advantage.

[ArticMine]

I am trying to find some statistics on the current orphan rate for Monero.

[smooth]

I am trying to find some statistics on the the current orphan rate for Monero.

It's hard to do because they aren't propagated. If your node is close to the "center" of the network you may see very few, but nodes with slower propagation will see a lot. The winning fork will likely be the one that propagates to >50% of the network. If you're usually in that >50% portion, you will see few reorgs. Nodes outside that "center" will see more.

Also

the optimum appears the be the smallest time that gives close to zero orphans even in a decentralized network (not just a few pools with fast connections to each other)

That is somewhat hypothetical, but certainly desirable.

[Anon136]

deleting the other post, this is its replacement.

ok here is the formula.

a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else

f(n)=a^(b-1)        (im sure this can be simplified but w/e it works)

So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.

1 0.250000

2 0.125000

3 0.062500

4 0.031250

5 0.015625

6 0.007812

7 0.003906

8 0.001953

9 0.000976

10 0.000488

and after 60 minutes like bitcoin satoshi client suggests with 1 minute blocks it would be 4.336808e-19.

So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.

[smooth]

ok here is the formula.

a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else

f(n)=a^(b-1)        (im sure this can be simplified but w/e it works)

So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.

1 0.25

2 0.125

3 0.0625

4 0.03125

5 0.015625

6 0.007812

7 0.003906

8 0.001953

9 0.000976

10 0.000488

and after 60 minutes like bitcoin wants you to wait. its 4.3368087e-19.

So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.

These time scales just don't matter. If you want 5 second transactions, you can't get it this way. If you have to wait an hour for effective finality, you can wait a few hours. There is no significant benefit that would offset the disadvantages of an unstable network and pressure toward centralization.

[Anon136]

ok here is the formula.

a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else

f(n)=a^(b-1)        (im sure this can be simplified but w/e it works)

So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.

1 0.25

2 0.125

3 0.0625

4 0.03125

5 0.015625

6 0.007812

7 0.003906

8 0.001953

9 0.000976

10 0.000488

and after 60 minutes like bitcoin wants you to wait. its 4.3368087e-19.

So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.

These time scales just don't matter. If you want 5 second transactions, you can't get it this way. If you have to wait an hour for effective finality, you can wait a few hours. There is no significant benefit that would offset the disadvantages of an unstable network and pressure toward centralization.

Ok well its completely wrong to say the timescales dont matter. This is a black and white fallacy. There is no on off switch here between hours and seconds. Its a smooth sliding scale all the way across the spectrum between them. At each point on that scale there is a marginal consumer somewhere.

additionally i wasnt suggesting that we crank the orphan rate up to 75% inorder to get 5 second blocks. Obviously that would be terrible. It's a trade off. Higher orphan is pressure towards centralization of course, but dont discount the advantage of how much stronger a 10 minute transaction is with 10 1 minute blocks than 1 10 minute block. The difference is massive. Some amount of pressure towards centralization is a worthy trade off for that massive improvement in transactional security.

[smooth]

ok here is the formula.

a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else

f(n)=a^(b-1)        (im sure this can be simplified but w/e it works)

So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.

1 0.25

2 0.125

3 0.0625

4 0.03125

5 0.015625

6 0.007812

7 0.003906

8 0.001953

9 0.000976

10 0.000488

and after 60 minutes like bitcoin wants you to wait. its 4.3368087e-19.

So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.

These time scales just don't matter. If you want 5 second transactions, you can't get it this way. If you have to wait an hour for effective finality, you can wait a few hours. There is no significant benefit that would offset the disadvantages of an unstable network and pressure toward centralization.

Ok well its completely wrong to say the timescales dont matter. This is a black and white fallacy. There is no on off switch here between hours and seconds. Its a smooth sliding scale all the way across the spectrum between them. At each point on that scale there is a marginal consumer somewhere.

I don't agree. The significant benefit is from real time (up to maybe 30 seconds) and then pretty much everything else is a minor benefit from going faster or slower because it isn't real time. 10 minutes vs. 20 minutes is really not a game changer. This has been discussed pretty widely in the context of Bitcoin recently. You should review some of those discussions (I don't remember exactly where but I saw them on reddit) because they apply in almost exactly the same way to Monero.

Even a block time of 30 seconds doesn't give you "real time" 1-confirm transactions because it is random. You could have to wait several times the average (and that will happen regularly).

[Anon136]

ok here is the formula.

a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else

f(n)=a^(b-1)        (im sure this can be simplified but w/e it works)

So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.

1 0.25

2 0.125

3 0.0625

4 0.03125

5 0.015625

6 0.007812

7 0.003906

8 0.001953

9 0.000976

10 0.000488

and after 60 minutes like bitcoin wants you to wait. its 4.3368087e-19.

So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.

These time scales just don't matter. If you want 5 second transactions, you can't get it this way. If you have to wait an hour for effective finality, you can wait a few hours. There is no significant benefit that would offset the disadvantages of an unstable network and pressure toward centralization.

Ok well its completely wrong to say the timescales dont matter. This is a black and white fallacy. There is no on off switch here between hours and seconds. Its a smooth sliding scale all the way across the spectrum between them. At each point on that scale there is a marginal consumer somewhere.

I don't agree. The significant benefit is from real time (up to maybe 30 seconds) and then pretty much everything else is a minor benefit from going faster or slower because it isn't real time. 10 minutes vs. 20 minutes is really not a game changer. This has been discussed pretty widely in the context of Bitcoin recently. You should review some of those discussions (I don't remember exactly where but I saw them on reddit) because they apply almost exactly the same to Monero.

Even a block time of 30 seconds doesn't give you "real time" 1-confirm transactions because it is random. You could have to wait several times the average (and that will happen regularly).

Again i think you are miss characterizing the situation. Again no such black and white line exists where something falls on one half of an imaginary line and everything else on the other. its a perfectly smooth sliding scale from the lower bound (probably something like 30 seconds) to some upper bound (probably something like a day) with an in-finite number of points between any two points. at every point on the scale there lies a group of marginal consumers who appreciate that particular time threashold for their purposes. There are people who benefit a lot from 2 minutes instead of 3 or 3 instead of 4 ect... You cant artifically devide people into two clumps who are fine waiting hours and want it done in 30 seconds.

Though i will admit there is a tendency for people to clump on either end of the spectrum and fewer people to fall in between and that is a counter argument to be made for why less weight should potentially be applied to my argument, it however is not an argument for why my argument should be discarded entirely. Because plenty of people would still fall in between those two clumps.

Additionally there is no black and white line between acceptable number of orphans and not. its a sliding scale just like the one before. you can always have more and always have less, you just have to chose. what im arguing for here is simply a line of reasoning that should be factored into how you decide to make that choice. thats all. its not saying we should have any particular target. i.e. Its not an argument for or against 1 minute block times.

And if you want to look at the 10 minute situation, its not 10 minutes vs 20 minutes in transactional security. that would be a bigger deal than you are giving it credit for i think if it were the case but it isnt. in this admittedly simplified model which assumes 0 orphan rate but i think is still a useful tool for thought, a transaction with 10 blocks in 10 minutes is 512 times more secure than a single block in 10 minutes. And again thats not just at any 10 minutes, we could make similar models for any two time values you wanted, where ever you personally thought they were most useful.

[From Above]

@anon136 would u be willing to trade all ur personal assets for munero and put all ur family's savings in munero ?
how much do u love this coin and trust what the devs say about dem Munero future ?

[Anon136]

@anon136 would u be willing to trade all ur personal assets for munero and put all ur family's savings in munero?

Lol no that would be crazy.

how much do u love this coin

Lol im a fan but i dont love it per say.

how much do you ... trust what the devs say about dem Munero future ?

just because they are smarter than me doesn't mean they are always right about everything I do know a little bit about how crypto currencies work myself.