Buffer Playback...

[12:56:28] No idea, which is why it may be an attack 🙂 It's very unclear.

[12:59:30] no hardfork needed because output ring selection is not a part of consensus

[13:20:25] can also be mitigated by coordinating with pool ops because Mining Pools Are Decentralized (tm)

[13:34:14] sethsimmons, check around dec 11th re: relatively recent large tx spike

[13:34:17] 2020

[14:03:20] sethsimmons: "for a fixed client to be released ASAP" <- why ASAP? the div0 has no imminent impact

[14:04:30] Quoting jberman: "For more color on divide by 0 bug, it requires an average of >120 outputs per block over a trailing 12 month period."

[14:26:33] Anyone elses node complaining? "There were 22 blocks in the last 90 minutes"

[14:27:16] <plowsof[m] "Anyone elses node complaining? ""> Yes, nothing too abnormal about that.

[14:29:45] Ok thanks Seth (wouldnt have a node if it wasn't for your guides thnx)

[14:48:55] just to be sure, that div by zero vuln can only affect network congestion, not anything security-related, right?

[14:51:00] My understanding is that it's simply a DoS that would prevent TX construction if exploited. But I could be wrong.

[14:52:48] Yea, Seth is correct

[14:53:27] Would prevent tx construction in wallets, and a simple patch to wallets would allow construction

[14:54:21] great to hear, thanks :)

[15:39:20] Running numbers right now to provide more information. Here's where I'm at so far

[15:39:40] First of all, to trigger it would require an average of over 120 outputs per block over the trailing ~1 year period

[15:39:48] We are currently at 62.44 outputs per block over the last year

[15:40:14] Two days ago, before the tx volume spike, we were at 62.03 outputs per block over prior year

[15:40:46] Calculation I'm currently working on is if the last 12 hour volume is sustained, how long it would take to trigger

[15:41:11] It looks like a long time

[15:51:05] is this volume even enough to trigger the bug eventually?

[15:53:06] 42000 tx/day is barely enough for 120 outputs/block on average

[15:55:40] And is it realistic that somebody speculates we don't fix that bug for a year or so?

[15:56:46] Looks more like "Let's f*ck with those Monero people a little and watch them running around after a doubling of traffic". Somebody's definition of fun maybe.

[16:11:50] should we start preparing a hard fork for 30-60 days from now? I know that there were debates whether a hard fork would even be worth it with tryptich on the horizon.

[16:18:54] the fix doesn't require a hardfork

[16:38:23] Estimate if the current avg outputs per tx stays the same, in order to trigger the divide by 0 in 2 weeks, tx volume would need to increase 10.6x to ~702 transactions per block

[16:38:43] <jberman[m] "Estimate if the current avg outp"> Holy hell lol

[16:39:06] That would cost a lot in fees due to being the sole driver of increasing block sizes

[16:39:24] In the worst case, assuming all txs included 16 outputs, tx volume would need to increase 0.6x to ~97 txs per block

[16:40:08] <jberman[m] "In the worst case, assuming all "> That would, thankfully, be very visible on-chain and quickly.

[16:41:09] there's my math, would def appreciate more eyes to validate. Can also change the days from 14 to whatever to see

[16:50:58] It would take ~293 days to trigger divide by 0 if the trailing 24hr output volume is sustained

[16:55:30] Sorry for a short disturbance, but I need some feedback on what I've posted in #monero 20 minutes ago (I'm referring to this article: pastebin.com/fumfKAjL ). Thank you in advance.

[17:12:10] Ok, I've just been directed towards a forum that discusses this article and found another article that clears everything up (german). Thank you nevertheless. blocktrainer.de/bitcoin-crash-wirklich-vorprogrammiert

[17:12:48] please keep non-development topics out of this channel in the future

[17:13:18] This discussion of the details of how to exploit this bug should probably not be in a public channel given there is a chance it is being actively exploited

[17:13:31] too late now

[17:13:33] too late

[17:14:49] Remainder that there is a -community meeting in less than 24 hours to give/receive updates. If there is an imminent release this might be a good time to disseminate that :

[17:14:49] monero-project/meta #588

[17:25:02] I figured all the details on how to exploit are already public anyway so it made sense to provide information for people running services who are concerned

[17:25:02] In hindsight, I agree discussing how to exploit in the first place should have been avoided

[17:32:57] Especially considering the above information should make it clear how unlikely to affect anyone it is, or at least provide a greater level of understanding of how safe they are at the moment

[19:46:16] Read the Github thread and on here. If this attack isn't feasible without 702txns per block (at 16 outputs) ... and if the pre/post fix without hardfork has the potential for use as a heuristic (unclear now but we know it could be another "bit" of info for use by the likes of CypherTrace)

[19:46:39] ... then wouldn't it make sense to wait to roll this out until we see clear evidence that an attack is actually taking place?

[19:48:02] Right now, even if it is an attack, they're nowhere near being successful. So releasing an update that could harm transaction uniformity might be jumping the gun a bit

[03:53:28] are u proposing to wait until a hard fork such that more wallet clients are likely to upgrade?

Playback Complete.

Basically. It would be a good idea to have a patch ready to roll out, in case we see the clear signs of an attack along these lines developing

But unless we actually see that, we should try and wait until the next hard fork

Monegro patch has been ready for more than a week in PR #7799