Hello all

morning

'ello

halo

Supply audit blag post MR: repo.getmonero.org/monero-project/monero-site/merge_requests/1207

Please read and comment

"whatever more complex mathematics is used for balance assertion is unlikely in practice" I think the word unlikely means something else for the casual reader than for a cryptographer.

amounts are hidden using cryptographic structures called Pedersen commitments Xthat hide amountsX.

The benefit is to help with -> This helps with

"It is not possible to _prove_ that these problems are hard" Is that really right ? I thought it was possible to prove.

koe: added the small wording change

Or at least not known to be impossible. But hey, I'm in the peanut galleery.

I'll defer to sarang for the others

Hardness assumptions are just that: assumptions

But AFAIK assumption as in we did not prove it was, nor that it wasn't. Not as in we proved it's not possible to prove even if it's true. Though I'm not sure how you'd prove it's not possible to prove something which is true but it doens't sound impossible offhand.

(say so if I'm plain wrong, I might well be)

Oof, good catch koe

moneromooo: this seems like en.wikipedia.org/wiki/G%C3%B6del's_incompleteness_theorems

!

OK. I was wrong then. Thanks.

Oh no, I don't mean to say that any particular hardness assumptions fall into that

The wording I used could be changed

to something like "these hardness assumptions are not proven"

Ah. Back in the race :D

ping me when you two sort it out :p

"It is not possible to _prove_ that these problems are hard, but decades of research and use implies this." <-- "The computational hardness of such assumptions is not proven, but decades of research and use imply this."

Something like that, perhaps?

well, sarang just referenced Gödel, so we could be here a while.

-____-

I like that better

suraeNoether: any thoughts on the post?

sarang hrm i get the concepts but (a) it sounds like the blog ends on the note that further research on soundness isnt considered theoretically to be likely fruitful .. and separately (b) the diagram kinda makes it sound like soundness of the supply is not tied to implementation risks ... are you saying 'theoretical soundness' in that diagram?

(diagram with the circles)

the diagram confused me as well

That was sgp_'s work

o no what am I liable for now

point was to try and visualize relative risks

LOL sarang instantly blame sgp

Not my intent!

just teasing

I can replace the image with something else that helps show relative risk

easy could be replacing 'soundness' with 'theory' (i.e. the theory/math) - and i'd make it the same color as the other dots since they're supposed to sorta be in the same category of objects

maybe put 'em all side by side, labels under

oops edit fail

s/the theory/the model/

I think it could be fine without the image

sarang: I think so too, but I want some visual if possible

endogenic koe sarang is this better? what can I replace the '...' with? I'm thinking something funny. 'fluffypocalypse'? usercontent.irccloud-cdn.com/file/QY45aCfL/relative_risks

I'm not a fan of assigning relative risk sizes like this... someone will rightly complain

how else can I help show users it's a relative balance of risks? in a large sense that's a main point of the post

let me try a graph

I already don't like the graph idea

great post sgp_, sarang. enjoyed it.

do you at least get the goal of what I'm trying to convey?

Maybe compare to likely vs. unlikely events?

Getting a speeding ticket vs. getting struck by lightning

You don't want either, but one of them is much less likely

<atoc> yep speeding ticket is less likely

hi math nerds, Im wondering if the MLSAG decoy responses can be theoretically compressed if we change the randomness into hash outputs of the signed message (e.g. h1 = H(m,1), h2 = H(m,2); something like that)

I dont know how to compress while hiding the real one, but is it logically possible?

by compress Im considering the sum of field elements, e.g. q = a + b

or q = a*b

and the hiding effect from a truly random number, so generate a random number, compute the hashes, compute the decoy responses from true random and hashes, perform the signature and get the real response, compress the responses, then return one or two scalars which can be used in combination with the known hashes to generate the list of responses

and the real response is at an unknown index in that list

definite progress visually sgp

solved that problem

can you elaborate endogenic?

uh nevermind i thought you renamed it for some reason. this is what i get for doing 4 things at once

koe: I don't see how you could do that while still hiding the signing index

would it be reasonable to outsource the problem to other math nerds? here is my outline justpaste.it/5zdsd

would it be worthwhile to offer a bounty (e.g. let you guys focus on your current projects)? if so, would someone mind helping me formalize this? draft 2 justpaste.it/2ounn

moreover, where would you even go to propose such a challenge?

I think you can do this by seeding a hash-based chain and including an offset

@sgp maybe something like a bee sting, a car accident, a tornado, and a tornado

(if I'm understanding the problem correctly koe)

koe: are you saying you want to be able to generate a sequence `S` such that for a secret index `l` we have `S[l] == v` for some secret value `v`?

and the sequence `S` is uniformly distributed field elements?

Because that is possible

where v is the product of a one way function of the other members of s

or in other words v can only be determined after all other members of s are known, and v is random

Could you use a method like this: gist.github.com/SarangNoether/bdceabf9a72de13040fed91dd2104c7c

You can select `v` at random after building the hash sequence `S`, and choose the offset `x` accordingly

Isthmus: hmm, I'll try a few options

In that example, `v` is whatever you want it to be

You could have a set value, or choose it after building the sequence

ok lemme see

Maybe this isn't what you're asking

It uses this ed25519 test library: github.com/SarangNoether/skunkworks…/blob/curves/dumb25519/dumb25519.py

well we have MLSAG scalars, and most of them are completely random, so why not offload most of that randomness to a hash function that verifiers can compute as well? then the prover just has two pieces of important info: the real response scalar, and the randomness used to obfuscate which index is the real scalar

kind of like how the commitment mask was changed, it's now created out of the transaction public key's randomness

not sure that code works, since x is a function of v, so after S += x, ALL the scalars will be functions of v

Yeah, this wouldn't work for MLSAG/CLSAG

Since you need `v` to construct `x` and offset the whole sequence

Unless you operate on each sequence element, the verifier would gain information

Im trying to think of a way where, you do an operation on each element, and most of the time information related to v gets canceled out EXCEPT for the element v itself