10:59:39 <***> Buffer Playback...
10:59:39 <sethsimmons> [12:56:28] No idea, which is why it may be an attack 🙂 It's very unclear.
10:59:39 <sech1> [12:59:30] no hardfork needed because output ring selection is not a part of consensus
10:59:39 <gingeropolous> [13:20:25] can also be mitigated by coordinating with pool ops because Mining Pools Are Decentralized (tm)
10:59:39 <gingeropolous> [13:34:14] sethsimmons, check around dec 11th re: relatively recent large tx spike
10:59:39 <gingeropolous> [13:34:17] 2020
10:59:39 <jtgrassie> [14:03:20] sethsimmons: "for a fixed client to be released ASAP" <- why ASAP? the div0 has no imminent impact
10:59:39 <jtgrassie> [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."
10:59:39 <plowsof[m]> [14:26:33] Anyone elses node complaining? "There were 22 blocks in the last 90 minutes"
10:59:39 <sethsimmons> [14:27:16] <plowsof[m] "Anyone elses node complaining? ""> Yes, nothing too abnormal about that.
10:59:39 <plowsof[m]> [14:29:45] Ok thanks Seth (wouldnt have a node if it wasn't for your guides thnx) 
10:59:39 <MasFlam[m]> [14:48:55] just to be sure, that div by zero vuln can only affect network congestion, not anything security-related, right?
10:59:39 <sethsimmons> [14:51:00] My understanding is that it's simply a DoS that would prevent TX construction if exploited. But I could be wrong.
10:59:39 <jberman[m]> [14:52:48] Yea, Seth is correct
10:59:39 <jberman[m]> [14:53:27] Would prevent tx construction in wallets, and a simple patch to wallets would allow construction
10:59:39 <MasFlam[m]> [14:54:21] great to hear, thanks :)
10:59:39 <jberman[m]> [15:39:20] Running numbers right now to provide more information. Here's where I'm at so far
10:59:39 <jberman[m]> [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
10:59:39 <jberman[m]> [15:39:48] We are currently at 62.44 outputs per block over the last year
10:59:39 <jberman[m]> [15:40:14] Two days ago, before the tx volume spike, we were at 62.03 outputs per block over prior year
10:59:39 <jberman[m]> [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
10:59:39 <jberman[m]> [15:41:11] It looks like a long time
10:59:39 <sech1> [15:51:05] is this volume even enough to trigger the bug eventually?
10:59:39 <sech1> [15:53:06] 42000 tx/day is barely enough for 120 outputs/block on average
10:59:39 <rbrunner> [15:55:40] And is it realistic that somebody speculates we don't fix that bug for a year or so?
10:59:39 <rbrunner> [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.
10:59:39 <Guest97> [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.
10:59:39 <sech1> [16:18:54] the fix doesn't require a hardfork
10:59:39 <jberman[m]> [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
10:59:39 <sethsimmons> [16:38:43] <jberman[m] "Estimate if the current avg outp"> Holy hell lol
10:59:39 <sethsimmons> [16:39:06] That would cost a lot in fees due to being the sole driver of increasing block sizes
10:59:39 <jberman[m]> [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
10:59:39 <sethsimmons> [16:40:08] <jberman[m] "In the worst case, assuming all "> That would, thankfully, be very visible on-chain and quickly.
10:59:39 * jberman[m] [16:40:24] posted a file: (8KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/ucZYUaejFkqLjXEopUYYIIBx/Volume%20needed%20to%20trigger%20divide%20by%200.ods >
10:59:39 <jberman[m]> [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
10:59:39 <jberman[m]> [16:50:58] It would take ~293 days to trigger divide by 0 if the trailing 24hr output volume is sustained
10:59:39 <solominer> [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: https://pastebin.com/fumfKAjL ). Thank you in advance.
10:59:39 <solominer> [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. https://www.blocktrainer.de/bitcoin-crash-wirklich-vorprogrammiert
10:59:39 <hyc> [17:12:48] please keep non-development topics out of this channel in the future
10:59:39 <carrington[m]> [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 
10:59:39 <Guest97> [17:13:31] too late now
10:59:39 <hyc> [17:13:33] too late
10:59:39 <carrington[m]> [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 :
10:59:39 <carrington[m]> [17:14:49] https://github.com/monero-project/meta/issues/588
10:59:39 <jberman[m]> [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
10:59:39 <jberman[m]> [17:25:02] In hindsight, I agree discussing how to exploit in the first place should have been avoided
10:59:39 <jberman[m]> [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
10:59:39 <Monegro> [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)
10:59:39 <Monegro> [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?
10:59:39 <Monegro> [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
10:59:39 <gingeropolous> [03:53:28] are u proposing to wait until a hard fork such that more wallet clients are likely to upgrade?
10:59:39 <***> Playback Complete.
17:02:01 <Monegro> 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
17:02:24 <Monegro> But unless we actually see that, we should try and wait until the next hard fork
17:07:16 <sech1> Monegro patch has been ready for more than a week in PR #7799