10:49:42 <suyash67> I have summarised the number of multi-scalar multiplications necessary for BP and BP+ in the comment to our CCS proposal (Link: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156#note_10110).
14:08:11 <sarang> Thanks suyash67
15:31:18 <sarang> 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
15:31:39 <sarang> (relating to their BP+ CCS, I mean)
15:31:59 <sarang> Nor am I claiming that I would "do it worse"
15:34:36 <moneromooo> Basically, you are claiming you are not claiming anything :)
15:35:44 <sarang> I didn't want it to be interpreted as me opposing the proposal because of this
15:36:08 <sarang> I'd have to read the logs, but I'm not sure if anyone said I could do it better
15:36:13 <sarang> At any rate, I don't claim this
15:36:57 <sarang> It's accurate to say that I _do_ think I could produce a quality implementation
15:38:44 <moneromooo> 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).
15:39:43 <sarang> I had not heard of the proposer before, but I have seen omershlo's work elsewhere
15:40:22 <sarang> I think a bigger risk might be if the code were sufficiently different to make the review process difficult
15:40:30 <sarang> Which might necessitate another full audit
15:40:45 <sarang> But the proposers did say they want to reuse code to the extent reasonable
15:41:13 <sarang> 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."
16:37:17 <sarang> Weekly meeting here is at 17:00 UTC (about 20 minutes from now)
17:00:18 <sarang> OK, let's get started!
17:00:26 <sarang> The usual agenda: https://github.com/monero-project/meta/issues/490
17:00:31 <sarang> First, GREETINGS
17:00:51 <h4sh3d[m]> Hello
17:01:09 <sgp_> hello
17:01:41 <sethsimmons> Hi all
17:02:45 <sarang> Let's move to ROUNDTABLE, where anyone can share research topics of interest with the channel
17:03:04 <sarang> Note that Isthmus posted a few items on the agenda and said he would be unable to attend today
17:03:18 <sarang> He linked this: https://github.com/Mitchellpkt/stingy_spammer
17:03:48 <sarang> and noted some related work in Zcash that showed a 0-value/0-fee transaction could be mined, posing a spam risk
17:04:24 <sarang> and further, that even if not relayed, such transactions could be mined if not disallowed by the protocol (not specific to Zcash, of course)
17:05:44 <sarang> It is certainly the case that the Monero protocol also does not verify that the sum of spent inputs is strictly greater than zero
17:05:56 <h4sh3d[m]> How does this apply to Monero?
17:06:28 <h4sh3d[m]> Is there a verification for sum(inputs)>0
17:06:28 <sarang> It would apply if miners can mine 0-fee transactions, since this means it would be free to spam the network
17:06:39 <sarang> Nope, this is not the case
17:06:50 <sarang> Range proofs allow zero value
17:08:33 <ArticMine> but the miner wold have to pay the penalty on the spam
17:08:37 <ArticMine> ikn Monero
17:09:02 <sarang> h4sh3d[m]: and it's important for distinguishability of "fake change" that zero values look the same
17:09:17 <ArticMine> So the economics are very different
17:09:23 <sarang> ArticMine: well, at a certain point
17:09:27 <sarang> If penalty-free, no problem
17:09:50 <ArticMine> Yes up to the penalty free zone
17:10:02 <sarang> Enforcing minimum fees at the protocol level would mitigate this risk
17:10:12 <ArticMine> but this is not in the miner's interest
17:10:13 <sarang> but I know this has been brought up before
17:10:33 <ArticMine> Enforcing fees at the protocol does not mitigate this risk
17:10:39 <sarang> The existence of a penalty zone is certain a disincentive at some point
17:10:58 <h4sh3d[m]> Can the block size grow if you are under the penalty-fee?
17:11:09 <sarang> How would it not mitigate? It at least ensures that the spammer has to pay something
17:11:18 <moneromooo> The miner would pay himself.
17:11:29 <ArticMine> The miner just pays out of one pocket to the other
17:11:35 <sarang> Oh, you mean in the case that the miner chooses to execute the spam attack, sure
17:11:47 <sarang> can't remove that risk in the penalty-free zone
17:12:10 <sarang> but it does mean that a non-miner user can't trivially execute the spam
17:12:40 <ArticMine> The non miner has to deal with node relay minimum fees
17:13:04 <ArticMine> on top of the penalty
17:13:29 <moneromooo> If a miner exposes their sendrawtransaction RPC, someone could send 0 fee txes this way.
17:13:39 <ArticMine> It is also in the interest of the miner to allow for fluctuation in the block weight
17:13:59 <ArticMine> ... and have the miner pay the penalty for the spam
17:16:31 <sarang> Anyway, might be useful to bring up at the next dev meeting, to see if there are mitigations that receive general agreement
17:17:58 <ArticMine> Also as Monero mature the penalty free zone is below the block weight
17:18:27 <ArticMine> So this attack becomes moot
17:20:00 <sarang> Well, something to keep in mind... if non-miners users can easily produce such spam and it gets mined, it's a problem
17:20:26 <sarang> I have a few things to share
17:20:36 <moneromooo> I guess forcing a min fee also removes a way to get fingerprinted.
17:21:03 <sarang> 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 :)
17:21:11 <ArticMine> It simple cannot be enforced because of out of bounds payments / refunds
17:21:17 <sarang> The audit is finally closing
17:21:19 <sarang> for CLSAG
17:21:51 <sarang> 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
17:22:05 <sarang> moneromooo has rebased the code, so it's ready for testing
17:22:24 <sarang> Trezor support will be there for the upgrade
17:22:34 <sarang> still working with Ledger on some scheduling problems, unfortunately
17:22:58 <sarang> And I updated some code and tests for transaction proofs and message signing
17:23:36 <sarang> Any questions or comments on these topics?
17:26:10 <sarang> There is a proposal for a research team to implement Bulletproofs+ in Monero: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156
17:27:33 <sarang> 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
17:30:05 <sarang> Any thoughts on BP+ in Monero?
17:30:26 <sarang> Regardless of the actual verification benefits, the size benefits are certain
17:30:34 <moneromooo> If they're smaller and faster and just incremental code changes, yes please.
17:31:26 <h4sh3d[m]> does the transaction structure changes with the proof size reduction?
17:31:29 <sarang> 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
17:31:36 <sarang> h4sh3d[m]: what do you mean?
17:31:42 <sarang> The proofs contain different elements, sure
17:31:57 <sarang> Nothing else changes (except standard transaction weights)
17:32:22 <h4sh3d[m]> So de/serialization of transaction changes
17:33:03 <sarang> Sure
17:33:12 <h4sh3d[m]> Ok
17:33:15 <sarang> It did for BP, it does for CLSAG, etc.
17:33:23 <sarang> I don't think that's a reason not to do it
17:33:42 <sarang> I assume it'd be a consensus requirement, so no issues there
17:34:01 <h4sh3d[m]> Me neither, just wondering
17:34:15 <moneromooo> How comfortable are you with the safety of the changes, mathematically ?
17:34:24 <moneromooo> (since you mention "something so new").
17:35:25 <sarang> The construction appears sound and correct
17:35:49 <sarang> but it hasn't received formal external review yet
17:36:03 <sarang> That's no guarantee of correctness, but it is useful
17:36:24 <sarang> FWIW it's not like the math expires, if it were decided to wait until the preprint gets more eyes on it
17:36:50 <sarang> The downside would be the sunk cost of heavier proofs on chain
17:37:25 <sarang> BPs were also new, but they received a _lot_ of good review and attention from a lot of researchers
17:37:57 <sarang> You could easily argue that not that many people have done thorough review of CLSAG either, though
17:38:13 <ArticMine> The trade-off is mathematical risk vs heavy transactions. It can be a very delicate one
17:40:59 <sarang> Yeah. I don't doubt that the proposers did a thorough review of the BP+ preprint, as it appears they have
17:44:42 <sarang> Anyway, certainly a proposal worth considering
17:44:52 <sarang> Did anyone else have topics they wish to share?
17:46:10 <h4sh3d[m]> Yep. I nearly finished the researched funded by the CCS on atomic swap
17:46:19 <h4sh3d[m]> The paper has just been updated
17:46:44 <sarang> Excellent! Link?
17:46:51 <h4sh3d[m]> sarang: if you find time to have a look, I'd appreciate some feedback
17:46:55 <h4sh3d[m]> https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/whitepaper/xmr-btc.pdf
17:47:20 <sarang> Happy to
17:47:20 <h4sh3d[m]> and feedback from all of you too!
17:48:21 <h4sh3d[m]> I'm happy with the results and I'll have a better look at what you did in MRL-0010
17:48:35 <sarang> ^ what andytoshi did
17:48:42 <h4sh3d[m]> As it is one of the two "new" cryptographic primitives used in the scheme
17:49:44 <h4sh3d[m]> yes, andytoshi was the first to talk about it, you wrote the tech note!
17:50:45 <h4sh3d[m]> Anyway, feedbacks are welcome and thanks for the inputs from the last months. I'll write on reddit a summary of the research soon
17:51:16 <sarang> Thanks h4sh3d[m]
17:51:27 <sarang> Any other topics folks wish to bring up, before we move along?
17:53:14 <sarang> OK, then on to ACTION ITEMS
17:54:16 <sarang> 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
17:54:21 <sarang> Anyone else?
17:56:41 <sarang> All right, in that case, we are adjourned!
17:56:54 <sarang> Thanks to everyone for participating; logs will be posted shortly to the GitHub agenda
17:57:06 <ArticMine> Thanks for hosting
17:57:14 <h4sh3d[m]> Thank you for hosting sarang!
17:57:37 <ArticMine> ... and a thank you to all participants
18:16:38 <selsta> Would it make more sense to implement BP+ ourselves and ask the CCS author for an audit including maybe a second audit?
18:16:54 <sarang> That's a very interesting idea
18:18:37 <selsta> (second audit by OSTIF or so)
18:19:13 <selsta> Seeing that we always did the crypto code ourselves in the past I don’t see a reason to do this different this time.
18:19:21 <sarang> 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
18:21:15 <dEBRUYNE> But it would provide some assurance I guess
18:21:40 <sarang> Well, having at least one audit would be ideal
18:21:52 <sarang> I think my wording above was unclear
18:22:01 <sarang> by "separate audit" I meant "a second audit"
18:26:58 <dEBRUYNE> I was referring to the second audit basically
18:27:20 <dEBRUYNE> Having both the authors plus an independent party (via OSTIF) audit the implementation would provide better assurances imo
18:27:44 <ArticMine> The key is that the audits be independent
18:28:08 <sarang> To be clear, the CCS proposers are not the authors of the BP+ preprint
18:28:12 <sarang> if that was in question
18:28:33 <sarang> So there's already a degree of independence
18:31:09 <dEBRUYNE> Ah I missed that
18:31:35 <sarang> Yeah, they did a Rust implementation and wrote up some posts about how the math works, but they didn't write the preprint
18:33:49 <ArticMine> So the CCS proposers write the code and then we organize the audit?
18:34:42 <sarang> 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?
18:35:32 <selsta> Yes you, mooo or both of you. I think it would take you less time due being familiar with monero’s source.
18:35:48 <sarang> I am certainly willing to do this
18:36:13 <sarang> It also has the benefit of having the audit done (if they are open to this) by people who clearly are knowledgable about BP+
18:36:29 <sarang> Finding additional experts might be challenging since the preprint is so new
18:36:37 <sarang> (but this challenge is likely to be reduced over time)
18:36:51 <gingeropolous> 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?
18:37:11 <sarang> This is also true, and omershlo specifically mentioned it
18:38:14 <sarang> So it should be considered as part of the value proposition
18:38:29 <gingeropolous> 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
18:38:45 <selsta> gingeropolous: we don’t inhibit them but they ask for 3 person months of work, it seems like it would take sarang less time
18:38:47 <sarang> What exactly does that mean?
18:38:51 <gingeropolous> it might add some complexity, but it seems like the best of both worlds....
18:38:55 <sarang> ^ gingeropolous
18:39:20 <gingeropolous> ive rambled about it before, but basically you use both proof 1 and proof 2 for a given time
18:39:34 <sarang> 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
18:39:45 <gingeropolous> once proof 2 is considered good, you don't have to verify proof 1 anymore and can drop the data from the chain
18:40:26 <gingeropolous> apparently google did this when they migrated from something or another
18:40:32 <sarang> gingeropolous: that sounds tricky to implement properly :/
18:40:41 <sarang> and potentially risky if not done correctly
18:40:45 <gingeropolous> indeed
18:41:24 <gingeropolous> but so is using hot off the press mathemagic. audits are great, but...
18:41:53 <sarang> Right, no audit is a guarantee
18:42:12 <sarang> Just a way to reduce risk if done well
18:44:38 <gingeropolous> i guess, in general, upgrades to the monero protocol are not something new, and its something we'll hopefully do for a long time
18:45:32 <gingeropolous> so i think some sort of protocol for how these upgrades are done would be neat.
18:45:42 <sarang> Ah, a protocol protocol =p
18:45:50 <gingeropolous> yep
18:45:52 <gingeropolous> all about the meta
18:47:27 <gingeropolous> and audits are expensive. imagine all the sarangs we coulda gotten from all the other audits. into the clone machine u go!
18:47:46 <sarang> 0_0
18:48:16 <dEBRUYNE> Running both schemes concurrently seems to have little benefit
18:48:29 <dEBRUYNE> It would still expose the chain to any flaws in B+ as they are valid transactions
18:50:06 <sarang> Yep, it could only possibly help in the event of a flawed implementation
19:19:26 <sarang> Hello omershlo !
19:20:02 <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
19:20:03 <omershlo> motivation. We appreciate the thoughtful polite discussions and all the help the community is offering.
19:21:47 <sarang> Thanks for the excellent discussion in response to the feedback omershlo
19:21:55 <sarang> I really appreciate it
19:22:43 <sarang> I also like this audit idea in particular because you and suyash have experience with the protocol and your existing implementation
19:23:18 <sarang> And having new researchers work on Monero is a huge benefit as well, as you had said
19:23:21 <omershlo> Should we submit a new proposal ?
19:27:55 <sgp_> omershlo: imo yes, thank you for coming here to talk with the community
19:28:31 <sgp_> sarang: can you fill us in again on the pros/cons of implementing BP+?
19:46:15 <sarang> Marginal but nontrivial improvements to size and time
19:46:49 <sarang> Downside is it's new work that hasn't been formally reviewed much
19:48:07 <sgp_> so it would be good to have math review outside of the main authors?
19:49:38 <sarang> Yes. The CCS proposers have done this, albeit not in the context of the traditional academic review process
19:50:08 <sarang> And again, academic peer review is no guarantee