02:09:09 I _think_ that was gingers question, because my statements above seem to contradict that quote >>> indeed 15:04:33 Reminder that today's research meeting is at 18:00 UTC (about 3 hours from now) 15:05:21 Agenda is here, where anyone can add links/data/etc. as comments: https://github.com/monero-project/meta/issues/441 17:45:50 Hey guys, I am in doctors appointments all day today, I will be dropping an update later tonight 17:46:01 Can't attend the meeting unfortunately :( 17:47:58 Anything of note to mention in advance? 17:48:10 Or shall we wait on pins and needles? 17:48:13 =p 17:56:46 * Isthmus waves 17:56:54 Hi 17:57:33 [keybase] : Just the clsaf draft I got back to you day before yesterday that you are already commenting on 17:57:42 Got it, thanks! 17:57:48 We'll start the meeting in just a few minutes 17:58:38 Crap where is my lab coat 17:59:24 The usual agenda: https://github.com/monero-project/meta/issues/441 18:00:03 It's time to start: https://www.youtube.com/watch?v=QgMvWkOzF08 18:00:40 Hello all, and welcome to the weekly research meeting 18:00:44 First, GREETINGS 18:00:45 Hi 18:00:55 hi 18:02:03 hi 18:02:40 * sarang will wait a moment for otheres 18:02:42 *others 18:02:51 Peanut gallery quickly checking in to ask what the latest is on return addresses. Last I remember there was an idea to include a subaddress in the tx as a return address. Is that still being being considered? 18:03:28 It's always possible to include in tx_extra, which is not consensus 18:03:34 and there was a space-minimizing proposal as well 18:03:49 AFAIK no one has coded such a thing yet 18:04:34 As always, there's a consideration of how optional behavior is bad for indistinguishability 18:04:53 Let's go ahead and start the ROUNDTABLE 18:05:02 Does anyone have research topics of interest to share? 18:06:06 I'll go ahead, then 18:06:27 First, the Stanford Blockchain Conference was held this past week 18:06:42 Here is a link to the schedule and recordings of talks for each day: https://cbr.stanford.edu/sbc20/ 18:07:19 Second, a small PR on hash function domain separation was updated, and could always use extra eyes for review: https://github.com/monero-project/monero/pull/6338 18:07:54 Third, I made some updates to the structure of CLSAG signature verification code... by reducing the modularity of the signature verification routine to specifically include some commitment offsets, I was able to shave about 5% off the verification time 18:07:59 See this branch for details: https://github.com/SarangNoether/monero/tree/clsag-optimized 18:08:09 Any particular talks that you recommend from SBC?n 18:08:27 hello everyone, catching up on the chat so far 18:08:39 Florian's talk about Monero and Zcash side-channel analysis on Wednesday's stream is very good 18:09:03 All of session 4 on Wednesday is interesting 18:09:13 As is session 5 on Thursday 18:09:46 Fourth, I worked on similar improvements for MLSAG... however, this is trickier, since verification requires particular byte-representation hash inputs for backwards compatibility 18:10:03 The results for that aren't great: https://github.com/SarangNoether/monero/tree/mlsag-optimized 18:10:09 Ah I loved that paper 18:10:30 Yeah, kudos to Florian and collaborators for great work and responsible disclosure 18:11:09 Finally, another researcher contacted me with an idea for atomic swaps that might remove the need for a SHA-256 preimage proof 18:11:28 We're still working out the details, but it's an intriguing idea for which the necessary building blocks already exist 18:11:35 More information as we work on it! 18:11:46 interesting, haven't heard from atoc in a while who was looking into that 18:12:17 Yeah... I don't want to provide more information until the researcher and I have discussed it (as a courtesy to them) 18:12:20 sorry 18:12:41 Respecting privacy is good ;- ) 18:13:02 Anyway, those are my updates! Mostly code updates and testing 18:13:08 Does anyone else wish to share research of interest? 18:13:59 thanks to sarang 's initial draft, tx knowledge proofs chapter is done (wip tag is off) for ztm2 18:14:04 https://www.pdf-archive.com/2020/02/26/zerotomoneromaster-v1-0-30/zerotomoneromaster-v1-0-30.pdf 18:14:14 chapter 9 18:14:14 Nice! 18:14:28 "An Axiomatic Approach to Block Rewards" https://arxiv.org/pdf/1909.10645.pdf 18:14:31 sgp_ may be interested in section 9.3 for audits 18:14:57 reader beware various things arent implemented and are just theoretical 18:15:38 Yeah, the idea for a general audit framework is super interesting to me 18:15:55 and could be useful to reduce confusion about what proof types provide what information 18:16:03 Right now, it's sort of ad-hoc 18:16:08 ZtoM will contain unimplemented features and ideas from the roadmap? 18:16:13 also made some updates/fixes to minimum fee change idea https://github.com/monero-project/research-lab/issues/70 @ArticMine 18:16:13 Isthmus: that paper is on my literature review list! 18:16:20 thanks for sharing! I will see if I can get feedback on it 18:16:55 cankerwort part 2 'extensions' contains unimplemented features; saying they are roadmap is quite ambitious 18:17:01 One thing to note about the audit idea from UkoeHB_ is that it requires proofs applying to _all_ transactions for which a given output appears in rings 18:17:12 which I suspect may require substantial engineering effort (as a guess) 18:17:27 also proofs for every single tx in the chain 18:17:37 for each normal address you own 18:17:37 but the benefits of this approach are worth investigation 18:17:39 IMO 18:17:56 audits arent trivial for sure 18:18:30 Should be called "ZtoM... and beyond!" 18:18:35 lol yeah 18:18:37 I'm familiar with some people who do Monero audits for businesses so I'll try and get their feedback 18:18:43 UkoeHB_: fortunately the proofs are all off-chain anyway 18:18:50 So efficiency is much less of a consideration 18:19:02 Id refrain from expecting anything in ZtM that isnt implemented to actually get implemented. They are just ideas 18:19:24 UkoeHB_ and I had discussed this very topic earlier... about the intended purpose of ZtM 18:19:32 e.g. protocol spec, or something else 18:20:23 I think that flavoring it with the latest ideas and discussions will convey the lively R & D, provide helpful context, and leave an important historical record 18:20:47 In 10 years I want to sit down and nostalgically re-read the old "future work" sections 18:20:59 heh 18:21:28 Anything else to share UkoeHB_? 18:21:33 (just to keep the meeting on track) 18:21:39 dont think so 18:21:44 Cool, thanks for the update 18:21:53 Isthmus: you had chimed in earlier 18:22:00 Did you wish to continue with anything else? 18:22:24 Life has been hectic, so haven't had many Monero moments lately. 18:22:25 However 18:22:49 n3ptune was doing some data QC/QA and noticed that in a recent preliminary figure I had missed 100 recent transactions with no payment id (encrypted nor unencrypted) 18:22:58 But that's a minor difference 18:23:05 How recent is "recent"? 18:23:11 If you recall 18:23:21 Probably this version, but idk 18:23:28 It's only like a 0.5% change over the previously presented data 18:23:41 I've been working on a little design thought experiment, but it's still rough and maybe more -lounge appropriate 18:23:52 Otherwise, nothing else to report, that I can think of 18:23:54 Got it, thanks 18:24:16 I know suraeNoether said he was unavailable, but would provide an update later today on his recent work 18:24:30 He's been working on some interesting updates to linkable ring signature security models 18:24:41 I've been reviewing those as well 18:24:50 Does anyone else wish to share ongoing research? 18:26:04 Either specific to something mentioned here, or more generally 18:26:23 If not, we can move on to QUESTIONS 18:27:04 * sarang will wait a few minutes if anyone has questions 18:29:11 OK, looks like no questions so far 18:29:18 Let's move to ACTION ITEMS before closing the meeting 18:29:30 Feasibility of child pas for parent in Monero (child has parent as one of the mixins) 18:29:40 ? 18:29:43 pays 18:29:46 Can you elaborate, ArticMine ? 18:30:24 In Bitcoin a tx in the tx pool has to low a fee 18:30:30 * sarang rewinds the agenda to QUESTIONS 18:31:09 "has to low a fee"? 18:31:10 A second tx is sent using the tx with to low a fee as an input 18:31:13 Sorry, I'm not following 18:31:24 ah 18:31:29 The miner miones both txs in a block 18:32:05 In the Monero case the child has the tx output of the parent as one of the mixins 18:32:20 can be real or fake 18:32:38 What is the specific question you're getting to? 18:32:57 Interesting interesting 18:32:59 Can this e done in Monero 18:33:05 be 18:33:13 oh is it about what can be done if a tx is stuck since its fee is too low? 18:33:28 e.g. make a new tx with more fee for it 18:33:28 Yes this can e part of the toolkit 18:33:36 be 18:34:19 but in addition to what I am looking at with the fees, etc 18:35:18 we do have 10block lock time atm, so tx spending other tx output doesn't quite work, though there could be new rules around 'in the same block' 18:35:41 I actually think this seems very plausible 18:35:46 You wouldn't mine only the bump 18:35:55 And once the transaction is mined, the bump is unnecessary 18:36:24 The bump transaction should have exactly 2 outputs: a plaintext fee and an encrypted change output 18:36:40 And reference the first transaction by hash 18:36:56 yeah 18:37:04 hmm 18:37:15 Im wondering why not just remake the same tx 18:37:19 with more fee 18:37:51 because of multi sig 18:37:56 ah yeah 18:38:25 Huh, that's a very interesting question 18:38:28 * sarang ponders 18:39:43 Oh, and only 1 bump per transaction 18:39:50 You can broadcast more if you want, obviously 18:39:59 But only one bump can be claimed by the miner 18:40:36 So if you bump with 0.2 XMR then change your mind and send a 0.5 XMR bump, a miner would just ignore the smaller bump 18:40:45 Yes 18:41:07 but anyone can do the bump in Monero unlike Bitcoin 18:41:15 Why "becauae of multisig"? 18:41:31 You could design it either way: allow anybody to bump, or require a signature from the original sender to bump 18:41:39 (one of the original senders) 18:41:46 sounds like it's possible, although would require protocol level changes (new transaction type, etc) 18:41:48 wouldn't being able to do that (child pays for parent) drastically decrease the overall cost of the chain reaction attack? 18:42:05 You include the parent as one of the mixins 18:42:15 @UkoeHB_ I'm only here for the protocol level changes :- P 18:42:31 Also the big bang attack presumably 18:42:44 The miner does know if the parent is real or not 18:43:13 ArticMine I don't know if the parent needs to be a mixin, just include the parent tx hash as part of bump tx, an additional data field 18:43:39 That does not mine the parent 18:44:03 It would be a new tx type 18:44:10 'bump tx' 18:44:17 Not really 18:44:17 RCTTypeBumpIt 18:44:23 heh 18:44:34 lol 18:44:47 The point of child pays for parent is that in order to mine the child one has to mine the parent 18:44:57 right 18:45:06 But that seems straightforward to enforce, no? 18:45:19 In Bitcoin that means spending the output of the parent in the child 18:45:24 I think you might get into weird 0-conf territory if can spend an output with 0-block lock time 18:45:27 @cankerwort yeah, though as long as the bump density [XMR per kB] is higher than transaction density [XMR per kB] then they would effectively take up less space (be less effective) for a big bang attack 18:45:34 the 10block lock is there for a reason afaik 18:45:46 just willy nilly 18:46:16 in Monero it means including it in the ring real or fake. The miner does no know 18:46:43 Yeah, I think the "bump" transaction needs to be a new type with exactly [fee delta + change] outputs and a new field referencing the transaction hash of the transaction to be accelerated 18:47:08 And everything is subject to the 10-block lock 18:47:28 or you could make it an optional field in normal tx type, to reduce complexity 18:48:07 Both are mined in the same block so there is no issue with orphans 18:48:32 UkoeHB_: not in extra, right? 18:48:37 for parsing etc. 18:48:47 no, unless we start enforcing it 18:49:10 aye 18:49:41 interesting idea articmine 18:49:52 Surely the delta could be as small as you like though? So it could be used to make big bang attack cheaper 18:50:12 big bang is about total block weight 18:50:35 still have to pay fee for bump tx too 18:51:03 Ie you are adding 2 transactions for one fee? 18:51:15 The fee in the bump has to cover both the weight of the bump itself and the original transaction 18:51:34 Ah 18:51:44 So if I have a 5 kB txn and a 2 kB bump, then the total fee has to incentivize the miner to include 7 kB 18:52:00 Yes enough to provide an incentive the miner 18:52:32 That is the point of child pas for parent also in Bitcoin 18:52:41 Quick note that we should try to finish up soon, since Konferenco has a meeting in a few minutes 18:52:43 pays 18:52:50 May we quickly review action items, and then continue discussion? 18:53:01 Yes of course 18:53:07 * sarang apologizes for interrupting discussion :/ 18:53:20 I'll be working on some review for vtnerd's 64-bit operation code 18:53:26 as well as some Triptych coding for timing purposes 18:53:30 Others? 18:54:45 OK, then let's formally adjourn for log posting purposes... please continue discussion! 18:55:10 Thanks to everyone for attending 18:56:03 ah, within next couple days Ill start on bulletproofs for ztm2, the very last topic before it goes out for proofreading 18:56:07 thanks sarang 18:56:09 (please carry on discussion!) 18:56:19 UkoeHB_: awesome, please let me know if I can assist you 18:56:43 * sarang will post meeting logs to the agenda issue shortly 18:57:33 Anyone interested in this year's Konferenco, note that there is a meeting in #monero-konferenco beginning shortly 19:04:38 Logs posted: https://github.com/monero-project/meta/issues/441#issuecomment-591588889