<r​ottenwheel:unredacted.org> wat in the hell is dis, Brandon? moneroleaks.xyz

<r​ottenwheel:unredacted.org> spirobel he didn't pay attention to your replies, he instead built a whole site...

<s​yntheticbird:monero.social> low effort fed slop

<s​yntheticbird:monero.social> sad

<s​yntheticbird:monero.social> glowies were a little better in the past

<b​asses:matrix.org> Agree, see "Case studies" list, point 1 and 3, they were already tracking their transparent blockchain coins they used to swap for XMR

<b​asses:matrix.org> Ciphertrace tool had a great reddit post explaining the details on what probably is happening since the annoucement.

<b​asses:matrix.org> The only *real* curious case is the recent one with Arch, but it sounds like they got into their infra like with Lockbit etc so there could have been some *tells* with how they managed flow of transactions.

<e​longated:matrix.org> It think it z**o kiddies

<o​frnxmr:xmr.mx> "Every monero transaction leaks the amount received by the recipient to the sender" lmao

<o​frnxmr:xmr.mx> Written by a toddler. This is worse than AI slop

<s​pirobel:kernal.eu> people should stop engaging with him. just mass report and do community notes maybe

<g​ingeropolous:monero.social> semi-related, if anyone wants to develop monerofact.org, monerofact.com, or monerofacts.org , or monerofacts.com, i can transfer them to yah. im tired of paying domains reg fees and my current expires in november

<g​ingeropolous:monero.social> i got motivated to do it at one point, but then sorta felt that a project that needs these kind of buttresses is meh (because i remember similar crap for xrp and whatever), so I just ended up squatting

<g​ingeropolous:monero.social> but im no marketing genius

<a​tomfried:matrix.org> Random thought i guess the only way to battle the "Inflation bug" fud once and for all is to write something like moneroinflation.com in lean4 or coq ...

<o​frnxmr:xmr.mx> in rust*

<a​tomfried:matrix.org> In rust you can still have a faulty implementation ...

<d​uvet:midov.pl> Is there any write up or best practices for consolidating multiple outputs?

<r​ucknium:monero.social> The Zano team released a response to jhendrix's network privacy research: blog.zano.org/team-response-to-zano-network-analysis-report

<r​ucknium:monero.social> jhendrix's research (Tor browser necessary): g7cpug4k6ydyq5dlxrji35xnfq5n5rba3n7holux4tmdsm42ju543tad.onion

<r​ucknium:monero.social> duvet: I don't know of any solid research about this.

<o​frnxmr:xmr.mx> Rather sad, really

<o​frnxmr:xmr.mx> consolidating (aka co-spending) outputs is always going to have privacy implications. it's my view that consolidating early and often is better than consolidating many at once. This also aligns with how monero _prefers_ to cospend 2 outputs.

<o​frnxmr:xmr.mx> If monero did not prefer to spend a full output, then you would end up building up a cache of change outputs, and eventually cospend many of them at once, which would link all of your prior transfers together

<o​frnxmr:xmr.mx> while preferring to spend 2 enotes at once will link those 2 together, it "erases" one of them. So future references to it on chain will be decoys, instead of spending old outputs well into the future

<c​haser:monero.social> ofrnxmr: what do you mean by "monero prefers to cospend 2 outputs"?

<o​frnxmr:xmr.mx> i mean, when selecting outputs to make a tx, monero prefers to spend a whole output before spending a partial one

<o​frnxmr:xmr.mx> "monero" = wallets

<o​frnxmr:xmr.mx> If you have 0.2 + 1.0 xmr, and need to spend 0.8xmr, instead of spending 0.8/1.0 and leaving 0.2 + 0.2 in your wallet, it will spend 0.2+1.0 and return change of 0.4

<o​frnxmr:xmr.mx> Not doing so would result in a lot of dust

<o​frnxmr:xmr.mx> Consolidating many dust inputs at once, especially if said dust comprises of change outputs, is a privacy nightmare

<c​haser:monero.social> thanks, I didn't know about this behavior.

<c​haser:monero.social> besides that, consolidating in as many steps as possible (so only 2 inputs) gives you the most obfuscation. also, 2-in/2-out (the other output would be a dummy in our case) is IIRC the 2nd most frequent transaction shape on the blockchain, so it won't stick out of the crowd.

<v​tnerd:monero.social> wallet2 consolidates like that? I need to recheck the algorithm, my lwsf spend algorithm definitely doesn't do this

<v​tnerd:monero.social> Does it prefer to 2in/2out then, to slowly consolidate? I don't recall btc wallets doing this either, but it's likely do fees and privacy nightmare of consolidating

<v​tnerd:monero.social> *due to

<o​frnxmr:xmr.mx> Yeah

<v​tnerd:monero.social> Something to update in lwsf then, otherwise my implementation was looking good