Is my labeling under the "Example" section correct so far? github.com/Mitchellpkt/crypto_field_stats_tests/blob/master/README.md

Really I suppose "amount: 0" is more like n/a

Has there been thought around setting fees/fee multipliers at a protocol level?

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

And rejecting transactions with non-standard fees/multiple of fees?

Yes.

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

Would be interesting to have a base fee ala eips.ethereum.org/EIPS/eip-1559

And then just allow set multiples of that

<moneromooo "Yes."> What was the finding/ideas that came out of that, if you don't mind sharing?

I don't remember.

Ok 🙂

I haven't seen talk about it in a long time, so not surprised

<cankerwort> monero-project/monero #5711

Thanks for the share! Will read through that

Great news! Triptych was accepted to the CBT 2020 workshop! deic-web.uab.cat/cbt/cbt2020

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

Congrats :)

woho!

Exciting :D

I'll work on a few updates to help clarify the efficiency estimates anyway

And now that I have a test implementation in the Monero codebase, I can at least compare Triptych performance to CLSAG and MLSAG properly

albeit without batching at this point

Unfortunately I couldn't submit Arcturus since it was still under consideration elsewhere, and that's generally against the rules

Worth announcing this elsewhere?

Reviewer comments: paste.debian.net/hidden/bc28edab

nice sarang !!!!

Kudos also to coauthor Surae Noether, and to research collaborator RandomRun who suggested the underlying idea

It'll appear in the conference proceedings, and I'll make a presentation in September

nice

Sarang I assume the typos are locked in stone now?

For review two specifically

For Triptych? No, I can make changes before the camera-ready version is provided to the organizers

What typo do you mean?

The reviewers didn't identify any typos (but there certainly could be typos) in the preprint

Oh, do you mean typos in the _review_ itself?

Those don't appear in publications

They're typically only seen by the authors and editors

Ah OK

And yeah in the review itself

I never got a degree higher than BS, idk all this PhD garbage :D

Only the final camera-ready paper will appear in the proceedings

And depending on the editors, they could make further formatting edits or grammar tweaks

BP+ fast verifier is done and passes initial tests: SarangNoether/skunkworks 9b929fc

Now on to batching, then to C++

Was kind of inactive lately, but do we have any timing figures for BP+ verification?

Should be pretty much the same as for BP, by initial estimates

<sarang> Worth announcing this elsewhere? <= Reddit for sure

Strictly speaking, marginally faster

OK, thanks

So basically we still have mere size optimizations?

dEBRUYNE: the organizers said they would post the program list after all papers confirmed; perhaps wait until I can link that?

^^ for the most part

Sure, sounds good

I don't know when that will be, but I can give it a few days perhaps

It's just very exciting :)

dEBRUYNE: FWIW here are numbers from the BP+ CCS proposers on their Rust implementation: repo.getmonero.org/monero-project/c…als/-/merge_requests/156#note_10184

The improvement still seems high to me, but we shall see!

Did you not say they compared apples to orange there ?

In their original timing numbers

The link is to updated numbers after some changes to their Rust implementations

k

At any rate, the BP+ verification will be no worse than BP is!

Monero v0.17: we managed to make it no worse.

"Monero v0.17: could be worse"

Monero v0.18: "You asked how"

lol

"expectations low, results no lower"

Thanks sarang

Seems like there are only improvements for transactions with a lot of outputs

'Exceeding expectations by setting the bar low'

Low bar, lower expectations? :D

Batch verification: SarangNoether/skunkworks cf906bb

Once I add a few additional features to this proof-of-concept, I'll modify the existing C++ code

This was just to work out the algorithms and algebra more easily