02:05:00 is the problem solved with a ringsize 1024 02:05:44 cause sometimes i convince myself it is, but then i think of the iterative thing 02:17:14 we kept coming back to the fundamental problem that your outputs just aren't ever used as decoys much, if at all. <<< i mean if this is the case, i dunno whats gonna augment this besides order of magnitude changes in ringsize 02:18:00 in 2018 there was no triptych or arcturius.... lets do it 02:26:40 What fraction of outputs never showed up in a ring? 02:27:08 (within some arbitrary window) 02:27:43 gingeropolous the problem is, even at ring size 1024, you have tens of millions of outputs to choose from, so getting outputs owned by the same set of users appearing in all 3 branches (in my diagram) is just not going to happen 02:27:58 Isthmus actually i misremembered, most outputs are used 02:28:37 Isthmus https://paste.debian.net/plain/1156115 02:29:07 * Isthmus is pleasantly surprised 02:29:28 so yeah actually 100% coverage is so good there that i wonder if that can be right... 02:29:38 hmm 02:29:44 looks too good to be true 02:30:13 all but 8 out of 27120 were used at least once 02:32:13 it's as if someone pumping monero was running a script to artificially inflate the tx count, knowing that spamming 100k txs only costs $140 12:19:57 now who would do that 12:49:56 Hello all 12:50:05 Looks like a lot of discussion about churn this past weekend 12:50:27 I'll catch up today (but will be away for a few hours for an appointment) 14:00:46 needmoney90: I haven't looked at the numbers, but shouldn't churn behavior be relatively well hidden for a few churns given the relatively hasty selection algo? Maybe not for dozens of churns, and probably not for even >2,3 if done every 10 blocks exactly or something 14:01:26 knaccc: paste expired; can you reshare please? 14:04:54 disregard my earlier comment 14:08:01 what is the difference between the count and chain length numbers? 14:08:51 sgp_ 90-day expiry on this one https://paste.debian.net/plain/1156229 14:09:04 count means nubmer of times an output is referenced by another (in a ring) 14:10:06 chain length means for each output, what is the maximum length of any chain that follows that output (due to other outputs referencing it in a ring, and other outputs referencing the results of those rings, and so on) 14:11:12 knaccc: that's really clear, thanks 14:13:46 sgp_ oops sorry, it may have been clear ,but also wrong :) 14:13:49 it would be sweet if there was a way to extrapolate these with diferent ringsizes using the selection algo 14:13:56 it's the preceeding chain 14:13:57 haha 14:14:16 so you take each output, and you go backwards as far as you can in the chain 14:14:33 so did it reference any outputs, and did those outputs reference outputs, etc 14:15:20 ah, I read it that way anyway haha 14:17:13 one aspect of this proposal, the instant-on, hasn't been commented on: which is whether there is acceptance that monero will hit a wall if it gets 10x the daily tx volume or beyond, because people simply are not going to want to wait 12 hours to sync their wallet each time they start it, and it'll be too much of a hassle to use 14:20:45 instant-on would be transformative for monero 14:28:03 sarang: is that relevant to monero (e.g. for checking incoming txs)? https://twitter.com/hashbreaker/status/1282300847607578625 14:28:13 knaccc: instant-on? 14:28:16 ah no, probably not 14:28:20 hm 14:29:32 not sure, I don't know remember how this this works in monero :D 14:34:55 sgp_ yeah that's one of the biggest upsides - you don't have to expensively scan the blockchain with your wallet if your incoming outputs are tagged with subaddress hashes. so monero wallets can be instant-on, like electrum 14:36:08 if you didn't know about the instant-on thing, maybe you didn't see the github mrl issue? 14:38:36 which issue? 14:39:07 if you can tag outputs, can you tag them with amount encrypted by viewkey, so that view-only wallets can see outgoing txn amounts? 14:43:46 hyc this one, with the diagram explaining iterated-eabe https://github.com/monero-project/research-lab/issues/75 14:43:50 knaccc: I've just had a super busy weekend buying a car and moving haha 14:43:58 oh nice, porsche? 14:44:16 Lmao nah, Kia Forte 14:44:23 lambo or get out 14:44:45 actually that forte looks pretty nice 14:45:31 hyc the purpose of tagging is so that other people can correlate outputs as being owned by the same subaddress 14:45:57 but sure, you could tag with other stuff too 14:46:32 the main thing is you can't rely on a thief tagging it, in order to notice the theft 14:46:56 which is why i think people have not considered something like what you propose 15:01:36 it can be forced by consensus 15:01:53 if the tag is missing or incorrect, reject the tx 15:03:14 The network can't enforce encryption with a key it doesn't know 15:03:24 It can certainly require a tag be present 15:44:04 well, instant on if there's a server doin the work for yah 16:15:01 still not instant-on, you still need to scan all the blocks that are newer than the last time you were online 16:15:14 you're just making the output detection operation faster 16:17:52 yeah afaict "instant-on" is a little bold (maybe it's fine for marketing), but faster is better :) 16:18:23 hard to say that it will be a noticeable improvement for majority of users 16:18:49 everyone with compute access has cheap access to relatively fast CPUs 16:18:56 they don't all necessarily have access to fast internet 16:19:17 the block scan may not be improved at all, if the network was the bottleneck 16:21:36 and frankly, making outputs readily identifiable to 3rd parties seems insane 16:22:53 I agree on the limitations part, but in my experience CPU has always been the bottleneck for syncing 16:23:27 maybe that isn't the case on some high-end desktop CPUs 16:25:42 syncing daemon or wallet? 16:26:21 you're right I was thinking daemon, but I also think this applies for wallet sync? I'm only 75% sure about that one 16:27:10 knaccc wanted to have the wallet tell the daemon "gimme outputs with a tag in the following list". 16:27:32 So the daemon would do the work. And be able to tell even more about the wallet. 16:27:51 And you know people would also trust a stranger's daemon for this. 16:27:52 ohh, didn't realize he moved the entire scan to daemon side 16:27:55 that's also nuts 16:28:14 Not the scan, just a preliminary filter. Also asking for tags that are not yours. 16:28:16 sorry I can't believe anyone is giving serious consideration to any of this 16:28:36 hyc: I think the tradeoffs are too significant personally 16:28:59 OK, back from my appointment 16:29:10 Hooray for healthy eyes 16:29:14 Boo for those eye drops 16:29:49 even the notion of using a 32bit hash as the tag. so you collapse the 128bit key space down to 32 bits. that helps attackers as much as it helps legit wallet owners 18:20:08 hyc i don't think there is an attack on 32-bit hashes that wouldn't also apply to 512-bit hashes. re: scanning, the daemon would provide a bloom filter to the client. the client then knows which blocks it needs to request, and will over-sample blocks to avoid giving too much away 18:21:26 but you could, of course, also request all blocks. and you'd have no CPU problem 18:21:40 i don't see how monero can survive if tx volume goes up my more than 10x 18:22:03 syncing a wallet takes forever if you don't leave it running all the time 18:22:40 do you mean with a remote node? 18:22:58 yes, nodes will provide bloom filters to anyone that asks 18:22:59 because it doesn’t take too long when using a local node IMO 18:23:10 Did you not have an idea about the sender brute forcing keys so the prefix/suffix could be used to discard 1/256 of incoming outputs ? 18:23:55 255/256 18:24:01 mooo i had an unworkable variant of that years ago, UkoeHB_ had a working one recently 18:24:16 but that discards 255/256 of scalarmultbases 18:24:24 you still always have to do the first variable-base scalarmult 18:25:28 It seems plausible that one could skip outputs outright. 18:25:47 moneromooo i'm not sure i understand that sentence 18:26:07 Why do you need to do a scalarmult in the first place ? 18:26:21 so that only the recipient knows the tx is for them 18:27:05 Why does "so that only the recipient knows the tx is for them" imply "have to do the first variable-base scalarmult" ? 18:27:34 they could be advised of the location of the received funds out-of-band 18:28:10 but if it has to be done within the blockchain, there have been no alternative ways found, so far 18:28:12 If the key prefix is set to, say, the first byte of some data in the tx prefix encrypted with the destination subaddress' pubkey. Nobody knows that except sender and recipient. 18:28:38 anyone with that address would be able to decrypt 18:28:39 Ah, but the recipient still has to encrypt tht. 18:28:57 Yes, and that's only sender and recipient ideally :) 18:29:09 sure but that's knaccc's idea I think 18:29:16 using the public address 18:29:35 (this is not like rsa public key encryption at all) 18:29:40 Hmm. Alright. 18:30:21 moneromooo so yes, the subaddress-hash proposal effectively means that only the holder of the destination address can know if an output was destined for that address 18:30:36 and if it's one subaddress given out to each sender, that does preserve privacy 18:31:27 if you have end to end encryption on the out of band communication, etc etc 18:31:37 right 18:35:21 hyc don't get me wrong, i'd be horrified if everyone just said it was a great idea and started coding it. it will take a lot of thinking about. i'm just trying to spark some ideas, and at least get consensus over the severity of intersection attacks that make a mockery of untraceability, and of the wall we'll hit one day with tx volume 18:38:49 Hmm. What would you say if I'd started coding it... 18:50:22 you'll get my attention when it's deployed on the mooonero testnet 19:05:23 Updated version of FROST, the threshold signature construction from Zcash Foundation research: https://eprint.iacr.org/2020/852 19:30:14 haha genuis reverse psychology my mooo. i retract everything! 19:33:38 I didn't. 19:43:25 by* mooo 19:46:07 i really do think i'm at least onto something though, about the correct unit of anonymity perhaps needing to be wallet-level rather than transaction-level, due to the intersection attack 19:53:36 It's certainly an interesting way to look at the "level" of anonyimity 20:07:54 I suppose it was wallet-level before the intrduction of subaddresses 20:29:13 wallet sync is not that slow, I did a rescan of 3 years of transactions in about 20 minutes yesterday 22:21:08 hyc what i mean is that even prior to subaddresses, the anonymity set of each transaction was considered separately from the anonymity set of any other transaction made. so the change in thinking would be to start choosing decoys patterns across all transactions, rather than per-transaction. 23:47:45 not sure if this has been mentioned, but it seems like a malicious actor could inject outputs with fake subaddress tags to pollute specific individuals' rings