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