01:36:17 Isthmus: is it economically in the interest of miners to increase block size? what if they make more in fees from small blocks? 11:58:15 would that be 100 miners, or 100 mined blocks (several of which could be the same miner/pool) ? 12:15:48 my take is that miners will always act in the best interest of themselves, and the protocol just needs to make those interests align with the interest of the network. 12:16:46 see: selfish mining, 0 tx block mining, block withholding (though i guess thats selfish mining), ASICs 12:22:59 Thats the whole incentive system in the current dynamic blocksize system -- if there are more fees to be collected in the mempool than the subsidy penalty for increasing the blocksize, miners will increase blocksize to make more money from tx fees. 12:23:51

It would be a vote per block, kind of like signalling for an upgrade in Bitcoin, so likely would be split across pools/miners roughly proportionate to hashrate. 12:24:23 Isn't this similar to how Ethereum handles gas limit increases? Don't miners vote for that to change it without any dev intervention? 12:26:51 https://www.etherchain.org/tools/gasLimitVoting 12:28:52 i mean, as it stands, creating a block above the median *is* a vote to increase the blocksize. 12:29:24 "Currently, due to a lack of clear information about how miners will behave in reality, we are going with a fairly simple approach: a voting system. Miners have the right to set the gas limit for the current block to be within ~0.0975% (1/1024) of the gas limit of the last block, and so the resulting gas limit should be the median of miners’ preferences. The hope is that in the future we will be able to 12:29:24 soft-fork this into a more precise algorithm." 12:29:55 Yeah, the "signalling" method would just be a clearer/delayed way to do it (which is probably against the core idea of dynamic block sizes) 12:30:19 If there is a 100 block delay on a change, you lose much of the short term flexibility in the block size adjustments. 12:30:41 What if the rush is less than 100 blocks long? 13:50:10 To be clear, people are discussing how to dynamically increase the blocktime on the protocol level in the case where blocksize increases would lead to unstable orphan rates? 13:50:18 Tricky problem 13:51:35 As increasing both are eventually needed for on chain scaling but making them both dynamic means there is no actual reliable constant to the ticking of the blockchain 13:53:48 And unlike block size, there is an upper limit on acceptable block time (regardless of HW improvements) for purposes of confirmation time 14:36:11 Hello all 14:36:18 Remember meeting today at 17:00 UTC 14:36:28 I'll be working on BP+ fast verification via recursion unrolling 15:28:40 sethsimmons: yep that’s how Ethereum handles it, except the votes are plaintext 15:29:50 (And therefore don’t have to be windowed) 15:31:34 Note that the block size could be responsive to short surges within the window 15:32:24 Our current algo already has long-term (slow-moving) baselines that support short-term spikes on top of that 15:32:41 The miners would just vote for the former, and we leave the mechanism for the latter 15:33:09 s/leave/retain 15:33:09 Isthmus meant to say: The miners would just vote for the former, and we retain the mechanism for the latter 16:52:41 Meeting begins here at 17:00 UTC (about 10 minutes from now) 16:52:42 .time 16:52:42 2020-08-19 - 16:52:42 16:53:06 Agenda: https://github.com/monero-project/meta/issues/499 16:56:13 sarang what we really need is a surreal number curve 16:57:22 Verification takes place in the Twilight Zone 16:57:32 LOL 16:58:02 proof of life 16:58:20 mining is actually a set of go endgames 17:00:00 All righty then 17:00:06 Let's begin our meeting 17:00:19 The usual agenda: https://github.com/monero-project/meta/issues/499 17:00:27 As always, logs will be posted there after the meeting 17:00:34 First, greetings! 17:00:35 hi 17:00:41 ullo 17:01:02 * sarang will wait a couple of minutes for others to arrive 17:01:28 holup can't find my goggles 17:01:58 safety first 17:02:21 Oh, under the bed, of course... 17:02:21 /me puts on goggles and lab coat 17:02:23 Okay, let's roll 17:02:53 nice hair 17:03:10 * Isthmus closes webcam cover 17:03:26 OK, next up is the roundtable, where anyone can share research topics of interest 17:03:33 Does anyone wish to go first? 17:04:49 sarang first 17:04:53 If not, I have a few items to share 17:04:55 sarang is all you need 17:05:19 I'm in discussion with an ISO-affiliated standards committee in the U.S. regarding blockchain-based privacy 17:05:27 hello 17:05:42 The goal is to provide accurate technical information about the field 17:05:51 More on that as it develops, I suppose 17:05:55 interesting 17:06:04 I made some small updates to Arcturus/Triptych code for better storage efficiency 17:06:16 sounds like formalizations of traceability and taint etc will he useful 17:06:17 be 17:06:24 Reviewed a delightful Triptych article by the outreach workgroup that I look forward to seeing posted 17:06:38 Got a few PRs out the door relating to transaction proofs and message signing 17:06:56 One PR, for key encryption, was reverted since its tests were not properly capturing necessary functionality 17:07:15 Anyone who happened to test this will find that their wallets work just fine after the reversion (or prior to applying the PR) 17:07:28 Thanks to selsta for identifying this problem 17:07:42 And finally, I have working proof-of-concept Bulletproofs+ code 17:07:51 Initially, the weighted inner product proving system 17:08:04 Additionally, aggregated range proofs and a more efficient recursion-unrolled verifier 17:08:18 love that you are doing that code :P 17:08:20 That's progressing quite nicely and working precisely as intended 17:08:34 I'm working out the full batched BP+ stuff in stages, as I did for BP and some related projects 17:08:41 Thanks endogenic! 17:08:47 can i ask again if it'd help to have a coder at your side to do your bidding? 17:08:58 I expect to have the full Python-based batch stuff soon, after which migrating to C++ should be straightforward as well 17:09:17 endogenic: certainly, as I'm sure there are small optimizations in C++ that would be helpful 17:09:24 I should be at that point in a few days 17:09:36 Anyway, that's my update 17:09:38 i found the coder-theorist pair almost overpowered in the past 17:09:46 I'm happy to take questions on any of these topics 17:11:26 Does anyone else wish to share research of interest? 17:12:23 Amy further thoughts on te risk vs return between Arcturus and Triptych. I mean tx size vs the newness for Arcturus? 17:13:13 I don't know a good way to assess the practical risk of the nonstandard assumption in Arcturus 17:13:40 A reviewer seems to stand by their assertion that the assumption is unsafe, though I disagree with their claimed break 17:13:51 and they did not provide any follow-up details beyond standing by their assertion 17:14:03 I'll post the claimed break shortly 17:14:26 I believe they did not properly read the definition 17:15:32 (I intended to post this earlier, but it completely slipped my mind) 17:16:25 curious to learn more about how the assumption is unsafe and the consequences that the reviewer imagines.... 17:16:44 The definition for the assumption has a few conditions on it 17:17:13 and it appears that the reviewer's claimed break doesn't apply to all of them (which is precisely why there are multiple conditions) 17:17:39 The follow-up response was something like "this can be extended" but with no details 17:18:04 ha that is not terribly helpful 17:18:11 looking forward to reading the updated later 17:18:14 thanks 17:18:18 I think the reviewer misread the final condition, which is subtly (but importantly) different than the others 17:18:28 But if there is a problem, I certainly want to know 17:18:36 this is the point of preprints and review! 17:19:07 Are there any other opinions on this? 17:19:30 I know this is real tough 17:20:07 It is tricky 17:20:17 This is why I hope for a reduction to a known hardness assumption 17:20:24 but haven't been able to produce one 17:20:37 Anyway, I'll post the reviewer's comments shortly 17:20:47 (after this meeting; need to hunt down the email) 17:20:47 Thanks so much 17:20:53 np 17:21:30 Nice work as always :- ) 17:21:44 Many thanks! 17:21:54 Does anyone else wish to share research topics? 17:23:18 I have a quick update and a quick half-baked question 17:24:05 Regarding the update, have switched gears to formal documentation. I find this exciting! Instead of "X algo breaks Y feature" we're actually showing step-by-step how mechanism Y could be subverted. 17:24:18 Nice! 17:24:22 Maybe have draft ready for public feedback next week 17:24:29 It's fun to see the play-by-play attacks imho 17:24:31 Super excited to read it :) 17:24:44 To clarify, this assumes a hypothetical future quantum adversary? 17:24:45 that's been missing for a while 17:25:00 No idea about the timeline 17:25:06 Just looking at the algorithms 17:25:16 Timeline for building QCs out of scope of research 17:25:32 Right, I just mean that such attacks are considered infeasible given current known technology? 17:25:43 (to avoid unnecessary FUD and maintain only necessary FUD...) 17:25:54 * Isthmus won't be baited into speculating about the timelines since I don't know about private research 17:26:09 Given PUBLIC technology, definitely infeasible right now 17:26:15 I don't intend to have anyone speculate about quantum computing 17:26:29 Thanks :) 17:26:52 Great point about focusing on algorithms, and not specific computing ability 17:27:17 regardless of public or private research, it's clear that current QC-resistant algos are infeasible on current tech 17:27:34 Well, that's part of this research, no? 17:27:36 nobody is going to run a network using megabyte+ keys etc... 17:27:41 Looking at current research and directions? 17:27:42 challenge accepted 17:28:02 The question I see is given that this is possible some unknown time in the future, what are the possible mitigations? 17:28:07 * infeasible on current classical computers 17:29:43 the only machines capable of running QC-resistant algos will be large servers. adopting QC-resistant algos will thus kill decentralization 17:29:54 Isthmus: out of sheer curiosity, do you know of any other major projects looking into post-QC vulnerability in this level of detail? 17:30:29 I agree with hyc that any proposed post-QC mitigations would need to be balanced against practical considerations, as would any changes 17:30:44 but that seems not to be the primary goal of this work, from how I read it 17:31:16 Having a better understanding of the areas of the protocol that would be vulnerable is useful 17:31:26 as is understanding where research stands today, and where it's headed 17:31:39 RE other projects, AFAIK Monero is leading the pack for pq-privacy research. 17:31:39 But this certainly isn't speaking for Isthmus and his team 17:31:43 Quantum Resistant Ledger has pq-security mechanisms but no privacy mechanisms. 17:31:45 Nice :) 17:31:56 There have been some papers on Bitcoin, but they tend to only look at 1-2 algorithms, nowhere near the comprehensive treatment that we're executing 17:32:01 Yeah, I know of QRL but it seems not widespread at this point in terms of popularity or use? 17:32:32 I met one of the QRL leads at a conference, in fact 17:32:32 They're leaning hard into some cool researh 17:32:46 ZK-lattice, STARKs, and pq-signature aggregation 17:32:48 Isthmus: any good resources on that in particular? 17:32:59 I haven't looked into their specific tech in a while (the conference was a while back) 17:33:19 The QRL whitepaper is actually a pretty easy read and nice summary of security attack surfaces and possible approaches 17:33:30 Isthmus: might be a silly question but will there be a report from the work you are doing? 17:34:17 Side note, https://github.com/theQRL/Whitepaper/blob/master/QRL_whitepaper.pdf 17:34:26 Thanks Isthmus 17:34:27 ^ white paper 17:34:37 Interestingly, they're moving towards RandomX which is about the only pq-secure part of Monero 17:34:46 lol 17:35:24 :D 17:35:27 I did not know that 17:36:58 Yea, they follow MRL research 17:37:05 cool 17:37:06 * Isthmus waves 17:37:30 Anyways, that's about all from me. Technical details next week ^_^ 17:37:35 Great, thanks 17:37:42 Any other topics to be discussed today? 17:37:45 Or questions? 17:38:13 sarang: any updates on the ISO? 17:38:20 Sorry if I missed these... 17:38:32 midipoet: I have not heard back from the person who handles the logistics 17:38:37 but I did speak with the chairperson 17:39:34 He sent along invitations to relevant meetings, and indicated that participating before completing the paperwork should not be a problem 17:39:41 given the delays that might occur 17:40:56 sounds good 17:43:01 OK, let's move on to action items, where anyone can share their research plans for the next week or so 17:43:22 I'll complete BP+ proof-of-concept code with full batching, and then move to a C++ implementation for timing data and comparison 17:43:40 and post the claimed Arcuturus hardness assumption break 17:43:53 Oh wait, I still had a question (bout non pq stuff) 17:44:01 Oh go ahead Isthmus 17:44:10 https://usercontent.irccloud-cdn.com/file/609yOFnf/image.png 17:44:31 https://usercontent.irccloud-cdn.com/file/WkDekAar/image.png 17:44:38 https://usercontent.irccloud-cdn.com/file/DVzt3Gr6/image.png 17:44:59 Raw version for those not afraid of Google: https://docs.google.com/document/d/1TBICG6RFoeTOv-Yn9HEOHvWgSdx2NOtGZ1ckvG9VT8w/edit?usp=sharing 17:45:16 please explain 17:45:23 Stuff in yellow is not expected to be cryptographically random/uniform/etc. 17:45:53 Stuff in green should be all noise, right 17:46:07 No repetition/collisions, etc. No patterns if I comb through, etc. 17:46:13 Correct? 17:46:16 But? 17:47:03 I don't have the `but` yet, just asking whether that is the correct expectation 17:47:29 BP data is expected to be uniform across proofs for different commitments, yes 17:48:02 It's certainly possible to generate non-uniform signature scalars in a valid signature 17:48:31 * Isthmus nods 17:48:32 I assume you're identifying something suggesting non-uniformity? 17:49:04 Note for BPs that AFAIK nothing stops commitment reuse... 17:49:15 and that's not _necessarily_ dangerous 17:49:19 but certainly nonstandard 17:50:16 FWIW all but one signature scalar in MLSAG (and CLSAG) is signer-selected and arbitrary 17:50:26 You can absolutely have a valid signature with terrible scalars 17:50:47 Haven't identified anything yet, still in the hypothesis generation and experiment design phase. 17:50:48 Essentially we will hypothesize that certain fields should be uniform/random/non-colliding, and then look for counterexamples 17:50:53 ok 17:51:06 It's probably important to separate what's signer-controlled and what isn't 17:51:15 ^^ 17:51:20 e.g. almost all MLSAG/CLSAG scalars are signer controlled 17:51:26 the same is not the case for BP 17:51:36 Oh yea, I need 3 categories, not 2 colors 17:51:46 So the MLSAG scalars _should be_ random, but don't _need_ to be 17:51:59 there's additional layers to BP 17:52:29 1) signer controlled, expect patterns (e.g. lock time) 17:52:29 2) signer controlled, but should be random (e.g. MLSAG scalar) 17:52:29 3) output of cryptographic fxn, expected no patterns (e.g. proof outputs) 17:52:53 Interestingly, there was an idea to use a hash function for MLSAG/CLSAG to allow for data hiding or signer identification of the signing index 17:53:03 This would, if implemented, help avoid the case of a bad PRNG 17:53:08 but can't be enforced, of course 17:53:53 Ooh that's interesting 17:54:07 Yeah, I have some example proof-of-concept code for it 17:54:41 You use a hash function for all the signer-controlled scalars, and the remaining one is uniformly distributed 17:54:56 The signer can use this to later recover the signing index, but this isn't public 17:55:05 it's a cool idea 17:55:37 Sweet. 17:55:39 Okay, that's all for today then, I'll work on formalizing and splitting stuff up into the 3 buckets. 17:55:44 Great! 17:55:52 Any other action items, questions, or the like? 17:56:49 If not, we are adjourned! 17:56:53 Thanks to everyone for joining 17:56:57 Logs will be posted shortly 17:57:18 gg 18:03:25 Here is the reviewer's claimed break of the Arcturus hardness assumption: https://paste.debian.net/hidden/518ed57e/ 18:03:33 This is the Arcturus preprint: https://eprint.iacr.org/2020/312 18:04:04 The relevant definition is Definition 1 on page 4 of the preprint 18:05:09 I would appreciate any comments or analysis of this 18:59:22 So if I understand this correctly. In the definition G and H are chosen by the Challenger (Adversary) and sent to A. A then chooses the sets {Gi} and {Hi} subject to the constraints and sends them back to the Challenger. The reviewer has this backwards, with A choosing G and H and the challenger choosing the sets {Gi} and {Hi}. 19:01:34 The question I have is who is the adversary? 19:30:05 In this application, someone trying to build a proof adversarially 19:31:46 I think the reviewer is considering the `G` and `H` bullet-point conditions in the definition the same, when they're constructed differently 19:31:54 Note the index difference, which is important 19:34:11 The interactive challenger choice of the `mu` coefficients is replaced in practice by a hash function via the Fiat-Shamir heuristic 19:34:39 So each `mu` is computed using all the components from the previous transcript steps from the interactive version 19:34:56 Also, the challenger is not the adversary 19:35:34 The adversary is playing this game against the challenger and, if the adversary can win non-negligibly, it could break soundness 22:03:16 Thanks. I see the point about the G and H conditions being different. The reviewer is not providing choices for G