Hi there, I wonder if an implementation of CLSAG in Python or Sage exists?

grydz, sarang has a proof of concept implementation made for demonstration purposes (and not production use) in python here: github.com/SarangNoether/skunkworks/blob/clsag/clsag/clsag.py

Thank TheCharlatan, that's exactly what I was looking for :)

I’ll not be able to attend today’s meeting sadly, but have fun researchers!

does the sarang ccs vacation require proof of vacation of from sarang and @sarangcat? pictures of the two with 🍹 on the 🏖️?

we need proof of relaxation to fulfill the proposal.

so, who is around?

Hi

Hello :)

are there any topics posted?

I am not aware of any posted

So straight to the round table then, does anybody have something to share or discuss?

Yes

I want to provide a brief update on issue 70 and my recommended changes

I have finalized the consensus part with the recommendation of using the longterm median as the penalty free zone

hello

On the fee calculation part I am goin to wait for the HF this week before finalizing the fee calculations since then we will have actual on chain tx weight data

The is one question I like some feedback on

Namely where the community want to go with ring size. In particular if there is any interest in increasing this in the short term?

The reason being this has a direct impact on tx weight

Actually i worked on bitcoin fees before, and I find liveness is totally an understaded problem, specially on bitcoin... can u give a hint on how u pick the fees?

What I will do is calculate the fees based upon no change from the current ring size of 11, unless there is a interest to change this

I think the ring size discussion will arise once we get around deploying a one-out-of-many proof based system.

So nothing before that. I will then work on that assumption

given that it was not changed for CLSAG, I would say that appetite for changing it until then is low.

That is also my impression

Hey Artic, that makes sense. Would you mind also modeling for some larger ring sizes?

My reasoning is this: if we set the fee system based on calculations that were only carried out for ring size 11, this might become a future sticking point (based on bad logic) when discussing potential increases ("Oh well, privacy aside, we shouldn't touch the ring size because our fee economics are based on ring size 11")

zkao Fees in Monero are very different from Bitcoin, since they are effectively controlled by the adaptive blocksize

(well, are based on <txn size> but you get the idea)

So I think for the immediate decision, modeling for 11 alone is fine. But if you have the time/bandwidth to model other size in parallel might be good for future discourse

Isthmus That is exactly my concern

Hm, either way, it'll be interesting to see the sensitivity of (any given) fee system with respect to transaction size

If models show that tx size could triple and fee system will still work, I think we can all rest easy

That being said my overall recommendation is to increase the minimum penalty free zone currently at 3000 bytes if the reference tx size goes over 3000 bytes

300 kB currently, right?

It is the ration of the tx size to the penalty free zone that is critical here

300,000 bytes with a reference tx size of 3000 bytes

Ohh yea

Sorry, I'm sleep today and a bit slow

s/p/py

So it works if the bult of the tx are below 3000 bytes

In any case modeling this is a great idea

I understand that the adaptive block size is game changer. What I can contribute to this discussion from my experience in Bitcoin is: Fee estimators that look at the mempool in the very shortterm work, the ones that dont work look do stats of past data, and always gives irrevevant fees.

That makes a lot of sense for Bitcoin

Interesting note @zkao

In Monero The main determining factor is are we in the penalty zone?

By that I mean can we load the entire transaction pool into a block an not pay a penalty

transaction pool being the equivalent to mempool in Monero

So that in effect determines the fee level

If the tx pool attracts a penalty then what is the max penalty rate

so in bitcoin when the fees went insane, the issue was the fee estimators, new transactions kept overtaking all ones and so on

but in fact they can just squeeze in, and pay almost the same fee as other transactions

There is increase in supply as a result of demand regardless of price in Bitcoin

In Monero if one increase price then one increases supply in a very predicable way

So this actually leads to very deterministic fees if one assumes a free market

Oh yea, I just remembered... Artic, how much would discretized fees (e.g. must be multiple of two, or power of two) impact your results?

Cuz we've got a lot of problems with hardcoded fees (software fingerprint), hardcode absolute fees (software fingerprint), fee sniping (software fingerprint), anomalous repeated values (software fingerprint), ...

actually the best strategy was to try to make the sorted fees on the transaction pool to be as smooth as possible to really allow prioritization of transactions. if the transaction pool fee distributions is totally irregular, its too hard to prioritize transaction

The other issue in Monero is that one wants to avoid fee personas for reasons of privacy

all im saying, the fee mess on bitcoin was not only because of congestion, but also because no fee estimator knew how to deal with that

It is both

exactly

( for anybody not familiar with the fee anomalies observed in the wild, plots start at 8:41 here youtu.be/XIrqyxU3k5Q?t=521 )

Thanks I was looking for that link

It deals very well with the fee persona issue

I've never heard "fee persona" until today, and it's such a perfect term

It is easy to limit the number of fees and also limit the number of significant digits

The key is to always round up and not down

Isthmus, do you have anything to share with us?

oh, and I was looking for the post-quantum report a few days ago. Where is it posted?

A draft is here: github.com/insight-decentralized-co…/master/writeups/technical_note.pdf

Haven't publicized yet, was going to wait 2 weeks for feedback from MRL et al. Otherwise, I'll blast onto Reddit and Twitter early next week

Oh yea, good point about ceiling() vs round() @ArticMine

I am posting some short articles on unlock time usage in monero. The first one is here (about hardware wallets no validating it): thecharlatan.ch/Wallet-Timelock

I'll post the next two over the next week.

the title sounds like: i have fun burning money

:D

something something it's about sending a message.

Haha I locked some Monero for 500 billion years once

I was wondering what would happen if I sent deeply locked outputs to a CCS donation address

Oh wait I should clarify

The super locked outputs are from research wallet 1 --> research wallet 2

Have NOT done any locked outputs to CCS

Great writeup @TheCharlatan

<Isthmus> Haha I locked some Monero for 500 billion years once <---- The US DOJ might be interested in that. It effectively burns Monero is the time >> age of the universe

if

so I guess that it's for today?

Looks like it

Ooh @ArticMine I hadn't thought of that use case. Publicly verifiable too...

Yea, I gotta hop onto a call

gg

see you later

cheers guys