Commitment was recommended but never integrated AFAIK due to compatibility and communication complexity AFAIK suraeNoether

well my notes say a message is signed with the key, which is good news, though idk where in the code that is done

reading this, not promising taiga.getmonero.org/project/rbrunne…ions/wiki/22-multisig-in-cli-wallet

"Now exchange addresses and compare, they must be the same."

ok that quote isn't relevent, but nevertheless I dont see evidence of signing

I would still like to see a commitment phase as indicated in our preprint :D

the whole thing might deserve an audit

It needs to be updated to reflect the paper, or acknowledged as not being what the paper represents

This isn't anything new

It required another round , and IIRC there was not interest for introducing this at the time

(again, I disagree)

it seems like key cancellation isn't a problem for sub-N threshold aggregation

though maybe some edge cases..

I think round robin can be reasonably avoided with 4 rounds of communication (assuming secure communication channel). Round 1: signing initiator sends the message to be signed to all possible participants (or a subset no smaller than threshold). Round 2: each participant who wishes to sign signals their intent by sending their opening components to

the signature to either the initiator or to all other participants. Round 3: once the initiator has collected enough intent-to-sign signals, he broadcasts a list of signers who are expected to participate (may be >= to threshold). Round 4: each participant makes sure they have all the opening components from list of planned signers (perhaps in

Round 3 the initiator sent out all the signer information along with the list, to each prospective signer), and completes their signature response, sending it to either the initiator or any number of other active signers. Once any signer (or observer, of any kind) collects a full valid signature, they may publish it. Each signer must make sure that

they only provide one response for a given opening component. If something goes wrong, repeat from Round 2.

in Round 4, the participant bases their response on the intersect of a sorted list of all participants, and the list of real participants, and assumes the lowest-index signer with a given key will use it to sign

although that implies broadcasting to >= threshold will result in some non-participating signers

> not >=

Have you read the description in the preprint?

not yet

Please do

ok starting now lol, got through all the other documents

you say preprint, was it submitted for peer review?

I believe suraeNoether had submitted for SBC

But that has a low acceptance rate

i think im misdefining a round..

a round is more like.. 'everything you can send without doing computations'

or maybe 'the next round may not begin, until this one is over'

it seems to boil down to giving an adversary some level of control over the challenge value; the attacker can, after collaborating with the signer on a number of signatures (or maliciously aborted signatures), use Wagner's algorithm to produce a forgery

interesting

since the response is only secure when both opener and challenge are randomly distributed

So no CLSAG for this fork either, apparently ?

suraeNoether had requested that I put it aside temporarily while he considered additional aspects of the LRS definitions

So you'd have to ask him

FWIW the security model is better than that of MLSAG, and we had agreed that no LRS model we've seen is ideal

By "put it aside", you don't mean the searching for reviewers right ? That goes on in parallel.

Correct

And that is the main obstacle AIUI.

Availability, yes

What's planned for the upcoming fork so far?

Any intent to delay, either this one or for a generally longer period (9 months or a year between them)?

CLSAG only :)

I don't know about 9 months vs 6.

If no CLSAG, then delaying seems very likely.

Well I will wait until suraeNoether approaches, to get his thoughts on any further changes he wishes for the security model

But good point about delaying. We don't need to have that oncoming wall for any review to meet.

Otherwise the draft preprint is sitting in overleaf, being lonely

I think that it makes sense to delay the hardfork if no clsag. Just have a major release instead without consensus changes

then people aren't going to upgrade.

Isn't that basically the same situation as minor upgrades?

gingeropolous: flash a fancy feature in their face I guess. Otherwise I guess it doesn't matter if they don't since it doesn't impact consensus

Now in rose gold!

Comes with a coupon for a free beer!

the point of the rolling hardforks was to establish and maintain a network participant behavior to ensure a healthy network

lets just enjoy a nice, non PoW related hardfork like the good ol days

this is maybe getting a little off-topic for this channel

nah, we can sprinkle some math on this

How about that scalar multiplication

Crazy, amirite

moneromooo: I'll have a 10-line change to the CLSAG code, FWIW... it removes some unnecessary 0-entries from a hash input

It's not related to security, but currently wasted cycles

OK

The entries were going to be used for some index stuff that we ended up not needing, and I never removed the 0-allocation

Think of the savings!

Fractions of a microsecond!

adds up

We could... pre divide key images by 8...

Fractions of a millisecond!

lol

I'm getting some new timing code up and running for CLSAG-with-timelocks today

See what that effect would be

We do pre-divide auxiliary images in CLSAG currently (currently = the test code)

but not the linking key image

moneromooo: small updates for CLSAG

Something's out of sync already. I do have that FIELD(D) in my version.

OK, then you must have added that

I can run a diff on the sign/verify if you like

The rest applies fine.

You never had it ?

Actualy... Did you write the C++ code ?

Oh, I'm confusing with bulletproofs. nvm.

I wrote the C++ code, but didn't include the serialization change since I was only writing for performance testing

I included it now because I noticed it

Anyway, that means the only change is to those unused hash inputs

OK, so I must have added it myself then.

There's no effect on overall timing since it's so minor

suraeNoether you here by any chance?

what's up

Have you gotten a chance to look at my response to the ccs submitted? If not yet, it's fine. I wanted to discuss it with you

ah hey

i haven't seen your response yet, sorry, let me take a gander

No worries

i hope you aren't discouraged!

Not at all, I wanted to make sure you saw my apology. I did not mean to put your name without your approval

I was meaning to run it by you, and I feel bad about it now. I have amended it so far by removing your name

Everyone was new here at one point; no worries

That's part of the GitLab process for this; getting feedback and making edits as needed

*nod*

sarang and i have been talking about a list of possible problems that could use tackling, he recommended a huge list of possible projects

Cool yeah this was my first time submitting and I was making sure I got all the steps right, one of the most important things slipped my mind lol..

Yeah, my list of interesting-sounding project is usually pretty long

Hmm cool

I'd like to take a look

I can list a few here; it's not a public list

go for it

Okay yes, excited to hear

The DLSAG preprint mentioned the possibility of CLSAG-style key aggregation, but this was not included in the paper itself due to space and time limitations

and the security model for DLSAG needs updating for a future submission

Zero to Monero (by koe) has recent additions for which they'd like review

BLAKE3 was just released, and I thought it could be fun to write up a Python version for test library compatibility, just for the helluvit

This PR needs review, from vtnerd: monero-project/supercop #3

Multi-input Triptych has soundness/proof-relation questions to be answered still

I'd like to see an implementation of a bulletproofs circuit proving knowledge of equality between a SHA-256 hash preimage and a DL preimage (on ed25519)

It would be nice to analyze the ability to include arbitrary field elements in bulletproofs using a randomness-unrolling method (there's a term for this that I'm blanking on), as well as determining applicability to Triptych, RCT3, and Omniring

Hmm okay this is good. Just looking at this so far. I can review ZtM and the BLAKE3 project sounds interesting.

^ that BP circuit one would have implications for swaps between monero and bitcoin

I'd like to see a test implementation of Omniring, to determine if there are any algebra issues (I have found a few that are questionable)

etc.

(the list continues...)

blake may be appealing for a few reasons, including it's tree-like structure

Note that I don't have a particular application in mind for BLAKE3, but it's a really cool design

my understanding is that it allows partial verification of hashes, but that paper is not high on my priority list rn

that was a low-priority one, but it's so new that I haven't found many implementations

Tell me more about BP circuit one, that could be interesting too

The BP paper did some timing estimates for a SHA-256 preimage circuit

and someone did a writeup describing an idea for XMR-BTC swaps that requires such a zk proof

I'd like to see a proof-of-concept implementation of this

Is this higher priority than the BLAKE3 project?

The writeup: github.com/h4sh3d/xmr-btc-atomic-swap

It's likely more applicable

atoc higher likelihood of seeing app... damn sarang

type slower

at least more _directly_ applicable for sure

oh this looks cool

So does an initial implementation of this exist yet?

I looked it over a long time ago, but haven't done anything formal with it

or is that what you would like to see?

Not that I know of

Interesting. I think I will like this project

(Note: I didn't write this, obviously!)

So I can't speak to the safety or correctness of the writeup's proposed protocol

However, the preimage proof is a building block requirement

Ok that's fine. Yes but it would be something interesting to discuss

We have a bulletproofs implementation, but it's only for range proofs (not for arbitrary circuits)

the dalek project has a more general one in Rust that's faster and very well written

So a Python implementation of this is something good?

Oh yes I have heard of Rust

Well, if the protocol turns out to be feasible/safe/practical enough to warrant it

Doing a general circuit BP implementation in Python would be personally interesting to me, but a lot of work

btw - not necessarily super relevant, but are most of your research projects done in python?

mm I see

If you use the dalek libraries in Rust, you've already got a BP circuit framework done

I like Python for fast proof-of-concept iteration, but it's not claimed to be secure code

yes indeed

Rust provides nice guarantees, but I am not proficient enough to iterate quickly with it

(so don't use my Python curve library for anything except proof-of-concept stuff that's assumed to be insecure)

but it is great to start initial implementation as you mention, if there are libraries for a BP circuit then this is more attractive to start with

Does the dev team use Rust for final implementations? I assumed it was mostly Python

The Monero codebase is mainly in C++

Ah I see - makes sense

The dalek BP library: doc-internal.dalek.rs/bulletproofs/index.html

There may be other good BP libraries in other languages too

Oh, Benedikt Bunz had a Java library

Can't believe I forgot about that

Not sure what your language of choice is

This looks good - hmm I'd be interested to see that.

So I don't necessarily have a preference but most of my work is in C, Java, or Python

Rust sounds attractive because I have heard it used for other projects

I will look at both and see which one seems quicker just so that we can start experimenting

Do you use Java / Rust?

atoc: just to clarify, if you *want* to tackle the matching code, feel free. it's still an interesting project, and the code is in a good state for someone new to mess around with. but the project overall is nearing completion, and this is why i sort of waved you away from it.

I have some Python curve library stuff (and BP range proof code) in my repo

I used Java in the past, but don't really like it

I'm starting to tinker more in Rust

I'd like to use a language that the you guys are also familiar with (incase I need you to review code)

suraeNoether yes I noticed that. I think what might be best is if I take on a larger project and also help where I an to complete it

but as you say it's near completion

sarang then Rust is good with me

I will take a look at the dalek library more

If you're interested, you might find this useful: github.com/crate-crypto

Another contributor worked up CLSAG and MLSAG in Rust

using the Dalek libraries

Ah very cool

Well this is really very great. The paper already looks very interesting.

suraeNoether in the Thring paper you use several `hash' functions, e.g. H_sign(), H_com(); these are equivalent to H_com(x) == H_n(000, x), H_sign(x) == H_n(010, x). How important is it for implementations to use those prefix tags?

The proofs of security assume that all of them are distinct functions. I would have to examine the proofs very carefully again in order to determine how dangerous it would be to exclude the tags, but there's almost no cost to including those prefix tags, and the scheme is proven secure with them.

if you held a gun to my head, I would say that it's probably safe to get rid of the prefixes, but that's not how we want to think about secure software development

ok thanks I'll put that in my chapter; code base needs an upgrade too, I think (on several fronts); not sure how easy it would be to migrate older multisig wallets moneromooo

If you want to change the way keys are computed ? And define migrate.