04:28:50 <r4v3r23[m]> looking at monerujo's PocketChange feature - is there any privacy benefit (from a protocol perspective) from splitting your balance into X amount of different addresses vs sending X amounts of transaction to the account's primary address?
04:28:51 <r4v3r23[m]> assuming youre able to send to the same address multiple times on a batch spend
04:30:42 <r4v3r23[m]> s/addresses/subaddresses/
05:43:22 <jeffro256[m]> No but there are potential privacy downsides
08:56:07 <valldrac[m]> <jeffro256[m]> "No but there are potential..." <- What downsides? 🤔
09:29:31 <jeffro256[m]> If you split and then recombine (which you don’t really have control of as an end user), then you end up revealing the true spends with a high degree of probability if someone knows they were split from the same place. It’s the same reason why you don’t want to spend from two old outputs in the same transaction
09:33:26 <plowsof11> there are some gui wallets that have added coin control (featherwallet for example) 
11:47:08 <r4v3r23[m]> <jeffro256[m]> "If you split and then recombine..." <- thats an issue when splitting to same address? or splitting in general?
12:13:58 <jeffro256[m]> Anytime you split and recombine, you reveal the true spend with a much greater probability than if you just sent it without splitting
12:14:25 <jeffro256[m]> Recombine in the same transaction especially
12:16:18 <ofrnxmr[m]> Yuppppp
12:17:42 <ofrnxmr[m]> Which is why "pocketchange" is a dangerous feature considerig it also adds a 10/11 output intermeduiry tx. Which is about as rare as you can get. 
12:19:08 <ofrnxmr[m]> With no rules for minimum sizes of outputs. Just takes 1 output and forcefully splits and recombines webs that woukd otherwise be extremely rare
12:23:28 <ofrnxmr[m]> There is 0 positives for privacy from combining outputs.
12:23:29 <ofrnxmr[m]> monero is actually coded to try to use 2 outputs when possible. Which pruvacy harming, its not as absolutely terrible as _never_ using small outputs, accumulating dust, THEN consolidating a whole lot of dust (same as splitting and recombining)
12:25:47 <ofrnxmr[m]> Tldr: monero privacy is not perfect/ monero is not perfectly fungible. 
12:25:47 <ofrnxmr[m]> the easiest way to stand out, is to do anything out of the ordinary. Sebd a 3 out tx, fir example, to yourself 
12:27:21 <ofrnxmr[m]> My suggestion to monerujo and anyone else doing  UX stuff like this, was to use splits in   half and splits in 16. At least then those splits blend in with regular tx volume
12:27:42 <ofrnxmr[m]> Consolidating pn chain is still fingerprintable, but not shooting fish in a barrel
12:29:11 <jeffro256[m]> If the Pocketchange input selection algorithm was prohibited from ever recombining the “bills” within a certain window of time then the vast majority of the privacy downsides would go away.
12:29:38 <ofrnxmr[m]> It uses 10 outs and has no minimum
12:29:50 <ofrnxmr[m]> So you can aplit into 0.0001 or aomething im assuming
12:29:58 <jeffro256[m]> ofrnxmr[m]: The downside of this approach is that you would be unintentionally doing a decoy flood 
12:29:59 <ofrnxmr[m]> Leading to consolidations by default 
12:30:10 <ofrnxmr[m]> jeffro256[m]: No
12:30:13 <ofrnxmr[m]> The opposite
12:30:24 <ofrnxmr[m]> Adding non 2's and 16's is a decoy flood
12:30:43 <ofrnxmr[m]> Splitting in half is a regular tx
12:31:21 <jeffro256[m]> If you’re padding to 16 tx outputs and never intend to use them, other people will select those decoys more on average than if you made fewer tx outs
12:31:29 <ofrnxmr[m]> Not padding
12:32:10 <jeffro256[m]> Like you make the user split it equally among 16, no less ?
12:32:47 <ofrnxmr[m]> yeah, 16 or 2. Anything else is missing from 70+% of rings and is an easy to see moneujo tx
12:33:12 <ofrnxmr[m]> my suggestion included minumum abounts to trigger chabge creation
12:33:55 <r4v3r23[m]> jeffro256[m]: thats how ive been doing it in my wallets
12:34:10 <ofrnxmr[m]> 3 or less outputs in wallet, 1.6*(i change my number)+ xmr requited to trigget a 16 split, 0.6+ for splils in half
12:34:22 <jeffro256[m]> Oh yeah that would be better for anonymity but it makes the UX way way worse. The people who are specifically using PocketChange probably don’t want to be forced to split only between 2 and 16
12:34:33 <ofrnxmr[m]> well thats too bad
12:34:45 <ofrnxmr[m]> Privacy ia more important than 6 spli%a
12:35:01 <ofrnxmr[m]> If youre 3-15 splits you might as well just ualae ltc
12:35:12 <ofrnxmr[m]> Since you just doxxed your tx
12:35:15 <ofrnxmr[m]> And all of the outputs
12:35:31 <jeffro256[m]> The recombination is by far the worst part so they need to make sure they’re mitigating that first
12:35:35 <moneromooo> I actually want to ualee ltc now. Whatever is it.
12:35:55 <moneromooo> Jesus. Of course my line has types. Go me.
12:36:08 <ofrnxmr[m]> ❤️‍🔥
12:36:11 <jeffro256[m]> Types
12:36:20 <moneromooo> Akways.
12:36:41 <jeffro256[m]> No ragrats
12:36:52 <r4v3r23[m]> so what would be the best way to do an output splitting feature to not fuck up privacy?
12:36:55 <ofrnxmr[m]> 😆😆. None at all
12:37:02 <moneromooo> Except for rugrats.
12:37:22 <moneromooo> Sorry, wrong channel, I'll leave.
12:38:17 <ofrnxmr[m]> Raver. Imo one where you dont 
12:38:17 <ofrnxmr[m]> 1. Create more outputs than necess`ry (only trigger when under 3 for regular users)
12:38:17 <ofrnxmr[m]> 2. Only split into outputs of respectable value where they can be used withiut consolidatinfn
12:38:32 <moneromooo> You really only need splitting if you want to send several times in a row quickly. Maybe you can plan to avoid doing it ?
12:38:37 <jeffro256[m]> r4v3r23[m]: Always do a 2 or 16 output tx, and NEVER have more than 1 input (oversimplifying but might as well err on the side of being conservative)
12:39:13 <r4v3r23[m]> jeffro256[m]: so sweep balance > 16 outputs is a no?
12:39:40 <moneromooo> You cannot do this, consensus *should* block those (assuming post-rct).
12:40:10 <moneromooo> Oh wait. You mean using > 16 outs as inputs ? If so, ignore my last line.
12:40:38 <r4v3r23[m]> no, i mean taking entire balance and splitting into 16 outputs
12:40:52 <r4v3r23[m]> not sure if there is a way to sweep into a multidest spend
12:41:08 <moneromooo> It's fine, what's not fine is then using more than one of these 16 in a tx.
12:41:46 <jeffro256[m]> Using sweep_all is generally bad for privacy (it’s recombining in the same tx)
12:42:05 <moneromooo> I think there's an old video from sarang describing this, breaking monero. Was a series of video I believe.
12:44:58 <r4v3r23[m]> moneromooo: so splitting is fine, but using any 2 of those outputs together when spending harms privacy
12:45:11 <r4v3r23[m]> which would defeat the point in splitting
12:46:16 <nikg83[m]> moneromooo: https://www.monerooutreach.org/breaking-monero/poisoned-outputs.html
12:46:26 <moneromooo> Yes, mostly, but you can split without issues if two things are true:
12:46:40 <moneromooo> - you tell your wallet not to use a second input if unnecessary
12:47:19 <moneromooo> - oh boy, that one's a bit complicated
12:47:33 <moneromooo> So that second one is, roughly:
12:47:51 <moneromooo> You want to always send less than the highest output in your wallet
12:48:06 <moneromooo> You need to tell your wallet to confirm before actually sending
12:48:10 <nikg83[m]> moneromooo: Yep it’s one from same split, don’t use that output 
12:48:24 <moneromooo> If the wallet tries to use more than one input, cancel, exit wallet, remove shared ring db, try again until it uses one
12:48:31 <moneromooo> Easy, right ? :)
12:48:47 <r4v3r23[m]> yikes
12:48:52 <moneromooo> I guess there should be a wallet set called "try to use a single input if you can".
12:50:00 <jeffro256[m]> Also if you split into a tx with the number of outputs not equal to 2 or 16, like ofrnxmr mentioned, your tx will potentially stick out as a pocket change tx 
12:50:24 <r4v3r23[m]> right, i already knew about the 16 outputs bit
12:50:47 <r4v3r23[m]> so split into 16 outs, and make sure never to merge those 16 outputs
12:51:06 <r4v3r23[m]> each of those 16 should be considered its own account/wallet
12:51:17 <moneromooo> It should be less of an issue with ring size 256, though how much better is hard to say.
12:51:25 <ofrnxmr[m]> In my brainstorming the best way i could think of from a wallet ux perspctive it to set sane minimums 
12:51:26 <jeffro256[m]> Yes 👍🏻
12:51:53 <r4v3r23[m]> what if i spend 2 outputs separately and get change, can those 2 now merge?
12:52:01 <ofrnxmr[m]> The increased ring size helps to ensure (i think) that you accidentally inckude your own outputs, even when youre not using them
12:52:17 <ofrnxmr[m]> Leading the plauaible deniability
12:52:56 <jeffro256[m]> r4v3r23[m]: You should avoid that
12:52:56 <moneromooo> Yes, they can merge too. That's somewhat less of a dead giveaway.
12:52:58 <ofrnxmr[m]> But if you include your own in a 16, it looks like p2pool.observer's consolidation trackinf
12:53:09 <moneromooo> I think I have a patch that tries to avoid this actually...
12:53:16 <jeffro256[m]> moneromooo: It’s less but still statistically higher of a chance of it being you 
12:53:39 <Rucknium[m]> The ten block lock, which tries to avoid privacy problems by preventing transaction invalidation when a deep re-org happens, ironically may make privacy worse by encouraging users and wallet devs to do things like PocketChange.
12:54:02 <moneromooo> Hmm, I PRed it about a year ago...
12:54:31 <jeffro256[m]> Damned if you do damned if you don’t
12:55:02 <ofrnxmr[m]> Well. If the 3 input minimum is set ,like i described, then pocketchange would onky be triggered on occasion and most times would be splitting in half. For people with large balances, or large inputs, it shouldnt be an issue
12:55:35 <moneromooo> https://github.com/monero-project/monero/pull/8424   <-- if someone with a clue wants to look at it, it's a "free" privacy improvement
12:55:58 <jeffro256[m]> With Seraphis, we can construct transaction with delegated membership proofs so we can string these pocket change sends to the same place over time in different transactions which would be the best of both worlds
12:55:58 <ofrnxmr[m]> xFFC @xFFC:libera.chat:  :)?
12:56:20 <jeffro256[m]> moneromooo: I’ll look at it within the next couple of days !!
12:56:25 <moneromooo> Thank you.
12:56:47 <ofrnxmr[m]> Thanks jeffrro and mooo
12:56:58 <moneromooo> There's more medium hanging fruit to be had this way as well if you (or someone else) want to.
12:58:31 <r4v3r23[m]> so what would be the best way to split your wallets balance into different outputs without harming privacy?
12:58:50 <r4v3r23[m]> if a self-batch spend is that bad
12:59:06 <xFFC[m]> ofrnxmr[m]: Hey, what’s up? Let me take a look at discussion 
12:59:26 <moneromooo> Why do you want to split your wallets balance into different outputs ?
13:00:00 <Rucknium[m]> One small saving grace of PocketChange is that the outputs are self-spends. The real spends of that self-spend might be revealed by combing outputs in a later tx, but an adversary is actually interested in an output that the user received from somewhere else. That output is one step removed.
13:00:00 <r4v3r23[m]> to not lock the entire (or most) of wallet balance as change
13:01:00 <moneromooo> Why do you want to not lock the entire (or most) of wallet balance as change ?
13:01:18 <moneromooo> (I'm not being a smartarse here, just trying to see the root reason)
13:01:22 <r4v3r23[m]> in order to spend in succession
13:01:32 <moneromooo> Why do you want to spend in succession ?
13:02:22 <r4v3r23[m]> sometimes i need to. 20 minutes is a long time when spending IRL
13:03:03 <r4v3r23[m]> pocketchange is obviously trying to solve a monero UX problem
13:03:24 <moneromooo> A possible way to mitigate might be to add a function in monero that splits to different accounts.
13:03:57 <moneromooo> Then you're sure you won't re-merge later (except as fake outs, which will have the correct probability).
13:05:17 <r4v3r23[m]> ok so looks like splitting is a no-go
13:05:20 <moneromooo> Maybe... changing major:minor system to be... major on 24 bits, medium on 8, minor on 32.
13:05:27 <moneromooo> It should be transparent.
13:05:40 <moneromooo> Then the new split sends to same major, but different mediums.
13:05:58 <r4v3r23[m]> and is there any harm in selecting the specific output to pay from (like in feather's coins section) vs letting the wallet decide?
13:06:03 <moneromooo> And the wallet will consider relatedness of same medium to, say, 0.95.
13:06:16 <moneromooo> That should ensure the wallet will never re-merge, except if it must.
13:06:27 <moneromooo> And it shold be transparent to the user.
13:06:36 <moneromooo> ie, it's the same account as far as they're concerned.
13:06:54 <moneromooo> It'd also need the wallet to start trying to use one out if it can.
13:07:50 <r4v3r23[m]> say i have a 2.1 XMR output and a .34 XMR outputs, and i know my next purchase is less than 0.34, so i can manually select that one to spend and keep my 2.1 XMR as available
13:08:17 <moneromooo> It can't do that. It's been requested before, but I'm not sure it doesn't leak info.
13:08:37 <r4v3r23[m]> feather wallet has that option
13:21:35 <seh> Hey does anyone have any good reccomendations to learn about randomx and the bridge to monero source code
13:25:33 <jeffro256[m]> I would go to the RandomX repository and look at the doc files there . Also wdym by “bridge to Monero source code”?
13:26:13 <jeffro256[m]> https://github.com/tevador/RandomX/blob/master/doc/design.md
13:26:28 <jeffro256[m]> There’s other useful docfiles in that directory
13:27:38 <seh> Thanks, I looked through their repository and it went over the algorithim well, I just didn't understand how the hash function directly applies to the monero network, but ill look more into that link maybe I'm just missing sm
13:29:43 <moneromooo> It applies in the same way that double-sha256 (IIRC) applies to bitcoin. You'll probably find more/better info on that.
13:30:05 <moneromooo> It's about brute forcing a preimage.
13:30:19 <moneromooo> Well, a preimage inside a very very large range.
13:35:10 <jeffro256[m]> Put simply, It’s a proof of work hash that’s really difficult to make an ASIC for
13:38:05 <seh> Thanks, I figured it worked like how sha applies to bitcoin but wanted to see where the specific implemention / details can be found
13:38:12 <seh> I'll look into it
14:00:09 <Rucknium[m]> r4v3r23: Here are some suggestions about _decoy selection_ when outputs are combined:  Borggren, N., & Yao, L. (2020). "Correlations of multi-input Monero transactions." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=57
14:00:42 <Rucknium[m]> "We have shown that correlations in the Monero blockchain can be detected and can reveal information associated to the real transaction within a ring. These correlations in future releases of Monero could be removed by adding a copula step to correlate the spoofed transactions as well, but residue of this effect from past transactions would continue to propagate."
14:01:32 <Rucknium[m]> The lead author of that paper was just funded to analyze the EAE attack and churning: https://monerofund.org/projects/eae_attack_and_churning
14:02:30 <moneromooo> What's a copula step ?
14:03:32 <moneromooo> Also, if we know signs that two outputs are related, the wallet could try to select fake outs to generate some of that same signal. Basically for a "I'm Spartacus" effect.
14:03:47 <moneromooo> That might take some non trivial amount of search though.
14:05:37 <Rucknium[m]> I only have passing familiarity with copulas. I think the suggestion is basically to not choose the two decoy sets of two different transactions independently because the real spends are not really independent. Real spends are correlated in time, so have the decoys also correlated in time.
14:06:11 <Rucknium[m]> I mean two different inputs in the same tx*
14:13:44 <Rucknium[m]> I messaged Borggren to see if he could explain the copula step. He would appear here as compdec
14:15:24 <moneromooo> Oh, it was just curiosity, I never saw that word. I have little background knowledge in statistics to make sense of an explanation, I suspect.
14:17:54 <Lyza> re: PocketChange -- are we sure it doesn't avoid recombining outputs? Reading the medium post it says "That way, the coins won’t merge again, and you’ll be ready to spend instantly from all those pockets without waiting the dreadful 20 minutes."
14:17:59 <Lyza> https://anhdres.medium.com/monerujos-pocketchange-what-it-is-and-how-it-works-8e1ea1f7489e
14:18:59 <moneromooo> Whee. If THAT is dreadful, someone's not going to like life.... :D
14:19:57 <Lyza> also it does currently have a minimum size of 0.1 xmr per "pocket"
14:22:31 <Lyza> I hear you moo, people can work around the 20 minutes for the most part, I guess all I would say to that is that monerujo is a *mobile* wallet and has a bit of a different user profile
14:23:17 <ofrnxmr[m]> <Lyza> "re: PocketChange -- are we..." <- Splitting to different sub _addresses_ doesnt avoid mergingc subaccounts does though
14:24:14 <ofrnxmr[m]> And im not sure that 0.1 is a minimum. Looks like its a default
14:24:19 <Lyza> well presumably they programed some custom output selection logic, or maybe it uses accounts on the back end, I'm just pointing out they say it doesn't mix --- is anyone actually in contact with monerujo devs?
14:24:40 <Lyza> 0.1 is definitely the minimu, I checked in the app, I've been using monerujo for awhile
14:25:09 <ofrnxmr[m]> Later in the article it says they do mix
14:25:15 <ofrnxmr[m]> Monerujo 
14:26:01 <Lyza> where?
14:27:53 <ofrnxmr[m]> you could have just one dedicated PocketChange account and not mess with the rest of your other ones
14:29:20 <Lyza> okay so it doesn't sue the 'account' system under the hood to keep them seperate, but that doens't necessarily imply they don't have custom enote selection logic to avoid recombining
14:29:24 <Lyza> use*
14:29:46 <ofrnxmr[m]> The pockets are 10 subaddresses of an account. Can have multiple pocketchange accounts that dont mix, but the change in the pockets must... otherwise how do you spend the pocketchange if say something is 0.11xmr?
14:30:06 <Lyza> well, the simple answer is you woulnd't be able to
14:30:56 <ofrnxmr[m]> that sounds like more of a problem than a solution. I would assume it doesnt work that way
14:31:02 <Lyza> or you'd have to spend it back to a different account and re-merge it manually, perhaps..... all I'm saying is it's ambiguous to me whether monerujo keeps the pockets seperate or not, but it seems to imply they might. guess I could do some testing, but seems easier to just ask the devs
14:32:18 <ofrnxmr[m]> Either way, 3-15 output pocketchange tx are bad privacy layered ontop of bad privacy (assuming you CAN combine these outputs easily)
14:33:04 <ofrnxmr[m]> (10 is even worse than a random 3-15)
14:34:58 <Lyza> well it won't always be 10 but I see what you mean
14:36:11 <ofrnxmr[m]> m2049r was invited to the convo, ill wait to see what he says about their current impl
14:36:49 <Lyza> cool
14:50:49 <compdec[m]> <moneromooo> "Oh, it was just curiosity, I..." <- The idea is simple enough to state at least, draws are made as usual, but then the draws are further transformed by a matrix that corrects for the correlation.  The net result is you have two draws that are both random variables from a distribution, but also possess the correlation.  The theory of Copulas I find really dense, but in practice it is actually pretty easy to implement.  Here
14:50:50 <compdec[m]> gaussian variables https://math.stackexchange.com/questions/446093/generate-correlated-normal-random-variables
14:52:27 <Rucknium[m]> compdec: Thank you :)
14:56:04 <moneromooo> thanks
14:57:09 <moneromooo> It seems counterintuitive at first glance.
15:01:09 <compdec[m]> no problem.  It does seem strange that the draws still look like they came from the original distribution.  It'll probably come up during my current research too at some stage so I would implement something at that stage.  
15:06:05 <Rucknium[m]> After copula transformation, the (theoretical) marginal distributions would be the same but the joint distribution would be different, right?
15:11:43 <compdec[m]> yeah
15:42:15 <Pascal123> hey guys
15:42:21 <Pascal123> how are you doing ?
15:43:36 <Pascal123> Is perhaps one of the core developers here ? :) I m computed a mining blob and it would be very nice if someone could verify it, if it is built correctly.... https://pastebin.com/4t3JLpP7
16:25:58 <moneromooo> cn_deserialize will tell you if it's valid, and will dump the decoded data.
16:26:15 <moneromooo> in src/debug_utilities
16:53:47 <Pascal123> hi moneromoo, ok thank you :)
16:55:52 <Pascal123> but how i know if the merkle tree is correct ??
16:57:38 <moneromooo> monerod will reject your block if not.
17:00:13 <Pascal123> ah ok
17:38:43 <Pascal123> see ya later