Can someone explain to me what the purpose of these few lines in bulletproofs are? github.com/monero-project/monero/bl…ter/src/ringct/bulletproofs.cc#L116

It sets a variable to false then immediately checks if it is true or not.....why?

It is intended to run the rest of function once and no more.

is that an object oriented programming thing?

No. There are objects in there, like the lock above.

huh. i get what QQ is getting at, but im no programmer. but it reads like init_done is never gonna be true, cause its always set as false in the preceding line. but this is why im not the programmer. i'll go back to whatever it is i was doing

It's static. It means its value stays unchanged over calls.

It's set at the end of the function.

The way I see it, if init_exponents() was called before, it will return. If not, it will run and set init_done at the end.

And the lock protects the init code from running in two threads at the same time,

i feel bad cluttering my lack of c++ understanding here... but ... 116 is setting it to false. And then 117 is checking if its true. if its false, it will run, and 141 will set it to true. if its called again, 116 will set it to false. etc.

< moneromooo> It's static. It means its value stays unchanged over calls.

Imagine it's global.

It kinda is.

Well, I certainly appreciate the attempt to explain it. I will chew on it some more and see if I can pick up what you are laying down.

It does not get reset when called again.

Its value does not change across calls.

Does the line on 116 set it to false if the function gets called a second time?

ah, so the initialization call in 116 sets it to false, but when the code wants to initialize it again, it goes "nah buddy, im alrady initialized"

No QQ, yes ginger.

cause its pointing to a location in memory. and pointing to, changing, and creating a memory address are all unique things.... hrmm.. thats cool

It's global really as I said. Except lexically.

Thanks moneromooo, I appreciate your patience.

I was pointed to an interesting paper about multiparty ECDSA today: eprint.iacr.org/2019/114

Might be useful in building MPCs for new proposals that require inversion

^_^

Will read today and think about applications

A variation of the method discussed in section 4.2 of that paper may be suitable for inverse computation... and presumably the rest of the linearly-dependent private key stuff could be handled as usual

The question becomes how many rounds, versus the security guarantees

Things like precommitments add computational complexity, but prevent tomfoolery

hey everyone

please excuse my absence yesterday, i was sick and i was coding offline while drinking lots of tea. i'm trying to get matching off my plate while i take a break from security proofs

i'm giving myself until end of day tomorrow before i switch contexts back to proof writing and checking

suraeNoether: I tidied up some Triptych definitions and finished the LA proof in CLSAG

i've made a small change to my Matching code because playerchallenger was getting really messy and was unnecessarily object oriented. i've replaced that script with tracing.py, which has the general structure of the space i'm trying to explore (for each ring size, for each churn length, etc, run a simulation and add the result to a csv file) but is still sufficiently buggy to require more massaging

I'd like your opinion at some point on applying the Triptych linkability and non-frameability defs to CLSAG

i saw you had made some changes *right after* i printed the older version of the paper, and this is one of the (minor) reasons i switched gears briefly. :P hehe

No problem

That's my fault :/

nah, it's copyediting

I wasn't happy with how linkability was being presented

it's how it goes

I've come around on the Backes linkability definition

does triptych support dual output with hidden trigger heights btw?

It's basically a set-theory test

Ummmmmm not that I can immediately see

The linking tag structure (and its use in verification) is much different

how about threshold multisig?

using a commit-and-open approach

Well, if the MPC inversion approach works, in theory Triptych and RCT3 could benefit from it for multisig

but this is a hypothesis

is there a point in my logs that you've discussed that recently?

Earlier today I posted a relevant paper on ECDSA MPC that was brought to my attention

It uses a clever approach to computing the inverse of a secret field element

was this a *this morning* sort of realization? or is this one of many papers you've been reading about the topic lately?

This morning

I've been working up some initial math on paper today

ok :D thanks for the clarifications

The issue is that the secret key is used in different ways in each sublinear protocol

So we must tread lightly on how to go about MPC

Each requires an inverse, which was the tricky part

and also an affine computation, which we understand much better

This is the paper I'm looking at: eprint.iacr.org/2019/114

thanks

Namely, adapting the method presented in section 4.2, which uses the protocol in section 3

who brought it to your attention if you don't mind me asking

It was in PM, so I'll respect their privacy unless they wish otherwise

it was satoshi, wasn't it

or craig wright

-___-

craig wright has, admittedly, given me my best shower thoughts, but i'll also admit they have nothing to do with computer science or math.

In practice, what t-of-n values are most useful for multisig?

I ask because the method I'm looking at requires pairwise interactions between players

I think 2/3 and 3/5. Also possibly 2/2.

suraeNoether: did you ever get those graphs you talked about on Monday?

It would also require a one-time setup phase where each player has its own keypair used just for transmitting multisig data

Hmm, looking at that, the paper suggests the use of Paillier as this internal additively homomorphic cryptosystem

This means computationally-constrained devices would need support for the more generic computations (arbitrary modular reduction, etc.) that this would imply, rather than only curve operations

ElGamal is homomorphic, but requires a mapping of the message onto the curve group homomorphically... and in this case the messages are scalar field elements

So really what we want is an additively homomorphic encryption scheme that's light enough to implement and plays nicely with scalar messages

^ suraeNoether

Sgp: the code for that is in my tracing.py file which is currently being debugged. That script generates a csv file importable into Excel. Or it will once I figure out a few problems with it

Sarang you mean an analytic/computable function? If such a map were a homomorphism then discrete log would not be hard. And for a simple map you can just keep a hash table with secret key public key pairs. So I'm guessing you want something computable that isn't a homomorphism and that doesn't require a hash table (because the table may as well be used as a discrete logarithm oracle)?

So why not Hs(X)

Because that's a hash table

So I'm not sure exactly what you are looking for

Nah, you're right... that would imply an advantage on discrete logs

Paillier it is!

A hash map unfortunately would not work for this