I have summarised the number of multi-scalar multiplications necessary for BP and BP+ in the comment to our CCS proposal (Link: repo.getmonero.org/monero-project/c…als/-/merge_requests/156#note_10110).

Thanks suyash67

I don't think I specifically pointed this out during the earlier conversation with suyash67 and omershlo, but they mentioned one possible concern was "Sarang can do it better"... to be clear, I don't claim this

(relating to their BP+ CCS, I mean)

Nor am I claiming that I would "do it worse"

Basically, you are claiming you are not claiming anything :)

I didn't want it to be interpreted as me opposing the proposal because of this

I'd have to read the logs, but I'm not sure if anyone said I could do it better

At any rate, I don't claim this

It's accurate to say that I _do_ think I could produce a quality implementation

I think I said something close to that: that I wasn't comfortable leaving crypto code to unknowns (implicit was: I'd be more comfortable if sarang were to do it).

I had not heard of the proposer before, but I have seen omershlo's work elsewhere

I think a bigger risk might be if the code were sufficiently different to make the review process difficult

Which might necessitate another full audit

But the proposers did say they want to reuse code to the extent reasonable

From Suyash on CCS: "By code reuse, we mean that we want to keep the same interface as much as possible, use the same functions used in BP as much as possible (to make audit and review easier). Ideally, keeping similar naming/naming conventions and code structure."

Weekly meeting here is at 17:00 UTC (about 20 minutes from now)

OK, let's get started!

The usual agenda: monero-project/meta #490

First, GREETINGS

Hello

hello

Hi all

Let's move to ROUNDTABLE, where anyone can share research topics of interest with the channel

Note that Isthmus posted a few items on the agenda and said he would be unable to attend today

He linked this: github.com/Mitchellpkt/stingy_spammer

and noted some related work in Zcash that showed a 0-value/0-fee transaction could be mined, posing a spam risk

and further, that even if not relayed, such transactions could be mined if not disallowed by the protocol (not specific to Zcash, of course)

It is certainly the case that the Monero protocol also does not verify that the sum of spent inputs is strictly greater than zero

How does this apply to Monero?

Is there a verification for sum(inputs)>0

It would apply if miners can mine 0-fee transactions, since this means it would be free to spam the network

Nope, this is not the case

Range proofs allow zero value

but the miner wold have to pay the penalty on the spam

ikn Monero

h4sh3d[m]: and it's important for distinguishability of "fake change" that zero values look the same

So the economics are very different

ArticMine: well, at a certain point

If penalty-free, no problem

Yes up to the penalty free zone

Enforcing minimum fees at the protocol level would mitigate this risk

but this is not in the miner's interest

but I know this has been brought up before

Enforcing fees at the protocol does not mitigate this risk

The existence of a penalty zone is certain a disincentive at some point

Can the block size grow if you are under the penalty-fee?

How would it not mitigate? It at least ensures that the spammer has to pay something

The miner would pay himself.

The miner just pays out of one pocket to the other

Oh, you mean in the case that the miner chooses to execute the spam attack, sure

can't remove that risk in the penalty-free zone

but it does mean that a non-miner user can't trivially execute the spam

The non miner has to deal with node relay minimum fees

on top of the penalty

If a miner exposes their sendrawtransaction RPC, someone could send 0 fee txes this way.

It is also in the interest of the miner to allow for fluctuation in the block weight

... and have the miner pay the penalty for the spam

Anyway, might be useful to bring up at the next dev meeting, to see if there are mitigations that receive general agreement

Also as Monero mature the penalty free zone is below the block weight

So this attack becomes moot

Well, something to keep in mind... if non-miners users can easily produce such spam and it gets mined, it's a problem

I have a few things to share

I guess forcing a min fee also removes a way to get fingerprinted.

I made a couple of PRs to finally jettison old JS analytics code from CCS and the main getmonero site, which isn't really research :)

It simple cannot be enforced because of out of bounds payments / refunds

The audit is finally closing

for CLSAG

We're finalizing the report with OSTIF and the reviewers, and I have a blog post ready to go that explains CLSAG and the audit results, which were helpful and positive

moneromooo has rebased the code, so it's ready for testing

Trezor support will be there for the upgrade

still working with Ledger on some scheduling problems, unfortunately

And I updated some code and tests for transaction proofs and message signing

Any questions or comments on these topics?

There is a proposal for a research team to implement Bulletproofs+ in Monero: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156

The numbers they get for verification seem better than when I had first looked at estimates, but they've since provided information on operation counts that I think are much better than from specific implementations

Any thoughts on BP+ in Monero?

Regardless of the actual verification benefits, the size benefits are certain

If they're smaller and faster and just incremental code changes, yes please.

does the transaction structure changes with the proof size reduction?

When first brought up a while back (when the preprint came out), it seemed like there were some questions on using something so new for a marginal (but certainly nontrivial) benefit

h4sh3d[m]: what do you mean?

The proofs contain different elements, sure

Nothing else changes (except standard transaction weights)

So de/serialization of transaction changes

Sure

Ok

It did for BP, it does for CLSAG, etc.

I don't think that's a reason not to do it

I assume it'd be a consensus requirement, so no issues there

Me neither, just wondering

How comfortable are you with the safety of the changes, mathematically ?

(since you mention "something so new").

The construction appears sound and correct

but it hasn't received formal external review yet

That's no guarantee of correctness, but it is useful

FWIW it's not like the math expires, if it were decided to wait until the preprint gets more eyes on it

The downside would be the sunk cost of heavier proofs on chain

BPs were also new, but they received a _lot_ of good review and attention from a lot of researchers

You could easily argue that not that many people have done thorough review of CLSAG either, though

The trade-off is mathematical risk vs heavy transactions. It can be a very delicate one

Yeah. I don't doubt that the proposers did a thorough review of the BP+ preprint, as it appears they have

Anyway, certainly a proposal worth considering

Did anyone else have topics they wish to share?

Yep. I nearly finished the researched funded by the CCS on atomic swap

The paper has just been updated

Excellent! Link?

sarang: if you find time to have a look, I'd appreciate some feedback

Happy to

and feedback from all of you too!

I'm happy with the results and I'll have a better look at what you did in MRL-0010

^ what andytoshi did

As it is one of the two "new" cryptographic primitives used in the scheme

yes, andytoshi was the first to talk about it, you wrote the tech note!

Anyway, feedbacks are welcome and thanks for the inputs from the last months. I'll write on reddit a summary of the research soon

Thanks h4sh3d[m]

Any other topics folks wish to bring up, before we move along?

OK, then on to ACTION ITEMS

I'll finish up some tests on some older code and PRs, see if we can get the audit report posted publicly, continue some investigation of BP+ specifics, and finish up CLSAG testing

Anyone else?

All right, in that case, we are adjourned!

Thanks to everyone for participating; logs will be posted shortly to the GitHub agenda

Thanks for hosting

Thank you for hosting sarang!

... and a thank you to all participants

Would it make more sense to implement BP+ ourselves and ask the CCS author for an audit including maybe a second audit?

That's a very interesting idea

(second audit by OSTIF or so)

Seeing that we always did the crypto code ourselves in the past I don’t see a reason to do this different this time.

Given that the conceptual changes from BP to BP+ aren't that huge, I don't think a separate audit would necessarily provide much benefit

But it would provide some assurance I guess

Well, having at least one audit would be ideal

I think my wording above was unclear

by "separate audit" I meant "a second audit"

I was referring to the second audit basically

Having both the authors plus an independent party (via OSTIF) audit the implementation would provide better assurances imo

The key is that the audits be independent

To be clear, the CCS proposers are not the authors of the BP+ preprint

if that was in question

So there's already a degree of independence

Ah I missed that

Yeah, they did a Rust implementation and wrote up some posts about how the math works, but they didn't write the preprint

So the CCS proposers write the code and then we organize the audit?

It sounds like selsta's idea is to have MRL contributors write the code, and see if the CCS proposers are open to auditing that code; is that right selsta?

Yes you, mooo or both of you. I think it would take you less time due being familiar with monero’s source.

I am certainly willing to do this

It also has the benefit of having the audit done (if they are open to this) by people who clearly are knowledgable about BP+

Finding additional experts might be challenging since the preprint is so new

(but this challenge is likely to be reduced over time)

well, to advocate for more hands in monero, are we biting the hand that feeds or some other metaphor if we .... inhibit other scienticians from getting dirty in the monero code?

This is also true, and omershlo specifically mentioned it

So it should be considered as part of the value proposition

i'd also put forward the idea that we can do a double thinger .... use both systems (the old one and the new one) concurrently, and then when the new one is given the 100% by either time or audit, the old once can be dropped during the overlap time

gingeropolous: we don’t inhibit them but they ask for 3 person months of work, it seems like it would take sarang less time

What exactly does that mean?

it might add some complexity, but it seems like the best of both worlds....

^ gingeropolous

ive rambled about it before, but basically you use both proof 1 and proof 2 for a given time

FWIW if someone else writes the code, I don't think having moneromooo or I review it should be considered equivalent to an external audit

once proof 2 is considered good, you don't have to verify proof 1 anymore and can drop the data from the chain

apparently google did this when they migrated from something or another

gingeropolous: that sounds tricky to implement properly :/

and potentially risky if not done correctly

indeed

but so is using hot off the press mathemagic. audits are great, but...

Right, no audit is a guarantee

Just a way to reduce risk if done well

i guess, in general, upgrades to the monero protocol are not something new, and its something we'll hopefully do for a long time

so i think some sort of protocol for how these upgrades are done would be neat.

Ah, a protocol protocol =p

yep

all about the meta

and audits are expensive. imagine all the sarangs we coulda gotten from all the other audits. into the clone machine u go!

0_0

Running both schemes concurrently seems to have little benefit

It would still expose the chain to any flaws in B+ as they are valid transactions

Yep, it could only possibly help in the event of a flawed implementation

Hello omershlo !

Hi all, I am one of the authors of the CCS on BP+. Both Suyash (co-author) and me are open to the idea of auditing instead of writing the code. We believe that between us and for that specific protocol we have the tools to audit it successfully. We saw this project as an opportunity for us to get involved and contribute. This is our main

motivation. We appreciate the thoughtful polite discussions and all the help the community is offering.

Thanks for the excellent discussion in response to the feedback omershlo

I really appreciate it

I also like this audit idea in particular because you and suyash have experience with the protocol and your existing implementation

And having new researchers work on Monero is a huge benefit as well, as you had said

Should we submit a new proposal ?

omershlo: imo yes, thank you for coming here to talk with the community

sarang: can you fill us in again on the pros/cons of implementing BP+?

Marginal but nontrivial improvements to size and time

Downside is it's new work that hasn't been formally reviewed much

so it would be good to have math review outside of the main authors?

Yes. The CCS proposers have done this, albeit not in the context of the traditional academic review process

And again, academic peer review is no guarantee