16:59:58 meeting time https://github.com/monero-project/meta/issues/743 16:59:59 1. greetings 16:59:59 hello 17:00:40 hi 17:00:45 Hello 17:00:58 Hi 17:01:19 Hi 17:01:42 Hello 17:01:42 hello 17:02:33 2. updates, what's everyone working on? 17:02:35 Hi 17:03:40 me: PR for background sync mode is incoming right after this meeting, then going to do some stress testing on monerod + @rbrunner's pool PR 8076, then jump into Seraphis 17:05:33 hyc completed his review of my OSPEAD estimator proposal. isthmus gave me partial feedback. So far, no major changes. 17:05:39 me: finished planned unit testing for balance recovery in a legacy-seraphis transition, wrote a serialization proof-of-concept for seraphis txs https://github.com/UkoeHB/monero/blob/seraphis_lib/tests/unit_tests/seraphis_serialization.cpp , started working on supporting legacy inputs to seraphis multisig txs (right now working on multisig key image recovery for legacy enotes, which could probably be PRd to master at 17:05:39 some point) 17:06:32 I'm working on my understanding of wallet2 and simplewallet and trying to create some logical reasoning of what is going on there. 17:06:54 ^ nice. that's some srsly messy code. 17:07:33 One more person understanding wallet2 is certainly a plus ... 17:09:38 :p 17:10:05 3. discussion 17:10:18 I have been working on fess and following the ZCash attack. There are some changes that can be implemented as part of comprehensive fee and scaling updates. 17:11:31 I am moving back to OSPEAD 17:12:33 By the way the ZCash attack is continuing 17:14:50 btw, in case anyone missed it https://libera.monerologs.net/monero-dev/20221016#c151626 we can probably fit 2-3 more people without it getting too out of hand (7 devs + sgp attending right now) 17:15:40 Thanks for stepping up to schedule this :) 17:15:46 as an aside: it appears the zcash attackers may have followed our discussions of the attack and improved their methods as a result 17:16:40 Hmmm ... Isn't the idea "Just keep attacking" a bit trivial to come up with, even without our help? 17:16:54 UkoeHB: Really nice from you :) 17:17:07 sgp yep, somehow the seraphis lib got pretty big lol 17:17:21 Yeah, such things happen :) 17:17:21 rbrunner: one would think so, but then why didn't they just do that from the very beginning? 17:17:28 It may be the case but I have been discussing this kind of attack for over three years 17:17:57 hyc: Good question 17:18:57 ArticMine[m]: any news about zcash planning mitigations? 17:19:37 Maybe they just want to get Zcash improved with a non-brain-dead fee model, and when they saw that intermittent attacks do not yet inspire enough sense of urgence, they stepped up the attacks 17:19:47 anyway sure it may all be coincidence, but the fact that their observed behavior changed within a couple days of our discussion seems to point that way 17:20:01 They want to stop wallets allowing this stuff but only enforce it on protocol level "later" 17:20:01 I have not been following that. There is very little in the news 17:20:58 The observed behaviour chand around October 10th 17:21:05 Changed 17:21:18 UkoeHB: Yes. They have a ZIP to alter fees. They are going to change the block template RPC to give low-fee txs a lower probability of being added to a block (strange to me) to avoid forcing all wallet users to upgrade 17:21:46 in any case, it's a good reminder that just because an attack vector isn't being exploited right now, it always can be 17:22:34 https://github.com/zcash/zips/pull/631 17:23:23 Rucknium[m]: do they need a wallet upgrade to handle dynamic fees? 17:23:49 In my view they have a host of problems with their fee structure going back to Bitcoin. I simply do not know where to start 17:24:31 Shhh, don't tell too much, they should take you as a highly paid consultant :) 17:24:51 ;) 17:24:53 (My understanding of the Monero fee-blocksize relationship is incomplete) Are we sure that the Monero mining infrastructure (pool software, p2pool) will raise block size when fees spike suddenly? Have we seen it in the wild, in the current hardfork era? 17:25:40 I think you have the causal relation backwards 17:25:55 but yes we've seen the dynamic blocksize adjust as designed 17:25:56 We saw the proper behaviour just before the HF 17:26:14 UkoeHB: I am not 100% sure, but I would bet that many "third party" wallets have hard-coded the min fee per tx (of any size), which is one zat IIRC 17:26:15 Also back in 2017 17:26:21 Rucknium[m]: the block size constraints change automatically based on past block sizes; block sizes are pushed up if fees exceed the block reward penalty (and there are enough txs to exceed the median block size constraint) 17:27:39 Ok. Don't XMR miners have to "decide" to forgo some of the 0.6 XMR block reward to add the excess-size txs? It's not completely automatic, right? 17:28:00 The kind of massive super low fe tx would not get past node relay 17:28:11 Do starters 17:28:34 Fot 17:28:36 Rucknium[m] p2pool goes above block size limit if there are enough transactions 17:29:19 ... and the proper fee is paid 17:29:39 even if it's the lowest fee level, it can go up to 300k + 1000 bytes or so 17:29:44 as I've seen in practice 17:30:35 Then the scaling begins with the rate depending on the fee paid 17:30:40 On this topic, I'd like to recapitulate my idea for upgrading how wallets select fees. Basically, wallets should estimate the confirmation delay for different incremental fee/weight ratios and present them to users in form fee/weight * tx weight (e.g. fee 0.002 = delay 5 blocks, fee 0.01 = delay 0 blocks), then users select which fee they want to pay. 17:31:08 sech1: But you had to program this yourself after all, a dumb version of p2pool would not take part in pushing up the blocksize, if I understand correctly? 17:31:33 no, any sane tx selection algorithm will push above block limit 17:31:50 it will keep adding transactions as long as additional fee overweights the penalty 17:32:00 and start from best fee/byte transactions 17:32:22 Yes, that "tx selection algorithm" is inside your own code, and you could have built a very primitive version with hardcoded blocksize? 17:32:47 why hardcode blocksize? monerod tells it 17:32:57 p2pool does have the limit though 17:33:02 it's 1000 tx per block currently 17:33:48 I try to get a grasp on Rucknium's question: "It's not completely automatic, right?" Seems to me indeed it isn't all automatic. 17:33:56 rbrunner: This is the point I was making. Anyway, not a huge concern for spamming since a miner hardcode would limit chain bloat. But would also possibly frustrate users trying to get their txs confirmed 17:34:31 It is a very serious concern for scaling 17:34:40 Rucknium[m]: yes there is a block reward penalty when you exceed the median block size, which increases non-linearly as you go farther into the penalty zone; you only add a tx into the penalty zone if the new tx exceeds the penalty and removing any other other tx from the block won't improve the block reward 17:34:44 If this is true 17:35:43 If different miners all have their own logic how they fill txs into blocks, and how many, *in theory* block growth could fail because of too-stupid such algorithms. 17:36:34 A mining pool can refuse to increase the blocksize but they would loose money doing this 17:37:15 This particular mechanism requires rational behavior on the part of miners. But maybe it was rational to take a coding shortcut :/ . Just raising the issue. Probably it is OK. 17:37:24 in general, miners don't do any selection themselves. they let monerod select for them. 17:37:41 ArticMine[m]: if enough pools do it, they could force a fee market to arise which would increase rewards 17:38:04 Ah yes, there is a call for that after all. 17:38:34 There is already a fee market 17:39:11 UkoeHB: You mean the Bitcoin scenario 17:39:18 Well, a fee market with fixed supply (i.e. if miners cap block size at the median 17:39:40 UkoeHB: Very good point. In the future it could be a nice idea to examine the incentives of miners to check whether they align with what was intended. There are various papers about PoW miners subverting the intention, even for fixed-blocksize chains 17:40:46 We need to understand first if this is happening and where. It is a very valid point 17:40:47 a competing pool could easily break that cartel by offering higher block rewards to miners though 17:41:03 er miner shares I guess 17:42:17 ... and the hashers would move there 17:42:20 This sounds a lot like an economics question :) 17:42:20 Industrial Organization, even. 17:42:39 It does 17:43:32 ArticMine[m]: yeah, and the supply of hash power might increase which would increase the marginal cost and might push the cartel miners into unprofitability (even though block rewards are nominally higher) 17:44:03 I think I found the RPC version: COMMAND_RPC_GETBLOCKTEMPLATE 17:44:22 yes 17:47:48 there is probably a certain percentage of tx volume that a cartel could block without the cartel being broken, but it's probably pretty small since switching pools is fairly simple for miners 17:48:40 Speaking of economics, last year Zcash hired some economists to develop their fee model for Zcash Shielded Assets, which do not exist yet. They didn't think to hire them to look at the fee model of ZEC itself 17:49:01 lol 17:49:09 If renting hashpower somehow somewhere is cheaper than the income you get from blackmailing tx submitters into high fees by artificially small blocks, you win :) 17:49:17 Few miners switched when minexmr raised their fee though 17:49:52 Needs pretty serious hashpower to work however ... 17:50:06 an example of 'small enough' 17:50:26 It would be a money loosing proposition for the cartel except if the bigger blocks increased by orphan rate 17:51:19 There was a paper way back by Peter Rizun on this 17:52:25 He is a BCH community member 17:53:06 anyway we are closing in on the end of the meeting, any last-minute questions/topics? 17:53:37 So there is an edge case where this can make senses 17:53:38 I will put this on the open research questions list. 17:53:40 I will look for it 17:56:34 ok seems like we are done, thanks for attending everyone 17:57:11 Thanks for 17:57:21 Hosting