--- layout: post title: Logs for the MRL Meeting Held on 2020-02-26 tags: [dev diaries, crypto, research] author: asymptotically / Sarang --- # Logs **\** Hello all, and welcome to the weekly research meeting **\** First, GREETINGS **\** Hi **\** hi **\** hi **\** \*others **\** 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? **\** It's always possible to include in tx\_extra, which is not consensus **\** and there was a space-minimizing proposal as well **\** AFAIK no one has coded such a thing yet **\** As always, there's a consideration of how optional behavior is bad for indistinguishability **\** Let's go ahead and start the ROUNDTABLE **\** Does anyone have research topics of interest to share? **\** I'll go ahead, then **\** First, the Stanford Blockchain Conference was held this past week **\** Here is a link to the schedule and recordings of talks for each day: https://cbr.stanford.edu/sbc20/ **\** 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 **\** 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 **\** See this branch for details: https://github.com/SarangNoether/monero/tree/clsag-optimized **\** Any particular talks that you recommend from SBC?n **\** hello everyone, catching up on the chat so far **\** Florian's talk about Monero and Zcash side-channel analysis on Wednesday's stream is very good **\** All of session 4 on Wednesday is interesting **\** As is session 5 on Thursday **\** Fourth, I worked on similar improvements for MLSAG... however, this is trickier, since verification requires particular byte-representation hash inputs for backwards compatibility **\** The results for that aren't great: https://github.com/SarangNoether/monero/tree/mlsag-optimized **\** Ah I loved that paper **\** Yeah, kudos to Florian and collaborators for great work and responsible disclosure **\** Finally, another researcher contacted me with an idea for atomic swaps that might remove the need for a SHA-256 preimage proof **\** We're still working out the details, but it's an intriguing idea for which the necessary building blocks already exist **\** More information as we work on it! **\** interesting, haven't heard from atoc in a while who was looking into that **\** Yeah... I don't want to provide more information until the researcher and I have discussed it (as a courtesy to them) **\** sorry **\** Respecting privacy is good ;- ) **\** Anyway, those are my updates! Mostly code updates and testing **\** Does anyone else wish to share research of interest? **\** thanks to sarang 's initial draft, tx knowledge proofs chapter is done (wip tag is off) for ztm2 **\** https://www.pdf-archive.com/2020/02/26/zerotomoneromaster-v1-0-30/zerotomoneromaster-v1-0-30.pdf **\** chapter 9 **\** Nice! **\** "An Axiomatic Approach to Block Rewards" https://arxiv.org/pdf/1909.10645.pdf **\** sgp\_ may be interested in section 9.3 for audits **\** reader beware various things arent implemented and are just theoretical **\** Yeah, the idea for a general audit framework is super interesting to me **\** and could be useful to reduce confusion about what proof types provide what information **\** Right now, it's sort of ad-hoc **\** ZtoM will contain unimplemented features and ideas from the roadmap? **\** Isthmus: that paper is on my literature review list! **\** also made some updates/fixes to minimum fee change idea https://github.com/monero-project/research-lab/issues/70 @ArticMine **\** thanks for sharing! I will see if I can get feedback on it **\** cankerwort part 2 'extensions' contains unimplemented features; saying they are roadmap is quite ambitious **\** 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 **\** which I suspect may require substantial engineering effort (as a guess) **\** also proofs for every single tx in the chain **\** for each normal address you own **\** but the benefits of this approach are worth investigation **\** IMO **\** audits arent trivial for sure **\** Should be called "ZtoM... and beyond!" **\** lol yeah **\** I'm familiar with some people who do Monero audits for businesses so I'll try and get their feedback **\** UkoeHB\_: fortunately the proofs are all off-chain anyway **\** So efficiency is much less of a consideration **\** Id refrain from expecting anything in ZtM that isnt implemented to actually get implemented. They are just ideas **\** UkoeHB\_ and I had discussed this very topic earlier... about the intended purpose of ZtM **\** e.g. protocol spec, or something else **\** 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 **\** In 10 years I want to sit down and nostalgically re-read the old "future work" sections **\** heh **\** Anything else to share UkoeHB\_? **\** (just to keep the meeting on track) **\** dont think so **\** Cool, thanks for the update **\** Isthmus: you had chimed in earlier **\** Did you wish to continue with anything else? **\** Life has been hectic, so haven't had many Monero moments lately. **\** However **\** 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) **\** But that's a minor difference **\** How recent is "recent"? **\** If you recall **\** Probably this version, but idk **\** It's only like a 0.5% change over the previously presented data **\** I've been working on a little design thought experiment, but it's still rough and maybe more -lounge appropriate **\** Otherwise, nothing else to report, that I can think of **\** Got it, thanks **\** I know suraeNoether said he was unavailable, but would provide an update later today on his recent work **\** He's been working on some interesting updates to linkable ring signature security models **\** I've been reviewing those as well **\** Does anyone else wish to share ongoing research? **\** Either specific to something mentioned here, or more generally **\** If not, we can move on to QUESTIONS **\** OK, looks like no questions so far **\** Let's move to ACTION ITEMS before closing the meeting **\** Feasibility of child pas for parent in Monero (child has parent as one of the mixins) **\** ? **\** pays **\** Can you elaborate, ArticMine ? **\** In Bitcoin a tx in the tx pool has to low a fee **\** "has to low a fee"? **\** A second tx is sent using the tx with to low a fee as an input **\** Sorry, I'm not following **\** ah **\** The miner miones both txs in a block **\** In the Monero case the child has the tx output of the parent as one of the mixins **\** can be real or fake **\** What is the specific question you're getting to? **\** Interesting interesting **\** Can this e done in Monero **\** be **\** oh is it about what can be done if a tx is stuck since its fee is too low? **\** e.g. make a new tx with more fee for it **\** Yes this can e part of the toolkit **\** be **\** but in addition to what I am looking at with the fees, etc **\** 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' **\** I actually think this seems very plausible **\** You wouldn't mine only the bump **\** And once the transaction is mined, the bump is unnecessary **\** The bump transaction should have exactly 2 outputs: a plaintext fee and an encrypted change output **\** And reference the first transaction by hash **\** yeah **\** hmm **\** Im wondering why not just remake the same tx **\** with more fee **\** because of multi sig **\** ah yeah **\** Huh, that's a very interesting question **\** Oh, and only 1 bump per transaction **\** You can broadcast more if you want, obviously **\** But only one bump can be claimed by the miner **\** 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 **\** Yes **\** but anyone can do the bump in Monero unlike Bitcoin **\** Why "becauae of multisig"? **\** You could design it either way: allow anybody to bump, or require a signature from the original sender to bump **\** (one of the original senders) **\** sounds like it's possible, although would require protocol level changes (new transaction type, etc) **\** wouldn't being able to do that (child pays for parent) drastically decrease the overall cost of the chain reaction attack? **\** You include the parent as one of the mixins **\** @UkoeHB\_ I'm only here for the protocol level changes :- P **\** Also the big bang attack presumably **\** The miner does know if the parent is real or not **\** 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 **\** That does not mine the parent **\** It would be a new tx type **\** 'bump tx' **\** Not really **\** RCTTypeBumpIt **\** heh **\** lol **\** The point of child pays for parent is that in order to mine the child one has to mine the parent **\** right **\** But that seems straightforward to enforce, no? **\** In Bitcoin that means spending the output of the parent in the child **\** I think you might get into weird 0-conf territory if can spend an output with 0-block lock time **\** @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 **\** the 10block lock is there for a reason afaik **\** just willy nilly **\** in Monero it means including it in the ring real or fake. The miner does no know **\** 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 **\** And everything is subject to the 10-block lock **\** or you could make it an optional field in normal tx type, to reduce complexity **\** Both are mined in the same block so there is no issue with orphans **\** UkoeHB\_: not in extra, right? **\** for parsing etc. **\** no, unless we start enforcing it **\** aye **\** interesting idea articmine **\** Surely the delta could be as small as you like though? So it could be used to make big bang attack cheaper **\** big bang is about total block weight **\** still have to pay fee for bump tx too **\** Ie you are adding 2 transactions for one fee? **\** The fee in the bump has to cover both the weight of the bump itself and the original transaction **\** Ah **\** 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 **\** Yes enough to provide an incentive the miner **\** That is the point of child pas for parent also in Bitcoin **\** Quick note that we should try to finish up soon, since Konferenco has a meeting in a few minutes **\** pays **\** May we quickly review action items, and then continue discussion? **\** Yes of course **\** I'll be working on some review for vtnerd's 64-bit operation code **\** as well as some Triptych coding for timing purposes **\** Others? **\** OK, then let's formally adjourn for log posting purposes... please continue discussion! **\** Thanks to everyone for attending