<vtnerd> I _think_ that was gingers question, because my statements above seem to contradict that quote >>> indeed

Reminder that today's research meeting is at 18:00 UTC (about 3 hours from now)

Agenda is here, where anyone can add links/data/etc. as comments: monero-project/meta #441

Hey guys, I am in doctors appointments all day today, I will be dropping an update later tonight

Can't attend the meeting unfortunately :(

Anything of note to mention in advance?

Or shall we wait on pins and needles?

=p

Hi

[keybase] <surae>: Just the clsaf draft I got back to you day before yesterday that you are already commenting on

Got it, thanks!

We'll start the meeting in just a few minutes

Crap where is my lab coat

The usual agenda: monero-project/meta #441

It's time to start: youtube.com/watch?v=QgMvWkOzF08

Hello all, and welcome to the weekly research meeting

First, GREETINGS

Hi

hi

hi

*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?

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: cbr.stanford.edu/sbc20

Second, a small PR on hash function domain separation was updated, and could always use extra eyes for review: monero-project/monero #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: 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: 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

chapter 9

Nice!

"An Axiomatic Approach to Block Rewards" 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

<cankerwort> ZtoM will contain unimplemented features and ideas from the roadmap?

also made some updates/fixes to minimum fee change idea monero-project/research-lab #70 @ArticMine

Isthmus: that paper is on my literature review list!

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

<cankerwort> 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

<cankerwort> 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

<cankerwort> 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

<cankerwort> 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

<cankerwort> 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

<cankerwort> 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

ah, within next couple days Ill start on bulletproofs for ztm2, the very last topic before it goes out for proofreading

thanks sarang

(please carry on discussion!)

UkoeHB_: awesome, please let me know if I can assist you

Anyone interested in this year's Konferenco, note that there is a meeting in #monero-konferenco beginning shortly

Logs posted: monero-project/meta #441#issuecomment-591588889