06:19:08 <sech1> 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.
06:57:49 <cryptobab> @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)
09:33:34 <merope> That just means that an attacker has indeed the possibility of pushing the blocksize past that limit and starting such a flood attack
09:34:43 <merope> Is the fee is an unsigned int, at least? (Just to double check)
09:35:39 <sech11> https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L3721
09:35:49 <sech11> it's all done using 128 and 64 bit unsigned ints
09:36:14 <sech11> but it doesn't check for 0 fee in the end, even if it says "round_up" in the comment there
09:38:52 <merope> The check_fee function right underneath has a check that might prevent a node from accepting (?) a 0-fee tx, I think?
09:38:59 <merope> L3812
09:39:38 <merope> Oh wait, no
09:40:04 <merope> 0 < 0 is false, so that block would be skipped
09:41:02 <sech11> yes, that's what I'm talking about. If the base dynamic fee is 0, it will accept 0-fee transactions
14:54:13 <UkoeHB> That’s an interesting point. ArticMine ^
14:58:33 <UkoeHB> Meeting 2hr
17:01:05 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/699
17:01:05 <UkoeHB> 1. greetings
17:01:05 <UkoeHB> hello
17:01:20 <Rucknium[m]> Hi
17:01:23 <rbrunner> Hi there
17:01:24 <dangerousfreedom> Hi!
17:01:55 <jberman[m]> howdy
17:02:15 <mj-xmr[m]> o/
17:02:34 <sech1> hello
17:03:00 <UkoeHB> 2. updates, what is everyone working on?
17:03:20 <h4sh3d> Hello
17:03:36 <mj-xmr[m]> Decoy selection algo:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d66c3eaf1e9d569973e5d8ddb921115d615aeab4)
17:05:17 <jberman[m]> atm focused on trying to finish reviewing rbrunner's 8076
17:05:30 <rbrunner> Very glad to hear you are on it :)
17:05:51 <Rucknium[m]> 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).
17:06:07 <UkoeHB> 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.
17:07:52 <Rucknium[m]> 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?
17:08:25 <mj-xmr[m]> Rucknium: I think I need at least 2 weeks for this.
17:09:25 <mj-xmr[m]> 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.
17:10:24 <Rucknium[m]> Thanks. Sounds good. Timeline is useful for my planning purposes.
17:10:28 <UkoeHB> 3. discussion (if anyone has more updates, feel free to drop them)
17:10:40 <UkoeHB> looks like Rucknium[m] is raring to go
17:10:45 <dangerousfreedom> 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
17:10:45 <dangerousfreedom> and with my Python implementation.
17:12:23 <UkoeHB> Rucknium[m]: did you have something to discuss?
17:12:58 <Rucknium[m]> 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....
17:13:48 <Rucknium[m]> 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
17:14:17 <UkoeHB> The rate change seems like it would be too small to affect anything
17:14:57 <Rucknium[m]> 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
17:15:56 <Rucknium[m]> UkoeHB: I think in theory you are probably right. Hopefully some statistical analysis can help test that hypothesis.
17:16:50 <Rucknium[m]> An implication of the "no effect" hypothesis is that minexmr would have increased their revenue by 10%.
17:17:35 <Rucknium[m]> So any other factors that may affect minexmr's share of found blocks? endor00 may have some ideas.
17:20:32 <merope> I agree with koe's take: at first glance, the 0.1% fee increase is just more money in their pocket
17:20:34 <UkoeHB> probable factors: marketing efforts by different pools (including grassroots eg p2pool), software changes by different pools
17:21:37 <UkoeHB> also perception around overall hashrate can influence whether people enter/exit a pool
17:21:47 <UkoeHB> hashrate share*
17:22:52 <UkoeHB> What did you want to say about empirical spend age?
17:23:10 <merope> 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)
17:23:29 <UkoeHB> good summary
17:23:29 <merope> 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
17:23:57 <merope> Or they even think that bigger is better (which I've had to dispel several times)
17:24:17 <Rucknium[m]> endor00: Thanks. I wonder if there is a way to measure some of those factors.
17:25:06 <merope> Bonus round: there are many botnets that pick the top pools due to the greater stability of their larger infrastructure
17:25:20 <w[m]> Are you already tracking number of mineral per pool?
17:25:20 <w[m]> / hashrate migration?
17:25:43 <merope> 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
17:26:24 <merope> One useful metric would be looking at the historical number of miners on the pool, in relation with the total pool hashrate
17:26:32 <w[m]> Hashrate often moves minexmr to and from "unknown" and also to some spikes on pps pools 
17:26:59 <Rucknium[m]> 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.
17:27:38 <merope> 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
17:28:35 <merope> (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)
17:29:05 <Rucknium[m]> 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
17:29:12 * w[m] uploaded an image: (200KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/UzmOKEzWUfvieyXWKQSVOpkC/Image_110.jpg >
17:29:36 <UkoeHB> Rucknium[m]: what did you want to discuss re: empirical spend age?
17:29:38 * w[m] uploaded an image: (166KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/OynAVotgXmXzrOJFMCKEZIUv/Image_111.jpg >
17:29:49 <w[m]> These are from the week leading into Feb 17
17:30:46 <w[m]> 30+% of the hashrate came from 200 miners or less
17:31:11 <w[m]> * 30+% of the hashrate came from 200 miners or less
17:31:11 <w[m]> Edit. In theory.
17:31:21 <Rucknium[m]> 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. 
17:31:34 <Rucknium[m]> 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.
17:32:04 <Rucknium[m]> This is related to forecasting with mj-xmr 's `tsqsim` software -- what is the risk?
17:32:24 <Rucknium[m]> So what other blockchains other than BTC, BCH, LTC, and DOGE would make sense here?
17:33:05 <UkoeHB> are there any other simple chains with meaningful tx volume?
17:33:20 <Rucknium[m]> (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)
17:34:44 <merope> DASH is somewhat comparable to Monero, in terms of tx volume
17:34:58 <Rucknium[m]> 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"
17:35:14 <merope> And the api should be the same, I think
17:35:26 <UkoeHB> Tbh I don't think enforcing decoy selection would work well
17:35:36 <UkoeHB> aside from deterministic bins
17:36:09 <Rucknium[m]> 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.
17:36:18 <UkoeHB> It's really hard to make decoy selection deterministic and not a huge mess that's hard to validate
17:37:26 <rbrunner> 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?
17:37:26 <UkoeHB> deterministic bins on their own are already pretty complex
17:37:28 <Rucknium[m]> I thought your proposal did that?
17:37:46 <UkoeHB> I just decided to implement the deterministic bins part, but let bin locations be user-defined
17:38:01 <UkoeHB> the bin location selector can be injected
17:38:28 <UkoeHB> https://github.com/UkoeHB/monero/blob/seraphis_lib/src/seraphis/tx_ref_set_index_mapper.h
17:39:06 <UkoeHB> you can see how complex the bins are here: https://github.com/UkoeHB/monero/blob/seraphis_lib/src/seraphis/tx_binned_reference_set_utils.cpp
17:39:21 <Rucknium[m]> 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.
17:40:41 <rbrunner> 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
17:41:07 <rbrunner> As you don't really "see" user behaviour, do you?
17:41:09 <Rucknium[m]> So a sudden shift in user behavior without a corresponding shift in the decoy selection algorithm can create problems for user privacy.
17:41:38 <Rucknium[m]> No, but you see the decoy selection algorithm.
17:42:36 <rbrunner> 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"?
17:42:52 <rbrunner> If such shift happen often, higher risk for Monero
17:42:55 <merope> 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?
17:43:14 <merope> Or does that make no sense, because such parametrization would inherently expose the age?
17:44:08 <jberman[m]> rbrunner: you can plot on a graph like this and the blue line would diverge heavily from orange: https://user-images.githubusercontent.com/26468430/130846265-d9fa5363-4b5b-4440-b1e9-fb656c614f4a.png ... so in a way, you can still "see" user behavior
17:44:16 <Rucknium[m]> 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
17:46:04 <Rucknium[m]> endor00: Your second conclusion is correct, IMHO.
17:46:21 <rbrunner> "so in a way, you can still "see" user behavior" the aggregate of it, right?
17:46:26 <UkoeHB> before the end of the meeting, there are two more items
17:46:39 <jberman[m]> right
17:47:05 <Rucknium[m]> Basically, you don't want to make the decoy selection algorithm change dependent upon what the real spend of a particular tx is.
17:47:29 <h4sh3d> UkoeHB: you mentionned some work to document the multisig protocol with dangerousfreedom, how can I help?
17:47:32 <UkoeHB> 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.
17:47:37 <UkoeHB> right
17:47:48 <h4sh3d> :) perfect timing
17:48:05 <UkoeHB> tbh I'm not sure the best way to do it
17:48:34 <h4sh3d> what king of documentation do we want to produce? (IIRC it's for helping audit)
17:48:58 <h4sh3d> *kind
17:49:14 <UkoeHB> Probably a pdf that describes the algorithms (key generation and signing) with comments and citations justifying different parts of the design.
17:50:10 <UkoeHB> It needs a little more technical precision than ZtM2, but that style is probably good.
17:51:22 <UkoeHB> I guess the question for this meeting is if anyone else wants to participate.
17:52:56 <UkoeHB> Well, maybe not
17:53:30 <UkoeHB> We can coordinate more outside the meeting. I will try to put together a communication channel
17:53:53 <h4sh3d> perfect, thanks
17:54:05 <dangerousfreedom> I will be happy to help h4sh3d with this multisig stuff, thanks
17:54:32 <UkoeHB> item 2: this issue was made https://github.com/monero-project/research-lab/issues/100 does anyone have questions/comments? sounds like kayabaNerve will try to demo what a membership proof circuit would look like
17:56:40 <rbrunner> The idea wasn't kindly received on Reddit
17:56:56 <rbrunner> but it seems thankfully that did not spill over to GitHub ...
17:57:26 <UkoeHB> it's not like we will implement something that actually sucks; if it actually doesn't suck, then why not?
17:57:40 <rbrunner> Lol ... that's the spirit :)
17:58:15 <Rucknium[m]> 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?
17:59:03 <Rucknium[m]> From my understanding, MobileCoin (koe please correct me) has defense in depth with ring sigs and secure execution environment.
18:00:34 <merope> 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
18:00:55 <UkoeHB> 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
18:01:31 <UkoeHB> merope: no that's the Fog service, mobilecoin also validates all txs within SGX then discards signatures when finalizing blocks
18:02:19 <merope> Oh I see
18:02:44 <merope> 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
18:02:56 <UkoeHB> yes it's part of their trust model
18:03:32 <UkoeHB> ok we are at the end of the meeting, thanks for attending everyone
18:03:37 <Rucknium[m]> 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.
18:04:43 <UkoeHB> I think it's right to be concerned/attentive when actually funding/implementing something. Zk circuits in monero are just a fancy idea...
18:05:33 <rbrunner> And I guess it would be a long, long way to arrive at something that can safely deployed in a hardfork. Mountains of work.
18:06:07 <UkoeHB> right, a mountain that begins with actually looking at it lmao (instead of hysterics)
18:07:17 <rbrunner> 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"
18:11:11 <jberman[m]> 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:
18:11:57 <jberman[m]> (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 
18:12:08 <jberman[m]> (2) modularity enables tx chaining and a cleaner tx building protocol - UkoeHB 
18:12:24 <jberman[m]> Seems like a sensible first step at the problem to me, and to validate those points as it progresses
18:17:09 <UkoeHB> good point about the pools
19:28:02 <ArticMine> <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?
19:28:40 <ArticMine> because of an integer overflow
19:30:14 <UkoeHB> precision loss, not integer overflow, I'm guessing
19:30:36 <ArticMine> right it becomes 0
19:30:54 <sech1> yes, minimum allowed fee will be 0 if median weight is over 42.4 MB
19:31:36 <sech1> So maybe it's better to actually round it up as the comment says?
19:31:59 <sech1> or just do "if 0 return 1"
19:32:13 <ArticMine> Rounding up would avoid the issue
19:32:14 <UkoeHB> yeah probably `if 0 return 1`
19:32:57 <sech1> 0 fee transactions are unlikely to be picked up by mining pools though
19:33:11 <moneromooo> Rounding up is done from an already truncated result, we can't know the ideal real number.
19:33:56 <ArticMine> The issue is that in principle a DDOS against the nodes is possible at no cost since the tx are not mined
19:36:06 <ArticMine> Since it is node relay and not consensus one can set the min fee at 1 as UkoeHB suggested
19:36:44 <sech1> *min fee per byte at 1
19:38:13 <ArticMine> I see the issue there is a factor of 10^3
19:39:01 <ArticMine> The better solution is to work in terms of min fee per 1000 bytes
19:39:07 <sech1> what factor? DYNAMIC_FEE_REFERENCE_TRANSACTION_WEIGHT?
19:39:36 <ArticMine> The actuall fee paid is for a tx > 1000 bytes
19:40:06 <sech1> right
19:40:07 <ArticMine> but we are reaching a precision issue at the fee per byte
19:40:37 <sech1> we had fee per kb before, but it was changed to fee per byte
19:42:21 <ArticMine> Yeah I know because of confusion between KiB and KB
19:49:56 <ArticMine> So fee per kB (1000 bytes) as opposed to (KiB 1024 bytes or KB 1024 bytes legacy) 
19:50:34 <ArticMine> Then we can apply the min of 1 at a level of 10^3 lower
19:53:25 <ArticMine> https://en.wikipedia.org/wiki/Kilobyte Note the confusion still with MB
19:54:52 <sech1> 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
19:56:34 <ArticMine> Bitcoin still allows 0 fee tx? 
19:56:48 <sech1> I have no idea, I don't use it
19:57:47 <UkoeHB> 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.
19:59:10 <ArticMine> but still we I do not see an issue here with 1 * 10^(-12) XMR/ byte for now
20:00:19 <sech1> the issue is with 0 XMR/byte fee after certain block size, that's an invitation for an attack
20:00:27 <UkoeHB> agreed
20:00:48 <mj-xmr[m]> <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:
20:00:48 <mj-xmr[m]> https://github.com/mj-xmr/tsqsim/blob/master/src/lib-base/src/TicksProviderGenerated.cpp 
20:00:48 <mj-xmr[m]> Secondly, the out of sample performance can be tested.
20:00:48 <mj-xmr[m]> 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).
20:00:53 <ArticMine> I very much doubt that with an increase in adoption of 300x USD price would remain the same
20:01:34 <sech1> Even at 1e-12 XMR/byte, a full 42.4 MB block will have only 0.0000424 XMR in fees in total
20:01:56 <sech1> the inverse quadratic relation makes total block fees go smaller and smaller
20:02:01 <sech1> not sure this is good
20:02:39 <ArticMine> 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)
20:03:19 <sech1> so "if 0 return 1" for now
20:03:25 <sech1> the easiest thing to do
20:03:37 <ArticMine> Yes that is th simple solution for now
20:05:48 <ArticMine> 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
20:08:57 <ArticMine> 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
20:09:33 <UkoeHB> It would take 2 years of max long term median growth to reach that level.
20:11:32 <ArticMine> There are scenarios such as a state actor attacking VISA for example that could trigger this kind of impact on Monero 
20:12:22 <ArticMine> So we should be both aware and prepared
20:28:39 <ArticMine> 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
21:39:01 <ArticMine> <sech1> the inverse quadratic relation makes total block fees go smaller and smaller
21:39:01 <ArticMine> <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. 
21:39:41 <ArticMine> Below 1.5 MB this leads to a higher min fee than what we had
21:41:44 <ArticMine> 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
21:43:54 <ArticMine> So any kind of flood attack with such low fees would not work as the miners would loose money on the penalty