10:20:21 Did you know that all witdraw-buyer-seller-depoist chains are trackable in Monero? No? You should have read Breaking Monero. How many people are you endangering with your 'privacy' coin? 14:33:41 I updated issue 70 with the new proposal for scaling 14:33:46 https://github.com/monero-project/research-lab/issues/70 15:24:05 ArticMine: can you describe the dynamic minimum penalty free zone 15:29:18 thanks ArticMine, I will take a look and formulate a response over the next few days 16:38:02 sgp In a nutshell. The long term median is calculated first using fixed minimum penalty free zone of 300000 bytes. Then short term median is calculated using the long term median as the penalty free zone. So the long term median becomes the dynamic penalty free zone 16:42:34 ArticMine: can you repeat that please? users are having issues with irccloud today 16:49:36 Thanks UkoeHB 16:49:59 Sure 16:50:15 sgp In a nutshell. The long term median is calculated first using fixed minimum penalty free zone of 300000 bytes. Then short term median is calculated using the long term median as the penalty free zone. So the long term median becomes the dynamic penalty free zone 17:17:35 Meeting? 17:22:30 .time 17:22:53 sorry, I was off by an hour 17:22:59 meeting pushed to 18 utc 17:23:06 in 35 mins 17:23:18 ok 17:23:28 sorry :/ 18:01:14 okay, meeting time 18:01:24 these are issues with irccloud today, so many people will pop in and out 18:01:32 the matrix relays appear to be working however 18:01:43 https://github.com/monero-project/meta/issues/545 18:01:45 1. Greetings 18:01:49 Hi 18:02:23 ArticMine sarang moneromooo knaccc dEBRUYNE vtnerd 18:02:55 howdy 18:05:10 hi 18:07:17 pretty quiet crowd, but it normally picks up as the meeting goes on 18:07:39 Hi all 18:07:43 were there any outstanding items on the triptych discussion from the last two weeks? 18:08:50 The question I saw came down to timing 18:08:51 looks like there aren't any outstanding items at this time, except to find out who will work on it 18:09:44 my understanding is that this is waiting on optimizations and some consensus decisions from sarang (eg: related to output selection) 18:10:01 unless someone else is willing/able to work on these 18:10:13 ... and the issue of multisig 18:10:47 are there any multisig decisions that need to be made? 18:11:25 whether it must be supported if triptych goes live 18:11:37 It is more a question on how multisig will be handled and the time required 18:12:02 yeah it sounds like a big project 18:12:25 It raised issue around changing the address format to ensure compatibility 18:13:44 I agree with UkoeHB it is a big project to deal with all the details and ramifications 18:14:39 Yeah, it's a big project 18:15:05 I don't think we should change address formats, but it's a potential option 18:15:31 It may be necessary to support multisig 18:15:58 In what way is changing address formats necessary? 18:16:35 It I recall it had to do with preventing the sending to 18:16:58 The legacy multisig "conversion" process is the other option 18:17:20 I lean towards that actually 18:17:33 of new format transactions to old addresses 18:18:27 My take on this is that we should not hold up BP+, CLSAG ring changes and Issue 70 over this 18:18:51 Yes, to spend triptych outputs sent to legacy multisig wallets, they need to be "converted" to a non-multisig wallet before they can be spent iirc 18:20:06 Is there anything new on triptych or should we talk about 70? 18:20:07 So one needs to prevent Triptych outputs from being sent to legacy multisig wallets 18:20:20 hence the address format change 18:20:48 ArticMine: not necessarily, those changes could cause more problems than they solve 18:21:12 I'd rather defer that conversation topic however and talk about 70 18:21:20 This is of course valid and in need of further dicussion 18:21:27 Sure 18:22:01 https://github.com/monero-project/research-lab/issues/70#issuecomment-768036260 18:22:30 you have the floor articmine 18:22:58 In a nutshell we need to prevent drastic increases in fees 18:23:32 With the current situation if we had say 100x the level of adoption 18:23:36 I think we discussed this last week, triptych multisig requires no conversions or different address formats. The main problem is it requires implementing complicated new crypto https://github.com/monero-project/research-lab/issues/72 18:24:32 although if multisig isn't supported then sending triptych outputs to a multisig address is bad 18:24:35 ArticMine: I'm worried fees are way too low right now honestly 18:24:44 or more. Then a disruption to the Monero network either external or the result of an attack would cause a drastic fee increase 18:25:10 My proposal by the way has a fee icrease about 5x for the min fee 18:25:40 Okay, so getting rid of the current min tier effectively 18:25:55 Yes 18:26:25 So if I can try to summarize changes: 18:26:37 The min fee is set to the minimum fee that support scaling 18:26:52 THere are 3 critical changes 18:26:53 1. Higher initial minimum fee, but lower fee "slope" as transaction counts increase? 18:27:08 Correct 18:27:43 So at 1425000 bytes the min fee equals the current formula 18:28:17 ... but the spam cost is higher 18:28:24 than now 18:28:44 The main consensus changes are 18:29:13 Is that crossover point ~10x increase in transactions compared to now? 18:29:23 (Roughly) 18:29:48 more like 30x or more 18:30:16 Give me a sec 18:30:24 How did you choose the "slope?" 18:30:37 Based on expected market cap? 18:30:59 It follows the minimum fee that allows for scaling 18:31:34 So it follows the inverse square of the long term median 18:32:01 So this is the natural slope 18:32:23 Back to blocksize 18:32:35 You changed a variable though right? 1.4 to 2? 18:32:46 currently the average is about 40k 18:33:11 Yes that is the consensus part 18:33:33 It is needed to allow for the current rate of growth 18:33:49 so the long term median does not fall behind 18:33:57 even at maximum 18:34:06 Here, mostly reading 18:34:19 The other 2 consensus changes are 18:34:26 I'm a little skeptical about the 1.4->2 change in particular 18:34:43 2) putting a floor under the long term median for decay 18:35:24 This is critical 18:35:50 Is there currently no floor? No max rate of decrease? 18:36:03 since we cannot have a long term median that ahs been built up over years falling in just over 2 months 18:36:08 none 18:36:44 the other is making the minimum penalty zone dynamic 18:36:56 by setting it to the long term median 18:37:38 The rate increase from 1.4 to is needed just take a look at the growth in adoption 18:37:52 Okay, I think I am following on how it is dynamic 18:37:58 We cannot stymie Monero like Bitcoin 18:38:54 So there needs to be room on the max growth not be set so tight that say events like 2016 would cause problems 18:39:04 You're allowing the minimum penalty free zone to grow 18:39:10 Yes 18:39:28 The prevents a sharp drop in the short term median 18:39:43 and prevents a sharp increasein fees 18:40:13 Do you have a table where you play this out? 18:40:30 I am not sure 18:40:37 I have soem fe examples 18:40:39 fee 18:40:46 Sure what are those 18:41:20 I am looking at all the way from 300000 bytes to 1500000 bytes 18:41:57 Okay, so with some form of penalty under current circumstances 18:42:32 The penalty formula does not change 18:42:36 Will we have to say bye to our current 0.2 cent fees? 18:42:53 Yes they will become 1 centUSD 18:43:14 but if adoption increase theny can come back 18:43:18 they 18:43:27 But what if we just scale everything down 5x after these changes? 18:43:39 or 4x 18:43:57 The low fee will not scale 18:44:07 just as it does not scale now 18:44:59 You say the penalty formula doesn't change; I don't really get that 18:44:59 but there are many in the community that are concerned about the very low fee especially befroe the network grows 18:45:12 Doesn't it set a new ML so it does indeed change? 18:45:45 The penalty formula applies to the MS / MN 18:46:00 What changes is the penalty free zone 18:46:23 so MN does not fall below ML 18:47:04 much has now MN does not fall below 300000 18:47:26 Once MN is over ML the penalty formula does not change 18:48:21 You mean going from 1.4 to 2 in the rate of growth of ML? 18:48:38 That wasn't what I was referring to, but we can talk about that separately 18:48:58 There is nochange in ML then 18:49:40 The different is that now MN can go below ML and still require penalty 18:50:25 What growth rate is allowed with 2 18:50:41 1.4 to 2 is a pretty large jump 18:50:41 2x over 69 days 18:51:11 vs 1.4x over 69 days 18:51:23 The is maxing every this out 18:51:37 That 18:52:42 So with 2x, looks like a 7.4x allowable increase per year if my math is right 18:52:51 Wait 18:52:56 What was under 1.4 18:53:00 *that 18:53:19 10.6x with 2? 18:53:52 Or does it scale up even faster 18:54:46 5.3 with 1.4 vs 32 with 2 18:54:55 In 2016 we say 10X 18:55:29 What's the math to get 5.3 and 32? 18:55:54 1.4^5 vs 2^5 18:56:18 Got it 18:56:25 For it to work properly it is not run at max 18:56:35 not even close 18:57:24 Why not, say, 1.6? Closer to 10x, and you can still pay more to use the space than the min fee 18:57:53 It would have failed in 2016 18:58:14 It wouldn't have failed, transactions simply would have gotten more expensive for a short term 18:59:06 We would the be relying on the burst capability on ongoing growth 18:59:32 and setting up the stage for the scenario in issue 70 18:59:45 I need to run, but we can continue this conversation later 19:00:19 In any case the place for this is on the githu post 19:00:24 github 19:01:32 not tying up the meetig 19:01:36 meetig 19:01:37 Okay cool 19:01:43 Meeting over :) 19:01:47 Ty ArticMine! 19:02:03 We need to move on to the ring size question 21:03:14 sorry, I needed to run immediately earlier 21:03:20 ArticMine: can you post the logs on github? 21:10:41 I vote for increasing the ring size.