Author

Topic: [XMR] Monero Speculation - page 1955. (Read 3313084 times)

legendary
Activity: 2282
Merit: 1050
Monero Core Team
April 12, 2015, 11:27:55 PM
If I understand this correctly one can count the number of
Code:
REORGANIZE SUCCESS!
events on bitmonero.log vs the number of blocks that have elapsed to get measure of the orphan rate that one sees. If a representative sample of nodes monitor this then one should be able to get a handle on the orphan rate.
hero member
Activity: 700
Merit: 520
April 12, 2015, 10:52:48 PM
I think you are trying to win an argument rather than really listening to what I'm saying. What im arguing is incontrovertible but i don't think you are really listening enough to know specifically what it is that i am arguing.

Lol.  BAM!
props for direct honesty
legendary
Activity: 1722
Merit: 1217
April 12, 2015, 10:50:24 PM
I think you are trying to win an argument rather than really listening to what I'm saying. What im arguing is incontrovertible but i don't think you are really listening enough to know specifically what it is that i am arguing.

Oh well its not that big of a deal anyway. As far as i understand it fluffypony is only wanting to increase the block time to 2 minutes or something like that. For all i know without having more information that could very easily be an improvement to the security of monaro. In fact i would bet it is since FP is a really smart guy.

Anyway I'm done arguing.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 10:43:05 PM
a transaction with 10 blocks in 10 minutes is 512 times more secure than a single block in 10 minutes.

No, it isn't 512 times "more secure" it has a 512 times smaller result using this particular probabilistic model of one aspect of security. That is not the same thing at all. For example, a less decentralized network is "less secure" because it violates the assumption in proof of work of any actor having a "small" share of the hash rate (an inconvenient truth that is conveniently ignored in Bitcoin and most if not all other PoW coins today). There is also an upper bound on practical security from the absolute hash rate (regardless of how it is broken up into blocks) because an attacker can just buy or build the necessary hash rate to defeat an arbitrarily large number of confirms.

So as discussed on that thread I linked, these results only apply directly when:

1. Orphans are not a major consideration
2. The absolute hash rate is high

The context there was Bitcoin with 10 minute blocks (orphans not a major considerations) and a hash rate cost in the hundreds of millions of dollars (absolute hash rate is high). Neither of those applies to Monero today.
legendary
Activity: 1722
Merit: 1217
April 12, 2015, 10:41:14 PM
@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 Wink I do know a little bit about how crypto currencies work myself.
hero member
Activity: 700
Merit: 520
April 12, 2015, 10:36:08 PM
@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 ?
legendary
Activity: 1722
Merit: 1217
April 12, 2015, 10:25:12 PM
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.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 10:03:31 PM
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).
legendary
Activity: 1722
Merit: 1217
April 12, 2015, 09:52:55 PM
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.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 09:48:18 PM
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.



legendary
Activity: 1722
Merit: 1217
April 12, 2015, 09:39:25 PM
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.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 08:59:55 PM
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.

legendary
Activity: 2282
Merit: 1050
Monero Core Team
April 12, 2015, 08:55:08 PM
I am trying to find some statistics on the current orphan rate for Monero.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 08:16:41 PM
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.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 07:36:45 PM
...

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



legendary
Activity: 2282
Merit: 1050
Monero Core Team
April 12, 2015, 07:24:09 PM
...

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.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 07:12:45 PM
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.
legendary
Activity: 2282
Merit: 1050
Monero Core Team
April 12, 2015, 07:10:32 PM
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.
legendary
Activity: 2968
Merit: 1198
April 12, 2015, 07:07:38 PM

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://bitcointalksearch.org/topic/m.2781832
hero member
Activity: 560
Merit: 500
April 12, 2015, 07:02:09 PM
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.
Jump to: