00:08:41 <UkoeHB> ofrnxmr[m]1: idk, these big txs have been showing up since that weird point of congestion last fall (maybe before then too). A worthy target for guys like Rucknium[m].
00:09:38 <UkoeHB> it does beg the question where they got so many tx inputs, not something I can answer though
00:25:02 <ooo123ooo1234567> even if all info about these tx is known there is no mechanism to prevent similar behaviour in future
00:25:14 <ooo123ooo1234567> there is no even test environment to measure worst case impact on privacy
00:25:26 <ooo123ooo1234567> only increase fee is supposed to be enabled with the next hf
00:25:38 <ooo123ooo1234567>  * only fee is supposed to be increased x5 with the next hf
00:28:11 <ooo123ooo1234567> `0.000020480000` ~= 5 * `0.000004100220`, funny
00:30:24 <ooo123ooo1234567> <Rucknium[m]> "Ring member age distribution..." <- it would be good to learn reference wallet implementation already, but who cares
00:41:34 <ofrnxmr[m]1> <ooo123ooo1234567> "even if all info about these..." <- Is creating a mechanism feasible?
00:45:37 <ooo123ooo1234567> https://blox.minexmr.com/tx/4f4f08c33df42cc626e90072c1224f932fc3ffa352651008867a5cf1c5e86d8b, tx with many inputs but minimum fee
00:46:09 <ooo123ooo1234567> those 194 inputs tx has already 5x higher fee, that's funny
00:46:23 <ooo123ooo1234567> like an intentional preparation for the hf
00:48:16 <ooo123ooo1234567> who is creating huge tx with broken decoys (it hurts only tx creator privacy and harmless for others) and using 5x higher fees before actual hf ?
00:48:30 <ooo123ooo1234567> it isn't spam, it isn't greedy custom wallet, what is it ?
01:06:46 * ofrnxmr[m]1 uploaded an image: (229KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/TbBvgaENXVOSQcNvDTVDpEOY/Imagepipe_178.jpg >
01:08:02 <ofrnxmr[m]1> I noticed 2017 ring members that had weird rings
01:08:02 <ofrnxmr[m]1> This one has 0 inputs and 0 rings
01:08:42 * ofrnxmr[m]1 uploaded an image: (232KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/uCaBpSQrwhmwVAFGhEMISBGe/Imagepipe_177.jpg >
01:09:13 <ofrnxmr[m]1> And heres a 2017 with ring size 3 (there is a bunch of these)
01:10:09 <ofrnxmr[m]1> https://monero.hashvault.pro/explorer/tx/a2a77859ede9405b37f807f5a7798d5ba98403e2344c5fc214482f669f9f3f4d
08:05:38 <MeowingCat> hiiiiiiiiiiiiiiiiiiii
08:06:23 <MeowingCat> sometimes Monero::PendingTransaction::txid() doesn't return anything
08:06:46 <MeowingCat> but transaction is working
11:42:17 <Guest29> Should 0 dummy outputs be generated to a random address or an address controlled by the sender?.
11:50:40 <ofrnxmr[m]1> <MeowingCat> "hiiiiiiiiiiiiiiiiiiii" <- 1. https://xyproblem.info
11:50:40 <ofrnxmr[m]1> 2. Since you wont offer, I'll request. Send 0.5 xmr per hr of debugging.
11:50:40 <ofrnxmr[m]1>  8343hzpypz2BR5ybAMNvvhaLtbXSMgCT7KqYSTfLBk3DF8Yayi5b7JGRWZc2GdqNu1EkALEFv1FHkCgeQ1zzkUFVMqtcTBy
15:12:20 <MaxicanTakeout96> ooo123ooo1234567: There are some 100kb transactions in mempool and on some mined blocks. Is this what they were trying to achieve from yesterday?
15:16:20 <MaxicanTakeout96> I think the goal is quite clear now, they want to congest the network.
15:39:33 <TrasherDK[m]> <MaxicanTakeout96> "I think the goal is quite..." <- If that's the case, they failed. Even my very low end laptop is syncing happily.
15:39:44 <TrasherDK[m]> x86_64 Intel(R) Core(TM)2 Duo CPU T8100  @ 2.10GHz
15:41:05 <sech1> The transactions that are in the mempool now use the lowest fee tier (4000 piconero/byte). They're just trying to consolidate funds for cheap.
15:44:50 <MajesticBank> it's weird they use custom decoy selection algorithm
16:22:17 <Lyza> is it confirmed a custom decoy selection? I kinda been assuming it's just p2pool consolidations, p2pool creates a whole bunch of outputs
16:22:58 <Lyza> maybe worth revisiting the topic of separating coinbase transactions in decoy selection now that they're a LOT more coinbase outputs than before with p2pool
16:26:15 <nioc> If it's those 194 input txs being referenced, those have been happening since b4 p2pool and often happened in batches
16:40:38 <TrasherDK[m]> Could this "I background mining is enabled, but not started, waiting until start triggers" be changed to a change state event. Getting one of those every 20-30 seconds is kind of spammy. mining started/stopped would be enough.
16:46:21 * moneromooo agrees
16:53:38 <Rucknium[m]> Lyza: For tx a2a77859ede9405b37f807f5a7798d5ba98403e2344c5fc214482f669f9f3f4d ? Given the concentration of ring members in Aug/Sept 2021 for many of the rings, the probability of this tx using the standard decoy selection algorithm (DSA) is vanishingly small. If they used the standard DSA, ring members be would concentrated within the last month or so.
16:57:22 <sech1> It's not p2pool consolidations, otherwise it would have coinbase transactions in each ring, and these coinbase transactions would have more than 1 output
16:57:47 <jberman[m]> Don't really think it matters much, but wallet2 could in theory have been used for the decoy selection algo. it's the weird fee that gives me pause to say it was definitively wallet2
16:57:55 <jberman[m]> If you construct a tx on a particular date and then don't submit the tx, then the ring(s) your wallet constructed will be saved on disk and reused if you spend the input in the future
16:58:13 <jberman[m]> A 5x fee makes me think it could have been constructed using the MyMonero libs, though maybe they could have specifically chosen a higher fee using wallet2 haven't double checked the numbers
16:58:23 * ofrnxmr[m]1 uploaded an image: (119KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/KrgKYlAzWujFAzkdUEtvbHMJ/Imagepipe_176.jpg >
16:58:54 <ooo123ooo1234567> default fee multiplier is 5x and the next hf fee increase is also ~5x
16:59:03 <tobtoht[m]> Rucknium: None of the rings with high concentrations in Aug/Sept 2021 have any members past this date. Could be ringdb caching?
16:59:42 <tobtoht[m]> jberman[m]: Ah, exactly.
17:00:09 <ofrnxmr[m]1> tobtoht[m]: 2017-2021
17:00:09 <ofrnxmr[m]1> 2018-2021
17:00:09 <ofrnxmr[m]1> 2019-2022
17:00:09 <ofrnxmr[m]1> Weird ranges too, especially for the 2017's
17:04:58 <sech1> Lyza around 85% of all coinbase outputs are p2pool outputs now (p2pool finds ~50 blocks/day, but each with ~70 outputs, the rest 670 blocks only have 1 output each)
17:06:44 <jberman[m]> one negative with coinbase-only rings to consider is that it puts a known cap on the amount spent in the tx. Could argue this is less bad than the alternative of (sweeps of many coinbase outputs in 1 tx can reveal spends and amounts + pools definitively reveal spent coinbase outputs) = harm to other rings
17:07:03 <jberman[m]> The latter can probably be analyzed/risk quantified
17:08:29 <sech1> I think it's safe to assume that all (or >99%) coinbase outputs are spent within 1-2 months
17:10:03 <sech1> pools spend them quickly because they need to do payouts to miners, p2pool miners need to consolidate funds eventually. Only dedicated solo miners/holders don't spend their coinbase outputs.
17:11:42 * ofrnxmr[m]1 uploaded an image: (118KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/hfpuQudqQjhgWgwMJXeFbZOh/Imagepipe_180.jpg >
17:16:49 <ofrnxmr[m]1> My worry is tx like this where you effectively have a ring size of 7 (or worse)
17:18:48 <sech1> 11-3=8, no?
17:19:03 <sech1> and it will be increased to 16 in the next fork
17:20:01 <ofrnxmr[m]1> sech1: Only if you use a calculator 😆
17:20:01 <ofrnxmr[m]1> dont know why I was using the #10 
17:27:07 <selsta> arnuschky[m]: any update on the audit?
17:52:14 <tobtoht[m]> Is there a date for the next meeting?
17:56:50 <selsta> tobtoht[m]: plan was once the multisig audit is done
17:57:08 <tobtoht[m]> Ok, thanks.
18:00:58 <arnuschky[m]> <selsta> "arnuschky: any update on the..." <- They've gone dark on me again :(
18:01:10 <selsta> ok, hmm
18:01:19 <selsta> well let's wait until end of week
18:02:11 <dEBRUYNE> How does a professional audit firm go dark though, seems rather unprofessional to me..
18:03:31 <w[m]> You can watch them active on twitter though :) 
18:05:40 <ooo123ooo1234567> or inactive in case if they're busy
18:09:14 <binaryFate> luigi1111 is afk till early next week too, whatever we get from the audit I'd like him to have a look. So ideally at some point next week we can finally move to a more active decision-making mode wrt. multisig, release and fork date
18:15:43 <selsta> sech1: how did you build the binaries that didn't run on Ubuntu 16.04?
18:15:51 <selsta> gitian or just depends?
18:16:57 <sech1> gitian
18:21:31 <ooo123ooo1234567> selsta, are you still fighting with that glibc ?
18:21:41 <selsta> ooo123ooo1234567: i asked someone else now
18:22:42 <ooo123ooo1234567> when was the beginning ? (needed to measure duration)
18:23:26 <selsta> the only solution i think would work is replacing all explicit_bzeros with memsets, and put the reallocarray inline but that's even more ugly
18:23:54 <ooo123ooo1234567> who is that "someone else" ?
18:24:47 <selsta> TheCharlata n, he used to maintain the depends system initially
18:29:48 <ooo123ooo1234567> good candidate 
20:50:44 <ofrnxmr[m]1> I dont have full logs, but have never seem this error before. Says to share with moo
20:50:49 * ofrnxmr[m]1 uploaded an image: (1635KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/vGYBujSkoxmsbuJXhwFpxctB/Imagepipe_183.jpg >
20:57:13 <moneromooo> Is it about a mismatch to do with difficulty ?
20:57:38 <moneromooo> Probably. If so, what commit hash are you running ?
22:14:53 <selsta> sech1: https://github.com/monero-project/monero/pull/8400
22:16:41 <selsta> can you test this?