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?

assuming youre able to send to the same address multiple times on a batch spend

s/addresses/subaddresses/

No but there are potential privacy downsides

<jeffro256[m]> "No but there are potential..." <- What downsides? 🤔

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

there are some gui wallets that have added coin control (featherwallet for example)

<jeffro256[m]> "If you split and then recombine..." <- thats an issue when splitting to same address? or splitting in general?

Anytime you split and recombine, you reveal the true spend with a much greater probability than if you just sent it without splitting

Recombine in the same transaction especially

Yuppppp

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.

With no rules for minimum sizes of outputs. Just takes 1 output and forcefully splits and recombines webs that woukd otherwise be extremely rare

There is 0 positives for privacy from combining outputs.

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)

Tldr: monero privacy is not perfect/ monero is not perfectly fungible.

the easiest way to stand out, is to do anything out of the ordinary. Sebd a 3 out tx, fir example, to yourself

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

Consolidating pn chain is still fingerprintable, but not shooting fish in a barrel

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.

It uses 10 outs and has no minimum

So you can aplit into 0.0001 or aomething im assuming

ofrnxmr[m]: The downside of this approach is that you would be unintentionally doing a decoy flood

Leading to consolidations by default

jeffro256[m]: No

The opposite

Adding non 2's and 16's is a decoy flood

Splitting in half is a regular tx

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

Not padding

Like you make the user split it equally among 16, no less ?

yeah, 16 or 2. Anything else is missing from 70+% of rings and is an easy to see moneujo tx

my suggestion included minumum abounts to trigger chabge creation

jeffro256[m]: thats how ive been doing it in my wallets

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

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

well thats too bad

Privacy ia more important than 6 spli%a

If youre 3-15 splits you might as well just ualae ltc

Since you just doxxed your tx

And all of the outputs

The recombination is by far the worst part so they need to make sure they’re mitigating that first

I actually want to ualee ltc now. Whatever is it.

Jesus. Of course my line has types. Go me.

❤️‍🔥

Types

Akways.

No ragrats

so what would be the best way to do an output splitting feature to not fuck up privacy?

😆😆. None at all

Except for rugrats.

Sorry, wrong channel, I'll leave.

Raver. Imo one where you dont

1. Create more outputs than necess`ry (only trigger when under 3 for regular users)

2. Only split into outputs of respectable value where they can be used withiut consolidatinfn

You really only need splitting if you want to send several times in a row quickly. Maybe you can plan to avoid doing it ?

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)

jeffro256[m]: so sweep balance > 16 outputs is a no?

You cannot do this, consensus *should* block those (assuming post-rct).

Oh wait. You mean using > 16 outs as inputs ? If so, ignore my last line.

no, i mean taking entire balance and splitting into 16 outputs

not sure if there is a way to sweep into a multidest spend

It's fine, what's not fine is then using more than one of these 16 in a tx.

Using sweep_all is generally bad for privacy (it’s recombining in the same tx)

I think there's an old video from sarang describing this, breaking monero. Was a series of video I believe.

moneromooo: so splitting is fine, but using any 2 of those outputs together when spending harms privacy

which would defeat the point in splitting

moneromooo: monerooutreach.org/breaking-monero/poisoned-outputs.html

Yes, mostly, but you can split without issues if two things are true:

- you tell your wallet not to use a second input if unnecessary

- oh boy, that one's a bit complicated

So that second one is, roughly:

You want to always send less than the highest output in your wallet

You need to tell your wallet to confirm before actually sending

moneromooo: Yep it’s one from same split, don’t use that output

If the wallet tries to use more than one input, cancel, exit wallet, remove shared ring db, try again until it uses one

Easy, right ? :)

yikes

I guess there should be a wallet set called "try to use a single input if you can".

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

right, i already knew about the 16 outputs bit

so split into 16 outs, and make sure never to merge those 16 outputs

each of those 16 should be considered its own account/wallet

It should be less of an issue with ring size 256, though how much better is hard to say.

In my brainstorming the best way i could think of from a wallet ux perspctive it to set sane minimums

Yes 👍🏻

what if i spend 2 outputs separately and get change, can those 2 now merge?

The increased ring size helps to ensure (i think) that you accidentally inckude your own outputs, even when youre not using them

Leading the plauaible deniability

r4v3r23[m]: You should avoid that

Yes, they can merge too. That's somewhat less of a dead giveaway.

But if you include your own in a 16, it looks like p2pool.observer's consolidation trackinf

I think I have a patch that tries to avoid this actually...

moneromooo: It’s less but still statistically higher of a chance of it being you

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.

Hmm, I PRed it about a year ago...

Damned if you do damned if you don’t

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

monero-project/monero #8424 <-- if someone with a clue wants to look at it, it's a "free" privacy improvement

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

xFFC @xFFC:libera.chat: :)?

moneromooo: I’ll look at it within the next couple of days !!

Thank you.

Thanks jeffrro and mooo

There's more medium hanging fruit to be had this way as well if you (or someone else) want to.

so what would be the best way to split your wallets balance into different outputs without harming privacy?

if a self-batch spend is that bad

ofrnxmr[m]: Hey, what’s up? Let me take a look at discussion

Why do you want to split your wallets balance into different outputs ?

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.

to not lock the entire (or most) of wallet balance as change

Why do you want to not lock the entire (or most) of wallet balance as change ?

(I'm not being a smartarse here, just trying to see the root reason)

in order to spend in succession

Why do you want to spend in succession ?

sometimes i need to. 20 minutes is a long time when spending IRL

pocketchange is obviously trying to solve a monero UX problem

A possible way to mitigate might be to add a function in monero that splits to different accounts.

Then you're sure you won't re-merge later (except as fake outs, which will have the correct probability).

ok so looks like splitting is a no-go

Maybe... changing major:minor system to be... major on 24 bits, medium on 8, minor on 32.

It should be transparent.

Then the new split sends to same major, but different mediums.

and is there any harm in selecting the specific output to pay from (like in feather's coins section) vs letting the wallet decide?

And the wallet will consider relatedness of same medium to, say, 0.95.

That should ensure the wallet will never re-merge, except if it must.

And it shold be transparent to the user.

ie, it's the same account as far as they're concerned.

It'd also need the wallet to start trying to use one out if it can.

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

It can't do that. It's been requested before, but I'm not sure it doesn't leak info.

feather wallet has that option

Hey does anyone have any good reccomendations to learn about randomx and the bridge to monero source code

I would go to the RandomX repository and look at the doc files there . Also wdym by “bridge to Monero source code”?

There’s other useful docfiles in that directory

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

It applies in the same way that double-sha256 (IIRC) applies to bitcoin. You'll probably find more/better info on that.

It's about brute forcing a preimage.

Well, a preimage inside a very very large range.

Put simply, It’s a proof of work hash that’s really difficult to make an ASIC for

Thanks, I figured it worked like how sha applies to bitcoin but wanted to see where the specific implemention / details can be found

I'll look into it

r4v3r23: Here are some suggestions about _decoy selection_ when outputs are combined: Borggren, N., & Yao, L. (2020). "Correlations of multi-input Monero transactions." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=57

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

The lead author of that paper was just funded to analyze the EAE attack and churning: monerofund.org/projects/eae_attack_and_churning

What's a copula step ?

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.

That might take some non trivial amount of search though.

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.

I mean two different inputs in the same tx*

I messaged Borggren to see if he could explain the copula step. He would appear here as compdec

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.

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

Whee. If THAT is dreadful, someone's not going to like life.... :D

also it does currently have a minimum size of 0.1 xmr per "pocket"

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

<Lyza> "re: PocketChange -- are we..." <- Splitting to different sub _addresses_ doesnt avoid mergingc subaccounts does though

And im not sure that 0.1 is a minimum. Looks like its a default

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?

0.1 is definitely the minimu, I checked in the app, I've been using monerujo for awhile

Later in the article it says they do mix

Monerujo

where?

you could have just one dedicated PocketChange account and not mess with the rest of your other ones

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

use*

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?

well, the simple answer is you woulnd't be able to

that sounds like more of a problem than a solution. I would assume it doesnt work that way

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

Either way, 3-15 output pocketchange tx are bad privacy layered ontop of bad privacy (assuming you CAN combine these outputs easily)

(10 is even worse than a random 3-15)

well it won't always be 10 but I see what you mean

m2049r was invited to the convo, ill wait to see what he says about their current impl

cool

<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

gaussian variables math.stackexchange.com/questions/44…-correlated-normal-random-variables

compdec: Thank you :)

thanks

It seems counterintuitive at first glance.

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.

After copula transformation, the (theoretical) marginal distributions would be the same but the joint distribution would be different, right?

yeah

hey guys

how are you doing ?

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.... pastebin.com/4t3JLpP7

cn_deserialize will tell you if it's valid, and will dump the decoded data.

in src/debug_utilities

hi moneromoo, ok thank you :)

but how i know if the merkle tree is correct ??

monerod will reject your block if not.

ah ok

see ya later