00:17:54 this is my attempt at a diagram https://imgur.com/a/FX8KN1j cc: sgp_ 00:26:30 ;/ 00:26:59 (that was accidental typing, not a smilie) 00:52:51 knaccc: how do you know which set of subaddresses to select from? Ideally the exchange would use one subaddress per user 00:54:40 sgp_ the hash is just a simple hash of the subaddress. so alongside every output in every transaction (involving exchanges or otherwise), the hash that appears corresponds to whatever subaddress the recipient asked for funds to be sent to 00:55:12 and all tx senders, including exchanges, must use the correct hash, or wallets will not notice the transaction 00:55:39 because wallets can now directly look for hashes matching wallet subaddresses, instead of doing heavy-ECDH scanning 00:56:20 cc moneromooo - i think what I just typed addresses the question you just posted to github? please let me know if it doesn't answer your question and i've misunderstood 00:59:00 (that was accidental typing, not a smilie) <---- its a funny emoticon to throw after posting a link for this :) im getting a good chuckle. 00:59:12 :) 01:01:06 It does, but it presupposes honest adversaries. 01:01:39 If an exchange wants to do this, you'll get lots of people asking for patches to recognize those outputs, since they were sent to the wallet. 01:02:01 Not sure it'd get done since an exhcange would not gain that much from it though. 01:02:36 The first paragraph (the question) was not addressed though, just the second one. 01:03:43 sorry knaccc , that figure didn't do it for me :( but EABE makes my head hurt. i need to go prime myself on it again 01:04:14 Assuming I understand your technique, I think that it's mostly pointless if the number of exchanges is high enough compared to the ring size. 01:05:10 If low enough, I see it helping, but whether it overrides the flaws I dunno. 01:05:47 moneromooo ah sorry, i updated the github comment to address the first part 01:06:07 the scheme does not rely on hoping to get outputs from any particular exchange or from any exchange at all 01:06:31 all that matters is that it's not only A's outputs that appear in all 3 branches, but other users' outputs too 01:07:03 That will only be the case if those come from the exchange, no ? 01:07:59 i don't think i understand your question. i hope its clear that these hashes appear in all txs, not just txs sent by exchanges 01:08:22 and this scheme also solves the equivalent of EABE traceability issues in ABC scenarios etc 01:08:35 so exchanges aren't even necessary to think specially about 01:09:03 Well, F is another exchange, and Carol and Dave are F users. 01:09:28 Alice sends to Bob, and looks for grouped outputs. She finds lots of stuff F sent Carol and Dave. She uses those in her ring. 01:10:03 When E receives Bob's monero, it finds lots of A smelling outputs, but also some of C and D. 01:10:13 And... I can see why it doesn't matter actually. 01:10:52 its like trying to bin based on the emergent characteristics of a particular output type 01:11:09 mebbe 01:11:26 yes all that matters is that when A's outputs pop up in all 3 branches, outputs owned by other users pop up per-user in all 3 branches 01:11:28 So... interestingly, if A withdraws from E to a different subaddress every time, it makes Bob stand out more, does it not. 01:11:47 that's correct 01:11:49 Since Carol and Dave will not use A's outputs. 01:12:00 yes, you've totally got it 01:12:33 That's counter intuitive since people will generate addresses to be more private. 01:13:17 it's good that people use a subaddress per-sender 01:13:34 it's a problem if no one receives more than one output to any particular subaddress 01:13:51 But if they keep the same subaddress for multiple withdraws, then if someone learns about one, they can track all others. That's kinda catch 22. 01:14:16 We are currently pushing for one-time use subaddresses for manual payments though, which means this is a breaking UX recommendation 01:14:16 that's correct, there is no forward secrecy 01:14:37 Also I'm worried about change outputs to the same subaddress being used to clearly identify timing 01:15:32 can you elaborate on the that threat sgp_? what could be inferred 01:15:53 I really don't like the fact that if a group puts a donation address up, everyone knows whenever they receive somehting. 01:15:54 Someone uses their subaddress to buy goods from a malicious seller, say for something illegal. Then the same person buys coffee from a cooperating store 01:16:08 moneromooo neither do i. that is a problem. 01:16:10 Would those transactions not be linked based on the change output to the same subaddress? 01:17:06 Oh, that is a good point. Change goes to 0 now. 01:17:33 Afaict, change would connect all transactions to a single subaddress identity 01:17:40 sgp_ you make an interesting point. i think hashes on change outputs will have to be set randomly 01:18:14 At that point the benefit is decreased though from more blocks of subaddresses to choose the decoys from though, no? 01:18:15 yeah that's a very good point 01:18:42 It makes churn pointless too. Which might be good :D 01:19:04 Well, unless churning through a new subaddress every time... 01:19:34 well churn has never been popular because of bloat, and i also did work with either sarang or surae, i can't remember whom now, where it was becoming really obvious that multiple churns could not work because they stood out so clearly on the blockchain and were therefore not of any benefit 01:20:10 E send funds to Alice address. Alice sends funds to entity X, n transactions away. Entity X knows all transactions made by Alice. If given to exchange, they tie real identity to all these transactions. X can be any entity on the receiving end of those n transactions 01:20:59 sgp_ is this only if hashes are put on change addresses? 01:21:43 I don't understand fully, but if there is some linked grouping known to a counterparty 01:22:09 when you say "n transactions away", you mean it's EABCX or something like that? 01:22:25 and how does X know about all transactions made by Alice? 01:22:40 Alice is never transacting with X 01:22:41 Here's an example: 01:22:52 E -> A 01:23:09 A -> B,C,D,E,F,...X 01:23:58 so you're not saying A->B->C->D.... etc, you're saying A->B, A->C, etc? 01:23:58 E already knows all transactions sent by A without cooperation, if sent to the same subaddress 01:24:12 Yeah A->B, A->C, ... 01:24:24 ok so A->X happens too? 01:24:27 dircetly 01:24:30 Yes 01:24:34 ok 01:25:17 so yes you are talking about the change problem. this is easily fixed by A never putting that hash on change outputs A sends to herself 01:25:17 Let's say A->X is for a suspicious purchase where X is LE 01:25:36 X asks for the real identity of A from E 01:26:09 right, but how does X know A transacted with E? 01:26:35 and if that is known, how does X know that A transacted with both E and X? 01:26:59 If the change back to A and the transaction from E to A went to the same grouped, identifiable address 01:27:52 right, so the hash on change going back during A->B and A->C and A->X etc cannot be the same hash each time 01:27:59 or those txs will be linked 01:28:20 Yes it must always be different and unlinkable or else you learn the full list of someone's transactions 01:28:47 this is an easily solvable problem, all that needs to be done is to use hash(a || change one-time pubkey) instead for the hash on change 01:29:28 although that does break the bloom filter stuff a little 01:30:05 Suppose I'm B now and want to hide my association with A, who is not an exchange but is a malicious party 01:30:24 so this is a totally different scenario, right? 01:30:32 Yeah 01:30:55 How does B select the decoy outputs if they can't identify which outputs are related to A 01:32:08 so this is with A sending funds to B? 01:32:31 Suppose for simplicity that A sends funds to B 3 times 01:33:14 right, so the first time A->B happens, A chooses 10 decoys, each from a different per-subaddress bucket 01:33:44 and the subsequent times A->B happens, A chooses further decoys from each of those buckets used in the prior transaction 01:34:00 Okay, I think I'm with you so far 01:34:37 there is a problem, which is if the wallet is sending to B using a different subaddress owned by B each time, then the wallet won't realize 01:34:42 and so won't bucket properly 01:34:48 When B wants to send, what bucket(s) do they choose from? 01:35:20 it works exactly the same way again 01:35:22 Suppose A send 3 times to B, each to the same subaddress 01:35:56 Then what buckets does B select? 01:36:43 as a quick side-note, it doesn't acutally matter if B does anything clever at all or not when sending funds on to cash out at E 01:36:56 but B will just do the same thing A did 01:37:15 How can B identify A's buckets? 01:37:21 which is that on every tx from B to any particular destination, it will choose decoys from buckets 01:37:29 B doesn't care about A's buckets 01:37:34 that's not B's concern 01:37:40 just like A didn't care about E's buckets 01:37:56 assuming A got outputs in the first place by purchasing them from E 01:37:57 Okay, maybe I had the selection backwards in my head then one sec 01:45:56 knaccc I'm still not getting it. Can you try explaining the bucket selection from scratch again? Do I select the groupings arbitrarily or from someone I'm related to? 01:47:55 sure, so here are the steps: 01:48:07 1. you want to send funds to X 01:48:19 it doesn't matter who sent anything to you in the past. that's not relevant 01:48:44 2. you search the blockchain for a random bucket that contains at least a few outputs 01:49:05 3. you pick 10 such buckets at random, and pick an output from each of those buckets as a decoy 01:49:27 4. the next time you send to X, you check which buckets you had previously randomly picked from 01:49:59 and you pick from each of those buckets a decoy which you have not previously used as a decoy 01:50:01 that's it. 01:50:49 i should clarify: 01:51:07 s/you check which buckets you had previously randomly picked from/you check which buckets you had previously randomly picked from when sending to X 01:51:07 knaccc meant to say: 4. the next time you send to X, you check which buckets you had previously randomly picked from when sending to X 01:54:33 Okay, I think I get it now 01:54:55 You're trying to find another possible identity 01:55:46 Would this setup not encourage users to act selfishly and not make buckets whenever possible? 01:57:16 Buckets would only be created if someone resent to the same subaddress correct? 02:00:03 Also as a separate issue, when sending one transaction each to two addresses, how do you know both addresses are controlled by different people? You wouldn't know to select from buckets 02:00:26 *from the same buckets 02:01:06 And if you are always selecting from the same buckets for all transactions regardless, then all your transactions are trivially grouped together by any outside observers 02:01:32 > act selfishly and not make buckets < it's possible, but recoding wallets isn't easy 02:01:49 > how do you know both addresses are controlled by different people < you don't. this is a problem 02:02:34 and that last point is very good, i'll think about it 02:03:05 Last point is only relevant if you expect to always select from the same buckets for all transactions you send 02:04:05 Multiple transactions to the same subaddress will already be grouped due to the nature of the design 02:04:42 If someone transacts with one entity frequently, the change outputs are quite obvious too then 02:04:48 yes, but that would be what you'd want to do if you wanted to be sure you were never missing situations when the wallet thinks it is sending to two different entities, but they're actually the same entitiy asking for payment via different subaddressses each time 02:05:53 and i'm pondering the implications of always picking from the same buckets over and over 02:06:19 Conditionally dropping linkability will have a bunch of weird complications like these I imagine 02:07:43 Suppose this other extreme example: 02:07:54 E has only one customer, A 02:08:15 E -> A x3 02:09:33 Hmm, I need to flesh out that example a bit more before I write it down actually 02:10:09 But my thought process is: can E reliably eliminate buckets? 02:11:00 i don't understand what you mean by eliminate them 02:11:32 Heuristically eliminate all decoys related to specific buckets 02:11:33 you mean consider them not likely decoys simply beacuse they are not customers of E? 02:11:50 Yeah that was my first line of thinking, but I need to think about it more 02:11:51 i don't think so. none of this requires exchanges to be large or small 02:12:19 and works in non-exchange scenarios to prevent ABC issues if C is hacked (allowing A to see if B is transacting with C) 02:13:48 Different thought: could attackers increase the likelihood of their outputs being selected as decoys by making a ton of buckets, thus increasing their selection chances easier than spamming outputs? 02:14:08 Back to MRL 1 and 4 😎 02:14:26 yes, and that's the same as the problem of choosing decoys in general 02:14:59 True but it's exacerbated no? Since exchange deposits, mining pool payouts, etc would be 1 selection per user, not 1 selection per output 02:16:37 Maybe you could weight the bucket selection chance by the number outputs in it instead of treating all buckets as equal 02:16:49 i think in both cases it's still a case of proportion spammed that determines if they can get you that way, i may be wrong 02:17:03 oh i see, yes perhaps 02:19:11 I think with current ringsizes, there definitely is a way to conditionally sacrifice linkability to improve traceability for a net benefit, but damn it's hard to weigh those things 02:22:06 I dare guess the greatest chance of a net positive sweet spot is by losing a *tiny* bit of linkability 02:22:28 But wow would that increase the scope of Breaking Monero lmao 02:22:49 Thanks for the conversation knaccc! 02:29:28 sgp_ thank you for brainstorming it. my hope is that this could spark thoughts and it helps find the eventual solution 02:32:45 knaccc: I support all crazy ideas :) Did you see this slightly less sweeping idea for public wallets like mining pools? https://github.com/monero-project/monero/issues/5222 02:45:54 oh i missed that, thanks, will read 02:56:02 i wonder if fake inputs would fix this 02:59:31 probably not. because E would see A making a transaction to B, and so E could see E's output being used as an input, and now there's just another random (false) input. B then uses A's output as an input + some false input and sends back to E. 03:01:20 still a loop, and E would know that A is actually spending that output... yeah, not much different than if A combined E's output with another of its inputs to make a transaction 03:02:51 ugh this nomenclature is so cumbersome 03:11:13 Since the scheme is voluntary and people will normally use a subaddres per sender, the wallet could hash the subaddress *and* the sending wallet secret key. This makes the "locate donations to the EFF" impossible, while still allowing matching sends to the same subaddress by a blockchain observer. 03:11:20 * moneromooo goes back to sleep 10:19:40 Also, if change gets random tags due to the issue sgp mentioned, then if you see grouped outputs, you now know they aren't change. So change would have to *sometimes* reuse a tag. 11:56:10 Change would hide among outputs sent to single-use stealth addresses though, so I wonder how much that matters in practice. It definitely could matter 12:43:04 moneromooo > the wallet could hash the subaddress *and* the sending wallet secret key < whoa, i think that might be a really good idea 12:44:05 because as you point out, it's supposed to be a subaddress-per-sender anyway 12:44:20 so there is no loss when limiting the bucket in that manner 12:44:38 It definitely breaks fast scan and janus though. 12:44:56 true 12:46:36 i think the biggest showstopper at the moment could be what sgp_ came up with yesterday, which is that the wallet won't know if you're sending to the same merchant via different subaddresses, or to different merchants via different subaddresses 12:47:36 and it pains me to type this, but maybe the answer to that is to recommend subaddresses for normal people, and integrated addressses/integrated subaddresses for merchants 12:48:19 i can't believe i just typed that. this is messy. 12:49:04 and it feels a bit clunky to ask the user if an outgoing payment is to a merchant they've paid before 12:49:31 so the cleanest way to handle this is to consider the implications of having buckets that are used for all outgoing txs 12:49:45 and then have those buckets rotated in and out over time 12:50:08 and now the wallet doesn't need to know whether it's sending more outputs to the same entity or not 12:55:01 i think what i just wrote might work. it was already the case that merchants could have kept a note of all purchaser-change-addresses they observed during incoming transactions to the merchant, and then compared notes with other merchants to see if any of those change outputs were spent with other merchants 12:55:25 s/purchaser-change-addresses/purchaser-change-outputs 12:55:25 knaccc meant to say: i think what i just wrote might work. it was already the case that merchants could have kept a note of all purchaser-change-outputs they observed during incoming transactions to the merchant, and then compared notes with other merchants to see if any of those change outputs were spent with other merchants 13:30:13 just make a consensus rule so that exchanges need to pinky promise to share their data cleanly, but in a way no one else can :p 16:19:16 What's the most clear way to share CLSAG timing data? 16:19:22 Signatures only? Overall transaction estimates? 16:19:31 Range proof batching? No batching? 16:23:26 All of it :D But there was some verging on dishonest hyping of crazy speed improvements based on batching 64 txes or so recently, so should be careful how people use the data. 16:24:09 I've presented batch results before 16:24:37 Sure. But IIRC someone took the best number possible and threw it out to the masses. 16:24:52 Having numbers for all interesting cases is good. 16:25:14 Oh, was this for the BP improvement? 16:25:15 I might be wrong. My memory's hazy here. 16:25:21 Could be. 16:25:27 I had put a few batch examples into the PR, but they were clearly marked as such 16:25:28 Felt like shitcoin time. 16:26:06 For the blog post, I can list timing for CLSAG+BP with no batching, and then note that during sync, the improvement is better because of batching 16:26:11 That seems fair and accurate 16:26:21 Sounds good to me. 16:26:26 For a single 2-2 transaction, CLSAG+BP verification improvement is 10% 16:26:29 just signature is 20% 16:26:42 so you asymptotically approach something closer to 20% with higher batching 16:27:06 Most people will be interested in the whole tx verification really. Which is... annoying to get in monero. 16:27:17 Yeah 16:27:24 I count signature verification, balance check, and range proof 16:27:27 Which are the heavy hitters 16:27:50 and I note that YMMV 16:28:32 Oh even better, I can note that signature speedup is 20%, with at least 10% speedup for transactions as a whole 16:28:45 That doesn't downplay CLSAG's improvements, but also gives some better real-world estimates 16:30:07 Blog post draft: https://gist.github.com/SarangNoether/e7bc586d0efd89f74d29b62cc372eeb4 16:34:05 fwiw, I have typically used the 20% figure if someone asked about the relative improvements 16:34:33 20% is accurate for signatures along 16:34:34 *alone 16:34:35 Looks good. But uses ! for effect, which amused me. 16:34:51 I'm pretty sparing with exclamation marks :) 16:34:56 Never get to use them in formal papers 16:35:18 dEBRUYNE: for signatures alone, space is ~50%, time is ~20% 16:35:28 For overall 2-2 transactions, space is ~25%, time is ~10% 16:35:36 time improves with range proof batching 16:36:12 FWIW, I consider the size improvements to be the bigger deal 16:36:20 timing improvements are a nice benefit 16:36:28 (and depend on some optimizations that I did) 16:36:34 Ok, thanks 16:39:05 moneromooo: now you have me questioning the excitement of my punctuation... 16:39:08 bah 16:39:50 Sorry. I guess it's fine for blog post. 16:40:03 heh 16:41:10 I've got an overflow of hate for hype and dishonest arguments of late and I may be overmatching, you can ignore me ^_^