Monero takes privacy seriously. Monero needs to be able to protect users in a court of law and, in extreme cases, from the death penalty.

Sounds serious

Where is that from?

Atomic swaps based on h4sheds methods was added to Particl, not sure if there’s anything of interest for us there:

Was already shared in Reddit, I’m a bit behind the curve these days 😅

Reminder that our research meeting is today at 17:00 UTC

I'll be sharing some timing results from the new Gray method for Triptych and Arcturus

and I also shared my code with the Zcoin team, since the method would apply to Lelantus as well, with different efficiency

Results: docs.google.com/spreadsheets/d/e/2P…/pubhtml?gid=1695886143&single=true

so verification time is O(N) for all these?

hmm, looks a bit sub-linear to me

Verification is `O(N/lg(N))` in the input set size

lg is always log10 in English right?

Nope, I use the convention that `lg == log2`

ok

Triptych and Arcturus can use any base for the decompositions, but this work assumes base-2

Proof sizes for input set size `N = n^m` have proof elements scaling as `m*n` and others scaling as `m`

er, `m*(n-1)` actually, for the former

Using large fixed anonymity sets shared between proofs can help efficiency, which is what Lelantus is doing

But there are usability and security implications to this

I'm assuming that we share input sets only within transactions

You could get clever and do some partial batching for transactions sharing some of those sets, but this assumes a sort of worst-case verification scenario

One of the data points seems like an outlier

probably just a timing fluke on the test machine; I'd ignore it

methinks a linear y axis would be more telling

It still will look like a bunch of lines that are really close together, since it scales up so quickly

The point is that Gray doesn't always win, and that the benefits are highly dependent on how you construct and verify proofs, and on how you choose input sets across proofs

For something like Lelantus, they use giant windowed sets

But this has implications for spend heuristics and usability that are subtle

It will be very interesting to see what results the Lelantus team finds in any experiments they do

Looking at these charts... It looks like they're all linear, so it mostly depends on the quality of their implementation. Code optimizations can turn the tables.

Yeah, a lot of this depends on things like how inversions are performed

While you shave off a lot of scalar-scalar operations when computing certain coefficients, you replace that with an expensive inversion process

and you obviously want to reduce the number of times you have to do this inversion

We could get a lot of benefits from doing Zcoin-style large sets, but this could get complicated pretty quickly

and the security implications are bit iffy IMO

Research report is available: reddit.com/r/Monero/comments/j2oncd…_monthly_report_from_sarang_noether

good bot

If I do something like a sweep_all that only requires 1 output, and the wallet (as required by consensus) adds a second dummy output, what does it use for the address of the dummy?

(of course, this is a wallet-level design decision, and nothing that can be observed or enforced by the protocol)

It is randomly generated afaik

All right, time for our meeting!

First, greetings!

Hi

Hi

hello

Hi

hello

Salutations

OK, let's move to roundtable, where anyone is welcome to share research topics of interest

Does anyone wish to begin?

If not, I'll go first

You can read my monthly research report here: reddit.com/r/Monero/comments/j2oncd…_monthly_report_from_sarang_noether

It's the last report for my funding period

This past week, I gave a talk for the MCC virtual conference on privacy

and participated in a panel on privacy

I took cargodog[m]'s idea for `n`-ary Gray codes and build working prototypes for both Triptych and Arcturus in Python and in C++

and shared some timing results earlier today

I also updated the Triptych code for more efficient batching across proofs within the same transaction

That's about it for my update

Hi (sorry I can't attend today, have a good meeting)

I assume you have no ETA on the MCC videos being released?

No problem h4sh3d[m]

I don't know what their plans are for videos, sorry

I know they were recorded though

did you publish the slides anywhere?

No, but I can post them later today if that's useful

They needed Google Slides, so I can post a PDF but not any source code for them

Were there any other questions on my research topics?

Here are the MCC slides: github.com/SarangNoether/talks/tree/mccvr-2020

OK, does anyone else wish to share research of interest?

Quiet channel today!

If not, I can discuss the Gray code stuff a bit more

Here is a timing plot: docs.google.com/spreadsheets/d/e/2P…/pubhtml?gid=1695886143&single=true

I haven't put it into `gnuplot` yet

There's an outlier data point for the `Triptych Gray 2-2` dataset that's just a timing fluke, and can be safely ignored

(dashed blue line)

sarang: with respect to MCC videos -> reddit.com/r/Monero/comments/j074ro…arch_lab_will_be/g6t0egm/?context=3

If anyone has issues with differentiating the colors, please let me know here (or DM me) and I can provide a version with better color accessibility

Thanks dEBRUYNE!

np

Our use case for the Gray results in Triptych/Arcturus is to use common input sets within transactions, but not necessarily between proofs

This is distinct from something like Lelantus, where they intend to reuse large common input sets across many proofs

For our use case, the Gray method only starts "winning" between 64-128 sizes, and is different as you increase the number of inputs

This input-based advantage can be removed if we were to overhaul the way inversions are performed

And as you can see, while there is an improvement for larger input set sizes, it's reasonably marginal (single-digit percent decreases in time)

I shared my code with the Lelantus team; they may wish to conduct their own timing experiments based on their particular use case

looking at that plot now. very nice

and it sounds like cargodog[m] intends to add this to their own Rust implementation of Arcturus

Where can I read about the Gray code idea after being out of the loop? Meetings logs?

One sec binaryFate, will get some links for ya

thanks!

cargodog[m] had implemented a binary Gray code method for their Groth/Kohlweiss proof implementation

and speculated that it could be useful for the Bootle optimization used in Arcturus/Lelantus/Triptych

I implemented the idea using `n`-ary Gray codes for Arcturus and Triptych in Python (for prototyping) and in C++ (for timing)

Kudos to cargodog[m] for this super clever idea

it does look like mostly a wash

By switching from standard `n`-ary decomposition of integers to `n`-ary Gray decompositions, you simplify the multiplications used in computing certain scalars, but replace with an expensive inversion process whose complexity can be amortized

It's a wash for this particular kind of input set choice

But for other applications can have much better improvements

Any differences in transaction size?

No

Transaction size is identical

it's only how the proof elements are computed that changes

So a very small improvement in verification time

For the current use case of non-overlapping input sets between transactions, yes

Even with this use, it would be possible to overhaul the code to batch the expensive inversion across unrelated proofs, which I did not do here

So a batch would require only one such inversion

However, if the input sets don't overlap, I think the benefit to this would be fairly minimal

You really see the efficiency if you batch many proofs with the same input set, and also batch the inversions

As you can see, it gets really subtle

thinks

Anyway, this provides some reasonable timing data for this idea

I look forward to seeing the results of any experiments that cargodog[m] or the Lelantus team conduct

Since cargodog[m] uses a more efficient crypto library, and the Lelantus use case for batching and input sets is very different from ours

At any rate, it's a very interesting idea

and it was a fun challenge to implement for this experiment

cool work

btw ArticMine where are you at with the fee proposal?

it sounded like you were planning to reassess some aspects

The question I see is spam risk.

Which I feel for the most part can be mitigated

Then we can mover to using the long term median as a penalty free zone

Which effectively allows for very stable fees

The key is that for a Big bang attack it is neutral

since once the LT median moves then Big Bang moves on

ah my suggestion was to use the long-term-median for penalty zone, and let the penalty free zone fluctuate, are you thinking the opposite? if the penalty zone fluctuates then fees will fluctuate more

It is maintaining the sort term median that deters big bang

Yes using the LT median as the penatly free zone

can you elaborate what the "spam risk" would look like?

Basically there are tow cases

1) For a pre existing Big Bang attack there is no change since it does not make sense for the spammer to maintain the long term median

2) If the short term median falls below the long term median then it crease a similar situation to what we have now but at much higher block size and price

So the cost of spamming node relay f=minimum fee is much higher

There would be no penalty to get back to the long term median as there is now no penalty to get to 300000 bytes

but the cost of the spam in real terms would be much higher than ti is now

It is a much simple solution also than what we have now

SO the code wold be simpler

Ill have to think about this a bit

It comes down to can we have 100x the transaction rate and no increase in price

I do not think that is realistic

agree with you

So the cost of the ham in real terms remains the same, but the cost of the spam for a given % increase in block weight increases with price

OK, any other research topics to address before we end the meeting?

Any interest in setting block size by encrypted miner vote?

(which would boil down to the Nakamoto consensus assumption that 51% of miners will behave in the best interest of the network)

An Insight Fellow is playing around with building an noninteractive ZKP mechanism for this, based on Pallier encrypted voting

Oh interesting; I did not know this was happening

(each block contains one trinary vote for {decrease, same, increase})

what benefit would this bring?

Miner can effectively put a limit themselves any way

Any human input sounds like degrading from a purely algorithmic solution, but this is certainly interesting research

@sgp Well right now in 2020 we're trying to figure out a dynamic block size algorithm that produces desirable results in 2030, but I dunno how big transactions will be, how fast internet will be, how much transaction volume we'll have, etc.

So if we go with encrypted miner voting, then 2030 block size is set by 2030 miners, instead of 2020 researchers

And miners would have the best understanding of how much their infra can handle before blocks get too big, etc

so this would overrule existing restrictions?

With the current situation the miners can still limit the block weight

Miners can choose to make smaller blocks than the algo allows, but cannot choose to make bigger blocks than the algo allows

So it's one-sided

@sgp - doesn't have to.

Could be that we have a dynamic algo, but miners can vote some change on top of that

Right now it's just a toy, haven't worked it into a fully functioning secure economic model yet

Miner voting has only been proposed in cois that have a fixed block size such as Bitcoin

and Bytecoin

when the block reward falls to zero

Interesting, in those systems, what are they voting on/for?

Blocksize

In Ethereum max gas consumption per block

Ah yea, each ETH miner can vote +1/1024 or -1/1024 if I recall correctly

Hmm ArticMine using the long term median for penalty free zone still leaves us with minimum fee issues. Namely issues around if the short term median collapses then transactions with pre-collapse minimum fees will be invalid. That's unless we set a floor on the min fee based on the long term median. Doing that may make perfect sense actually, since if the short term median is low then you are unlikely to be

filling the penalty free zone anyway (assuming PFZ is now based on long term median).

or ceiling* I guess

The fee is set effectively by the long term median because the penalty free zone is a floor for the short term median

Especially because Monero makes a point to be mined on generic hardware, I would not assume much long-term interest or economic self-benevolence from Monero miners

aren't there dangers of cartelization if block size is based on voting? since you can force up the fees

It's different from what you would expect from miners who bought specialized hardware for other coins

<UkoeHB_> aren't there dangers of cartelization if block size is based on voting? since you can force up the fees <--- Very much so

"aren't there dangers of cartelization if block size is based on voting? since you can force up the fees" <--- this is the case now too, right? If lots of miners decided to voluntarily suppress block size, or something like that?

but it is the only option to a fixed block size for coions with falling emission

Cartels fail eventually

heck it's even worse than cartelization since the incentive to vote for small blocks is presented to all miners; cartelizing just forces out transactions not other miners

cartelizing nowadays is a losing proposition since other miners will just take the remaining tx

so the cartel has to operate at a loss unless they have a serious competitive advantage, but even then it's dubious

The way we implemented it, 501 of 1000 miners must vote for any block size change, so the cartel must be > 51%, implying failure of Nakamoto consensus asssumption

(again, that's just our toy version)

to clarify: a block size change will not occur unless >51% of miners voted for it

Anywho, once it's finished up, I'll share a link here

Sorry to derail the convo past time

Good discussion!

Let's go ahead and adjourn, and discussions can of course continue

A reminder that today is my last day of funded research

Anyone else is welcome to lead future research meetings if they wish

Thanks to the community for ongoing support of research; it's greatly appreciated

<3 <3 <3

This is just about prodding people to share/discuss what they worked on recently, right ?

Anything else ?

It's whatever this channel wants it to be

That's what makes communities so interesting... they get to decide what they want to be

Hey sarang, I know you are done with your proposal now, but you are truly amazing to work with, and you are without a doubt one of the greatest assets to Monero, ever. Words can't express how grateful I am.

I will try to if noone does it. If I remmeber :)

I appreciate that sgp_, and I appreciate you as well!

:D

thanks, everyone

shall we keep the same rythm for the meetings as a default get together & share time?

I will not regularly check IRC, but I am available if needed by email at sarang [dot] noether [at] proton mail [dot] com

Isthmus my revised point is that there doesn't need to be a cartel in a block voting scenario, since all miners are economically incentivized to vote for small blocks. Even solo miners. If the vote fails, it doesn't affect them. However with an algorithmic dynamic block size all miners who 'vote' for small blocks by ignoring transactions are directly penalized with the opportunity cost.

Ahh I see what you were saying

sgp_: +1!

I second sgp_'s words 1000%. Best wishes for whatever you're planning your life to look like this month and next.

Two hips and a hooray for sarang :)

All the best sarang. It has been an absolute pleasure working with you

thanks sarang 🙏

This community has more than its fair share of badass contributors; thanks for all the support and collaboration :)

Meeting logs posted: monero-project/meta #513

Sorry I missed the meeting, got caught up in something else. Wish you the best sarang!

thanks cargodog[m]

I miss everyone already :/

and it's been like 4 minutes

dang sarang

Its never too late to come back ;)

I'm not usually a very emotional guy, but hot damn...

MRL fam forever

enjoy the break but come back around visiting community and friends if nothing else :)

I'll obviously leave my GitHub up so code and research stays available for anyone who wants it

good I'll be sure to peper it with issues from time to time just to poke you

It's never too late to change your mind :D

And why would you leave IRC :c

ArticMine: are you planning to write up your updated algorithm recommendations?

sarang: It has been an absolute pleasure to have you working in the community - you brought very important legitimacy through your research and sharing. On a personal note, thanks for answering my silly n00b questions with nothing but patience and courtesy. You will be missed. A lot.

It's been my honor to be a part of this community

<UkoeHB_> ArticMine: are you planning to write up your updated algorithm recommendations? <--- Yes.

I should have it finalized in the next two weeks

sarang: Have you revealed where you'll be going next? Whoever gets to work with you is getting a great addition to their team.

I'm not totally sure what my future plans will be

Thanks for everything sarang. Will be weird to not see your name popping here and there

<#

s/#/3

good bot =p

Can another chanop remove my op privileges from this channel?

It doesn't seem appropriate to retain them

moneromooo etc.

Also from #monero-research-lounge plz

I don't know if I can remove my own op privileges

I am op just in -lounge from yesterday. I can remove it if you really want but I see no harm in leaving it as is for now.

It's ultimately up to the channel

IRC op have nothing to do with funding or working status, it's just about trust.

ok

Don't see a reason to remove you unless you want it

Don't see a reason either to remove it

I don't think sarang will abuse it lol

And I'd consider it a nod to hoping he comes back :)

Pretty sure I've banned maybe one user, and it was clearly a spambot

I think it's very fortunate that there hasn't really been a need to kick/ban anyone besides spambots in the channel

Moderation isn't just about taking action, it's about setting a cultute

Culture*

moneromooo: I do recommend having at least one other op in -lounge, but it's up to the group

Well said needmoney90

In general there is very little disruption in any of the monero channels, so moderation is pretty light.

Sure, but I think it's useful and good for accountability not to have a single op

AFAIK the core team can give ops to whoever they see fit on any monero channel.

True, they have some kind of special status with freenode

correct

not meddling with each channel policies (unless OPs go bonkers and infrindge freenode rules and paint a bad picture on Monero) but easy to get back a channel without OP or other practical issues

sarang today is a sad day, you've been so core to monero's progress that i'm struggling to comprehend you won't be full-time any more. thanks for all of your awesomeness!

Completely agree with Knaccc

Lots of smart guys around here, but you are towards the top of the pile

Thanks everyone; these kind words are really appreciated

what if a company hired you to work on xmr/crypto research full time?

or does burnout mean you want a change in scenery?

I certainly need some time off from research; because I never included vacation time specifically in my funding proposals, I didn't really take proper time off

This was probably a mistake in hindsight... but at the same time, would donors really want to fund time off?

The work has certainly been appreciated, and I'd like to think the donors would be fine funding some time off as part of the proposals, particularly if you return in the future. :) I'd like to think most of them are reasonable people who like their own time off from work projects.

If a company hired me to work on open privacy research full time with longer-term stable funding, perhaps that could help to provide a healthier work-life balance, but I suppose it would depend on the particular circumstances

sarang: I think donors would definitely symphatize with, say, 1 week off per quarter

At any rate, this community has many excellent researchers, developers, and other contributors

And there are certainly interesting funding proposals on the table presently

It may be helpful to revisit the Bulletproofs+ proposal

I had hoped to complete a C++ implementation, but did not end up having the time to do so

I did produce a Python prototype, FWIW

❤️

Gonna miss sarang. I know you will do well in whatever you choose next, whether that’s crypto or teaching or whatever. When one door closes, another door opens

If I can bear witness, it will be really exciting to see how you grow over the years to come

Thanks kenshamir[m]

It's been a pleasure working with you

If you do return, I think it will be with a new outlook on life and maybe even some new ideas on crypto. Yeah, I do hope that I will be able to follow your growth

You’ve taught me a lot, it was a pleasure working with you :)

I do also believe that maybe this should be a catalyst for the community to think about long-term stable funding for their most valued people

However, this probably goes against Moneros ethos as you would need some sort of company to take care of the logistics

Maybe it is a necessary trade-off that needs to be made to attract new cryptographers and software developers and keep them for the long haul?

yeah some more long-term funding for cryptographic research sounds like an excellent idea

Also with the explicit understanding that not all research will produce tangible deliverables. Not really sure how sarang and the others are/were managing to do it, as most research leads to dead ends and failures

They certainly had some amazing success :)

Also with paid time off, or some understanding around vacation times.

I think with the above, a cryptographic researcher would certainly be appealing to postgrads and rogue cryptographers. Not my area of knowledge, so no idea how feasible this is to pull off

<Inge- "They certainly had some amazing "> Yeah exactly haha, I think it implicitly shows how hard they are/were working for Monero

It would be really cool to have a way to get someone like that over to a 1 year and maybe even a 3-year gig, with decent renewal in good time

Yeah definitely, if I can speak even out of place, I think it would be worthwhile to fund sarangs time off now. I for one would definitely contribute as the less work he has to do during his timeoff, the easier it would be for him to recuperate. Even if he chooses to go somewhere else, it would be a sign of good faith to the invaluable work he has done

I would support it

+1

Okay good currently three people. I don’t know how CCS works, probably can point it to sarangs stealth address which is somewhere on the repo

Will wait to see if anyone else will +1

I would also support it

Me too

Perhaps as a gesture of good will, the community can fund, say, 1 month of vacation for sarang

Then he can properly rest and also doesn't need to worry about the bills for that month

We need to take into consideration the length over service over 6 years.

I really need to give some thought to what an appropriate amount would be.

<ArticMine "We need to take into considerati"> Yeah if possible, I was thinking the quarter

ArticMine: I suppose we can look at some European countries what they typically grant for vacation days

I think it's 4-6 weeks per year

Crypto industry standard in SF is also 4-6 weeks/yr off for vacation

I encourage my researchers/engs to take real vacations and truly unplug. I want a team of happy / healthy researchers, not a bunch of burned out drones with maximum hours of labor per dollar. You get more bang for the buck with the former, anyways. ;- )

Speaking of, one of our engineers came across this: github.com/monero-project/monero/bl…onote_basic/cryptonote_basic.h#L449

in `struct block_header {... ` there is a note `uint8_t minor_version; // now used as a voting mechanism, rather than how this particular block is built`

Have we ever used minor_version for voting?

Not on mainnet. It was shit and buggy.

ArticMine: Do you intent to write some kind of proposal btw?

It's used to gauge the amount of nodes which are ready to follow a fork atm.

Well, the amount of hash rate really.

I want first to listen to the comments.

That makes sense. In recent upgrades over the past few years, do miners change `minor_version` in practice to signal preparation?

Is its use for this purpose in the wild uncommon/mixed/common?

Then I would be prepared to make a recommendation

Yes, when they update their daemon.

Coolio

Nothing enforced, right?

I think it's enforced to be >= major version. Not 100% sure.

Oh yea, that would be a logical constraint

<ArticMine "Then I would be prepared to mak"> Given 4-6 weeks per year, that would mean 6-9 months given 6 years of service. This sounds reasonable to me. We should figure out what the living costs are first. Let’s hope sarang does not live in New York or The Valley :)

I think 2014-2017 was only part time, but we can easily verify that with the CCS/FFS history

We can use the CCS/FFS history and the historical XMR / USD exchange rate. Then adjust the USD amount to 2020 USD to adjust for fed printing and we would be close

Then we have a basis