<r​ucknium:monero.social> kayabanerve: You asked "If I have 10% of the hash power and want to do a 10-block reorg, what period of time do I need to maintain 10% of the hash power before I successfully pull off such an unlikely event?"

<r​ucknium:monero.social> This isn't a complete question because you don't specify a threshold probability for the second part of the question, i.e. do you mean "...what period of time do I need to maintain 10% of the hash power before I successfully pull off such an unlikely event _with 50% probability_?"

<k​ayabanerve:matrix.org> Yes

<k​ayabanerve:matrix.org> *am likely to successfully pull of

<k​ayabanerve:matrix.org> \*am likely to successfully pull off

<k​ayabanerve:matrix.org> (where 50% odds is the turning point from unlikely to likely)

<r​ucknium:monero.social> As a draft, what I have now is a table where the rows are the N block lock, the columns are the number of blocks that the adversary possesses the 10% hashpower share (i.e. 30, 360, 720, 5040), and the cells are attack success probability

<r​ucknium:monero.social> Ok I will change to making it a 50% threshold

<r​ucknium:monero.social> So, the rows should be the N block lock, columns should be hashpower share, and the cells should be the duration, in number of blocks, that the adversary possesses the hashpower share.

<r​ucknium:monero.social> ....to achieve the 50% probability of a successful attack

You would need <10% effort for 10 blocks in a row, and the rest of a network should have >100% average effort. It doesn't look like a high probability

<r​ucknium:monero.social> It's not a high probability for a single attack. But kayabanerve wants to know the probability when you try again and again.

<k​ayabanerve:matrix.org> If I can pay 100k a year for a minority of hash power yet enough to cause disruptions which impact user privacy (even infrequently), I believe that's valuable to consider.

10^-10 probability or so, probably even less

<r​ucknium:monero.social> What formula are you using?

<10% block effort = 10% probability, and you need it 10 times in a row

That's VERY approximate, but it's just a magnitude estimation

<r​ucknium:monero.social> The magnitude is not correct. I get 7.859765e-04 using Theorem 1 of Grunspan & Perez-Marco (2018). "Double spend races."

<r​ucknium:monero.social> That's the probability in percent: gist.github.com/Rucknium/da1e57b1864aca477dfa3b4e02e86e26

<r​ucknium:monero.social> IMHO, it is a little unrealistic to assume that an adversary could have the resources to possess 10% of hashpower for a year, but not 50% of hashpower for a few hours. But I'll compute this scenario anyway.

<r​ucknium:monero.social> There is an enormous difference in the attack success probabilities when an adversary has 10% of hashpower vs 30%.

<j​effro256:monero.social> For the record, current mining security budget is 157,680 XMR per year, so 100k XMR in a year would be almost two thirds of the security budget, which would be pretty impractical to guard against in any capacity

<j​effro256:monero.social> Oh you were probably talking about USD lol

<k​ayabanerve:matrix.org> *USD, jeffro256*

<k​ayabanerve:matrix.org> *USD*

<j​effro256:monero.social> fake money!

<k​ayabanerve:matrix.org> Yes, and that is very American-centric of me, but I promise I wasn't asking about spending 16m a year on DoSs.

<j​effro256:monero.social> 🦅🦅🦅

<k​ayabanerve:matrix.org> *16m USD

<r​ucknium:monero.social> My _very preliminary_ calculations say that the adversary has to possess 10% hashpower for about six years to have a 50% probability of maliciously re-orging a series of 10 blocks while constantly attacking. I'll double-check the numbers and present a table tomorrow at the meeting.

<j​effro256:monero.social> It would interesting to know what the "optimal" attack would be given a certain fixed budget, where the attacker gets to determine the timeline. Should one compress the attack into a few minutes and try to reorg as much as possible as quick as possible? Or should they try many many shallow reorgs over the period of a few weeks/months? Depends on the goals I guess

<j​effro256:monero.social> If they want to undermine confidence in the currency, a single very deep reorg at an opportune time might be the way to go

<m​onerobull:matrix.org> in reality surprisingly few people would actually care

<r​ucknium:monero.social> This assumes (1) That the attacker halts the attack if the honest chain reaches 10 blocks, but the attacker has not yet reached 10 blocks (Theorem 1.2 of Grunspan & Perez-Marco (2021). "On Profitability of Nakamoto Double Spend.") and (2) After the attack halts, (1-q)/q blocks elapse on the honest chain before the attacker mines their next block and starts their attack again. I si<clipped message

<r​ucknium:monero.social> mplified and took the average of the negative binomial distribution (Proposition 5.1 of Grunspan, C & Perez-Marco (2018). "Double spend races."

<m​onerobull:matrix.org> as long as they dont get personally affected by it

<r​ucknium:monero.social> Also, this probability is for when _at least one_ attack succeeds. The attack would succeed multiple times in the time window, with lower probability.

<r​ucknium:monero.social> monerobull: IMHO, it is "interesting" that very deep re-orgs on other chains had small effects on their exchange rates. e.g. Eth Classic and Firo.

<j​effro256:monero.social> And Firo's was 306 blocks deep lol

<m​onerobull:matrix.org> its because nobody actually uses these chains for anything real

<j​effro256:monero.social> I don't know if the reorger accompanied it with a double spend attack as well or it was just for the sake of disruption

<o​frnxmr:monero.social> Ppl trading on binance dont care what the chain does

<o​frnxmr:monero.social> Did my market maker bot stop? No? Then nothing happened

<j​effro256:monero.social> Okay apparently it was cointelegraph.com/news/privacy-focu…ro-cryptocurrency-suffers-51-attack

<j​effro256:monero.social> They might care if Binance loses money and halts trades on that chain

<m​onerobull:matrix.org> they would just let trades continue but block deposits

<o​frnxmr:monero.social> Right. "did my bot stop?"

<o​frnxmr:monero.social> Block withdrawals 😂

<m​onerobull:matrix.org> nah

<o​frnxmr:monero.social> Im poking fun at the fact that they do it all the time

<m​onerobull:matrix.org> "we sent the withdrawal, not our fault the chain you use is dogwater and erased a week of history"

<r​ucknium:monero.social> jeffro256: "In [15], the authors introduce a profitability setup and look for the optimal number of blocks that an attacker should premine before launching a double-spend attack (we will answer this question in a future article)." Grunspan & Perez-Marco (2021). "On Profitability of Nakamoto Double Spend."

<o​frnxmr:monero.social> (Block dep/wd and ket ppl keep trading)

<r​ucknium:monero.social> Maybe I should look around to see if they have posted the future article. We are in the future, after all.

<j​effro256:monero.social> Thanks Rucknium . I guess I should just suck it up and read that paper you keep referencing ;)

<r​ucknium:monero.social> They are available on moneroresearch.info :)

<r​ucknium:monero.social> jeffro256: IMHO Rosenfeld (2014) "Analysis of Hashrate-Based Double Spending" is easier to digest than the Grunspan & Perez-Marco papers: moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=191

<r​ucknium:monero.social> Rosenfeld's equation 1, page 7 is equivalent to Theorem 1 of Grunspan & Perez-Marco (2018). Grunspan & Perez-Marco use the regularized incomplete beta function instead of Rosenfeld's summation of binomials. Grunspan & Perez-Marco are more rigorous and it looks like it is easier to prove that a majority hashrate attack has 100% success probability as time goes to infinity if you us<clipped message

<r​ucknium:monero.social> e the version with the regularized incomplete beta function.