I have a question about the dynamic fee algorithm. Is it ok that it doesn't have lower limit? Fee can be 0 if the median block weight exceeds 42426406 bytes, which opens a possibility for transaction flood attacks.

@sech1 From what I understand, the miner can decide if he increases the size of the block, but it comes with a reduction of the block reward. So the miner would only increase the block size if it's profitable to do so (reduced block reward + sum of fees)

That just means that an attacker has indeed the possibility of pushing the blocksize past that limit and starting such a flood attack

Is the fee is an unsigned int, at least? (Just to double check)

it's all done using 128 and 64 bit unsigned ints

but it doesn't check for 0 fee in the end, even if it says "round_up" in the comment there

The check_fee function right underneath has a check that might prevent a node from accepting (?) a 0-fee tx, I think?

L3812

Oh wait, no

0 < 0 is false, so that block would be skipped

yes, that's what I'm talking about. If the base dynamic fee is 0, it will accept 0-fee transactions

That’s an interesting point. ArticMine ^

Meeting 2hr

meeting time: monero-project/meta #699

1. greetings

hello

Hi

Hi there

Hi!

howdy

o/

hello

2. updates, what is everyone working on?

Hello

Decoy selection algo:... (full message at libera.ems.host/_matrix/media/r0/do…eaf1e9d569973e5d8ddb921115d615aeab4)

atm focused on trying to finish reviewing rbrunner's 8076

Very glad to hear you are on it :)

Developing a model to estimate the effect of the 0.1% operator fee hike on minexmr's hashpower share (want to discuss this). Computing the empirical spend age of BTC, BCH, LTC, and DOGE outputs (also want to discuss this).

me: I implemented 16-byte address indices in my seraphis PoC (using Twofish for the address tag cipher), and fixed a multisig exploit that would let a tx proposer burn funds (both for pr 8149 and seraphis). Next I will implement discretized fees and finally implement an input selection solver.

mj-xmr: How close do you think we are to parity between the wallet2 and your python implementations of the decoy selection algorithm? When can we start statistical testing of equivalency?

Rucknium: I think I need at least 2 weeks for this.

It's just that it's not the only thing I do, and I'm continuously dragged for reviewing this and that. Which is good, as it pushes many things forward.

Thanks. Sounds good. Timeline is useful for my planning purposes.

3. discussion (if anyone has more updates, feel free to drop them)

looks like Rucknium[m] is raring to go

I'm still working on my website and monero tools to verify all the txs from the inflation point of view. I bought the domain moneroinflation.com (with xmr of course :p) and my first delivery will be by the end of the month. I believe I am on track regarding my CCS proposal and I am also exploring some algorithms and C++ implementations of these EC point multiplications to better understand what is going in the software

and with my Python implementation.

Rucknium[m]: did you have something to discuss?

Overall, I would like to "manage expectations" about the minexmr estimations. As has been said, all models are wrong, but some are useful. In time series especially there are many judgment calls to be made about model specification that can be debated. And this statistical problem has particular features, such as the fact that the data is count data, that can make things tricky....

But mainly just a brainstorm about what factors may affect minexmr's share of found blocks. So far I have on-chain difficulty from monerod and fiat/XMR exchange rate

The rate change seems like it would be too small to affect anything

The main purposes of adding more variables is (1) increases precision of the model and (2) hopefully avoids confusing the rate change increase with other factors that are changing at the same time

UkoeHB: I think in theory you are probably right. Hopefully some statistical analysis can help test that hypothesis.

An implication of the "no effect" hypothesis is that minexmr would have increased their revenue by 10%.

So any other factors that may affect minexmr's share of found blocks? endor00 may have some ideas.

I agree with koe's take: at first glance, the 0.1% fee increase is just more money in their pocket

probable factors: marketing efforts by different pools (including grassroots eg p2pool), software changes by different pools

also perception around overall hashrate can influence whether people enter/exit a pool

hashrate share*

What did you want to say about empirical spend age?

The choice of the pool is affected by many factors: some "purely rational" and financial (like the impact of the fee on income), others subjective or harder to quantify, such as marketing, perception (like having a nice website, and a good "image" in the community), connection latency, pool stability and uptime, and historical reliability (no exit scams or bad payments)

good summary

And all that gets thrown into the blender with miner education - there are many newcomers who have no idea about most of this stuff, so they just pick the first on the list and call it a day

Or they even think that bigger is better (which I've had to dispel several times)

endor00: Thanks. I wonder if there is a way to measure some of those factors.

Bonus round: there are many botnets that pick the top pools due to the greater stability of their larger infrastructure

Are you already tracking number of mineral per pool?

/ hashrate migration?

It's why Supportxmr doesn't ban some known botnets, despite their no-botnet policy: if they were to ban them, they would most likely move on Minexmr and make centralization worse

One useful metric would be looking at the historical number of miners on the pool, in relation with the total pool hashrate

Hashrate often moves minexmr to and from "unknown" and also to some spikes on pps pools

w: I think that number of found blocks and number of miners shouldn't be considered independent metrics. One causes the other in a very direct fashion.

Not aware of any platforms that save historical data about this though... Perhaps miningpoolstats.stream? They display the data for the last week or so, but I don't know if they save it further than that

(Though nothing stops you from digging through their page source and finding their api endpoint and saving data yourself - I looked into that a while back, but don't have any data saved)

endor00: Interesting idea. Also, we don't know what the hashpower behind each miner is, so it may be difficult to get any traction. There is probably a large diversity among the miners

Rucknium[m]: what did you want to discuss re: empirical spend age?

These are from the week leading into Feb 17

30+% of the hashrate came from 200 miners or less

* 30+% of the hashrate came from 200 miners or less

Edit. In theory.

Ok. On to computing the empirical spend age of BTC, BCH, LTC, and DOGE outputs. I have modified some code I wrote to analyze the BTC/BCH blockchain to extract the necessary data from blockchains that have bitcoin-like RPC calls. I now have preliminary results for LTC and DOGE.

The purpose for now is to measure the stability of the inter-temporal spend age distributions. This can give us a sense of the "out of sample" risk of a static decoy selection algorithm. In other words, the estimates done on Monero's historical block chain (which are still the most important estimates) cannot tell us what may happen if there is a sudden change in the composition of users or in the behavior of existing users.

This is related to forecasting with mj-xmr 's `tsqsim` software -- what is the risk?

So what other blockchains other than BTC, BCH, LTC, and DOGE would make sense here?

are there any other simple chains with meaningful tx volume?

(DOGE is in this mix since it has bitcoin-like RPC [with a small modification] and it experienced a sudden rise from obscurity to popularity, which XMR might do one day)

DASH is somewhat comparable to Monero, in terms of tx volume

This issue of the inter-temporal stability of the spend time distribution also is important for any enforcement of decoy selection algorithm down the line with Seraphis or before. I have had an idea to somehow have miners include some information about the dynamic change in the spend age distribution in the block header, to "conduct the orchestra"

And the api should be the same, I think

Tbh I don't think enforcing decoy selection would work well

aside from deterministic bins

Yes, I was considering Dash. I think there is a complication with their CoinJoin privacy features, but it may be worth it to compute it and see what it looks like.

It's really hard to make decoy selection deterministic and not a huge mess that's hard to validate

Say people suddenly start to spend twice as early as before. How would somebody notice this in the first place, with Monero, to do something with it, regarding any analysis?

deterministic bins on their own are already pretty complex

I thought your proposal did that?

I just decided to implement the deterministic bins part, but let bin locations be user-defined

the bin location selector can be injected

you can see how complex the bins are here: github.com/UkoeHB/monero/blob/serap…s/tx_binned_reference_set_utils.cpp

rbrunner: If there is a substantial mismatch between user behavior and the decoy selection algorithm, statistical methods can be used to narrow down which decoy is the true spend. xmr-ack 's preliminary research with machine learning illustrated that.

My fantasy just fails me when I try to imagine where any "signal" comes from here, that could be machine-learned, but that's probably my innoncence regarding statistics

As you don't really "see" user behaviour, do you?

So a sudden shift in user behavior without a corresponding shift in the decoy selection algorithm can create problems for user privacy.

No, but you see the decoy selection algorithm.

So it's kind of a risk estimation you will do, looking as those "clear" blockchains, and see what happened there regarding factors like "spend speed"?

If such shift happen often, higher risk for Monero

Random thought: could the decoy selection be "parametrized" based on the age of the real spend, such that the "degree of privacy" is maximised each time?

Or does that make no sense, because such parametrization would inherently expose the age?

rbrunner: you can plot on a graph like this and the blue line would diverge heavily from orange: user-images.githubusercontent.com/2…363-4b5b-4440-b1e9-fb656c614f4a.png ... so in a way, you can still "see" user behavior

Right. If there are quick shifts, then that will affect the tuning of a decoy selection algorithm. Sort of like if you are holding an asset whose value is very volatile. Your behavior would be different of the asset doesn't change much

endor00: Your second conclusion is correct, IMHO.

"so in a way, you can still "see" user behavior" the aggregate of it, right?

before the end of the meeting, there are two more items

right

Basically, you don't want to make the decoy selection algorithm change dependent upon what the real spend of a particular tx is.

UkoeHB: you mentionned some work to document the multisig protocol with dangerousfreedom, how can I help?

item 1: I am putting together a workgroup for documenting multisig for use by an auditor. So far, dangerousfreedom and h4sh3d seem interested in participating.

right

:) perfect timing

tbh I'm not sure the best way to do it

what king of documentation do we want to produce? (IIRC it's for helping audit)

*kind

Probably a pdf that describes the algorithms (key generation and signing) with comments and citations justifying different parts of the design.

It needs a little more technical precision than ZtM2, but that style is probably good.

I guess the question for this meeting is if anyone else wants to participate.

Well, maybe not

We can coordinate more outside the meeting. I will try to put together a communication channel

perfect, thanks

I will be happy to help h4sh3d with this multisig stuff, thanks

item 2: this issue was made monero-project/research-lab #100 does anyone have questions/comments? sounds like kayabaNerve will try to demo what a membership proof circuit would look like

The idea wasn't kindly received on Reddit

but it seems thankfully that did not spill over to GitHub ...

it's not like we will implement something that actually sucks; if it actually doesn't suck, then why not?

Lol ... that's the spirit :)

Poorly-informed question: If we wanted to have defense-in-depth and somehow combined a full ZK cryptographic system with ring signatures (stack one on top of the other?), then would tx size and verification be something like the sum of the two systems or multiplicative or some other function?

From my understanding, MobileCoin (koe please correct me) has defense in depth with ring sigs and secure execution environment.

I thought the secure environment was to hold the user's private viewkey for tx scanning, so that they won't get exposed even in case of a hack

Would the idea be to merkle proof all the ring members, then do a ring sig on the ring members, all within a circuit? It seems multiplicative

merope: no that's the Fog service, mobilecoin also validates all txs within SGX then discards signatures when finalizing blocks

Oh I see

Wouldn't that make it impossible for an external user to validate the chain by themselves though? Because they would miss all the signature data

yes it's part of their trust model

ok we are at the end of the meeting, thanks for attending everyone

I am out of my depth on this for sure, so I don't know what's possible. I think the broader community is concerned that ZK has not stood the test of time the way that the cryptographic assumptions that underpin ring sigs have. (I know RingCT is technically ZK, but I think the underlying assumptions are different from zk-SNARKS and the like.

I think it's right to be concerned/attentive when actually funding/implementing something. Zk circuits in monero are just a fancy idea...

And I guess it would be a long, long way to arrive at something that can safely deployed in a hardfork. Mountains of work.

right, a mountain that begins with actually looking at it lmao (instead of hysterics)

I for one find it interesting what will result from "looking at it", yeah. It's quite nebulous now, it's more or less just "that Zcash thing"

AFAICT (and excuse this potential over-simplification), these 2 reasons seemed to be the strongest justification for keeping the membership proof separate, and approaching it like that to start:

(1) future upgrades to the protocol could potentially still build off the same anonymity pool, which is unlike Zcash today which upgrades pools every major change - kayabaNerve's point as I understood it

(2) modularity enables tx chaining and a cleaner tx building protocol - UkoeHB

Seems like a sensible first step at the problem to me, and to validate those points as it progresses

good point about the pools

<sech11> yes, that's what I'm talking about. If the base dynamic fee is 0, it will accept 0-fee transactions <--- You mean that the node will relay 0 fee txs for a median over 42.4 MB?

because of an integer overflow

precision loss, not integer overflow, I'm guessing

right it becomes 0

yes, minimum allowed fee will be 0 if median weight is over 42.4 MB

So maybe it's better to actually round it up as the comment says?

or just do "if 0 return 1"

Rounding up would avoid the issue

yeah probably `if 0 return 1`

0 fee transactions are unlikely to be picked up by mining pools though

Rounding up is done from an already truncated result, we can't know the ideal real number.

The issue is that in principle a DDOS against the nodes is possible at no cost since the tx are not mined

Since it is node relay and not consensus one can set the min fee at 1 as UkoeHB suggested

*min fee per byte at 1

I see the issue there is a factor of 10^3

The better solution is to work in terms of min fee per 1000 bytes

what factor? DYNAMIC_FEE_REFERENCE_TRANSACTION_WEIGHT?

The actuall fee paid is for a tx > 1000 bytes

right

but we are reaching a precision issue at the fee per byte

we had fee per kb before, but it was changed to fee per byte

Yeah I know because of confusion between KiB and KB

So fee per kB (1000 bytes) as opposed to (KiB 1024 bytes or KB 1024 bytes legacy)

Then we can apply the min of 1 at a level of 10^3 lower

en.wikipedia.org/wiki/Kilobyte Note the confusion still with MB

I don't see the need for lower that 1 atomic unit per byte fee. It's already 10^-12 XMR/byte, in Bitcoin the minimum fee is 10^-8 BTC/byte

Bitcoin still allows 0 fee tx?

I have no idea, I don't use it

For a sense of scale, at 1mill USD/xmr a min of 1 atomic unit per byte fee would be 0.001 USD equivalent for 1kB.

but still we I do not see an issue here with 1 * 10^(-12) XMR/ byte for now

the issue is with 0 XMR/byte fee after certain block size, that's an invitation for an attack

agreed

<Rucknium[m]> "This is related to forecasting..." <- If I understood the question right, then I started to allow for scripted data generation and noising the existing one on purpose, to see how the system would react. So far this stub is there:

github.com/mj-xmr/tsqsim/blob/maste…base/src/TicksProviderGenerated.cpp

Secondly, the out of sample performance can be tested.

Thirdly, if the out of sample data isn't available yet, because it's the latest data, that you're training on, then the Monte Carlo's distribution of optimal solutions gives you a good hint, if the given model/params has a chance to work on future data ( = if the solutions are widely spread and most of them are above the baseline prediction's score, you may be quite confident that it will work).

I very much doubt that with an increase in adoption of 300x USD price would remain the same

Even at 1e-12 XMR/byte, a full 42.4 MB block will have only 0.0000424 XMR in fees in total

the inverse quadratic relation makes total block fees go smaller and smaller

not sure this is good

So I would suggest we can use 1 * 10^(-12) XMR/ byte for now and then move to 1 * 10^(-15) XMR/ byte by using per kB (1000 bytes)

so "if 0 return 1" for now

the easiest thing to do

Yes that is th simple solution for now

I say that we have to be very careful with a 300x increase in adoption. I would expect an increase in price between 300x and 90000x

We are talking here of tx rates ~50x the max that Bitcoin can support on chain so there is bound to be an impact of price

It would take 2 years of max long term median growth to reach that level.

There are scenarios such as a state actor attacking VISA for example that could trigger this kind of impact on Monero

So we should be both aware and prepared

One thing to keep in mind here is that there is a huge difference between node relay and consensus. With node relay one dos not have the problems that Bitcoin has developed with consensus over the years. Min fee for example in my view should never be made a part of consensus. min fees do belong in node relay

<sech1> the inverse quadratic relation makes total block fees go smaller and smaller

<sech1> not sure this is good <---- A lot depends on price here. Once we are over Bitcoin tx rates (median above 1.5 MB) we can take a look at this.

Below 1.5 MB this leads to a higher min fee than what we had

The quadratic formula is the minimum to allow for any scaling. It comes at the cost of allowing a lower and lower rate of growth as the blocksize increases

So any kind of flood attack with such low fees would not work as the miners would loose money on the penalty