Isthmus: is it economically in the interest of miners to increase block size? what if they make more in fees from small blocks?

would that be 100 miners, or 100 mined blocks (several of which could be the same miner/pool) ?

my take is that miners will always act in the best interest of themselves, and the protocol just needs to make those interests align with the interest of the network.

see: selfish mining, 0 tx block mining, block withholding (though i guess thats selfish mining), ASICs

<UkoeHB_ "Isthmus: is it economically in t"> Thats the whole incentive system in the current dynamic blocksize system -- if there are more fees to be collected in the mempool than the subsidy penalty for increasing the blocksize, miners will increase blocksize to make more money from tx fees.

<Inge- "would that be 100 miners, or 100"> It would be a vote per block, kind of like signalling for an upgrade in Bitcoin, so likely would be split across pools/miners roughly proportionate to hashrate.

<Isthmus "Each miner casts one [encrypted]"> Isn't this similar to how Ethereum handles gas limit increases? Don't miners vote for that to change it without any dev intervention?

i mean, as it stands, creating a block above the median *is* a vote to increase the blocksize.

"Currently, due to a lack of clear information about how miners will behave in reality, we are going with a fairly simple approach: a voting system. Miners have the right to set the gas limit for the current block to be within ~0.0975% (1/1024) of the gas limit of the last block, and so the resulting gas limit should be the median of miners’ preferences. The hope is that in the future we will be able to

soft-fork this into a more precise algorithm."

<gingeropolous "i mean, as it stands, creating a"> Yeah, the "signalling" method would just be a clearer/delayed way to do it (which is probably against the core idea of dynamic block sizes)

If there is a 100 block delay on a change, you lose much of the short term flexibility in the block size adjustments.

What if the rush is less than 100 blocks long?

<cankerwort> To be clear, people are discussing how to dynamically increase the blocktime on the protocol level in the case where blocksize increases would lead to unstable orphan rates?

<cankerwort> Tricky problem

<cankerwort> As increasing both are eventually needed for on chain scaling but making them both dynamic means there is no actual reliable constant to the ticking of the blockchain

<cankerwort> And unlike block size, there is an upper limit on acceptable block time (regardless of HW improvements) for purposes of confirmation time

Hello all

Remember meeting today at 17:00 UTC

I'll be working on BP+ fast verification via recursion unrolling

sethsimmons: yep that’s how Ethereum handles it, except the votes are plaintext

(And therefore don’t have to be windowed)

Note that the block size could be responsive to short surges within the window

Our current algo already has long-term (slow-moving) baselines that support short-term spikes on top of that

The miners would just vote for the former, and we leave the mechanism for the latter

s/leave/retain

Meeting begins here at 17:00 UTC (about 10 minutes from now)

.time

Agenda: monero-project/meta #499

sarang what we really need is a surreal number curve

Verification takes place in the Twilight Zone

LOL

proof of life

mining is actually a set of go endgames

All righty then

Let's begin our meeting

The usual agenda: monero-project/meta #499

As always, logs will be posted there after the meeting

First, greetings!

hi

ullo

holup can't find my goggles

safety first

Oh, under the bed, of course...

/me puts on goggles and lab coat

Okay, let's roll

nice hair

OK, next up is the roundtable, where anyone can share research topics of interest

Does anyone wish to go first?

sarang first

If not, I have a few items to share

sarang is all you need

I'm in discussion with an ISO-affiliated standards committee in the U.S. regarding blockchain-based privacy

hello

The goal is to provide accurate technical information about the field

More on that as it develops, I suppose

interesting

I made some small updates to Arcturus/Triptych code for better storage efficiency

sounds like formalizations of traceability and taint etc will he useful

be

Reviewed a delightful Triptych article by the outreach workgroup that I look forward to seeing posted

Got a few PRs out the door relating to transaction proofs and message signing

One PR, for key encryption, was reverted since its tests were not properly capturing necessary functionality

Anyone who happened to test this will find that their wallets work just fine after the reversion (or prior to applying the PR)

Thanks to selsta for identifying this problem

And finally, I have working proof-of-concept Bulletproofs+ code

Initially, the weighted inner product proving system

Additionally, aggregated range proofs and a more efficient recursion-unrolled verifier

love that you are doing that code :P

That's progressing quite nicely and working precisely as intended

I'm working out the full batched BP+ stuff in stages, as I did for BP and some related projects

Thanks endogenic!

can i ask again if it'd help to have a coder at your side to do your bidding?

I expect to have the full Python-based batch stuff soon, after which migrating to C++ should be straightforward as well

endogenic: certainly, as I'm sure there are small optimizations in C++ that would be helpful

I should be at that point in a few days

Anyway, that's my update

i found the coder-theorist pair almost overpowered in the past

I'm happy to take questions on any of these topics

Does anyone else wish to share research of interest?

Amy further thoughts on te risk vs return between Arcturus and Triptych. I mean tx size vs the newness for Arcturus?

I don't know a good way to assess the practical risk of the nonstandard assumption in Arcturus

A reviewer seems to stand by their assertion that the assumption is unsafe, though I disagree with their claimed break

and they did not provide any follow-up details beyond standing by their assertion

I'll post the claimed break shortly

I believe they did not properly read the definition

(I intended to post this earlier, but it completely slipped my mind)

curious to learn more about how the assumption is unsafe and the consequences that the reviewer imagines....

The definition for the assumption has a few conditions on it

and it appears that the reviewer's claimed break doesn't apply to all of them (which is precisely why there are multiple conditions)

The follow-up response was something like "this can be extended" but with no details

ha that is not terribly helpful

looking forward to reading the updated later

thanks

I think the reviewer misread the final condition, which is subtly (but importantly) different than the others

But if there is a problem, I certainly want to know

this is the point of preprints and review!

Are there any other opinions on this?

I know this is real tough

It is tricky

This is why I hope for a reduction to a known hardness assumption

but haven't been able to produce one

Anyway, I'll post the reviewer's comments shortly

(after this meeting; need to hunt down the email)

Thanks so much

np

Nice work as always :- )

Many thanks!

Does anyone else wish to share research topics?

I have a quick update and a quick half-baked question

Regarding the update, have switched gears to formal documentation. I find this exciting! Instead of "X algo breaks Y feature" we're actually showing step-by-step how mechanism Y could be subverted.

Nice!

Maybe have draft ready for public feedback next week

It's fun to see the play-by-play attacks imho

Super excited to read it :)

To clarify, this assumes a hypothetical future quantum adversary?

that's been missing for a while

No idea about the timeline

Just looking at the algorithms

Timeline for building QCs out of scope of research

Right, I just mean that such attacks are considered infeasible given current known technology?

(to avoid unnecessary FUD and maintain only necessary FUD...)

Given PUBLIC technology, definitely infeasible right now

I don't intend to have anyone speculate about quantum computing

Thanks :)

Great point about focusing on algorithms, and not specific computing ability

regardless of public or private research, it's clear that current QC-resistant algos are infeasible on current tech

Well, that's part of this research, no?

nobody is going to run a network using megabyte+ keys etc...

Looking at current research and directions?

challenge accepted

The question I see is given that this is possible some unknown time in the future, what are the possible mitigations?

* infeasible on current classical computers

the only machines capable of running QC-resistant algos will be large servers. adopting QC-resistant algos will thus kill decentralization

Isthmus: out of sheer curiosity, do you know of any other major projects looking into post-QC vulnerability in this level of detail?

I agree with hyc that any proposed post-QC mitigations would need to be balanced against practical considerations, as would any changes

but that seems not to be the primary goal of this work, from how I read it

Having a better understanding of the areas of the protocol that would be vulnerable is useful

as is understanding where research stands today, and where it's headed

RE other projects, AFAIK Monero is leading the pack for pq-privacy research.

But this certainly isn't speaking for Isthmus and his team

Quantum Resistant Ledger has pq-security mechanisms but no privacy mechanisms.

Nice :)

There have been some papers on Bitcoin, but they tend to only look at 1-2 algorithms, nowhere near the comprehensive treatment that we're executing

Yeah, I know of QRL but it seems not widespread at this point in terms of popularity or use?

I met one of the QRL leads at a conference, in fact

They're leaning hard into some cool researh

ZK-lattice, STARKs, and pq-signature aggregation

Isthmus: any good resources on that in particular?

I haven't looked into their specific tech in a while (the conference was a while back)

The QRL whitepaper is actually a pretty easy read and nice summary of security attack surfaces and possible approaches

Isthmus: might be a silly question but will there be a report from the work you are doing?

Side note, github.com/theQRL/Whitepaper/blob/master/QRL_whitepaper.pdf

Thanks Isthmus

^ white paper

Interestingly, they're moving towards RandomX which is about the only pq-secure part of Monero

lol

:D

I did not know that

Yea, they follow MRL research

cool

Anyways, that's about all from me. Technical details next week ^_^

Great, thanks

Any other topics to be discussed today?

Or questions?

sarang: any updates on the ISO?

Sorry if I missed these...

midipoet: I have not heard back from the person who handles the logistics

but I did speak with the chairperson

He sent along invitations to relevant meetings, and indicated that participating before completing the paperwork should not be a problem

given the delays that might occur

sounds good

OK, let's move on to action items, where anyone can share their research plans for the next week or so

I'll complete BP+ proof-of-concept code with full batching, and then move to a C++ implementation for timing data and comparison

and post the claimed Arcuturus hardness assumption break

Oh wait, I still had a question (bout non pq stuff)

Oh go ahead Isthmus

Raw version for those not afraid of Google: docs.google.com/document/d/1TBICG6R…dx2NOtGZ1ckvG9VT8w/edit?usp=sharing

please explain

Stuff in yellow is not expected to be cryptographically random/uniform/etc.

Stuff in green should be all noise, right

No repetition/collisions, etc. No patterns if I comb through, etc.

Correct?

But?

I don't have the `but` yet, just asking whether that is the correct expectation

BP data is expected to be uniform across proofs for different commitments, yes

It's certainly possible to generate non-uniform signature scalars in a valid signature

I assume you're identifying something suggesting non-uniformity?

Note for BPs that AFAIK nothing stops commitment reuse...

and that's not _necessarily_ dangerous

but certainly nonstandard

FWIW all but one signature scalar in MLSAG (and CLSAG) is signer-selected and arbitrary

You can absolutely have a valid signature with terrible scalars

Haven't identified anything yet, still in the hypothesis generation and experiment design phase.

Essentially we will hypothesize that certain fields should be uniform/random/non-colliding, and then look for counterexamples

ok

It's probably important to separate what's signer-controlled and what isn't

^^

e.g. almost all MLSAG/CLSAG scalars are signer controlled

the same is not the case for BP

Oh yea, I need 3 categories, not 2 colors

So the MLSAG scalars _should be_ random, but don't _need_ to be

there's additional layers to BP

1) signer controlled, expect patterns (e.g. lock time)

2) signer controlled, but should be random (e.g. MLSAG scalar)

3) output of cryptographic fxn, expected no patterns (e.g. proof outputs)

Interestingly, there was an idea to use a hash function for MLSAG/CLSAG to allow for data hiding or signer identification of the signing index

This would, if implemented, help avoid the case of a bad PRNG

but can't be enforced, of course

Ooh that's interesting

Yeah, I have some example proof-of-concept code for it

You use a hash function for all the signer-controlled scalars, and the remaining one is uniformly distributed

The signer can use this to later recover the signing index, but this isn't public

it's a cool idea

Sweet.

Okay, that's all for today then, I'll work on formalizing and splitting stuff up into the 3 buckets.

Great!

Any other action items, questions, or the like?

If not, we are adjourned!

Thanks to everyone for joining

Logs will be posted shortly

gg

Here is the reviewer's claimed break of the Arcturus hardness assumption: paste.debian.net/hidden/518ed57e

This is the Arcturus preprint: eprint.iacr.org/2020/312

The relevant definition is Definition 1 on page 4 of the preprint

I would appreciate any comments or analysis of this

So if I understand this correctly. In the definition G and H are chosen by the Challenger (Adversary) and sent to A. A then chooses the sets {Gi} and {Hi} subject to the constraints and sends them back to the Challenger. The reviewer has this backwards, with A choosing G and H and the challenger choosing the sets {Gi} and {Hi}.

The question I have is who is the adversary?

In this application, someone trying to build a proof adversarially

I think the reviewer is considering the `G` and `H` bullet-point conditions in the definition the same, when they're constructed differently

Note the index difference, which is important

The interactive challenger choice of the `mu` coefficients is replaced in practice by a hash function via the Fiat-Shamir heuristic

So each `mu` is computed using all the components from the previous transcript steps from the interactive version

Also, the challenger is not the adversary

The adversary is playing this game against the challenger and, if the adversary can win non-negligibly, it could break soundness

Thanks. I see the point about the G and H conditions being different. The reviewer is not providing choices for G