06:28:57 <sech1> Rucknium I think this is your domain, I can't come the definite conclusion: https://github.com/monero-project/monero/pull/8047
06:38:15 <Rucknium[m]> sech1: I will examine it. Thank you for bringing it to my attention.
07:02:15 <Rucknium[m]> AEON:
07:02:15 <Rucknium[m]> >We choose to stick with ring size 3 until a convincing evidence against it is found.
07:02:15 <Rucknium[m]> Uh oh...
08:02:25 <jberman[m]> 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: https://github.com/monero-project/monero/blob/eec3a6014cf906845491e4834d545bcbed6fa69a/src/cryptonote_core/tx_sanity_check.cpp#L87-L91
08:02:44 <jberman[m]> 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
08:02:44 <jberman[m]> maximize the chances your output gets picked up as a decoy by other people
08:17:25 <jberman[m]> I think this scenario makes it a bit clearer...... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4cbf48455641e0ee679d8d8817082588ca35430a)
08:25:11 <Rucknium[m]> I commented my initial thoughts:
08:25:11 <Rucknium[m]> https://github.com/monero-project/monero/pull/8047#issuecomment-963915762
08:30:30 <Rucknium[m]> 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.
08:31:33 <jberman[m]> 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
08:32:05 <jberman[m]> Even easier to just assume ring size of 2, and assume you're constructing a tx with 2 inputs
08:32:30 <jberman[m]> In theory allowing duplicates could reveal real outputs spent:
08:32:31 <jberman[m]> Ring 1: {0,1}
08:32:31 <jberman[m]> Ring 2: {0,1}
08:32:31 <jberman[m]> This reveals that you spent outputs 0 and 1 in the tx
08:33:38 <jberman[m]> although you don't know which ring spent which output
10:18:02 <monerobull[m]> Rucknium do you think we are getting flooded again?
10:48:25 <aberdeenik[m]> I have an interesting research question:  can we also hide timestamps in monero such that we can even anonymise the transaction dates and time?
10:51:33 <aberdeenik[m]> Is this something which can be implemented? Say like monero have it's own cryptic date time system.
10:52:47 <monerobull[m]> <monerobull[m]> "Rucknium do you think we are..." <- After looking into it, zCash also had an increase in transactions, it could be organic
10:57:09 <aberdeenik[m]> 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.
10:58:50 <monerobull[m]> This is effectively achieved with ring signatures, no?
10:58:57 <carrington[m]> As stated elsewhere, only blocks have timestamps and not individual transactions
11:28:47 <aberdeenik[m]> <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. 
11:29:30 <aberdeenik[m]> As the block time is only 2 min we can determine the timestamp of transactions easily
11:33:13 <aberdeenik[m]> 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. 
11:35:27 <atomfried[m]> just go on a boating trip with your private keys, strange things happen on boats with wallets and private keys i heard
11:40:28 <carrington[m]> 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
11:40:57 <carrington[m]> I'm not sure what you're suggesting makes sense anyway
11:45:07 <aberdeenik[m]> carrington[m]: In audit, full chain needs to be established. You can't just for sake of it transfer to another wallet.
11:45:19 <carrington[m]> 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
11:45:58 <aberdeenik[m]> carrington[m]: Yes, even making that extrapolation impossible is the ask
11:46:32 <carrington[m]> Big ask
11:46:37 <aberdeenik[m]> Instead of a chain structure it can be a non chain random structure?
11:47:33 <carrington[m]> If you could sketch out how something like that would actually work I'll give it a ponder
11:50:43 <aberdeenik[m]> 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
11:51:32 <aberdeenik[m]> So hiding  block height too
11:53:44 <carrington[m]> 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. 
12:02:51 <aberdeenik[m]> <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
12:06:30 <carrington[m]> 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.
12:16:29 <monerobull[m]> <aberdeenik[m]> "I understand but blocks should..." <- Yeah, let's just not chain the blocks in our blockchain
12:33:57 <Lyza> 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
12:37:36 <Lyza> 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
12:54:52 <aberdeenik[m]> <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
12:56:43 <aberdeenik[m]> 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
12:56:43 <aberdeenik[m]>  
12:57:29 <aberdeenik[m]> It may also increase storage efficiency 
12:57:56 <aberdeenik[m]> As the the nodes can alternate in what amount of blocks it stores.
13:25:11 <UkoeHB> 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).
13:36:13 <Lyza> <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'
13:36:28 <Lyza> are the penalties just very bad?
13:37:12 <Lyza> not clear how to calculate the difference in effective anonymity set that is
13:37:59 <carrington[m]> 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
13:41:36 <carrington[m]> 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
13:43:02 <carrington[m]> Maybe with 100+ size rings it makes sense to put all real spent outputs in one ring together
14:00:10 <Lyza> 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
14:07:39 <UkoeHB> iirc you get 1/2 the number of decoys per real spend when using a shared ring
14:10:04 <carrington[m]> UkoeHB  do you mean for a given transaction size? Or verification time?
14:13:55 <UkoeHB> verification time
14:14:04 <UkoeHB> tx size is also a bit bigger I think
14:14:31 <UkoeHB> on a per-real-spend-per-decoy basis
14:53:51 <Rucknium[m]> 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?
14:53:51 <Rucknium[m]> https://github.com/monero-project/monero/pull/8047
15:51:46 <yanmaani> Has there been any research done on homomorphic encryption for chain sync?
15:52:23 <yanmaani> like, "take all the transactions, decrypt them with my key, if match then add to list"
17:06:40 <aberdeenik[m]> > <@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?
17:06:40 <aberdeenik[m]> > https://github.com/monero-project/monero/pull/8047
17:06:40 <aberdeenik[m]> 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.
17:14:58 <Rucknium[m]> aberdeenik: Here is a decent summary:
17:14:58 <Rucknium[m]> https://monero.stackexchange.com/questions/4565/what-is-churning
17:32:20 <aberdeenik[m]> > <@rucknium:monero.social> aberdeenik: Here is a decent summary:
17:32:20 <aberdeenik[m]> > https://monero.stackexchange.com/questions/4565/what-is-churning
17:32:20 <aberdeenik[m]> 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.
17:35:38 <Rucknium[m]> aberdeenik: neptune has some great tools. You can talk to them. Their tools are available here:
17:35:38 <Rucknium[m]> https://github.com/neptuneresearch
17:37:11 <Rucknium[m]> 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.
17:37:46 <Rucknium[m]> An internet search of Monero and churning will pull up some leads, I think.
17:37:59 <wfaressuissia1> not understood well by who ?
17:39:18 <Rucknium[m]> wfaressuissia[m]: Anyone, as far as I know. It is an open research problem.
17:40:36 <Rucknium[m]> MRL has worked on it in the past, but I do not think any definitive conclusions were reached.
17:45:58 <wfaressuissia1> * ... by whom