03:34:23 Monero takes privacy seriously. Monero needs to be able to protect users in a court of law and, in extreme cases, from the death penalty. 03:34:27 Sounds serious 06:24:14 Where is that from? 11:23:09 Atomic swaps based on h4sheds methods was added to Particl, not sure if there’s anything of interest for us there: 11:23:09 https://particl.news/monero-and-particl-atomic-swaps-775f87f6208a 11:23:09 https://github.com/tecnovert/xmrswap/ 11:52:57 Was already shared in Reddit, I’m a bit behind the curve these days 😅 13:24:24 Reminder that our research meeting is today at 17:00 UTC 13:24:44 I'll be sharing some timing results from the new Gray method for Triptych and Arcturus 13:25:12 and I also shared my code with the Zcoin team, since the method would apply to Lelantus as well, with different efficiency 13:25:34 * sarang starts typing lots of numbers into a plot 13:53:22 Results: https://docs.google.com/spreadsheets/d/e/2PACX-1vROJzzfsOnkvxdsrQJgbYwdU2tlNYRJZVKGUAc6KswBGkaPduva-9-Yr6ACWF3Nu_-0I9q5Wt9MaUi7/pubhtml?gid=1695886143&single=true 13:58:20 so verification time is O(N) for all these? 13:58:29 hmm, looks a bit sub-linear to me 13:59:09 Verification is `O(N/lg(N))` in the input set size 14:02:30 lg is always log10 in English right? 14:03:36 Nope, I use the convention that `lg == log2` 14:04:00 ok 14:04:02 Triptych and Arcturus can use any base for the decompositions, but this work assumes base-2 14:04:45 Proof sizes for input set size `N = n^m` have proof elements scaling as `m*n` and others scaling as `m` 14:05:03 er, `m*(n-1)` actually, for the former 14:06:25 Using large fixed anonymity sets shared between proofs can help efficiency, which is what Lelantus is doing 14:06:37 But there are usability and security implications to this 14:06:47 I'm assuming that we share input sets only within transactions 14:07:15 You could get clever and do some partial batching for transactions sharing some of those sets, but this assumes a sort of worst-case verification scenario 14:09:21 One of the data points seems like an outlier 14:09:33 probably just a timing fluke on the test machine; I'd ignore it 14:43:50 methinks a linear y axis would be more telling 14:50:10 It still will look like a bunch of lines that are really close together, since it scales up so quickly 14:51:20 The point is that Gray doesn't always win, and that the benefits are highly dependent on how you construct and verify proofs, and on how you choose input sets across proofs 14:51:34 For something like Lelantus, they use giant windowed sets 14:51:51 But this has implications for spend heuristics and usability that are subtle 14:52:21 It will be very interesting to see what results the Lelantus team finds in any experiments they do 14:53:18 Looking at these charts... It looks like they're all linear, so it mostly depends on the quality of their implementation. Code optimizations can turn the tables. 14:55:30 Yeah, a lot of this depends on things like how inversions are performed 14:55:56 While you shave off a lot of scalar-scalar operations when computing certain coefficients, you replace that with an expensive inversion process 14:56:06 and you obviously want to reduce the number of times you have to do this inversion 14:56:51 We could get a lot of benefits from doing Zcoin-style large sets, but this could get complicated pretty quickly 14:57:00 and the security implications are bit iffy IMO 15:49:16 Research report is available: https://www.reddit.com/r/Monero/comments/j2oncd/september_monthly_report_from_sarang_noether/ 15:49:17 [REDDIT] September monthly report from Sarang Noether (self.Monero) | 1 points (100.0%) | 1 comments | Posted by SarangNoether | Created at 2020-09-30 - 15:48:27 15:49:42 good bot 16:50:47 If I do something like a sweep_all that only requires 1 output, and the wallet (as required by consensus) adds a second dummy output, what does it use for the address of the dummy? 16:51:05 (of course, this is a wallet-level design decision, and nothing that can be observed or enforced by the protocol) 16:51:11 It is randomly generated afaik 17:00:11 All right, time for our meeting! 17:00:19 First, greetings! 17:00:20 Hi 17:00:33 Hi 17:01:08 * sarang waits a few minutes for folks to arrive 17:01:37 hello 17:01:41 Hi 17:02:38 hello 17:03:32 Salutations 17:04:46 OK, let's move to roundtable, where anyone is welcome to share research topics of interest 17:04:51 Does anyone wish to begin? 17:05:37 If not, I'll go first 17:05:46 You can read my monthly research report here: https://www.reddit.com/r/Monero/comments/j2oncd/september_monthly_report_from_sarang_noether/ 17:05:47 [REDDIT] September monthly report from Sarang Noether (self.Monero) | 26 points (97.0%) | 5 comments | Posted by SarangNoether | Created at 2020-09-30 - 15:48:27 17:05:59 It's the last report for my funding period 17:06:18 This past week, I gave a talk for the MCC virtual conference on privacy 17:06:22 and participated in a panel on privacy 17:06:48 I took cargodog[m]'s idea for `n`-ary Gray codes and build working prototypes for both Triptych and Arcturus in Python and in C++ 17:06:56 and shared some timing results earlier today 17:07:13 I also updated the Triptych code for more efficient batching across proofs within the same transaction 17:07:17 That's about it for my update 17:07:28 Hi (sorry I can't attend today, have a good meeting) 17:07:39 I assume you have no ETA on the MCC videos being released? 17:07:42 No problem h4sh3d[m] 17:07:49 I don't know what their plans are for videos, sorry 17:07:57 I know they were recorded though 17:08:04 did you publish the slides anywhere? 17:08:32 No, but I can post them later today if that's useful 17:09:04 They needed Google Slides, so I can post a PDF but not any source code for them 17:09:39 Were there any other questions on my research topics? 17:11:47 Here are the MCC slides: https://github.com/SarangNoether/talks/tree/mccvr-2020 17:12:09 OK, does anyone else wish to share research of interest? 17:13:59 Quiet channel today! 17:14:40 If not, I can discuss the Gray code stuff a bit more 17:14:45 Here is a timing plot: https://docs.google.com/spreadsheets/d/e/2PACX-1vROJzzfsOnkvxdsrQJgbYwdU2tlNYRJZVKGUAc6KswBGkaPduva-9-Yr6ACWF3Nu_-0I9q5Wt9MaUi7/pubhtml?gid=1695886143&single=true 17:15:01 I haven't put it into `gnuplot` yet 17:15:35 There's an outlier data point for the `Triptych Gray 2-2` dataset that's just a timing fluke, and can be safely ignored 17:15:41 (dashed blue line) 17:15:44 sarang: with respect to MCC videos -> https://www.reddit.com/r/Monero/comments/j074ro/sarang_noether_of_the_monero_research_lab_will_be/g6t0egm/?context=3 17:15:45 [REDDIT] Sarang Noether of the Monero Research Lab will be speaking at the Magical Crypto Conference today at 1:15 PM EDT (Privacy: The Collision of Theory and Practice) and 1:55 PM EDT (Is Bitcoin Falling Behind on Privacy - Panel) (https://www.magicalcryptoconference.com/2020-vr#agenda) to r/Monero | 73 points (97.0%) | 13 comments | Posted by dEBRUYNE_1 | Created at 2020-09-26 - 14:37:48 17:16:33 If anyone has issues with differentiating the colors, please let me know here (or DM me) and I can provide a version with better color accessibility 17:16:48 Thanks dEBRUYNE! 17:17:14 np 17:17:20 Our use case for the Gray results in Triptych/Arcturus is to use common input sets within transactions, but not necessarily between proofs 17:17:35 This is distinct from something like Lelantus, where they intend to reuse large common input sets across many proofs 17:18:07 For our use case, the Gray method only starts "winning" between 64-128 sizes, and is different as you increase the number of inputs 17:18:20 This input-based advantage can be removed if we were to overhaul the way inversions are performed 17:19:12 And as you can see, while there is an improvement for larger input set sizes, it's reasonably marginal (single-digit percent decreases in time) 17:20:20 I shared my code with the Lelantus team; they may wish to conduct their own timing experiments based on their particular use case 17:20:38 looking at that plot now. very nice 17:20:39 and it sounds like cargodog[m] intends to add this to their own Rust implementation of Arcturus 17:20:40 Where can I read about the Gray code idea after being out of the loop? Meetings logs? 17:20:52 One sec binaryFate, will get some links for ya 17:21:05 https://github.com/cargodog/arcturus/issues/19 17:21:19 thanks! 17:21:20 cargodog[m] had implemented a binary Gray code method for their Groth/Kohlweiss proof implementation 17:21:38 and speculated that it could be useful for the Bootle optimization used in Arcturus/Lelantus/Triptych 17:22:12 I implemented the idea using `n`-ary Gray codes for Arcturus and Triptych in Python (for prototyping) and in C++ (for timing) 17:22:37 Kudos to cargodog[m] for this super clever idea 17:23:14 it does look like mostly a wash 17:23:34 By switching from standard `n`-ary decomposition of integers to `n`-ary Gray decompositions, you simplify the multiplications used in computing certain scalars, but replace with an expensive inversion process whose complexity can be amortized 17:23:43 It's a wash for this particular kind of input set choice 17:24:02 But for other applications can have much better improvements 17:24:27 Any differences in transaction size? 17:24:30 No 17:24:37 Transaction size is identical 17:24:44 it's only how the proof elements are computed that changes 17:25:12 So a very small improvement in verification time 17:25:35 For the current use case of non-overlapping input sets between transactions, yes 17:26:08 Even with this use, it would be possible to overhaul the code to batch the expensive inversion across unrelated proofs, which I did not do here 17:26:16 So a batch would require only one such inversion 17:26:30 However, if the input sets don't overlap, I think the benefit to this would be fairly minimal 17:26:49 You really see the efficiency if you batch many proofs with the same input set, and also batch the inversions 17:26:58 As you can see, it gets really subtle 17:28:14 thinks 17:28:40 Anyway, this provides some reasonable timing data for this idea 17:29:04 I look forward to seeing the results of any experiments that cargodog[m] or the Lelantus team conduct 17:29:23 Since cargodog[m] uses a more efficient crypto library, and the Lelantus use case for batching and input sets is very different from ours 17:30:36 At any rate, it's a very interesting idea 17:30:51 and it was a fun challenge to implement for this experiment 17:33:46 cool work 17:35:08 btw ArticMine where are you at with the fee proposal? 17:36:14 it sounded like you were planning to reassess some aspects 17:36:20 The question I see is spam risk. 17:36:44 Which I feel for the most part can be mitigated 17:37:18 Then we can mover to using the long term median as a penalty free zone 17:37:49 Which effectively allows for very stable fees 17:38:12 The key is that for a Big bang attack it is neutral 17:38:43 since once the LT median moves then Big Bang moves on 17:39:17 ah my suggestion was to use the long-term-median for penalty zone, and let the penalty free zone fluctuate, are you thinking the opposite? if the penalty zone fluctuates then fees will fluctuate more 17:39:23 It is maintaining the sort term median that deters big bang 17:40:23 Yes using the LT median as the penatly free zone 17:40:27 can you elaborate what the "spam risk" would look like? 17:40:49 Basically there are tow cases 17:41:49 1) For a pre existing Big Bang attack there is no change since it does not make sense for the spammer to maintain the long term median 17:42:51 2) If the short term median falls below the long term median then it crease a similar situation to what we have now but at much higher block size and price 17:43:22 So the cost of spamming node relay f=minimum fee is much higher 17:44:37 There would be no penalty to get back to the long term median as there is now no penalty to get to 300000 bytes 17:45:02 but the cost of the spam in real terms would be much higher than ti is now 17:45:30 It is a much simple solution also than what we have now 17:45:42 SO the code wold be simpler 17:46:14 Ill have to think about this a bit 17:47:43 It comes down to can we have 100x the transaction rate and no increase in price 17:47:56 I do not think that is realistic 17:48:11 agree with you 17:50:06 So the cost of the ham in real terms remains the same, but the cost of the spam for a given % increase in block weight increases with price 17:53:13 OK, any other research topics to address before we end the meeting? 17:53:33 Any interest in setting block size by encrypted miner vote? 17:53:33 (which would boil down to the Nakamoto consensus assumption that 51% of miners will behave in the best interest of the network) 17:53:33 An Insight Fellow is playing around with building an noninteractive ZKP mechanism for this, based on Pallier encrypted voting 17:54:00 Oh interesting; I did not know this was happening 17:54:14 (each block contains one trinary vote for {decrease, same, increase}) 17:54:16 what benefit would this bring? 17:54:46 Miner can effectively put a limit themselves any way 17:55:16 Any human input sounds like degrading from a purely algorithmic solution, but this is certainly interesting research 17:55:34 @sgp Well right now in 2020 we're trying to figure out a dynamic block size algorithm that produces desirable results in 2030, but I dunno how big transactions will be, how fast internet will be, how much transaction volume we'll have, etc. 17:55:34 So if we go with encrypted miner voting, then 2030 block size is set by 2030 miners, instead of 2020 researchers 17:55:58 And miners would have the best understanding of how much their infra can handle before blocks get too big, etc 17:56:17 so this would overrule existing restrictions? 17:56:35 With the current situation the miners can still limit the block weight 17:56:41 Miners can choose to make smaller blocks than the algo allows, but cannot choose to make bigger blocks than the algo allows 17:56:45 So it's one-sided 17:56:54 @sgp - doesn't have to. 17:57:09 Could be that we have a dynamic algo, but miners can vote some change on top of that 17:57:25 Right now it's just a toy, haven't worked it into a fully functioning secure economic model yet 17:58:20 Miner voting has only been proposed in cois that have a fixed block size such as Bitcoin 17:58:31 and Bytecoin 17:58:44 when the block reward falls to zero 17:59:25 Interesting, in those systems, what are they voting on/for? 17:59:39 Blocksize 18:00:08 In Ethereum max gas consumption per block 18:00:46 Ah yea, each ETH miner can vote +1/1024 or -1/1024 if I recall correctly 18:01:00 Hmm ArticMine using the long term median for penalty free zone still leaves us with minimum fee issues. Namely issues around if the short term median collapses then transactions with pre-collapse minimum fees will be invalid. That's unless we set a floor on the min fee based on the long term median. Doing that may make perfect sense actually, since if the short term median is low then you are unlikely to be 18:01:00 filling the penalty free zone anyway (assuming PFZ is now based on long term median). 18:01:40 or ceiling* I guess 18:02:29 The fee is set effectively by the long term median because the penalty free zone is a floor for the short term median 18:02:48 Especially because Monero makes a point to be mined on generic hardware, I would not assume much long-term interest or economic self-benevolence from Monero miners 18:03:07 aren't there dangers of cartelization if block size is based on voting? since you can force up the fees 18:03:08 It's different from what you would expect from miners who bought specialized hardware for other coins 18:03:43 aren't there dangers of cartelization if block size is based on voting? since you can force up the fees <--- Very much so 18:04:24 "aren't there dangers of cartelization if block size is based on voting? since you can force up the fees" <--- this is the case now too, right? If lots of miners decided to voluntarily suppress block size, or something like that? 18:04:28 but it is the only option to a fixed block size for coions with falling emission 18:05:04 Cartels fail eventually 18:05:12 heck it's even worse than cartelization since the incentive to vote for small blocks is presented to all miners; cartelizing just forces out transactions not other miners 18:05:49 cartelizing nowadays is a losing proposition since other miners will just take the remaining tx 18:06:31 so the cartel has to operate at a loss unless they have a serious competitive advantage, but even then it's dubious 18:06:47 The way we implemented it, 501 of 1000 miners must vote for any block size change, so the cartel must be > 51%, implying failure of Nakamoto consensus asssumption 18:06:52 (again, that's just our toy version) 18:07:31 to clarify: a block size change will not occur unless >51% of miners voted for it 18:08:02 Anywho, once it's finished up, I'll share a link here 18:08:07 Sorry to derail the convo past time 18:08:18 Good discussion! 18:08:30 Let's go ahead and adjourn, and discussions can of course continue 18:08:42 A reminder that today is my last day of funded research 18:08:52 Anyone else is welcome to lead future research meetings if they wish 18:09:08 Thanks to the community for ongoing support of research; it's greatly appreciated 18:09:15 <3 <3 <3 18:09:23 This is just about prodding people to share/discuss what they worked on recently, right ? 18:09:34 Anything else ? 18:09:38 It's whatever this channel wants it to be 18:10:09 That's what makes communities so interesting... they get to decide what they want to be 18:10:14 Hey sarang, I know you are done with your proposal now, but you are truly amazing to work with, and you are without a doubt one of the greatest assets to Monero, ever. Words can't express how grateful I am. 18:10:28 I will try to if noone does it. If I remmeber :) 18:10:35 I appreciate that sgp_, and I appreciate you as well! 18:10:46 * moneromooo agrees, sarang kicks ass 18:10:50 :D 18:10:53 thanks, everyone 18:11:29 shall we keep the same rythm for the meetings as a default get together & share time? 18:11:31 I will not regularly check IRC, but I am available if needed by email at sarang [dot] noether [at] proton mail [dot] com 18:11:45 Isthmus my revised point is that there doesn't need to be a cartel in a block voting scenario, since all miners are economically incentivized to vote for small blocks. Even solo miners. If the vote fails, it doesn't affect them. However with an algorithmic dynamic block size all miners who 'vote' for small blocks by ignoring transactions are directly penalized with the opportunity cost. 18:12:11 Ahh I see what you were saying 18:12:14 * Isthmus nods 18:12:38 sgp_: +1! 18:12:40 I second sgp_'s words 1000%. Best wishes for whatever you're planning your life to look like this month and next. 18:13:24 Two hips and a hooray for sarang :) 18:15:00 All the best sarang. It has been an absolute pleasure working with you 18:16:18 thanks sarang 🙏 18:16:28 This community has more than its fair share of badass contributors; thanks for all the support and collaboration :) 18:18:19 Meeting logs posted: https://github.com/monero-project/meta/issues/513 18:18:24 Sorry I missed the meeting, got caught up in something else. Wish you the best sarang! 18:18:29 thanks cargodog[m] 18:19:02 I miss everyone already :/ 18:19:10 and it's been like 4 minutes 18:19:29 dang sarang 18:19:33 Its never too late to come back ;) 18:20:29 I'm not usually a very emotional guy, but hot damn... 18:21:26 MRL fam forever 18:21:51 enjoy the break but come back around visiting community and friends if nothing else :) 18:23:09 I'll obviously leave my GitHub up so code and research stays available for anyone who wants it 18:23:35 good I'll be sure to peper it with issues from time to time just to poke you 18:24:39 It's never too late to change your mind :D 18:24:54 And why would you leave IRC :c 18:31:40 ArticMine: are you planning to write up your updated algorithm recommendations? 18:33:00 sarang: It has been an absolute pleasure to have you working in the community - you brought very important legitimacy through your research and sharing. On a personal note, thanks for answering my silly n00b questions with nothing but patience and courtesy. You will be missed. A lot. 18:33:35 It's been my honor to be a part of this community 18:34:03 ArticMine: are you planning to write up your updated algorithm recommendations? <--- Yes. 18:34:47 I should have it finalized in the next two weeks 18:36:25 sarang: Have you revealed where you'll be going next? Whoever gets to work with you is getting a great addition to their team. 18:37:10 I'm not totally sure what my future plans will be 18:44:57 Thanks for everything sarang. Will be weird to not see your name popping here and there 18:45:26 <# 18:45:33 s/#/3 18:45:33 sarang meant to say: <3 18:45:37 good bot =p 18:46:04 Can another chanop remove my op privileges from this channel? 18:46:08 It doesn't seem appropriate to retain them 18:46:14 moneromooo etc. 18:46:30 Also from #monero-research-lounge plz 18:47:21 I don't know if I can remove my own op privileges 18:47:36 I am op just in -lounge from yesterday. I can remove it if you really want but I see no harm in leaving it as is for now. 18:47:51 It's ultimately up to the channel 18:48:00 IRC op have nothing to do with funding or working status, it's just about trust. 18:48:05 ok 18:48:13 Don't see a reason to remove you unless you want it 18:50:14 Don't see a reason either to remove it 18:50:47 I don't think sarang will abuse it lol 18:51:09 And I'd consider it a nod to hoping he comes back :) 18:52:23 Pretty sure I've banned maybe one user, and it was clearly a spambot 18:53:20 I think it's very fortunate that there hasn't really been a need to kick/ban anyone besides spambots in the channel 18:54:22 Moderation isn't just about taking action, it's about setting a cultute 18:54:27 Culture* 18:54:28 moneromooo: I do recommend having at least one other op in -lounge, but it's up to the group 18:54:41 Well said needmoney90 18:55:40 In general there is very little disruption in any of the monero channels, so moderation is pretty light. 18:56:45 Sure, but I think it's useful and good for accountability not to have a single op 18:57:11 AFAIK the core team can give ops to whoever they see fit on any monero channel. 18:57:36 True, they have some kind of special status with freenode 19:01:38 correct 19:02:43 not meddling with each channel policies (unless OPs go bonkers and infrindge freenode rules and paint a bad picture on Monero) but easy to get back a channel without OP or other practical issues 19:09:12 sarang today is a sad day, you've been so core to monero's progress that i'm struggling to comprehend you won't be full-time any more. thanks for all of your awesomeness! 19:16:25 Completely agree with Knaccc 19:16:54 Lots of smart guys around here, but you are towards the top of the pile 19:19:01 Thanks everyone; these kind words are really appreciated 19:34:53 what if a company hired you to work on xmr/crypto research full time? 19:35:52 or does burnout mean you want a change in scenery? 19:46:14 I certainly need some time off from research; because I never included vacation time specifically in my funding proposals, I didn't really take proper time off 19:46:37 This was probably a mistake in hindsight... but at the same time, would donors really want to fund time off? 19:47:24 The work has certainly been appreciated, and I'd like to think the donors would be fine funding some time off as part of the proposals, particularly if you return in the future. :) I'd like to think most of them are reasonable people who like their own time off from work projects. 19:48:01 If a company hired me to work on open privacy research full time with longer-term stable funding, perhaps that could help to provide a healthier work-life balance, but I suppose it would depend on the particular circumstances 19:49:48 sarang: I think donors would definitely symphatize with, say, 1 week off per quarter 19:51:44 At any rate, this community has many excellent researchers, developers, and other contributors 19:51:59 And there are certainly interesting funding proposals on the table presently 19:52:18 It may be helpful to revisit the Bulletproofs+ proposal 19:52:29 I had hoped to complete a C++ implementation, but did not end up having the time to do so 19:52:39 I did produce a Python prototype, FWIW 19:56:54 ❤️ 20:03:27 Gonna miss sarang. I know you will do well in whatever you choose next, whether that’s crypto or teaching or whatever. When one door closes, another door opens 20:04:15 If I can bear witness, it will be really exciting to see how you grow over the years to come 20:06:12 Thanks kenshamir[m] 20:06:20 It's been a pleasure working with you 20:06:24 If you do return, I think it will be with a new outlook on life and maybe even some new ideas on crypto. Yeah, I do hope that I will be able to follow your growth 20:06:48 You’ve taught me a lot, it was a pleasure working with you :) 20:11:06 I do also believe that maybe this should be a catalyst for the community to think about long-term stable funding for their most valued people 20:11:34 However, this probably goes against Moneros ethos as you would need some sort of company to take care of the logistics 20:17:30 Maybe it is a necessary trade-off that needs to be made to attract new cryptographers and software developers and keep them for the long haul? 20:40:41 yeah some more long-term funding for cryptographic research sounds like an excellent idea 20:47:33 Also with the explicit understanding that not all research will produce tangible deliverables. Not really sure how sarang and the others are/were managing to do it, as most research leads to dead ends and failures 20:47:55 They certainly had some amazing success :) 20:49:47 Also with paid time off, or some understanding around vacation times. 20:49:47 I think with the above, a cryptographic researcher would certainly be appealing to postgrads and rogue cryptographers. Not my area of knowledge, so no idea how feasible this is to pull off 20:51:44

Yeah exactly haha, I think it implicitly shows how hard they are/were working for Monero 20:53:04 It would be really cool to have a way to get someone like that over to a 1 year and maybe even a 3-year gig, with decent renewal in good time 20:56:56 Yeah definitely, if I can speak even out of place, I think it would be worthwhile to fund sarangs time off now. I for one would definitely contribute as the less work he has to do during his timeoff, the easier it would be for him to recuperate. Even if he chooses to go somewhere else, it would be a sign of good faith to the invaluable work he has done 21:05:41 I would support it 21:13:08 +1 21:24:04 Okay good currently three people. I don’t know how CCS works, probably can point it to sarangs stealth address which is somewhere on the repo 21:24:49 Will wait to see if anyone else will +1 21:30:09 I would also support it 21:42:35 Me too 21:42:49 Perhaps as a gesture of good will, the community can fund, say, 1 month of vacation for sarang 21:42:58 Then he can properly rest and also doesn't need to worry about the bills for that month 21:44:20 We need to take into consideration the length over service over 6 years. 21:45:16 I really need to give some thought to what an appropriate amount would be. 21:45:51 Yeah if possible, I was thinking the quarter 22:06:52 ArticMine: I suppose we can look at some European countries what they typically grant for vacation days 22:06:56 I think it's 4-6 weeks per year 22:11:21 Crypto industry standard in SF is also 4-6 weeks/yr off for vacation 22:11:21 I encourage my researchers/engs to take real vacations and truly unplug. I want a team of happy / healthy researchers, not a bunch of burned out drones with maximum hours of labor per dollar. You get more bang for the buck with the former, anyways. ;- ) 22:11:42 Speaking of, one of our engineers came across this: https://github.com/monero-project/monero/blob/3cbb44a2fd79ce9c667006e2e42e61513993e59a/src/cryptonote_basic/cryptonote_basic.h#L449 22:12:06 in `struct block_header {... ` there is a note `uint8_t minor_version; // now used as a voting mechanism, rather than how this particular block is built` 22:12:42 Have we ever used minor_version for voting? 22:12:57 * Isthmus summons @n3ptune to find anomalous use of the `minor_version` field 22:13:03 Not on mainnet. It was shit and buggy. 22:13:27 ArticMine: Do you intent to write some kind of proposal btw? 22:13:52 It's used to gauge the amount of nodes which are ready to follow a fork atm. 22:14:02 Well, the amount of hash rate really. 22:14:31 I want first to listen to the comments. 22:15:11 That makes sense. In recent upgrades over the past few years, do miners change `minor_version` in practice to signal preparation? 22:15:11 Is its use for this purpose in the wild uncommon/mixed/common? 22:15:29 Then I would be prepared to make a recommendation 22:16:08 Yes, when they update their daemon. 22:16:31 Coolio 22:16:51 Nothing enforced, right? 22:17:10 I think it's enforced to be >= major version. Not 100% sure. 22:17:24 Oh yea, that would be a logical constraint 22:35:41 Given 4-6 weeks per year, that would mean 6-9 months given 6 years of service. This sounds reasonable to me. We should figure out what the living costs are first. Let’s hope sarang does not live in New York or The Valley :) 22:39:06 I think 2014-2017 was only part time, but we can easily verify that with the CCS/FFS history 22:41:27 We can use the CCS/FFS history and the historical XMR / USD exchange rate. Then adjust the USD amount to 2020 USD to adjust for fed printing and we would be close 22:42:04 Then we have a basis