Topic: [XMR] Monero Speculation - page 1954. (Read 3314330 times)

There are a host of scenarios where a 1 min block time can be very advantageous over a two min block time. We must keep in mind that were are dealing with the outlier event of say a 5 min confirmation vs a 10 min confirmation here also.  XMR.TO is a perfect case. With a 1 min blocktime on the XMR side there is a very high probability of meeting the 15 min transaction time set by XBT processors, with a 2 min blocktime on the XMR side this is no longer the case since there is a significant chance of an outlier 10 -12 min XMR confirmation that not allow for the 15min overall time limit.

Restaurant and bars are another example. Ever being out with a group of say 10 people and 8 of them pay by debit card or credit card? By the time the debit machine reaches the last person easily 10 min or more has elapsed. XMR or XBT transactions can be processed in parallel rather than in series for example by scanning a QR code printed on the bill with a smartphone. In this scenario XMR with a 1 min blocktime would beat debit while XBT with a 10 min blocktime would not. The target here is an average wait of 5 min with debit.

There may well be a very good case to increase the blocktime in XMR to say 2min; however if this is done it should be done promptly before more services that are dependent upon the 1 min blocktime are built on top of the network. We simply cannot predict what will be built on top of XMR. By the way XMR with 1 min blocktime is getting close to the theoretical limit, and I suspect that Vitalik's 12 sec confirmation could easily run afoul of the law of special relativity.

Edit: I will take a look at Vitalik's paper.

You're right that it's a "sliding" scale, but I think you're being a bit ridiculous to suggest that any significant number of users would stop using a crypto that ups it's block target from 1 minute to 2 or 3 or 4.

I think smooth's point is that a transaction is either fast enough for real time, point-of-sale purchases, or it isn't. Beyond that, the differences don't mean much.

For those who haven't seen it, Vitalik Buterin wrote an interesting article on what it would take to achieve ultra fast block times in a PoW currency: https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/

If I understand this correctly one can count the number of 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.

Lol.  BAM!
props for direct honesty

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.

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.

Lol no that would be crazy.

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

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.

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

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.

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

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.

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.

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.

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


That is somewhat hypothetical, but certainly desirable.

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

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.

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

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.

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.

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.