02:20:58 <Isthmus> Is my labeling under the "Example" section correct so far? https://github.com/Mitchellpkt/crypto_field_stats_tests/blob/master/README.md
02:21:52 <Isthmus> Really I suppose "amount: 0" is more like n/a
13:50:52 <sethsimmons> Has there been thought around setting fees/fee multipliers at a protocol level?
13:51:28 <sethsimmons> I.e. allowing a set list of multiples of some base fee, base fee being calculated based on average TX fee over past N blocks and stored in each block by miners
13:51:51 <sethsimmons> And rejecting transactions with non-standard fees/multiple of fees?
13:53:04 <moneromooo> Yes.
13:53:13 <sethsimmons> I know you've mentioned wallet fingerprinting at length before Isthmus, so I'm sure you've looked into this more than I have :D
13:53:56 <sethsimmons> Would be interesting to have a base fee ala https://eips.ethereum.org/EIPS/eip-1559
13:53:57 <sethsimmons> And then just allow set multiples of that
13:57:28 <sethsimmons> <moneromooo "Yes."> What was the finding/ideas that came out of that, if you don't mind sharing?
13:57:56 <moneromooo> I don't remember.
13:58:17 <sethsimmons> Ok 🙂
13:58:29 <sethsimmons> I haven't seen talk about it in a long time, so not surprised
13:59:27 <xmrmatterbridge> <cankerwort> https://github.com/monero-project/monero/issues/5711
14:00:04 <sethsimmons> Thanks for the share! Will read through that
14:09:51 <sarang> Great news! Triptych was accepted to the CBT 2020 workshop! https://deic-web.uab.cat/cbt/cbt2020/
14:11:31 <sarang> The only reviewer suggestion was to add numbers for an actual implementation, but to compare this against something like RCT3 would require a library-compatible implementation as well
14:13:25 <moneromooo> Congrats :)
14:13:34 <Inge-> woho!
14:13:38 <sethsimmons> Exciting :D
14:18:01 <sarang> I'll work on a few updates to help clarify the efficiency estimates anyway
14:18:50 <sarang> And now that I have a test implementation in the Monero codebase, I can at least compare Triptych performance to CLSAG and MLSAG properly
14:19:03 <sarang> albeit without batching at this point
14:19:46 <sarang> Unfortunately I couldn't submit Arcturus since it was still under consideration elsewhere, and that's generally against the rules
14:32:58 <sarang> Worth announcing this elsewhere?
15:02:42 <sarang> Reviewer comments: https://paste.debian.net/hidden/bc28edab/
15:06:05 <gingeropolous> nice sarang !!!!
15:09:26 <sarang> Kudos also to coauthor Surae Noether, and to research collaborator RandomRun who suggested the underlying idea
15:09:58 <sarang> It'll appear in the conference proceedings, and I'll make a presentation in September
18:09:35 <midipoet> nice
18:27:42 <needmoney90> Sarang I assume the typos are locked in stone now?
18:27:52 <needmoney90> For review two specifically
18:28:49 <sarang> For Triptych? No, I can make changes before the camera-ready version is provided to the organizers
18:29:27 <sarang> What typo do you mean?
18:29:58 <sarang> The reviewers didn't identify any typos (but there certainly could be typos) in the preprint
18:30:13 <sarang> Oh, do you mean typos in the _review_ itself?
18:30:24 <sarang> Those don't appear in publications
18:30:50 <sarang> They're typically only seen by the authors and editors
18:31:17 <needmoney90> Ah OK
18:31:36 <needmoney90> And yeah in the review itself
18:32:12 <needmoney90> I never got a degree higher than BS, idk all this PhD garbage :D
18:32:45 <sarang> Only the final camera-ready paper will appear in the proceedings
18:33:46 <sarang> And depending on the editors, they could make further formatting edits or grammar tweaks
19:08:27 <sarang> BP+ fast verifier is done and passes initial tests: https://github.com/SarangNoether/skunkworks/commit/9b929fcfc9231ce07c37c674e556b2497ece3916
19:08:33 <sarang> Now on to batching, then to C++
19:09:07 <dEBRUYNE> Was kind of inactive lately, but do we have any timing figures for BP+ verification?
19:09:35 <sarang> Should be pretty much the same as for BP, by initial estimates
19:09:48 <dEBRUYNE> <sarang> Worth announcing this elsewhere? <= Reddit for sure
19:09:48 <sarang> Strictly speaking, marginally faster
19:10:03 <dEBRUYNE> OK, thanks
19:10:10 <dEBRUYNE> So basically we still have mere size optimizations?
19:10:17 <sarang> dEBRUYNE: the organizers said they would post the program list after all papers confirmed; perhaps wait until I can link that?
19:10:25 <sarang> ^^ for the most part
19:10:27 <dEBRUYNE> Sure, sounds good
19:11:32 <sarang> I don't know when that will be, but I can give it a few days perhaps
19:11:38 <sarang> It's just very exciting :)
19:14:12 <sarang> dEBRUYNE: FWIW here are numbers from the BP+ CCS proposers on their Rust implementation: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156#note_10184
19:14:44 <sarang> The improvement still seems high to me, but we shall see!
19:15:03 <moneromooo> Did you not say they compared apples to orange there ?
19:15:16 <sarang> In their original timing numbers
19:15:26 <sarang> The link is to updated numbers after some changes to their Rust implementations
19:15:30 <moneromooo> k
19:16:06 <sarang> At any rate, the BP+ verification will be no worse than BP is!
19:16:28 <moneromooo> Monero v0.17: we managed to make it no worse.
19:18:14 <hyc> "Monero v0.17: could be worse"
19:19:00 <moneromooo> Monero v0.18: "You asked how"
19:19:22 <hyc> lol
19:19:53 <sarang> "expectations low, results no lower"
19:38:04 <dEBRUYNE> Thanks sarang
19:38:15 <dEBRUYNE> Seems like there are only improvements for transactions with a lot of outputs
19:44:16 <needmoney90> 'Exceeding expectations by setting the bar low'
19:44:40 <needmoney90> Low bar, lower expectations? :D
20:44:16 <sarang> Batch verification: https://github.com/SarangNoether/skunkworks/commit/cf906bbbe37799d6ec5f7ce9a0ead850e3ecb43f
20:52:55 <sarang> Once I add a few additional features to this proof-of-concept, I'll modify the existing C++ code
20:53:16 <sarang> This was just to work out the algorithms and algebra more easily