Hey, I know it's probably too early but I'm not familiar with the process of protocol changes.

Will the seraphis and jamtis papers be peer reviewed? And will they be submitted for independent third party audits?

Usually the answer is yes to both, but I think we're too far out for either to be on the radar ATM.

UkoeHB: thoughts on submitting Seraphis paper for peer-review?

We would definitely conduct multiple 3rd-party audits on both Seraphis and JAMTIS before implementation, of course. But that's likely a year or more out.

a year goes fast

For sure, but we have to have a "completed" approach to review, and really a "completed" implementation as well, plus be 100% sure we want to go that route before funding it.

Would be good to pivot to focus on that after the hard-fork.

For sure. Just wondering. Thanks Seth

I don’t plan to submit seraphis to any journals, if that’s what you’re asking (someone else can do that if they really feel like it). ‘Peers’ in the privacy coin world are very welcome to review the paper.

Meeting 1.75hr

The division of labor is great, so step up if you want to see something happen :)

UkoeHB: you'll be going "full time" on seraphis once v0.18 is out?

full time?

as in that will be the next major focus for monero development

what am I doing right now? github.com/UkoeHB/monero/commits/seraphis_lib lol

meeting time monero-project/meta #691

1. greetings

hello

hi

howdy

Hello

Hi

o/

hi

2. updates, what is everyone working on?

As per @Rucknium's request, together with @jberman I'm documenting the Decoy Algorithm, and the Gamma Picker. My approach is to create isolated unit tests, where each one of them goes a step further in the decision tree, testing corner cases, as well as going through the "happy" (typical) path. Each such test... (full message at libera.ems.host/_matrix/media/r0/do…42938f528ae8feb99fcb2baa41fd560b3ee)

`/wall o'text`

me: Continuous development on Seraphis. Today or tomorrow I should have unit tests for binned reference sets (bins are deterministic, bin locations are manually defined). I think overall it is better to let the bin location selection be wallet-defined, both due to complexity and for flexibility/continuous improvement outside of the hardfork schedule.

Gathering info about fee discretization. Set up reeemuru 's `analitiko` Shiny app on a VPS at analitiko.app . OSPEAD tasks.

Btw the view tag PR was merged, hurray :)! I will be rebasing multisig pr 8149 today.

3. ok, let's talk about discretizing fees

update from me: mainly PR review/updating my own PR's. I also dug into Dandelion++ tx broadcast a bit and found that there was not a leak where I suspected there might be one on tx re-submission to a node, so that was good

The basic idea with discretizing fees is to enforce a limited number of fee values at consensus. The advantage would be mitigating fee-based analysis of txs (wallet implementation fingerprinting, user behavior analysis, tx construction timing which is very impactful for multisig), and also saving a few bytes on tx size by using a compact representation. There are a few ideas to implement it: 1) mandate 1 significant

figure in the fee value, 2) use powers of some multiplier (e.g. 1.2, 1.5, 2), 3) use powers of some multiplier rounded to 1 significant figure.

My current view on discretizing fees: As has been discussed, high-precision fees can present a privacy risk due to fingerprinting. There are two issues I can think of right now that may be a drawback of discretizing fees:

1) Around discrete jumps that are high in percent terms, a poorly-constructed fee estimator may interpret the move from a 1 unit to 2 unit fee (i.e. a doubling of fees) as a signal to aggressively outbid competitors. Then there is a snowballing effect and a fee bubble, which would be irritating to users.

2) Discretizing fees may complicate other attempts to increase transaction uniformity by implementing some fee-smoothing ideas from, for example Ethereum's EIP-1559 fee mechnism

can you summarize fee smoothing?

But I think that the privacy benefits overrule both those issues, so I think we should move ahead with discretizing fees

Not to mention if you can artificially trigger raised fees and wait to see how long TXs take to use higher fees, right? Less accuracy increasing the severity of bad implementations which therefore makes them easier to detect?

Not really/not to a increased degree notable enough?

I am not an expert in EIP-1559, but from my understanding, the fee mechanism makes ETH gas fees more predictable. That reduces distinct fee levels. We also have to think about not just the fees themselves but also think about what fee estimation algorithm produced the fee -- if the fee estimation method can be reverse-engineered based on blockchain data or the mempool status, then that can create the anonymity "puddles".

So if there is less of a need to estimate fees -- i.e. the consensus rules gives an optimal fee -- then there is less scope for fingerprintability of fee estimation algorithms.

Even with discretized fees, some analysis will be possible. Hopefully rather than puddles, we will have more of a venn diagram where it isn't clear which puddle you're looking at.

I am a bit confused about talking about "estimates". Was always thinking that Monero fees are simply calculated?

Whether with high precision or maybe in more discrete steps in the future, but product of a formula?

fee estimator = estimating what fee you need to get your tx into the chain within '2mins, 10mins, 1hr, etc'

So this still quite theoretical for Monero, at least at the moment?

kayabanerve[m]: I think it would depend on the implementation... hard to know in advance

rbrunner: right

but the fee is based on the size (weight) of the tx. so does the fingerprintability concern center on when a tx was made?

We could theoretically provide a fee estimator in wallet2 and reduce differences that way

gingeropolous: that's only for the minimum fee, you can pick any fee value above that (and people do)

roight roight

rbrunner: In my mind this is the tricky part: You can have a free-for-all, as we have now. Transactions are included in a transaction basically as a first-price auction (assuming miners are rational). People can bid anything, which leads to privacy problems. Or we could bake a specific fee formula into consensus, but that leads to side deals between miners and users, which is harmful to privacy, as ArticMine alluded to a week or

two ago.

kayabanerve[m]: yeah wallet2 already has a fee estimator, so most txs already fall into one big pool

UkoeHB: ^ . The puddle attack would be something like the fee is 1, as it should be, and someone sends a few at 2. Half the wallets start using 3 saying it increased by 100%! We're at load! Use an even higher fee! Then the other half of sane wallets say 1 is fine, this is momentary. For the next few minutes you can fingerprint into puddles.

the fee estimator just chooses your tx priority, that's all (a more advanced estimator could bid arbitrary amounts)

Maintaining the first-price auction implicitly assumes that at some point Monero will have a fee market, either intermittently or permanently. If we didn't think Monero would ever have a fee market, then we would be better off baking a fee formula into consensus.

UkoeHB: Great to hear

So the basic idea with discretization is to leave freedom to choose fees to people, just not down to an arbitrary precision?

Note that sech1 said earlier, "No, wallet bumps the fee automatically when mempool is full"

Yeah, I think the wallet uses the next-higher standard multiplier then

kayabanerve[m]: I see, yeah it would be one vector for puddling. In practice, any implementation that isn't a copy paste of wallet2 right now, is going to be fingerprintable since the granularity is so high. With lower granularity, there would be a lot more overlap between different estimators.

UkoeHB: Considering wallet2 has one, I'd even be willing to discuss ruckniums original comment at this time

Not that it wasn't valuable or a fair theoretical point. Solely that most wallets will be successfully covered without issue and edge cases already are edges like you say.

about snowballing?

Snowballing and the privacy implications further discussed

Are you suggesting there would be _worse_ privacy with discretized fees?

I'm not saying we don't we have to review the code before deployment. I'm saying if we get that impl right... The ecosystem should be fine

UkoeHB: With puddling attacks which isn't applicable when an identical algorithm is applied, so no, I'm dropping that suggestion, but yes, I did suggest it had drawbacks originally

What exactly are you suggesting?

I think to avoid the fee "snowballing" or "bubble", it may be sufficiently to have a decent fee estimator in `wallet2`. The snowballing or bubble would probably only occur if the vast majority of wallets are misinterpreting the fee rise. If only a few fringe wallet implementations misinterpret it, then we would not have the cascading effect, probably.

I was pointing out non uniform, low quality algorithms, could be identified with on purposely triggered algorithms since increments would be more notable since they're no longer granular

Rucknium[m]: This is what I'm currently stating my belief is

*on purposely triggered snowballs

By the way, if anyone is interested in an extensive and rigorous analysis of Ethereum's EIP-1559, see: arxiv.org/abs/2012.00854

Rucknium[m]: there is also a recursive prisoner's dilemma with fee estimators. If fee estimators consistently overestimate fees, then users will just select lower fees manually (or switch to a wallet that performs better).

kayabanerve[m]: This can be "regularized"

I mean, the fee estimator can have a logarithmic-like ceiling protection.

UkoeHB: In theory, yes. With bounded rationality and satisficing behavior, users may tolerate poor fee estimation algorithms. `bitcoind` apparently has an algorithm that systematically overestimates necessary fees, and a huge number of people still use it.

Yep. So as long we get a good algorithm into wallet2 which the ecosystem then naturally adopts... All good :)

kayabanerve[m]: I'm not sure that discretized fees would have a bigger problem from triggered algorithm increments than non-discretized fees. Your trigger-er just needs to know what conditions are required to get a statistically significant response from the algorithm under scrutiny.

UkoeHB: Yeah, potentially not. I think my interest was in the fact that as a small integer it'll be rounded and because of the significant change at each step, normal network latency effects on fees which may cause a few % of variation, offering natural deviation, may be dropped. Because there's no longer a perpetual cycle of such sightly different tx fees... It cleans up the data a bit

That was my theoretical thought process I 100% haven't implemented nor extensively reviewed current fee policies before wanting to bring up current discussion. I do know there's already a mask on fees which handles this to some degree

In conclusion... anyone who think 'please dont do this' or 'eh dont bother'?

Seems to me that progressing in steps could be a good idea. Start small, e.g. with making tx construction time estimates much harder by discretization

and leave the complicated fee estimator wars and snowballs for later

rbrunner: the fee pr rounds fees to 2 sig figs in wallet2 monero-project/monero #7819

rbrunner: also, I am mostly looking at discretizing fees for seraphis (although we could expedite it to an earlier fork too)

Hmmm .. somehow missed that.

I said this before the meeting, but I'll put it on the record here in the meeting log: I'm willing and able to research a fee estimation algorithm that handles discrete fees, minimizes privacy risks, and reduces the likelihood of a fee bubble. Not now, but down the road as we get closer to Seraphis implementation on mainnet.

I think that the dynamic blocksize might also soften the blow in regards to any positive feedback loops in the fee levels

Since the blocksize is not fixed, keeping a steady fee pressure would push the blocksize up, which in turn would reduce the fee pressure for new transactions and increase the total cost of keeping the pressure up

Rucknium[m]: I think that would a really valuable long-term project, so I am looking forward to it :)

I think the dynamic bloc size is good for long-term fee stability, but it would still be subject to temporary short-term spikes in tx demand and feees

<kayabanerve[m]> "Yeah, potentially not. I think..." <- If one wallet is using a different algorithm than another or you're trying to pinpoint a tx to a particular point in time, more granular fees imo are definitely more likely to leak this and therefore the puddles form easier when that is the case. I can't imagine a circumstance where this wouldn't hold

^

Anyone have opinions on what a good scaling factor would be? I really like powers of 1.5 rounded to 1 sig fig (conveniently, this distribution includes every power of 10 from 1 to 1e19).

UkoeHB: If you implement this is the code now, and then somehow we figure out that it's a really bad idea before it hits mainnet, how difficult would it be to reverse it in the code implementation?

Rucknium[m]: probably not that hard

I think the scaling factor should be evaluated against the pressure it puts towards pushing the blocksize up. ie.: "If we bump to the next fee level, how many more transactions can we fit in a block? How much faster are blocks going to grow?"

If the granularity is too small, then a user/wallet might have to skip a few levels at a time to justify their inclusion in the next block

But if the granularity is too coarse, then the blocksize growth might become unstable

Just shillin' here, but this calls for a proper simulation...

:)

merope: sound's like you have some homework :)

One CCS proposal at a time 😅

I wouldn't know how to model it, but intuition tells me this is a control theory problem

It sounds like it, alright (I'm a control engineer)

(but maybe this already obvious to you)

maybe some homework for mj-xmr[m] ?

*this was

It's not just a control theory problem. People are not atoms ;)

UkoeHB: If anybody has time to give me a 1-2 hours tutorial, I can take it up.

Rucknium[m]: Discrete control theory. Happy now?

It has control theory elements

Ok, we are at the hour mark so I'll call it. Thanks for attending everyone

I will implement round(pows(1.5)) as an interim solution so I can make further progress on my PoC.

Thanks for moderating!

ArticMine: you here to help mj-xmr[m] figure out the dynamic block size?

An engineer syllogism

I am good at understanding numbers.

The stock market is made of numbers.

Therefore I– Wow, where did all my money just go?

mj-xmr[m]: I'd start with ZtM2 section 7.3.2 (there are some small changes in monero-project/monero #7819 )

Rucknium: would it help you if you learned that I'm at the 5th scene of this cartoon already? :)

> <@rucknium:monero.social> An engineer syllogism... (full message at libera.ems.host/_matrix/media/r0/do…b38a6a325242a54df3e13546b8d85434af4)

heyo

would like to know if there has been any time dedicated into making monero, say, unlaundearable?

have been thinking about ways of maintaining privacy whilst making it hard for those who do not want to be excellent to each other

such as?

nothing that seems to work

thats why i came to ask here

lol, I am not aware of anything

is there any plan to work on this

hmm

anyone interested in looking into this?

because i would

privacy respectful anti-laundering.. hmm

maybe you could integrate some kind of zk-kyc

im not sure if that’s logically possible

I think ZCash is working on this.

anti-laundering zec?

Yes, Zooko has mentioned he wants ZCash to be too traceable for criminals, but still private and fungible.

Wouldn't that go against the very definition of fungibility though?

merope: that’s what i was gonna say

lmao

and zec already has the ability to share transactions with a txn view key

for tax purposes

but that’s just non-private

just impose an automatic government tax on all transactions, I'm sure that will work greatt

Hilarious timing on my part to respond right after the message about Zec - but I was referring to the original idea: if you find a criterium/metric that allows you to tell those "bad apples" apart, then you've broken the definition of fungibility, ie. not being able to tell them apart

UkoeHB: You mean like Zcash's dev ta-oh, wait

yeah, and if you fail to be verified as a non-launderer you will be looked at with a furrowed brow

from an academic perspective, itd be cool to have some impossibilty proofs

You're describing what CBDCs will be

Private for me but not for thee

Only those with the Government Approved sticker can spend, and only how "they" see fit to allow

(until someone hacks the fed's SQL server)

Precisely

<chesterfield[m]> "I think ZCash is working on this..." <- gross