01:11:31 wat in the hell is dis, Brandon? https://moneroleaks.xyz/ 01:13:33 spirobel he didn't pay attention to your replies, he instead built a whole site... 08:27:15 low effort fed slop 08:27:18 sad 08:27:26 glowies were a little better in the past 09:01:15 Agree, see "Case studies" list, point 1 and 3, they were already tracking their transparent blockchain coins they used to swap for XMR 09:06:53 Ciphertrace tool had a great reddit post explaining the details on what probably is happening since the annoucement. 09:06:53 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. 10:48:44 It think it z**o kiddies 10:54:35 "Every monero transaction leaks the amount received by the recipient to the sender" lmao 10:57:14 Written by a toddler. This is worse than AI slop 11:17:05 people should stop engaging with him. just mass report and do community notes maybe 11:43:12 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 12:32:54 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 12:33:11 but im no marketing genius 13:36:31 Random thought i guess the only way to battle the "Inflation bug" fud once and for all is to write something like https://www.moneroinflation.com/ in lean4 or coq ... 13:48:50 in rust* 17:09:06 In rust you can still have a faulty implementation ... 17:32:23 Is there any write up or best practices for consolidating multiple outputs? 21:48:36 The Zano team released a response to jhendrix's network privacy research: https://blog.zano.org/team-response-to-zano-network-analysis-report/ 21:48:37 jhendrix's research (Tor browser necessary): http://g7cpug4k6ydyq5dlxrji35xnfq5n5rba3n7holux4tmdsm42ju543tad.onion/ 21:49:00 duvet: I don't know of any solid research about this. 21:50:31 Rather sad, really 21:52:42 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. 21:53:57 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 21:57:07 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 23:14:35 ofrnxmr: what do you mean by "monero prefers to cospend 2 outputs"? 23:16:05 i mean, when selecting outputs to make a tx, monero prefers to spend a whole output before spending a partial one 23:16:29 "monero" = wallets 23:17:34 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 23:18:08 Not doing so would result in a lot of dust 23:19:03 Consolidating many dust inputs at once, especially if said dust comprises of change outputs, is a privacy nightmare 23:24:12 thanks, I didn't know about this behavior. 23:30:20 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. 23:33:35 wallet2 consolidates like that? I need to recheck the algorithm, my lwsf spend algorithm definitely doesn't do this 23:35:25 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 23:35:42 *due to 23:36:16 Yeah 23:37:26 Something to update in lwsf then, otherwise my implementation was looking good