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

it does beg the question where they got so many tx inputs, not something I can answer though

even if all info about these tx is known there is no mechanism to prevent similar behaviour in future

there is no even test environment to measure worst case impact on privacy

only increase fee is supposed to be enabled with the next hf

* only fee is supposed to be increased x5 with the next hf

`0.000020480000` ~= 5 * `0.000004100220`, funny

<Rucknium[m]> "Ring member age distribution..." <- it would be good to learn reference wallet implementation already, but who cares

<ooo123ooo1234567> "even if all info about these..." <- Is creating a mechanism feasible?

blox.minexmr.com/tx/4f4f08c33df42cc…f932fc3ffa352651008867a5cf1c5e86d8b, tx with many inputs but minimum fee

those 194 inputs tx has already 5x higher fee, that's funny

like an intentional preparation for the hf

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 ?

it isn't spam, it isn't greedy custom wallet, what is it ?

I noticed 2017 ring members that had weird rings

This one has 0 inputs and 0 rings

And heres a 2017 with ring size 3 (there is a bunch of these)

hiiiiiiiiiiiiiiiiiiii

sometimes Monero::PendingTransaction::txid() doesn't return anything

but transaction is working

Should 0 dummy outputs be generated to a random address or an address controlled by the sender?.

<MeowingCat> "hiiiiiiiiiiiiiiiiiiii" <- 1. xyproblem.info

2. Since you wont offer, I'll request. Send 0.5 xmr per hr of debugging.

8343hzpypz2BR5ybAMNvvhaLtbXSMgCT7KqYSTfLBk3DF8Yayi5b7JGRWZc2GdqNu1EkALEFv1FHkCgeQ1zzkUFVMqtcTBy

ooo123ooo1234567: There are some 100kb transactions in mempool and on some mined blocks. Is this what they were trying to achieve from yesterday?

I think the goal is quite clear now, they want to congest the network.

<MaxicanTakeout96> "I think the goal is quite..." <- If that's the case, they failed. Even my very low end laptop is syncing happily.

x86_64 Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz

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.

it's weird they use custom decoy selection algorithm

is it confirmed a custom decoy selection? I kinda been assuming it's just p2pool consolidations, p2pool creates a whole bunch of outputs

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

If it's those 194 input txs being referenced, those have been happening since b4 p2pool and often happened in batches

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.

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.

It's not p2pool consolidations, otherwise it would have coinbase transactions in each ring, and these coinbase transactions would have more than 1 output

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

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

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

default fee multiplier is 5x and the next hf fee increase is also ~5x

Rucknium: None of the rings with high concentrations in Aug/Sept 2021 have any members past this date. Could be ringdb caching?

jberman[m]: Ah, exactly.

tobtoht[m]: 2017-2021

2018-2021

2019-2022

Weird ranges too, especially for the 2017's

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)

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

The latter can probably be analyzed/risk quantified

I think it's safe to assume that all (or >99%) coinbase outputs are spent within 1-2 months

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.

My worry is tx like this where you effectively have a ring size of 7 (or worse)

11-3=8, no?

and it will be increased to 16 in the next fork

sech1: Only if you use a calculator 😆

dont know why I was using the #10

arnuschky[m]: any update on the audit?

Is there a date for the next meeting?

tobtoht[m]: plan was once the multisig audit is done

Ok, thanks.

<selsta> "arnuschky: any update on the..." <- They've gone dark on me again :(

ok, hmm

well let's wait until end of week

How does a professional audit firm go dark though, seems rather unprofessional to me..

You can watch them active on twitter though :)

or inactive in case if they're busy

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

sech1: how did you build the binaries that didn't run on Ubuntu 16.04?

gitian or just depends?

gitian

selsta, are you still fighting with that glibc ?

ooo123ooo1234567: i asked someone else now

when was the beginning ? (needed to measure duration)

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

who is that "someone else" ?

TheCharlata n, he used to maintain the depends system initially

good candidate

I dont have full logs, but have never seem this error before. Says to share with moo

Is it about a mismatch to do with difficulty ?

Probably. If so, what commit hash are you running ?

sech1: monero-project/monero #8400

can you test this?