Rucknium I think this is your domain, I can't come the definite conclusion: monero-project/monero #8047

sech1: I will examine it. Thank you for bringing it to my attention.

AEON:

>We choose to stick with ring size 3 until a convincing evidence against it is found.

Uh oh...

It's not a bug in that it is intended behavior, you can see the sanity check intentionally allows a small margin of duplicates here: github.com/monero-project/monero/bl…te_core/tx_sanity_check.cpp#L87-L91

My inclination is that it makes sense to not allow duplicates in order to increase the anon set though. Allowing duplicates marginally increases the chances you re-select your own output as a decoy in your own transaction, and reduces the chances your output can be picked up as a decoy in someone else's transaction (since others are also marginally more likely to re-select their own outputs as decoys). Ideally you'd want to

maximize the chances your output gets picked up as a decoy by other people

I think this scenario makes it a bit clearer...... (full message at libera.ems.host/_matrix/media/r0/do…8455641e0ee679d8d8817082588ca35430a)

I commented my initial thoughts:

jberman: My sense is that you are saying that the current behavior is probably not a threat to user privacy per se, but that user privacy might be enhanced somewhat if we change things. I think it would be good to get a sense of how often these "collisions" actually happen in practice, as I mentioned in my GitHub comment.

Ya I think technically it's the correct thing to do, but it's not a huge deal with ring size 11 I don't think. And it's definitely a bigger deal with smaller ring sizes and fewer transactions like you mention in your comment

Even easier to just assume ring size of 2, and assume you're constructing a tx with 2 inputs

In theory allowing duplicates could reveal real outputs spent:

Ring 1: {0,1}

Ring 2: {0,1}

This reveals that you spent outputs 0 and 1 in the tx

although you don't know which ring spent which output

Rucknium do you think we are getting flooded again?

I have an interesting research question: can we also hide timestamps in monero such that we can even anonymise the transaction dates and time?

Is this something which can be implemented? Say like monero have it's own cryptic date time system.

<monerobull[m]> "Rucknium do you think we are..." <- After looking into it, zCash also had an increase in transactions, it could be organic

This is very important when states try to regulate XMR ,hiding the timestamps will make it resistant to regulations too eg : can't compute tax liability as we can't determine when the xmr was recieved. There are many more such advantages and will make it truly anonymous.

This is effectively achieved with ring signatures, no?

As stated elsewhere, only blocks have timestamps and not individual transactions

<carrington[m]> "As stated elsewhere, only blocks..." <- Yes, but even that can be anonymised. When I restored a wallet I could see the transaction timestamps.

As the block time is only 2 min we can determine the timestamp of transactions easily

Eg: A plausible use case is when some regulations come which make it mandatory to submit private keys for tax audit, in which case even block timestamps will give away a lot of information.

just go on a boating trip with your private keys, strange things happen on boats with wallets and private keys i heard

If you are being audited, surely you want them to see the timestamps? If you don't, you can just send your relevant balance to a fresh wallet and share those view keys

I'm not sure what you're suggesting makes sense anyway

carrington[m]: In audit, full chain needs to be established. You can't just for sake of it transfer to another wallet.

Transactions can inherently only be referenced by specifying which block they are in and blocks are every 2 mins. So even if timestamps on blocks were obscured, you could work out a transaction time by simple extrapolation

carrington[m]: Yes, even making that extrapolation impossible is the ask

Big ask

Instead of a chain structure it can be a non chain random structure?

If you could sketch out how something like that would actually work I'll give it a ponder

carrington[m]: Instead of having a blockchain structure we can have a block-set structure such that blocks don't stack and there is no order but a set of blocks connected randomly

So hiding block height too

I think any effort in that direction would suffer from the same issue as MimbleWimble. That is that you might obscure the details on chain, but a network observer can easily watch what order blocks appear on the network and record their sequential order.

<carrington[m]> "I think any effort in that..." <- I understand but blocks should not be chained and every node should not store all the blocks in the set , use some compression and redundancies to make it difficult for any one observer

I think this would take monumental effort (if it's even theoretically possible) for a very small gain which would be lost as soon as a single observer recorded the actual network timestamps. They would of course share the sequential list with governments and chain analysis.

<aberdeenik[m]> "I understand but blocks should..." <- Yeah, let's just not chain the blocks in our blockchain

When spending multiple inputs, I'm wondering if it would be possible to construct ring signatures so that instead of 2 rings where you have 1 of N as real spends, construct a single ring that has 2 of 2N

seems relevant to 8047 and just in general seems like it would reveal less info when consolidating inputs. it also seems like low hanging fruit so I'm guessing it can't work that way

<carrington[m]> "I think this would take monument..." <- Network timestamps of one observer won't help to recover the chain , as here the assumption would be that each node will not store all the blocks and only after a random amount of time the blocks be sync by a signature hash

Advancements in error correcting codes and compression can be leveraged to ensure that it is not required for all nodes to store the full block set

 

It may also increase storage efficiency

As the the nodes can alternate in what amount of blocks it stores.

Lyza: It can be done, but at loss of efficiency (your average number of decoys per real-spend will be lower for size/verification costs comparable to split rings).

<UkoeHB> I wonder how that looks with numbers, especially for Seraphis, but it's not immediately clear to me how to calculate the effective difference between '1 in N x times' and 'x in xN'

are the penalties just very bad?

not clear how to calculate the difference in effective anonymity set that is

aberdeenik the blocks still need to be broadcast to the whole network. At that point, a node just has to listen and incrementally number the blocks it sees being broadcast

The trouble with multiple rings in one transaction is it opens more windows for timing and recombination analysis, so the impact is hard to quantify

Maybe with 100+ size rings it makes sense to put all real spent outputs in one ring together

the group signature math reveals the number of real spends, yeah? like, I'm assuming you can't make 1 of N and 2 of N look the same on the blockchain

iirc you get 1/2 the number of decoys per real spend when using a shared ring

UkoeHB do you mean for a given transaction size? Or verification time?

verification time

tx size is also a bit bigger I think

on a per-real-spend-per-decoy basis

aberdeenik: Are you going to help us with the data science work? Monero needs analysis of churning, for starters. And you you have thoughts on this issue?

Has there been any research done on homomorphic encryption for chain sync?

like, "take all the transactions, decrypt them with my key, if match then add to list"

> <@rucknium:monero.social> aberdeenik: Are you going to help us with the data science work? Monero needs analysis of churning, for starters. And you you have thoughts on this issue?

> monero-project/monero #8047

What is churning here? Can you elaborate more. Would definitely want to contribute. My interest would lie in anything data science related that would drive monero adoption/popularity or make measurable impact.

aberdeenik: Here is a decent summary:

> <@rucknium:monero.social> aberdeenik: Here is a decent summary:

> monero.stackexchange.com/questions/4565/what-is-churning

Got it and what are the expectations for churn analysis and can you point me to some similar analysis where I can pull the data etc.

aberdeenik: neptune has some great tools. You can talk to them. Their tools are available here:

Churning is not understood well, so there are no "expectations for churn analysis" at this point. The research task is to better understand churning -- its strengths and weaknesses -- so that we can communicate to users the best way to do it, assuming it can help improve privacy.

An internet search of Monero and churning will pull up some leads, I think.

not understood well by who ?

wfaressuissia[m]: Anyone, as far as I know. It is an open research problem.

MRL has worked on it in the past, but I do not think any definitive conclusions were reached.

* ... by whom