re: inflation bug fud - how would that look in practice? receiving extra XMR when getting a payment/change output? that would be very obvious and not "undetectable inflation". also, would those "new" outputs even be spendable?

meeting 1hr

r4v3r23[m]: in practice it would be semantically invalid transactions that validate at consensus, ie txs that look completely normal but don’t have a proper amount balance

meeting time monero-project/meta #719

1. greetings

hello

Hi

Hello

Hello

Hello

2. updates, what is everyone working on?

Won’t be 100% available this meeting unfortunately, but update: submitted perfect-daemon’s PR 7760 socket connection fixes with merge conflicts resolved + some style changes more in line with the rest of the repo (see PR 8426), submitted a patch for zmq to publish txs submitted to the daemon (PR 8427), and updated openmonero for the hf

Mostly doing OSPEAD work.

I'm benchmarking my python code with the c++ code. Thank you for the detailed review on the website UkoeHB !

I published my new address specification, featured addresses

It's more dev, but I wanted to comment on it as it does remove the burning bug under one variant

I think I will implement bp in rust too by the end of this month or next one. It will be useful to build my skills and I think it may be useful for kayabanerve too

Hi

me: started work on the last big project on my end for seraphis poc -> integrating legacy cryptonote outputs into the main transaction type so they can be spent alongside normal seraphis enotes (instead of two tx types there will be just one, and the cryptonote inputs will be selected from the full range 2014-202x so if/when seraphis goes live there will be ONLY two tx types being created [main tx and coinbase])

UkoeHB: But the fact that an input is an old cryptonote output would be apparent to observers of the blockchain, correct? Can't mix two output types in the same ring, right?

correct

there would be seraphis inputs and legacy inputs

That will go all the way back to outputs from 2014?

yes, you can use the technique that's currently used with coinbase outputs to spend the cleartext amount outputs

Reassuring

The MAGIC Monero Fund is considering targeted outreach to external researchers to apply for research grants. If you have any in mind, let us know. We would be targeting people who could make a practical contribution to the protocol.

3. discussion, we can move on from updates :)

I was wondering where BP++ stand, not in connection to Monero, but in general as a new cryptographical/mathematical construct. It that "trustworthy" already, or does that need audits / reviews?

AFAIK, BP++ is not peer reviewed yet and was written by a single person.

Ah, yes, "peer review" was the word I was looking for

Rucknium[m]: the main research areas it would be nice to have are in zk circuits for 5th-gen membership proofs and in formalizing current ad hoc algorithms (and adding security modeling/proofs)

So I get no mad rush yet to implement them

Maybe coming up with a list of Monero's algorithms and dividing them into formalized and not-yet-formalized would be a good first step.

So that researchers would have a good idea about where to look for improvements

One of the questions in my mind for "zk circuits for 5th-gen membership proofs" is the assumptions that we would like to rely on. For example, Zcash's protocol has newer and less-tested assumptions. Ideally we would want researchers to develop membership proofs with global anonymity sets that rely only on old battle-tested cryptographic assumptions, correct?

Today I want to explain/discuss some of the next steps for seraphis after I am done with my stuff.

My remaining todo: integrate cryptonote inputs (possibly including a new default output scanning workflow for legacy outputs), add coinbase tx type.

Todos after that (not me): investigate/implement the wallet-side features of Jamtis (RIDs, Polyseed, address authentication), build wallets that use the seraphis library interface for building/handling txs and enotes (full wallet, view-only wallet, multisig full wallet, payment validator), integrate seraphis into the daemon/ledger, ... idk what else.

I don't want to instigate cutting-edge research that will be "too" cutting-edge for us to use.

Rucknium[m]: yes the more robust the better (no trusted setup is a requirement)

jberman[m]: has said he wants to work on seraphis/jamtis next steps, it would be nice if anyone else interested could start raising their hands (and start looking at the code to get an understanding how it works)

How do we get the cryptography in Seraphis to be peer-reviewed?

"anyone else interested could start raising their hands" Well, here :) Just not yet sure when, how and how much.

well that is a non-implementation todo of mine -> update the paper more and try to get more cryptographer eyes/contributions on it

rbrunner: I'm definitely interested in contributing for real. I'm just not finished yet on building my skills and understanding. In two months I believe I will be able to start contributing.

I guess I didn't make a public statement about my CCS: I won't actually make a wallet proof-of-concept, since designing the API and internal caches isn't really my domain. The remaining time of my CCS will be spent finishing the core library.

dangerousfreedom: Sounds good.

I basically way underestimated how much work was necessary to reach the point of 'write a wallet'.

I think implementation can start before we have more review / feedback for Seraphis and Jamtis themselves. Only requirement, bascically, that they don't "explode" compeletely

I mean turn out to have some un-fixable hole somewhere

if they explode, that implies lelantus spark will probably explode as well

Speaking of future plans, after OSPEAD I am thinking about researching churning best practices. From reading old GitHub issues, it seems Surae and knacc both made attempts, but did not complete the research.

OSPEAD won't be the final word in research on decoy selection, of course.

UkoeHB: are we using the existing hash_to_curve or elligator2 or...?

kayabanerve[m]: seraphis does not use hash to point except for making generators (which uses the cryptonote hash to point function)

Got it, sorry

are there any questions/comments/other topics to discuss?

Where are the most up to date and complete specifications for jamtis and seraphis?

wernervasquez[m]: aside from github.com/UkoeHB/monero/tree/seraphis_lib there are

the monerokon slides are 100% up to date

Thanks. I have some time coming up to put more work in on my library. Want to make sure my footing is sure.

@UkoeHB: thoughts on getting the poc audited and paper reviewed (once both complete), by e.g. veorq? Perhaps we can start opening discussion

no thoughts other than 'good idea'

has polyseed been look at? tevador says its production ready

not by me

there were some concerns raised that 16 words isn't enough entropy

it's only 128 bits yeah? and current seed is 256 bits

tobtoht implemented it already in Feather

If it's at least 128 bits...

*128 bits of security, that is.

They released a few days ago.

Yeah, we go from one possible wallet for each and every atom in the universe to one wallet per molecule or so ...

Or maybe grain of sand :)

Ok I think that's the end of the meeting. Thanks for attending everyone

Thank you for your work Koe!

+1

Bye everyone!

<rbrunner> "Yeah, we go from one possible..." <- how does that compare to bitcoins entropy>

Not sure, but I think to remember that Bitcoin also stands at around 128 bits of entropy

Bitcoin's 12 word seeds are 128 bits, yeah.

The polyseed readme claims 150 bits of entropy in the seed, which is bottlenecked by the 126 bits of security in ed25519 so it's there's no point in making it any longer as far as I understand.

Bitcoin addresses are hashed, right? Are encoded points like monero addresses more susceptible to an attack based on low entropy?

Here's where I found the info I just regurgitated: github.com/tevador/polyseed#secret-seed

If "attack" means just "try each possible private key" then it probably takes a bit longer if you have to hash as well before you can compare

So 10 times the remaining lifetime of the universe, and not only 5 times ...

I am a bit obsessed with all things universe, you know.

Anyway, who on Earth hacks something nowadays, even something that is almost trivial to hack. Sell the people NFTs, profit, done.

so polyseed is as secure as bitcoin's seed scheme. is there any criticism of that?

It's called "anchoring" in psychology. The current "anker" stands at 256 bits, you go lower, you get questions.

question is if going lower harms security in any tangible way, not just theoreticals. aka is 128 "good enough" for the task, which im assuming it is

a longer seed reduces chance of a collision

assuming ~2^40 user addresses, I believe you'd get a collision with that set in 150 - 40 = 2^110 ops

Isn't the whole question moot, like tevador seems to argue on GitHub, that if do operations on the ed25519 curve afterwards with your "entropy" you loose any bits beyond 128 anyway?

Fun napkin math on time to break any one specific 128-bit key: If we could check keys at the same rate as the bitcoin hashrate of 165EH/s (which we can't), it'd take 2^128/(165x10^18 * 60 * 60 * 24 * 365) = 65 billion years.

BusyBoredom[m]: so polyseed is secure af

the rho attack can break any private key in ~2^125 steps, even if you use a 256-bit seed

yes ~128 is the max, but you can get lower than that

for example, if your private key was in the range [0, 2^128], then your private key only has 64 bits of security

seeds don't have uniform entropy?

What do you mean? I only have to check 2^64 values? I am afraid that's too high for me :)

when you are hashing, you only have collision resistance equal to half the bits of the input variance

rbrunner: you need > 90 bits to be secure iirc (or maybe 100)

Ah, ok, collision resistance, slightly different problem

no, I am talking about two things

"for example, if your private key was in the range [0, 2^128], then your private key only has 64 bits of security" -> this is 2^64 ops to reveal any private key

if you select your private key uniformly from [1, ℓ-1], you'll get the full ~126-bit strength

"when you are hashing, you only have collision resistance equal to half the bits of the input variance" -> this is 2^{variance bits / 2} ops to find SOME collision

if you have a specific set you want to collide with at least once, it is 2^{variance bits - collision set bits} ops

tevador: yes, selecting uniformly at random means you won't have any DLP weakness. But if your selection variance is too low then collisions can be brute forced.

polyseed uses a 150-bit secret seed, so you'd need to attack ~17 million seeds simultaneously to break at least one key with 2^126 ops

tevadorcan you give a quick ELI5 explainaion for why a normal user should choose polyseed over 25 words?

two biggest reasons are: shorter seed, embedded wallet birthday

there have been many support cases that are basically "I restored my wallet from the seed and my balance is 0. Help."

-> because they entered the wrong restore height

and response to the lower entropy arguement?

shorter seed & restore height are major improvements

"lower entropy argument" is just a misunderstanding of how attacks against EC-based public keys work

tevador: what is your safety factor (in bits)?

against a single seed? if the attacker knows the month when the seed was created, the work factor is 2^150

tevador: from what i (a non technical user) understood, the security between polyseeds 128 vs current seeds 256 is a non issue

tevador: taking into account all plausible attack scenarios

UkoeHB: I don't follow why you say a 128 bit key has only 64 bits of security. What is weakening it? If you gimme some words to search I can Google my way to understanding.

the lowest safety factor in bits

BusyBoredom[m]: 128 bit keys have 64 bit security according to the giant step baby step algorithm

assuming fewer than 17 million new seeds are generated per month, the best multitargeted attack is at least as hard as Rho (and probably much harder if the KDF is assumed to provide additional ~12 bits)

idk what you are referring to with 'Rho'

Pollard's Rho attack

"giant step baby step algorithm" Huh?

the same attack works against hash functions

it breaks an N-bit ECDLP in 2^(N/2) steps

"the same attack works against hash functions" this is ambiguous

rbrunner: baby step giant step is another type of attack

hash functions have collision resistance and preimage resistance

UkoeHB: some article references are here in the bottom: safecurves.cr.yp.to/rho.html

it's currently the fastest known method to break ECDLP

tevador: the date only adds around 7-8 bits, so I guess that means you have 158 bits of variance total

if it is on a per-month basis

yes, ~160 bits total, plus perhaps 10 additional bits from the KDF

how do you get more bits from a KDF?

if you compare EC point addition to PBKDF2 with 10k iterations

oh like a kind of PoW barrier?

something like that, it's the constant factor of the attack (cost per one step)

r4v3r23[m]: the main takeway is that the current 256-bit seed provides only 128 bits security, not 256 bits

Ok assuming a 40-bit upper bound on collision surface, that's around 130 bits of EC-attack-equivalent cost for a collision, which leaves around 20-30 bits of security factor (which is typically what you want).

tevador: so equal to polyseed then?

or in other words, attack cost on par with the DLP

r4v3r23[m]: yes

excellent. no real drawbacks then, if any. thanks for the explaination