00:02:01 <[keybase] unseddd>: kenshamir: +1, thanks for the corrections, and in-depth answer 00:07:32 Hey, no problem 00:14:31 very interesting thanks kenshamir[m] 02:02:00 <[keybase] unseddd>: Isthmus: another paper for the reading list, 'Short Lattice-based One-out-of-many Proofs and Applications to Ring Signatures': https://eprint.iacr.org/2018/773.pdf 02:25:12 Thanks Unseddd - I'll check that out :- ) 02:59:15 Unfortunately the signatures are quite large 03:46:22 <[keybase] unseddd>: sarang: I haven't dug into it much, but found it when reading this: https://eprint.iacr.org/2020/430.pdf 03:47:24 <[keybase] unseddd>: maybe the latter work helps with signature size? 15:05:08 Research meeting is today at 17:00 UTC (about two hours from now) 15:05:10 .time 15:05:10 2020-05-06 - 15:05:10 16:14:31 Hey fam 16:14:35 Anything on the agenda? 16:14:38 I'm helping a Fellow with something, and will be sparsely or not available for the next few hours. 16:14:57 I'll talk a bit about a new key PR, but otherwise nothing of particular note this week 16:15:13 Was there anything you wanted to discuss? 16:33:53 Isthmus: I'll also talk a bit about Arcturus too 17:01:39 All righty! Time for the weekly research meeting 17:01:46 As always, we begin with GREETINGS 17:01:52 Hi 17:02:44 hi 17:02:47 hi 17:05:13 Let's move on to ROUNDTABLE 17:05:22 Any research of interest that folks wish to share? 17:08:03 I can share a few things, I suppose 17:08:12 I worked up a PR to update how keys are encrypted in memory 17:08:32 This has follow-on effects to how they're stored on disk, and I'm making some additional updates to improve the existing unit tests and add others 17:09:00 and I'm finishing up a test implementation of Arcturus, the extension of Triptych that offers better proof sizes 17:09:20 I'd like to determine exactly what the timing differences are, since initial estimates suggested that Arcturus and Triptych would be very close 17:12:02 Sorry if I've missed this; are there any comparisons for Arcturus, Triptych and CLSAG ? 17:13:59 hello 17:16:40 And kenshamir[m]: I have comparisons for CLSAG and Triptych, but this will add actual implementation data for Arcturus when finished 17:17:20 Oh right, very cool 17:17:36 The size data is already known, FWIW 17:17:47 But the Arcturus timing was always an estimate based on operation counts 17:18:00 It's different enough in how it handles transactions that I'd like to know for sure 17:18:03 concretely? 17:18:32 Is there a link for it? 17:19:29 The size/timing data? 17:19:40 Yeah, the size data 17:19:48 Yeah, let me pull it up 17:20:47 Probably may not be that helpful for Monero, but there is a new paper out on an endomorphism that allows you to compute aG + bH faster in variable time 17:21:00 Page 11: https://eprint.iacr.org/2020/312.pdf 17:21:02 Link : https://eprint.iacr.org/2020/454.pdf 17:21:18 Thank you 17:22:40 Anyway, that's what I wanted to share 17:22:45 Does anyone else have research of interest? 17:25:00 what's the gist of your encryption update? 17:28:26 The in-memory encryption of keys was being done with a chacha stream that was XORed with keys, instead of just encrypting the keys with chacha directly 17:28:38 This PR makes this change 17:29:59 The existing unit tests for wallet and key encryption also get some updates 17:30:28 ah interesting 17:31:30 It also transitions old encrypted keys to the new format, which needs better testing that I'm still working on 17:33:46 Seems pretty quiet today! 17:33:57 We could always end early if there isn't more that needs to be discussed... 17:34:41 I have nothing to add except to remind people that I still want coinbase outputs to be avoided entirely in non-coinbase-spend rings :p 17:36:02 You mean the idea that a ring containing a coinbase output must have all coinbase outputs, right? 17:37:53 sgp_: can you briefly recap your rationale, to ensure everyone is on the same page? 17:38:03 yes that idea 17:38:16 rationale is that no normal users spend coinbase outputs 17:38:32 even people who mine on mining pools never spend coinbase outputs 17:38:59 so the selection of these is markedly different from expected user spend behavior 17:39:37 When I thought about this earlier, I was concerned that it sort of kicks the can down the road one hop on the graph 17:39:43 separating these will increase the effective ringsize for most (>99%) users by 10-20% 17:40:08 sarang: it kicks the can down the road, but it's still MUCH better 17:40:25 Interesting 17:40:26 And that if a heuristic was "this coinbase probably isn't the true signer" previously, it would become "this output that came from a coinbase ring probably isn't the true signer" as a somewhat weaker heuristic 17:40:37 Yeah, I think it's better but doesn't totally eliminate it 17:41:34 If it were implemented, there would need to be a decision on what selection distribution to use, which should probably be based on a transparent-chain analysis at minimum 17:41:42 it's still essentially one set of transactions separated (one ring signature? I'm struggling to explain this simply and also accurately) 17:41:45 to see if it matches the overall distribution 17:42:12 The idea is that an ouput from a mining pool is far more likely to e spent by a normal user 17:42:37 basically the real spend of the after-coinbase output would look the same as several transactions that select this output as the decoys 17:42:51 Yeah 17:43:01 Does my statement about the analysis for a distribution make sense? 17:43:06 I agree it mitigates but does not completely eliminate the risk 17:43:16 but now this accounts for the behavior that the user could just be a miner on a mining pool, for example 17:43:27 which is hugely broader 17:43:34 But it is true that right now, the spend patterns of coinbase vs non-coinbase are assumed to be the same by the selection algorithm 17:44:14 It'll be very interesting to see that distribution for coinbase-only 17:44:25 only solo miners can spend coinbase outputs. Miners on mining pools can also spend from-coinbase outputs 17:44:41 right 17:45:08 so while it kicks the can down the road, in terms of practical behavior, it's a night and day improvement 17:45:35 I'll ping Isthmus here, since his group has access to this sort of data for other chains 17:46:14 discussion on this idea has been mixed for years. I'd like to see this actually done 17:46:40 10-20% better effective ringsizes just with smarter selection 17:47:56 It is a significant mitigation of the issue. I do not see a clear downside to this. 17:48:37 downside is to people that are running private pools. They effectively need to "churn" once by not directly sending the coinbase outputs to people 17:48:52 I think this is a small tradeoff 17:49:20 I think it's an improvement, provided it doesn't introduce unexpected or unintended consequences to the selection distribution, and is based on distribution data from known spends where reasonable (e.g. Bitcoin) 17:49:49 hoi, can someone evaluate how sound this ECDSA adaptor signature is? https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/ if these ECDSA adaptor signature works, it looks like the atomic swap can be done using a scheme similar to the suggested by andytoshi-sarang (equivalent discrete logs), mixed with the game theory from h4sh3d's proposal: all game theory on bitcoin script (forcing players to act or 17:49:49 I agree with that caveat, though I want to add my own caveat that I don't see how it can be worse 17:49:49 lose), and no need for monero refund. so it should work on monero today. 17:50:22 zkao: I didn't invent that cross-group discrete log idea; it was andytoshi 17:50:39 yes, i know, u proposed 17:50:58 sgp_: if the coinbase-only selection distribution ends up being very different to the overall distribution, it would introduce a heuristic for coinbase true signers 17:51:26 and for all we know, it could be a very different distribution in that miners/pools spend immediately or something 17:51:43 luckily then we can approach coinbase with its own algo 17:51:48 which we can't do now 17:51:59 The non-coinbase distribution could be easily modified to simply redraw if it chooses a coinbase 17:52:09 if these are actually very different spend patterns, then the possibility for increased privacy is even greater 17:52:20 since we can handle them separately, not together 17:52:20 The coinbase distribution would simply be some fixed selection distribution on block order, that doesn't need to do the shuffling method we do now 17:52:32 sgp_: right 17:52:59 my gut suggests coinbase spends are quicker on average 17:53:07 but Bitcoin data would be great for that ofc 17:54:01 Right 17:54:33 Hopefully someone like Isthmus's group can get that data, since they have easy access to the dataset AFAIK 17:54:40 I still support avoiding coinbase with the stupid method of re-selecting a coinbase is chosen, though improvements can make that better. I see even this stupid model as an incremental improvement 17:54:51 *if a coinbase is chosen 17:56:22 what I'm trying to say is that the data on Bitcoin should help make the selections better, but that they are not prerequisites to switch since it can't be worse than it already is in my eyes 17:57:40 If there were no known distribution from Bitcoin etc., what selection for coinbase-only would you suggest? 17:58:35 Reselect-on-coinbase seems reasonably for non-coinbase rings, but there still would need to be a chosen selection distribution for coinbase-only rings 17:58:46 same as current probably? I agree that's not ideal 17:59:21 Well, the current one takes block density into account, and that's not relevant for coinbase-only 17:59:31 keeping in mind most public pools publish this data openly anyway 18:00:10 so frankly the coinbase rings would be susceptible to a lot of public data causing a high proportion of heuristically dead outputs 18:00:53 in the worst of cases I say ~90% of of the hashrate accounted for by public pools sharing coinbase data, so ringsize 11 doesn't really help with that in the best of cases 18:01:02 *I saw ~90% 18:01:29 Well, at that point you could _almost_ suggest removing the requirement for nontrivial rings in coinbase-only at all 18:01:35 *altogether 18:01:57 If the thought is that analysis could reveal true signers in a huge number of cases anyway 18:02:23 there's a push for pools to not share this data, but I agree that in the current case, coinbase rings should be considered to offer near-zero protection 18:02:59 really any coinbase spend. in the current situation, they are still heuristically dead, just spread across normal users' transactions 18:03:34 Hmm, we're a bit over time 18:03:39 yeah we can end 18:03:41 Let's move to ACTION ITEMS and then continue discussion 18:04:12 I have some unit tests update to make for the key encryption PR, and hopefully can get Arcturus code working in C++ with the timing data that I want 18:06:09 Any other updates, action items, etc. before we adjourn? 18:06:31 If not, adjourned! 18:06:33 Logs will be posted shortly 18:07:09 sgp_: if there were a compelling argument for removing rings altogether for coinbase, I could see moving to a straightforward change in the non-coinbase selection algo 18:07:21 But if not, I think it's important to get distribution data on coinbase from elsewhere 18:07:29 Otherwise any selection algorithm is a shot in the dark 18:07:49 we can proceed with no rings for coinbase until we have an algo, sure 18:08:06 FWIW I'm not saying I am convinced of this yet :) 18:08:21 In my assumptions I basically considered them useless before triptych or something like that anyway 18:08:53 you've had two years to think about it, what more do you need? :p 18:09:22 Data on spend patterns 18:09:46 The argument about public pool data is much more compelling IMO 18:10:11 Because it shifts the question from "how do spends of coinbase or after-coinbase differ from general outputs" to "these outputs are mostly dead anyway due to pool data" 18:12:09 ultimately my concerns are about normal users having smaller effective ringsizes. Not only will they not realistically spend coinbase outputs, but they definitely won't spend coinbase outputs that are likely heuristically dead 18:13:42 Well, getting Bitcoin (or other transparent chain) separated data would help to tell us this 18:13:45 but that explains why I haven't cared a ton about the coinbase selection. Why care if it won't likely matter anyway haha 18:14:38 well I can tell you about a year ago, 90% of the hashrate was produced by pools that showed what blocks they mined. It might be slightly different now, but this is still common 18:15:26 Well, let's consider the case where that's still true but we do a better selection algo 18:15:34 Then at _worst_, there's an effective ring size of 1 18:15:42 But at best, there's still signer ambiguity 18:16:04 sure, which is why I assumed just leaving the coinbase selection the same anyway 18:16:13 Moving to a bad selection algo means that an adversary with good data could heuristically unmask signers much better 18:16:38 using coinbase age distribution data they obtain 18:16:47 And we should of course assume that good adversaries have done this 18:16:53 And so we should do it too :) 18:16:58 are you talking about coinbase-only rings still? I'm confused 18:17:30 I'm assuming the base case of the same algo as right now, but rerolling if 1+ coinbase are selected 18:18:07 If coinbase are removed, then the non-coinbase selection algorithm would probably be "the current thing, but re-draw on coinbase selection" 18:18:21 But the coinbase-only selection distribution is currently unknown, but obtainable from other chains 18:18:42 An analyst who has that selection distribution could use differences between it and whatever we might choose to heuristically unmask coinbase signers 18:18:57 And of course they could/should/would use any pool data they find 18:19:00 sure, so we can use an algo for non-coinbase, but honestly most of the time it will be useless with this ringsize, even if the selection is awesome 18:19:10 well I can tell you about a year ago, 90% of the hashrate was produced by pools that showed what blocks they mined. It might be slightly different now, but this is still common <--- Would this in fact be the downside. Only the most recent coinbase output is the real one 18:20:08 ArticMine: we may find people spend immediately, yes. But that's not incrementally worse with coinbase-only rings 18:20:15 sgp_: I think it's useful to maximize the benefit from the coinbase-only selection, even for a marginal benefit in case many decoys are dead by pool data 18:20:32 Otherwise, a bad selection algo might be as bad as no ring at all 18:20:38 (heuristically, at least...) 18:21:06 sure, I agree with you 18:21:19 point is that I don't consider this a reason not to implement 18:21:24 And it seems straightforward to obtain this data 18:21:41 consider it due diligence 18:21:44 I see it as a further area of improvement, but that the decision can be made even without this data 18:21:56 (I just don't want to keep moving the goalposts) 18:22:12 I see what you mean; that the decision of _whether_ to do it might be independent of the knowledge of a specific distribution to use if it were implemented 18:22:16 The cpoinbase spend pattern of pools is very predictable 18:22:27 ArticMine: sure, so we should find out what it is 18:22:33 ArticMine: yes, we're dealing with super public, predictable behavior here 18:22:55 Of course, not everyone mines in pools 18:23:14 hence why I've been concerned we're wasting 10-20% of decoys of transactions for years now 18:23:26 and then you have to weigh the likelihood of unmasking those signatures with the current scheme versus any new scheme 18:23:49 sarang: can you be specific about which type of signatures? 18:24:24 So the question becomes are there enough regular non coinbase txs to make it look like a real coinbase tx is a fake 18:24:44 sgp_ I am turning the argument on its head 18:24:52 The heuristic of "the coinbase is probably not the signer in this random transaction, because I don't think coinbase are selected this way" is different from "this coinbase in this coinbase-only transaction must be the signer, because of pool data and probably also this other heuristic I built" 18:25:06 So if you're not a pool miner, the latter means you're unmasked almost certainly 18:25:19 Whereas the former seems a weaker heuristic in practice 18:25:23 but a heuristic nonetheless 18:26:08 the short answer is that private miners will have a worse selection for their coinbase outputs than they have right now. They will need to churn once 18:27:47 The question I have is how can one tell in the current system a real from a fake coinbase output 18:28:06 ArticMine: most pools publish "real ones" 18:28:55 for private pools, them spending a real one will be pretty well-hidden among non-coinbase outputs (like as if they had churned once with this coinbase-only switch) 18:29:55 I wrote about all this in my "Let's Stop Using Coinbase Outputs" post a while back 18:30:45 So the issue becomes the tie lag between publication and spending of the output 18:30:50 time 18:31:59 ArticMine: a good heuristic is probably to determine if known coinbase spend patterns differ significantly from non-coinbase spend patterns 18:32:05 (they probably do) 18:32:08 Namely can the unspent coinbase be picked up by another normal transaction before it is spent 18:32:41 maybe but I think that's not the main focus here 18:33:37 I see it as critical since it would obfuscate if it is real or not 18:34:16 It's not about who spends first... it's about the spend-age distribution 18:34:24 The selection algo should match this 18:35:17 Yes the spend age distribution of the coinbase 18:35:23 If it turns out they're much different, then separating them with separate algos is reasonable in most cases (but harms private miners if pool lists kill all the decoys, as has been said) 18:36:43 note that spend-time distribution is only one (important) part 18:36:53 Yes, I don't mean to imply that it's the only factor 18:36:54 but they would still be included in the regular transaction only with a different algo 18:37:02 but it is one that used to lead to good heuristics 18:37:06 sarang: yeah, just clarifying :) 18:37:15 and it's something that is straightforward to get from other chains 18:37:21 (provided you're willing to use them as a proxy) 18:37:21 users not mining is another good heuristic 18:37:34 s/mining/mining directly 18:37:34 sgp_ meant to say: users not mining directly is another good heuristic 18:43:44 Solo miners or miners who spend or donate hashrate as opposed to those using a pool that pays out upon mining a block 18:45:07 Also the mining dynamics of Bitcoin and Monero are very different 18:47:47 Well, getting known spend data for Monero coinbase would require using published pool data or other external data 18:47:56 Using another chain is a proxy at best 18:48:31 Or using old Monero data where decoys can be removed using chain reaction etc. 18:48:49 as Miller et al. did for their ground-truth on spend distribution data (which matched Bitcoin trends reasonably well) 18:56:18 I may be talking out of my butt here, but it seems likely Bitcoin usage stayed at close to 0 for a few years, while monero did not. 18:57:01 Ethereum data would show a quicker uptake, though quicker than monero. But these probably give us min/max curves. 18:59:39 you can see number of txs per day for all three here: https://bitinfocharts.com/comparison/transactions-btc-eth-xmr.html#log 19:06:14 I mean, any assumption that Monero patterns match any others is essentially an extrapolation, maybe backed up by early known Monero data and then extrapolated to the present 19:06:28 But if you were trying to build a heuristic, it seems like the thing you'd do 20:50:59 <_ArmannY> hi , anyone have node-cryptonote-util for xmr RandomX ? 20:59:02 <_ArmannY>  hi , anyone have node-cryptonote-util for xmr RandomX ?