00:33:49 <UkoeHB_> It seems some care was taken to memwipe variables that store private keys as soon as they are done being used (see e.g. construct_tx_with_tx_key()). However, \alpha variables for MLSAG signatures are not memwiped, and they can be trivially used to recover the private key from any completed signature. Should this be updated?
00:34:47 <moneromooo> Yes.
00:35:30 <moneromooo> (either make a patch or point to the variables needing wiping)
00:39:57 <sarang> Last used here: https://github.com/monero-project/monero/blob/master/src/ringct/rctSigs.cpp#L257
00:40:19 <sarang> This alpha: https://github.com/monero-project/monero/blob/master/src/ringct/rctSigs.cpp#L192
00:40:26 <sarang> Probably should be wiped, true
00:43:35 <UkoeHB_> that seems the spot, and even the multisig kLRki \alpha term is copied into that same variable, so it only gets at most two instances within the signing process. I should probably look to make sure kLRki is only passed by reference everywhere else (and that the initial generation of \alpha for multisig is safely handled)
00:45:31 <UkoeHB_> this function also copies it https://github.com/monero-project/monero/blob/0bb7191fd6f138c8b85c65f6b45a9d5fe654838d/src/device/device_ledger.cpp#L1996
00:51:18 <moneromooo> Will you make a patch or should I ?
00:52:20 <UkoeHB_> Can you do it? Im not sure exactly what to do
00:52:54 <UkoeHB_> looking at this function get_multisig_kLRki(), is it safe? https://github.com/monero-project/monero/blob/081d49c59f0f19ee82f0d8e1b33371dc43c37938/src/wallet/wallet2.cpp#L12802
00:53:42 <UkoeHB_> seems to make a new definition of kLRki
00:55:55 <UkoeHB_> wallet2::export_multisig() also
00:57:40 <moneromooo> k is secret, L, R, ki aren't, right ?
00:58:01 <UkoeHB_> correct
00:58:15 <moneromooo> Thanks. I'll patch that tomorrow probably.
00:58:35 <UkoeHB_> ok lmk and Ill review
01:00:27 <UkoeHB_> wallet2::get_multisig_composite_kLRki() also has a copy
01:07:32 <UkoeHB_> transfer_selected() and transfer_selected_rct() has several copies in the src, sources_copy, and sources_copy_copy variables
01:10:02 <UkoeHB_> construct_tx_with_tx_key() has a new kLRki
01:12:59 <sarang> Are you assuming leakage of only alpha, and no other non-sig data?
01:14:25 <UkoeHB_> alpha seems the most important one, although I guess you could wipe everything else
01:15:46 <sarang> I mean in the situation you are considering
01:15:59 <UkoeHB_> Im wondering about the safety of pointer variables as well, although my ability to read c++ pointers is still weak
01:17:04 <UkoeHB_> As I said before "care was taken to memwipe variables that store private keys as soon as they are done being used". Whatever situation that was implemented to counter, is a situation that could also exist for \alpha variables.
01:17:10 <UkoeHB_> Idk what that situation is
01:18:42 <UkoeHB_> This is the original PR https://github.com/monero-project/monero/pull/4268
01:23:10 <UkoeHB_> everything using kLRki in rctSigs.cpp appears to pass by reference
01:26:36 <UkoeHB_> maybe stoffu can comment
01:35:07 <sarang> Are you concerned about `alpha` alone, or in conjunction with other signature input data
01:38:36 <UkoeHB_> alpha alone, since with alpha and the signature output you can compute the signing one-time address's private key
01:39:12 <UkoeHB_> k = (alpha - r)/c
02:36:17 <sarang> A straightforward fix
14:44:41 <sarang> Meeting today is at 17:00 UTC
14:53:17 <TrasherDK1> .time
14:53:17 <monerobux> 2020-04-08 - 14:53:17
16:37:30 <moneromooo> UkoeHB_: https://github.com/monero-project/monero/pull/6441
16:44:50 <sarang> moneromooo: see https://github.com/monero-project/monero/blob/master/src/ringct/rctSigs.cpp#L551
16:45:10 <sarang> Any reason this shouldn't be `memwipe(sk.data(), sk.size() * sizeof(key))` instead?
16:46:01 <moneromooo> I dunno. Are they all secret ?
16:47:15 <sarang> `sk[1]` is a commitment-dependent signing key
16:47:26 <sarang> No reason it should stick around, really
16:47:32 <moneromooo> That sounds like a yes. I'll change it.
16:48:03 <sarang> CLSAG_Gen should get the same scope-dependent wipe on the key `a`
16:48:16 <moneromooo> OK
16:48:24 <sarang> I updated my `clsag-device` branch for it
16:51:29 <moneromooo> Is there a point in me merging anything else for CLSAG now ?
16:55:36 <sarang> Well, the ledger PR remains not fully tested (according to cslashm) until it gets on testnet
16:55:56 <sarang> and the device-specific functions have been already moved out to device_default as well
16:56:11 <sarang> So I'm not sure how you want to proceed, since the trezor functionality is not completed AFAIK
16:58:52 <sarang> OK, time for the weekly research meeting
16:58:57 <sarang> Let's get started
16:58:59 <sarang> GREETINGS
16:59:01 <sarang> hi
16:59:05 <ArticMine> hi
16:59:09 <atoc> hi
17:00:59 <TheCharlatan> ahoy
17:01:00 <sarang> On to ROUNDTABLE, I suppose
17:01:24 <sarang> I've been working on papers for PoPETs submission, which has been a blast
17:01:27 <binaryFate> hello!
17:01:44 <sarang> As well as some review for a paper on hierarchical one-of-many proofs
17:02:14 * Isthmus sneaks in late and grabs a seat in the back
17:02:14 <sarang> Finally, plenty of code relating to Triptych
17:02:23 <sarang> Not too much exciting stuff to report overall
17:02:30 <sarang> Any particular questions?
17:03:33 <atoc> hierarchical one-of-many-proofs sounds interesting. can you link the paper?
17:03:53 <sarang> It's not on the IACR yet (and I am not the author)
17:04:35 <sarang> Otherwise, anyone else who wishes to share research topics is welcome to do so
17:05:05 <binaryFate> what are hierarchical one-of-many-proofs?
17:05:35 <sarang> An extension of the Groth proofs used in Triptych and Lelantus that trade size for prover complexity
17:06:00 <sarang> They use a clever layering technique
17:06:13 <binaryFate> smaller size for increased prover complexity?
17:06:21 <sarang> Other way around :)
17:06:26 <binaryFate> ok :)
17:06:52 <sarang> The author thought there could be verification savings in certain cases, but I don't think that's the case if you do batching in the usual way
17:08:11 <sarang> Does anyone else have research topics they'd like to share or discuss here?
17:08:28 <ArticMine> I can give an update on the scaling and fees issue #70
17:09:21 <sarang> Sure!
17:10:02 <ArticMine> I have a solution for the scaling side and minimum relay fee. I am still finalizing the fee ratios
17:10:29 <ArticMine> Basically we can use the long term medium to deal with this
17:10:32 <sarang> Can you summarize?
17:11:19 <ArticMine> Sure
17:11:43 <ArticMine> 1) Put a cap on the rate of fall of the long term medium so that it falls at the same rate it rises
17:13:07 <ArticMine> 2) Make the penalty free zone dynamic as the greater of 300000 bytes and 25% of the log term medium
17:13:28 <sarang> Will that 300K value change with CLSAG?
17:14:14 <ArticMine> No the reference transaction size will to 2100
17:14:20 <sarang> yes
17:14:33 <sarang> But there are no plans to change the fixed-value penalty-free size?
17:15:05 <ArticMine> The minimum relay fee will  very close to the old normal fee
17:16:00 <ArticMine> So for the current minimum penalty one the minimum fee will actually go up ~2.5x
17:16:36 <binaryFate> ArticMine what issue/risk is this solution tackling?
17:17:04 <ArticMine> A sudden drop in use followed by a recovery
17:17:24 <ArticMine> In many ways similar to COVID-19
17:17:46 <binaryFate> What would be the shortcomings of the current implementation in that situation?
17:17:59 <ArticMine> https://github.com/monero-project/research-lab/issues/70
17:18:16 <ArticMine> This create the scenario
17:18:36 <binaryFate> Ah, couldn't find issue. Thank you
17:19:09 <ArticMine> The basic problem is a sharp rise in fee that can take months or year to come back to normal
17:20:07 <ArticMine> Also a very sudden drop in the long term medium that also could take months or years to recover
17:21:17 <ArticMine> Issue #70 does not mention COVID-19 but COVID-19 is a very good scenario
17:22:27 <sarang> Will you have specific code or pseudocode soon to allow for simulations prior to any recommended deployment?
17:22:48 <ArticMine> Also there are scenarios where COVID-19 cold lead to a significant demand on the Monero network in terms of transactions
17:23:04 <ArticMine> Yes
17:23:37 <ArticMine> I have all the formulas now except for the fee ratios
17:23:44 <sarang> OK, thanks
17:23:44 <ArticMine> Still working on that
17:23:53 <sarang> I assume you'll post them to the issue you linked?
17:24:10 <ArticMine> Yes that is where I will post this
17:24:19 <sarang> Got it
17:24:35 <sarang> Anything else of note that folks wish to discuss?
17:25:35 <sarang> I know UkoeHB_ recently posted his new version of Zero to Monero
17:25:51 <sarang> not sure if he's around right now
17:25:54 <ArticMine> Yes that is excellent
17:26:11 <sarang> but that's on the getmonero library page, along with a link to the TeX source repo
17:26:37 * TheCharlatan applauds
17:27:00 <sarang> and there was also a suggestion from UkoeHB_ for updating how MLSAG secret data is wiped, which was a great catch (PR now available)
17:27:37 <sarang> Anyone else?
17:29:53 <sarang> Otherwise, we can move on to ACTION ITEMS for the week
17:30:27 <sarang> I will be continuing work on a C++ implementation of Triptych for timing efficiency tests
17:31:03 <sarang> as well as some new material for the multi-signer Triptych variant's security model, prior to the PoPETs submission deadline
17:33:11 <Isthmus> Oops, just got back. Nice work Artic!
17:33:32 <sarang> Isthmus: do you have any research or topics you'd like the group to discuss?
17:34:13 <Isthmus> Ah, I've been neck deep in Zcash all week.
17:34:17 <Isthmus> https://twitter.com/Mitchellpkt0/status/1245769462172745728
17:34:17 <monerobux> [ Mitchell P. Krawiec-Thayer on Twitter: "Several unique phenomena in the #Zcash transaction lock_time field. Most make sense: 0, block heights, unix timestamps, delayed broadcast. Still trying to under ] - twitter.com
17:34:26 <Isthmus> We did find that funny transaction over in NRL
17:34:34 <Isthmus> Probably more of a novelty than anything else
17:34:35 <Isthmus> Lemme grab the link
17:34:48 <sarang> Anything relating to the Zcash lock times that's been observed in the Monero network too?
17:34:49 <Isthmus> https://gist.github.com/noncesense-research-lab/a90b8bc5f57ffa9fff1a22d1323e5c2c
17:34:54 <sarang> Or any lessons to learn from the Zcash work?
17:35:10 <Isthmus> Monero's lock times look very similar
17:35:16 <Isthmus> Actually there's also 4 bands
17:35:18 <Isthmus> Like this:
17:35:19 <Isthmus> 0
17:35:31 <Isthmus> {1,3,8,10,12}
17:35:42 <Isthmus> {block heights ~ 1xxxxxx}
17:35:46 <Isthmus> and then UTC timestamps
17:36:06 <Isthmus> It's all over the place, and I don't think any of it is enforced, so the lock_time field is really just an arbitrary memo xD
17:36:13 <sarang> In Zcash too?
17:36:34 <TheCharlatan> Did you analyze the distribution of the UTC timestamps as well?
17:37:18 <Isthmus> Lemme try to find that notebook
17:38:18 <Isthmus> Shoot, I don't have it on this computer
17:40:13 <sarang> No worries
17:40:22 <sarang> Any other action items for the week?
17:41:02 <TheCharlatan> So what's up with duplicate subaddresses?
17:43:02 <sarang> Isthmus: were those the only two such examples?
17:43:12 <sarang> You suggested "novelty", heh
17:43:48 <Isthmus> No, there were several, But all very similar, that one is representative
17:43:59 <sarang> hmm
17:46:53 <sarang> Along those lines, it was suggested (last week, IIRC) to move some of the more standardized tx fields out of extra
17:47:08 <sarang> Which wouldn't eliminate strange behavior, of course
17:47:29 <sarang> but could help with distinguishing factors like ordering etc.
17:47:35 <sarang> Any further thoughts on that?
17:48:39 <Isthmus> I'm working on it a bit, but need to move ideas from my head into diagrams. Will share here in a week or two.
17:49:05 <Isthmus> Might have a new approach, but tbd
17:49:16 <sarang> New approach to what exactly?
17:49:21 <sarang> Transaction structure?
17:50:56 <Isthmus> Nah, mental models that more accurately describe information leaks
17:50:59 <Isthmus> But it doesn't all fit together yet.
17:51:21 <Isthmus> My action item is making it into something comprehensible by next week xD
17:51:22 <sarang> ah ok
17:51:25 <sarang> Neat!
17:51:31 <sarang> We're coming up on the end of the hour
17:51:40 <sarang> Any last questions, topics, action items, etc.?
17:52:37 <binaryFate> Just curious what's your perception of relevant research over the next 6 months. Everything staled? Business almost as usual?
17:53:00 <binaryFate> Conferences and events are mostly canceled or moved to remote?
17:53:09 <sarang> Oh you mean in the broader research community?
17:53:36 <sarang> Seems that some conferences planned for later in the year are playing it by ear for now
17:53:36 <binaryFate> Yeah, anything relevant to MRL and Monero, how do you see things going?
17:54:17 <sarang> The cancellation of the Konferenco was unfortunate, but necessary
17:54:46 <sarang> Otherwise, calls for papers seem to be mostly continuing as normal, which is great to see
17:55:21 <binaryFate> ok good to know thank you
17:55:24 <sarang> Perhaps bored academics stuck at home will be more eager to read and review new research too
17:55:42 <binaryFate> and go straight for journals :)
17:55:53 <Isthmus> Oh interesting question @binaryFate
17:55:54 <Isthmus> That reminds me, when do we want to research quantum-resistant PoW and/or quantum-resistant cryptography?
17:56:27 <Isthmus> Note that pqPoW isn't super important in the short term
17:56:39 <binaryFate> "before it's too late"
17:56:50 <Isthmus> However it is unfortunate that the Monero transaction I make tomorrow will most likely be decrypted by a quantum computer during my life time.
17:57:00 <sarang> I know that suraeNoether had taken a particular interest recently in post-quantum signature constructions, but I don't know of any relevant efficient results at this point
17:58:01 <Isthmus> It might be nice to have somebody put together a survey of (1) Exactly which pieces of Monero will be broken by quantum computers (2) Potentially Monero-compatible solutions
17:58:33 <sarang> The reliance on discrete log hardness is the kicker
17:59:31 <Isthmus> Yep, it's gonna be tricky.
18:00:36 <Isthmus> But, I believe we can do it! If not, Monero has a very limited shelf-life :- P
18:00:54 <atoc> I feel like the bipartite graph matching project that suraeNoether is verifying will be one of the most vulnerable
18:01:21 <sarang> Graph matching is already parallelizable without a quantum computer
18:01:34 <sarang> It's just a very large search space in general
18:02:01 <sarang> On that happy note, let's go ahead and adjourn!
18:02:06 <sarang> Thanks to everyone for participating
18:02:13 <sarang> Logs will be posted shortly to the agenda GitHub issue
18:02:55 <binaryFate> Thanks sarang and everyone!
18:03:32 <ArticMine> Thanks
18:09:03 <Isthmus> Can you imagine how cool it will be if/when Monero is the first privacy coin to implement quantum resistant mechanisms? Checkmate. It'd be *absurd* for anybody to use alternatives that they know will be retroactively anonymized, when there's a functional open source alternative.
18:09:15 <Isthmus> Especially if we can get rid of decoy-based sender anonymity in the process.
18:14:25 <sarang> I've tangentially followed some Zcash github discussions on the topic, since there are certain similarities
18:14:34 <sarang> e.g. key images vs. nullifiers
19:22:15 <jwinterm> Isthmus, are zcash current and near-future implementations not very quantum resistant?
19:27:39 <sarang> IIRC at least in Sprout, a quantum adversary can test a supposed output destination
19:27:50 <sarang> and can use nullifiers to detect when an output is spent
19:27:59 <sarang> I'm not sure what, if anything, changes in Sapling
19:45:22 <atoc> @sarang is it important that atomic swaps between btc and xmr do not have a timelock?
22:47:19 <yanmaani> Has the idea of giving miners scrip for unused block size been considered? Orthogonal to the soft limit - this incentivizes the creation of smaller blocks
22:47:25 <yanmaani> (below the limit)
22:47:49 <jwinterm> what exactly do you mean by scrip?
22:48:56 <yanmaani> Tokens that can be redeemed to temporarily up the block size limit.
22:49:49 <yanmaani> So, if the current limit is 1MB, your blocks would have the size of at least all transactions with fees > 0, and then all transactions with fees > penalty.
22:50:24 <yanmaani> So in practice it seems like miners would fill the blocks up to the limit with transactions which are just profitable enough, and then require large rents for whenever the demand surges.
22:50:47 <yanmaani> So, extremely cheap during off-peak hours, extremely expensive during peak hours, since you need to 'push through' the soft limit
22:51:33 <yanmaani> If you'd instead say, "the limit is 1 MB, if you only use 300 KB you get 700 K 'byte tokens'," then you'd get a more efficient use.
22:52:04 <yanmaani> That way, the low-rent transactions wouldn't get mined, since the miner would rather just take the block size token things and use them for future blocks during peak hours.
22:52:42 <yanmaani> In effect, the fees wouldn't depend on the instantaneous load (tangent), but on something like the expected future load (secant).
22:53:30 <jwinterm> I don't think that idea has been discussed, afaik, but it seems like the implementation may be quite complex and could result in some unanticipated consequences
22:54:08 <jwinterm> ArticMine has certainly given a lot of thought to block rewards and fees so maybe he has some thoughts
22:55:34 <yanmaani> I don't know if Monero supports colored coins well. There would be some market-based complexities, in which smaller miners might find it annoying to sell off their scrip
22:55:40 <yanmaani> Whereas pools can just dump them in the open market.
22:56:25 <yanmaani> Then again, it _seems_ like it should be possible to do on-chain atomic swaps for them. So, you have 10 scrip, and you want to sell them for 1 monero, you create a transaction which ... does this, atomically, and send it.
22:56:30 <jwinterm> yea that's another issue - monero does not currently have any colored coin implementation, and there are possibly some privacy implications with them, though if they were only used in coinbase txs that would probably not matter
22:56:45 <jwinterm> there's no scripting capability in monero txs
22:57:11 <yanmaani> Can't you create a transaction that spends multiple outputs though?
22:57:20 <jwinterm> yes
22:57:25 <yanmaani> Like, if I want to create a (completely unneeded) CoinJoin transaction, can't I do this?
22:58:04 <yanmaani> so if A has 1 XMR and B has 10 XMR, it's possible to create a transaction with moves 9 XMR from B to A, but also one which moves 11 XMR into a box, and then atomically 10+1 out of it. Right?
22:58:06 <UkoeHB_> Are you aware of Monero's dynamic block weight? Having a hard time following your argument
22:58:31 <jwinterm> I guess, each input will have its own ring signature though, so not sure if that would impact your scheme
22:59:19 <yanmaani> UkoeHB_: Yes. See the first messages.
22:59:39 <derpy_bridge> <[keybase] seddd>: sarang: will there be a security proof for dual-target dlog in future Arcturus revisions?
22:59:41 <yanmaani> The block weight takes away some of the incentives, since it's still usable, but this would make things more efficient.
22:59:53 <yanmaani> jwinterm: For the colored coins?
23:00:37 <yanmaani> I am not sure how you'd do colored coins in Monero. A very, very, very ugly hack might be to just not make them private.
23:00:59 <yanmaani> Say something like, "these are not a currency, you shouldn't use these for transactions, and they expire 1 year after creation"
23:01:18 <sarang> seddd: it'd be nice to reduce that problem to a known hardness assumption
23:01:22 <sarang> but I don't have that yet
23:01:30 <yanmaani> and then just have them move around without any privacy. The transactions would however reveal who's a big miner and such.
23:01:37 <yanmaani> So I hope there's a better way.
23:01:52 <jwinterm> the only potential implementation I know would be to put some data in tx-extra field, which has been discussed as a privacy issue
23:02:44 <yanmaani> But aside from those logistics; are there any other problems with the idea? You mentioned unanticipated consequences
23:03:02 <yanmaani> which unanticipated consequences is it you anticipate? ;)
23:04:48 <jwinterm> donaldrumsfeld.mp4
23:04:54 <derpy_bridge> <[keybase] seddd>: sarang: no worries, am looking at the traditional dlog proofs and fiat-shamir proofs. Down to work on the security proof for dt-dlog with you
23:05:21 <UkoeHB_> There are a lot of design choices that went into Monero's current dynamic block and fee system, and there is even ongoing research to improve it. Idk if it's reasonable for anyone to comprehend a whole new system and all its facets very quickly.
23:05:22 <sarang> If you can find a reduction from the dual-target game, that'd be great
23:05:26 <derpy_bridge> <[keybase] seddd>: Even if that ends up just being a reduction to classic dlog
23:06:07 <UkoeHB_> It would help if you could draft a clearly explained proposal, contrasting it with current design choices.
23:06:53 <derpy_bridge> <[keybase] seddd>: Am very far from suggesting design changes, still trying to figure out exactly what's going on 😅
23:07:10 <UkoeHB_> Not you seddd, talking to yanmaani
23:07:27 <derpy_bridge> <[keybase] seddd>: Will definitely provide a write-up w suggestions when/if I have them
23:07:29 <yanmaani> UkoeHB_: Right, makes sense.
23:07:34 <yanmaani> Any pointers where I should post it?
23:07:43 <yanmaani> Should I just like write it and post on pastebin and link here?
23:07:44 <derpy_bridge> <[keybase] seddd>: Lol for sure UkoeHB_
23:09:03 <UkoeHB_> yanmaani: a good place might be the monero-research-lab github issues
23:09:10 <yanmaani> thanks UkoeHB_
23:14:21 <UkoeHB_> For explanations of current and ongoing design: zero to monero v2 section 7.3, and this repo issue https://github.com/monero-project/research-lab/issues/70
23:19:48 <yanmaani> Ah, so the mental model I had was a bit off- there's always a penalty, right?
23:19:50 <yanmaani> "minimum fee"
23:19:53 <yanmaani> or does the miner get this?
23:20:11 <yanmaani> or no, that's just relay policy and thus useless
23:21:57 <yanmaani> or/
23:30:06 <yanmaani> OK, so rough draft here if anyone wants to read: https://pastebin.com/R7Eae6rE
23:30:42 <yanmaani> oops, typo on line 18. "324 units" -> "324,000 units"
23:54:45 <UkoeHB_> yanmaani: hm I wonder about this idea that profit-maximizing miners will artificially maintain large block weights. see ztm2 ch7 footnote 35 (pg 68). A miner only moves into the penalty free zone when the marginal fee from adding a tx is higher than the marginal penalty. This means ALL tx in a block must have that marginal fee, otherwise the miner will reject it in favor of the marginal penalty. However, if
23:54:45 <UkoeHB_> block sizes are high then tx authors will just use much lower fees than the marginal penalty of even the reference tx (the tx to go from full penalty free zone to full +1) (currently min fee is .2x the reference tx fee). Rather, a miner wants blocks as small as possible so tx authors are collectively forced into buying penalty zone space.