04:41:46 13404422 ring signatures generated by version 2 transactions 04:42:10 Whoops, wrong channel 04:42:21 Well, you can probably guess who I meant to send that to 05:04:59 Avg ~1 tx every 20secs 05:05:05 One ring sig* 14:59:12 Reminder that weekly research meeting is today @ 18:00 UTC (about 3 hours from now) 17:01:26 why do i keep thinking these meetings are 17:00 UTC? 17:01:53 They used to be 17:00 17:06:20 .time 17:06:27 .dementia 17:06:54 too bad that doesn't work here. works in #monero-community 17:14:30 so, good news everyone: i now have two full days of sleep, with a calorie defecit smaller than 500 calories, for the first time since xmas. finally freaking feeling better 17:14:57 :D 17:25:03 suraeNoether: that's great news! 17:29:48 How do we get the timebot here? 17:35:17 back in my day we wound our watches 17:35:29 Now we have robots to do that 17:36:59 Anybody have anything they want to specifically add to today's agenda? 17:45:27 nioc: i'm still winding my watch :) 17:46:26 my question is, what is the status of the matching project and how will is be used going forward to help select an appropriate ringsize? 17:47:07 Curious as well 17:47:09 Great question for the meeting, or for right now 17:47:25 +1 17:48:08 As I stated before, I don't think there are strong reasons to increase ringsize with clsag unless there's a justification other than "larger is better" or "it could theoretically help with churning" 17:48:21 I agree 17:48:46 Some forms of analysis are easily mitigated by small increases, and those have been done already 17:48:54 this was maybe fine a few years ago when the ringsize was MUCH smaller and this was the best analysis we had, and when we were dealing with more basic attacks 17:49:03 sarang: beat me to it :) 17:49:05 Other more targeted forms of analysis would be difficult to mitigate without very large increases that are not feasible right now without bloat 17:49:13 easy attacks are effectively covered 17:49:39 But marginal increases at the current size seem unnecessary without a good rationale, likely related to churn as sgp_ says 17:55:11 We'll start our meeting in just a few minutes 17:55:32 my hope is that the matching results come out in time to make a good decision regarding ringsize in the clsag update 17:55:33 The usual agenda, with an addition from Isthmus: https://github.com/monero-project/meta/issues/434 17:55:51 ^^ agreed 17:57:38 plus this project has been ongoing for what, a year or two now? 17:59:49 OK, let's get started 18:00:03 Logs from this meeting will be posted to the agenda issue shortly after the meeting 18:00:09 First, GREETINGS 18:00:10 hello 18:00:16 hello 18:00:34 good mroning 18:00:49 hiya 18:01:27 * sarang will wait a minute for anyone else to arrive 18:03:06 On to ROUNDTABLE, where anyone is free to share interesting research 18:03:18 I'll go first, since I have a small assortment of things 18:03:51 I worked up code and examples for doing hidden data storage within Bulletproofs and Triptych, suitable only for the prover 18:03:53 I,m kinda here, but on a conference call 18:04:20 Several ongoing projects/issues have been moved to monero-project/research-lab issues for comment and discussion 18:05:03 The CLSAG code on my monero fork (clsag-plumbing branch) has been cleaned up; thanks to UkoeHB_ for helpful suggestions and comments 18:05:28 It includes, among other things, hash function domain separation that we hope to roll out elsewhere for a more robust overall codebase 18:06:02 There is also CLSAG Python sample code showing how to do signer index extraction in a clever way, which I assume UkoeHB_ may wish to discuss when he shares 18:06:14 I've written up material for ZtM about transaction proofs/assertions 18:06:43 And have worked up some new C++ code that updates transaction in/out proofs to have correct Schnorr challenges 18:06:51 (still need to write tests for this) 18:07:04 That's my update; any particular questions before the baton is passed? 18:07:58 quick question: iirc you had done work on encrypted timelocks 18:08:03 yes 18:08:05 i've been chatting with both isthmus and TheCharlatan about them 18:08:13 do you have any notes prepared any place for later reading? 18:08:29 On what in particular? 18:08:37 alternatively: can we schedule a discussion in this room that will end up in the logs for later this week? 18:09:00 Sure 18:09:27 Let's table for now, and address at the end 18:09:34 if we implement them regardless of if we are using mlsag, clsag, or triptych, there's going to be a cost. i want to see how it's all going to fit into future monero dev 18:09:39 word, word, i can go next 18:09:45 OK, go ahead suraeNoether 18:09:48 * sarang makes a note about timelocks 18:09:58 last week i spent a lot of time on CLSAG and linkable ring signatures security definitions 18:10:22 there are a lot of definitions out there and they don't all relate to each other in a clean taxonomy, and it wasn't clear which ones we needed to use, and so on 18:10:43 so i started writing this rather large technical note summarizing all this with the intention of writing a second paper about it, but sarang and i have decided to merge the two into a new draft 18:11:12 the reason is that even definitions of unforgeability miss absolutely critical stuff becuase they are taken from "ring signatures" and mapped over to "linkable ring signatures" wholesale without regard for linking properties 18:12:04 so now the paper will be proposing a new definition of unforgeability specifically for linkable ring signatures that subsumes more than one security definition, and this is going to set the standard for a few years on how unforgeability is considered for all applications of linkable ring signatures. 18:12:09 this is good news(tm) for MRL 18:12:20 sweet 18:12:28 congrats :) 18:12:33 thanks :D 18:12:41 It makes the preprint all the more valuable 18:12:44 In addition to that, I have been preparing my talk for the Blockchain Tech Symposium at the Fields Institute in two weeks, and debugging my matching code. 18:13:01 i'm extremely grateful to the peer reviewer who "gently" pointed us towards the backes' paper actually 18:13:03 Having both improvements to security models _and_ a new construction seems to be the gold standard these days 18:13:07 they did us more of a favor than maybe they realized 18:13:37 my work for the week will include finishing up this new draft of CLSAG, and to begin large-scale data collection on matching 18:14:17 Thanks suraeNoether 18:14:20 Any questions for suraeNoether? 18:14:44 if you want more CLSAG work, it's possible to increase the number of linkable keys up to the total number of pub keys considered :p 18:15:05 Sure, but that's not useful for our particular application 18:15:09 which is why we didn't consider it 18:15:55 I believe there was an earlier question from nioc about matching 18:16:04 for suraeNoether 18:16:18 12:46 my question is, what is the status of the matching project and how will is be used going forward to help select an appropriate ringsize? 18:16:28 ^ was the question 18:17:42 ah, great question: the matching project is *what appears to be* a single-line bug away from correctly generating simulated ledgers. it already appears to generate correct confusion matrices; once this bug is cleared up, it's a matter of executing a big block of code for a large period of time to get all the sample data, and then analyzing the data that's dumped to file. 18:18:24 so... if this bug, just like all the others, is a hydra, then I don't have a good answer, but i suspect i've narrowed down the problems to the source 18:18:39 Is the purpose of the matching project to produce the ledgers? 18:18:56 there are several purposes, but here's the main thing 18:19:30 we want to estimate how well an adversary can do at finding the "real" history of a monero ledger, given some hints (like it's a KYC exchange) 18:19:44 i have a method of computing a maximum likelihood estimate of the real history given some obscured ledger, and all that code works 18:20:02 and i have a method of taking an estimate and comparing it to the ground truth, producing a confusion matrix, and all that code works 18:20:17 i have a simulator that generates simulated ledgers, and the vast majority of that simulator is working just fine, too 18:21:08 the origin of the project came from the idea of developing a game-theoretic description of traceability on the monero ledger: you hand me an obscured ledger and some hints, I hand back to you my best guess, and then success is judged by you comparing the best guess to the ground truth you kept from me the whole time 18:22:04 so, the hope is: graph performance against ring size, and see if getting larger than 11 is a waste of space/time or not 18:22:36 in the meantime, we hope to also get good data for zcash-style ledgers, so that we can actually rigorously compare the two ledgers against each other, instead of tweeting at each other about fragility 18:22:48 but that last bit is farrrrr down the line 18:23:10 Oh yea, I just remembered that ginger and I talked about generating synthetic blockchains forever ago https://github.com/insight-decentralized-consensus-lab/CryptoNote-Blockchain-GAN/issues/1 18:23:21 * Isthmus has to run to a meeting at :30, sorry >_< 18:23:27 OK, any follow-up questions on this? 18:23:37 unfortunately, i've not worked on matching since mid-January because CLSAG's security models are critically important 18:24:06 and CLSAG needs to get out the door 18:24:21 Anything else to share, suraeNoether? 18:25:51 Does anyone else wish to share relevant or interesting research? 18:27:02 I'm taking a break from blockchain logs analysis to do some chat log analysis, analyzing recurring logical fallacies in this space 18:27:03 Nope 18:27:11 isthmus lol really? 18:27:23 ? 18:27:29 Yeah, actually doing a formal analysis 18:27:35 Isthmus: if you are, i have a friend to hook you up with at the university of exeter 18:27:37 This channel in particular? 18:27:44 Or more broadly in cryptography? 18:27:50 Somewhat broady 18:27:56 There's 7 common ones that show up in -lab 18:28:01 go on... 18:28:24 But they break down into combinations of red herrings and something that is *similar* to the slippery slope argument, but not quite the same and I'm still nailing down its technical logical structure 18:28:33 dude, please elaborate 18:29:14 Like when we're debating fixing a tractable privacy leak, and somebody points out that there are other privacy leaks 18:29:23 :O 18:29:50 ah yeah 18:29:59 or comparing everything to 50% attack costs 18:30:13 Another one is the hashrate code control fallacy 18:30:34 ? 18:30:38 Confusing a 51% attack on longest chain with a 51% attack on the code 18:30:42 This came up a few weeks ago actually 18:30:45 aaaah 18:31:01 i smell some medium articles 18:31:02 Like why should we bother working on the protocol and code, when one day, somebody might run their own version on a bunch of their own miners 18:31:15 Based on what you've analyzed so far, any particular recommendations to avoid such flaws in discussion/thinking? 18:31:16 That one can be disproven by contradiction 18:31:32 If 50% of BTC hashrate moved to BCH, does that make BCH the official bitcoin? 18:31:33 "why should we patch little leaks in info here and there" styled privacy nihilism/despair 18:31:40 Oh shit, I gotta be in a meatspace meeting 18:31:43 ciao! 18:31:57 -__- 18:32:20 Very interesting stuff 18:32:37 Erm, not by contradiction. I mean by example demonstrating absurdity 18:32:44 We have plenty of time left... does anyone else wish to share anything? 18:32:47 lol 😆 18:32:52 lol "i'm going to use machine learning to watch all of your conversations and find out who repeats fallacies most zealously BAIII GOTTA GO GRAB A FREE SLIZE OF 'ZZA FROM THE CORPORATE OVERLORDS" amiright 18:33:06 Here's mine. Worked on write-ups of different ideas -> now Research repo Issues, with good feedback from sarang improving viewspent approach. TxTangle (aka my monero coinjoin protocol) is mostly done and just needs questions answered about network-layer anonymity. Current draft of ZtM2 is here https://www.pdf-archive.com/2020/02/05/zerotomoneromaster-v1-0-23/zerotomoneromaster-v1-0-23.pdf and current 18:33:06 ‘koe’s Ideas’ is here https://www.pdf-archive.com/2020/02/05/moneroideaskoe020520/moneroideaskoe020520.pdf 18:33:30 Yeah, the original view/spent idea was broken, but there's a better approach 18:33:44 It ties in with the CLSAG index extraction that I mentioned earlier 18:34:26 If the signer generates all non-signing scalars via a PRNG `s_i := H(seed,i)` (with appropropriate seed data), then it can be asserted privately what the signing index is 18:35:10 It removes the need to add anything to the chain, and hence is good for indistinguishability 18:35:24 I dig it, provided the UX is sufficient for reasonable use cases 18:35:37 yeah if view key can regenerate those scalars, it can know when an output has been spent with certainty 18:35:50 of course, it only works if tx author generates scalars like that 18:36:01 The problem is still that it's opt-in, so even an accidental use of a non-participating wallet ruins the account balance computation for good 18:36:16 So you'd have to be super-clear about presenting that to the user 18:36:24 hmm 18:36:40 Of course, a wallet could be doing that right now for all we know 18:36:51 it's non-consensus and can't be detected if done properly anyway 18:38:20 it does leave open questions about data stored by nodes, since signature scalars are pruned; perhaps only full nodes, or view-spent enabled nodes can be used 18:38:33 IMO that's a completely reasonable trade-off 18:39:04 sounds reasonable to me too 18:39:06 it also may greatly increase data transmitted to view-only wallets by remote nodes 18:39:09 Bloating the network for optional functionality benefitting only a single user seems unnecessary 18:39:28 But this approach means you can run a full node (good for the network) and have the functionality for your wallets safely 18:40:32 UkoeHB_: I think that's a good thing to point out but probably isn't a showstopper 18:40:53 might need to receive a gigabyte of data to read through a year's worth of tx 18:42:24 hmmm 18:42:31 i'm a little worried about this in the following sense 18:42:36 I still think that is okay for view-only wallets 18:42:45 you are selecting the non-signing scalars deterministically from a PRNG 18:42:52 anyone using them for critical stuff, or viewing multiple wallets, should run their own node 18:43:05 one thing we all know about schnorr signatures is that if nonces are selected deterministically, it's possible to extract the private keys 18:43:24 at least, under certain constraints 18:43:26 suraeNoether: yes, which is why seed selection is very important 18:43:26 so my question is 18:43:35 UkoeHB_ and I discussed this a bit already earlier 18:44:12 if the seed is chosen from a high entropy distribution and kept secret, it's computationally hard to detect that these are computed deterministically 18:44:27 i would prefer a method that is more than computationally hard 18:44:37 Presumably the seed is a combination of the view secret key, the index, the key image, etc. 18:44:50 suraeNoether: how would that even work? 18:45:15 Data extraction requires that only the designated parties be able to construct the "expected" output value 18:45:27 pfeh, we use PRNGs because statistical RNGs don't really exist :P so ... it wouldn't 18:45:49 Well, right now we operate on the assumption that the user has access to something behaving as an RNG 18:45:55 this moves to an honest-to-goodness PRNG 18:45:57 (and has to) 18:46:06 You can't do data extraction with a true RNG AFAICT 18:47:11 that... is... true. 18:47:21 Anyway, this is an interesting topic that could be useful for a future release 18:47:41 but has subtle aspects to seed selection and UX that need further review 18:47:46 Let's move on, for the sake of time 18:47:54 Any other topics you wish to share, UkoeHB_? 18:48:22 well, I hope people can leave feedback on the repo issues 18:48:27 Yes, please do 18:48:37 Much easier than only doing IRC comments =p 18:48:37 sorted TLV is probably most important for next hardfork 18:49:06 TBH that's probably going to be better for -dev discussion 18:49:20 More of an engineering question than a math question :) 18:49:25 true 18:49:38 I'd bring it up at a dev meeting, or just in -dev whenever 18:49:45 Get a sense of the work involved 18:49:59 ok 18:50:14 I know people have brought up tx_extra parsing before, and it's a hot topic 18:50:36 Does anyone else wish to discuss other research topics? 18:50:37 ah, CLSAG section was added to ZtM2 for anyone curious 18:50:43 excellent 18:51:16 uh i saw vtnerd's push on dandelion++ 18:51:21 Yes 18:51:23 Most excellent 18:51:29 It's on my list to review later this week 18:51:32 Speaking of which 18:51:41 Let's briefly move to ACTION ITEMS to respect everyone's time 18:52:42 I'll be reviewing the D++ PR, working through some additional transaction assertion/proof stuff, updating sublinear tx protocol MPCs, and writing up examples of RCT3 hidden data storage 18:52:49 yes. Mine: Finish CLSAG, start collecting matching data. Also, of primary importance: provide updates twice or three times a day in here until both of these are finished. 18:52:53 As well as getting tests written for the new tx in/out proofs 18:53:08 i'll be reviewing the D++ pr also once those are both off my plate 18:53:15 Yes, looking forward to the CLSAG stuff (will review when ready) 18:53:29 Anyone else have action items planned for the week? 18:54:18 To do: focus on multisig all week, hopefully finish txtangle (need a network anonymity expert for advice, any takers?) 18:54:33 The most knowledgeable person is probably vtnerd 18:54:59 I hear if you say his name 3 times, he gets 3 separate notifications... 18:55:10 =p 18:56:00 Any last-minute items, questions, etc. before we formally wrap up? 18:56:55 (I'm happy to discuss timelocks after we adjourn) 18:56:59 Going once... 18:57:22 twice... 18:57:44 Adjourned! Thanks to everyone for attending; logs will be posted shortly on the agenda issue 18:57:51 Feel free to continue discussions, of course 18:57:54 suraeNoether: timelocks 18:58:25 What do you wish to know 18:58:55 well, first question: is there a github issue or something describing any proposed methods of implementing them? 18:59:14 second question assuming no: is there a document anywhere describing any proposed method of implementing them? 19:00:15 I have some example code showing how they operate 19:00:20 What details do you want? 19:00:36 If you want timing information, that's separate (depends on performance timing) 19:01:04 and that doesn't address the engineering work required to integrate the timelock range proofs (used for inputs) with the existing bulletproofs (used for outputs) 19:01:17 It seems pretty nontrivial to do 19:01:20 Issue #65 I did a short explanation of how it works 19:03:20 uh #65? 19:03:47 UkoeHB_ means https://github.com/monero-project/research-lab/issues/65 19:03:59 I opened an issue describing the basic idea 19:04:18 oh! 19:04:28 i was in monero-project/monero :P 19:04:49 ok, this was *all* i wanted before i had more questions 19:04:50 thank you 19:05:55 The gist: requires each input to have an additional auxiliary commitment added; still a cleartext auxiliary time included; CLSAG verification complexity increases; range proofs basically unaffected if done properly 19:06:47 First-order estimate is that the MLSAG-CLSAG verification benefits go away with CLSAG-based timelocks 19:08:21 Although: I should note that range proofs currently have a cap on the number of commitments included... with timelocks, this cap would incorporate both input timelock commitments _and_ output value commitments 19:08:38 I mean unaffected since we already pad to the next power of 2 for size and time purposes 19:08:47 Increasing the limit would of course change this 19:13:21 *nod* 19:13:59 So there are still size benefits from the MLSAG-CLSAG transition, but the time benefits disappear 19:14:32 May be slower overall by a bit... there's always variance in the test numbers 19:14:43 Seemed like a wash during my initial testing 19:55:05 sarang: i have a weird notion of unframeability, or non-slanderability i wanna run by ou 19:55:12 but it requires out of the box thinking 19:55:20 if you are aroudn 19:55:27 I am around 19:55:56 ok so 19:56:48 firstly, unforgeability is a version of soundness, which is a matter of the existence of a witness extraction algorithm. when we prove unforgeability, we prove such an extractor exists and use it to violate a hardness assumption 19:57:30 secondly, if A is an algo that can produce a valid signature, then it can be rewound by the extractor to get the witness, so if A produces some (m, R, \sigma), we can wrap it without harming its advantage and output instead ((m, R, \sigma), w) for a witness w 19:57:35 follow me so far? 19:58:17 Ideally 20:00:05 https://www.irccloud.com/pastebin/uJUqZ5mb/ 20:01:14 this is an amped up definition of linkability. I suspect it's distinct both from Backes' and the older Tsang-style definitions, also 20:01:25 but i haven't proven proper containment of the securiyt models yet. 20:03:30 actually: this is a very strong definition of linkability that says two signatures will link if and only if their witnesses match 20:03:37 which implies Backes' definition for sure 20:04:59 hmm, yeah, actually i think this definition also implies tsang's definition 20:05:02 suggesting this is stronger than those 20:05:14 i... suspect htere's a problem with my thinking, though, other htan the fact that it assumes the scheme is unforgeable to start. 20:05:47 How do you frame this in a challenger-player scenario? 20:05:59 The challenger can't naively extract the witness itself 20:06:23 https://www.irccloud.com/pastebin/yh1NDdj9/ 20:06:28 Back by popular demand 20:06:31 ^@koe 20:06:36 @UkoeHB_ 20:07:54 Wow, we've had some transactions with a lot of inputs... 1187, 1086, 1067, ... 20:08:34 Ah is this the chain analysis I had asked for? 20:09:38 sarang: same way backes' linkability defines it as player-challenger 20:09:50 suraeNoether: this is a good conceptual example of linking unforgeability to (special) soundness by Groth and Kohlweiss: https://link.springer.com/content/pdf/10.1007/978-3-662-46803-6_9.pdf 20:10:00 oooh 20:10:48 taking a lunch break, and then sarang, i'm at the point where i'm copy-pasting proofs over... so i think i'll be done later today and passing a new draft along to you, but i'll do an update in a bit 20:14:22 Roger 20:15:43 Want to see 800 obviously spent outputs? 20:15:46 https://usercontent.irccloud-cdn.com/file/dRXOlFUI/image.png 20:16:26 Our ring signatures and decoy selection algorithm are simply statistically incompatible with spending a large number of temporally-correlated outputs in a single transaction 20:16:36 I can automate this too 20:16:50 Yup 20:17:29 Collapse the ring member ages of all 1000 ring into a histogram, find cluster centroids, flag every output within 1 stddev as spent. Loop this over all of the 500+ input transactions, and mark thousands and thousands of outputs as known to be spent. 20:17:37 Interesting, it seems like the amount of pool payouts is less than 1% of all tx 20:17:56 i haven't coded it up yet, but it could take a single pass through our database and identify >10,000 spends 20:17:58 Isthmus: *highly suspected* to be spent 20:18:07 Known for a long time :/ 20:18:30 Tricky to avoid without sufficient cluster/bin selection AFAICT 20:18:42 Which in turn is tricky without larger overall anon set sizes 20:18:43 And of course revealing 10,000 spends also reveals 50,000 decoys 20:19:15 I'm a statistician, not a court of law. For the purposes of commercial chain-analysis those are considered spent. 20:19:18 :- P 20:19:59 Sure, and I don't know a good way to avoid this beyond clustering and/or wallet warnings 20:20:41 All high input count inputs are pre-ringct 20:20:58 Or, alternatively, such a large-input transaction followed by a properly-executed self-spend 20:21:04 Since max tx size limit 20:21:07 to return the single output into the "recent pool" 20:21:48 " Or, alternatively, such a large-input transaction followed by a properly-executed self-spend" < protects the sender, but laces the chain with weak decoys 20:21:55 An on-the-fly analysis followed by a churn wallet warning might useful as a stopgap 20:22:08 Ah right, can you flag every tx with >1 input if it used RCTTypeFull? 20:22:15 Isthmus: right, but in general it's not possible to fully avoid 20:22:50 Or add a count column to that data set with #tx with rcttypefull 20:23:12 Yea it is, we just need to cap the number of inputs to force multiple transactions. A little bit of computational and fee overhead, but allowing insanely large numbers of inputs basically defeats the point of ring signatures 20:23:17 I'm not saying to cap it at 5 20:23:22 But it needs to be not 1000 20:23:43 And another flag if the first referenced input offset is pre-ringct (implies all inputs are pre-ringct) 20:24:58 Ah interesting 20:25:40 I think rcttypefull could get up to around 600 inputs, maybe more with smaller ring sizes 20:25:52 Pre-bulletproofs 20:27:03 Anyways, good lunch break but I gotta get back to the work 20:27:05 gg 20:27:20 Isthmus: the sharp dropoff for decoy selections means that the temporal effects may be reduced somewhat 20:27:27 but it'd be interesting to see to what extent this is the case 20:27:42 I'm guessing all those inputs from the same block are denominated pre-ringct outputs being swept 20:28:36 I still very much advocate for eventually moving to a bin/cluster selection approach, but I also think it only has maximal benefit when used with a large overall ring size 20:32:57 Isthmus multiple transactions doesn't work either, since with a little extra effort you can compare the input rings of adjacent tx for clusters 20:33:41 Well helps a little, and moreso as the time spread rises, but not a huge improvement 20:34:22 Larger clustered bins shared across all inputs seems to mitigate this 20:34:36 Yeah 20:34:44 True, in that sense transactions are kind of arbitrary boundaries around branches of the tree, but it's still the same tree 20:34:49 Even if you gain knowledge of the bin used across inputs, that doesn't necessarily identify all spends within the bin 20:34:58 Very mature graph analysis erases the boundaries from both blocks and transactions, to focus on the pure topology 20:35:25 and the presence of identical bins on all txns means you can longer use only cross-input techniques to guarantee a single set of spent inputs 20:39:52 Isthmus and UkoeHB_: suppose we can do ringsize 128 or 512 20:39:57 How would you structure selection? 20:40:03 I've thought a lot about this 20:40:18 but surely there are factors at play that I am missing :) 20:40:40 For starters, inputs should share the same anon set 20:40:51 (this is generally also very efficient) 20:41:42 Binning is also a good idea (Miller et al. show how to do deterministic shuffled binning to avoid miner shenanigans) 20:41:51 I think maintaining the gamma distribution as foundation is important, although I have some thoughts on how to make sure it ages decently 20:41:53 What else? 20:42:08 Yes, I assume the bin selection follows a reasonable spend distribution 20:42:19 with the rule that when you select a bin, the ring includes that entire bin 20:43:13 I feel that reveals too much about the spend timing 20:43:36 I need to clear my mind and think on that for a while. There are 3 concrete research strategies that I believe should inform selection 20:44:55 UkoeHB_: bear in mind one of the key reasons the Miller paper advocated binning (at least in the single-input simplified case) was to reduce the adversarial advantage from heuristically identifying the spent bin because of a bad distribution choice 20:45:07 At that point, the signer ambiguity is still at the level of the bin size 20:45:24 (1) What does the spend time distribution look like for other multiple other cryptocurrencies like BTC and transparent Zcash. Why multiple? I don't just want to see the distribution for one, I want to understand how representative it is and how much it varies across different coins 20:45:31 as opposed to a single output 20:46:21 (2) use the egregious decoy transactions (exhibit 1: uniform selection, exhibit 2: cached decoys, exhibit 3: links from by MonKon talk) to identify real spend times in Monero 20:46:42 There's enough obviously spent outputs (from a statistician's perspective) that we should be able to generate a pretty large data set 20:46:55 Isthmus: are you familiar with the data presented in the Miller paper? 20:47:04 Oh yea, I read it like once every 6 months 20:47:08 haha ok 20:47:15 Now, we don't know for sure whether these sore thumbs representative of general activity 20:47:18 I was gonna say, 1+2 is basically "do Miller again" 20:47:30 but with more sources 20:47:35 Yea, I just have more heuristics with more teeth :- ) 20:47:44 We've advanced chain analysis significantly since then 20:48:20 Because I wonder if, even armed with this extra data, there are good general rules beyond "build shuffled bins, select them using an estimated spend distribution, and that's it" 20:48:22 So the last strategy (3) is to take the transactions that appear to have the correct decoy algorithm matching core wallet implementation (assessed by offset-corrected median ring member age) and then subtract those from the observed distribution 20:48:32 (and reuse all bins across inputs) 20:49:23 This won't tell us anything about a *particular* ring, but across 13404422 ring signatures, the difference should paint a pretty accurate picture of the real Monero spend time distribution 20:50:02 OK, so assume you have that distribution in hand 20:50:08 What do you want to pull from it? 20:50:45 Our decoy selection algorithm should mimic the ground truth spend time 20:51:07 Sure, but we already know that doesn't play well across inputs 20:51:17 So now we also have the hypothetical advantage of 128-512 rings 20:51:44 Also assume that reusing inputs/decoys across rings is more efficient to verify (it is) 20:52:15 Oh I'm tacking theory for single ring before cross-ring stuff xD 20:52:27 I guess that's bad of me 20:53:07 Anyways, gotta bounce back to work stuff, will meditate on large rings laater 20:54:22 roger 20:59:48 Earlier I figured out how to hide the true distribution inside another distribution, but that only works if the true distribution is unknown. 21:01:37 only hides if the true dist is unknown to analyst* 21:02:33 We should assume a reasonably-accurate distribution is known (at least its general form, if not parameters) 21:03:00 The parameters we use in practice are from Miller, assumed to be "nothing-up-my-sleeve" values (or something reasonably so) 22:50:49 i still think it'd be worth it to have those values updated every 6 months or so 22:51:10 the market today is not the market in 2017, and the velocity of money largely determines spendtime... 22:51:20 one of the stupid things about spendtime is that it's sensitive to economic conditions 22:51:49 a depression is when spendtimes are long, and a bubble occurs when spendtimes get shorter; picking a single distribution to capture both regimes is not a smart way around the problem 22:52:15 but ya gotta pick *some* spendtime 22:56:45 The methods should also be consistent and reproducible 22:56:52 All NUMS values