17:45:35 Escrowed marketplace tx have 4 steps: buyer makes purchase order, vendor fulfills it, buyer completes payment (partially signs multisig tx), vendor finishes signing tx to accept payment. There is a huge lag between buyer making a purchase order, and buyer partially signing the payment tx. This means if the list of ring members is chosen at checkout, its age will be obvious to an analyst (the delta vs block 17:45:35 time stamp). However, if the list is chosen at 'completes payment' (the gap would be much smaller, albeit still meaningful depending how fast the vendor 'accepts payment') then this is after the commit-and-reveal step of multisig signing. What I'm concerned about is the security implications of affecting the signature's content after commit-and-reveal. Adding additional steps would be horrible to the UX, so 17:45:35 must we accept the age heuristic, or are my concerns unwarranted? 18:22:57 Of course the fees have to be chosen at 'completes payment', although as long as they are not too granular (add some rounding) there shouldn't be a problem. All signing keys are one time use anyway (or at most ~4 time use in extreme situations). 18:30:13 ArticMine: is there a chance fees could become too volatile since they depend on the short term median? In only 50 blocks the median could fall below the default penalty free zone, and if it was originally 200x that default (hypothetically) then minimum fees will increase 200x over just 2hrs. I imagine many tx would get stuck, not just long-term ones like for a marketplace. 18:33:27 Or would miners start spamming the chain to maintain volume so the short term median doesn't fluctuate? 18:50:19 Oh, maybe in a surge environment only the penalty free zone increases in size, while the penalty zone remains static. To increase the penalty zone, it depends on the long term median. Hmmmm 18:51:16 And fees only depend on long term median (plus rounding, which directly causes a binning effect) 19:00:41 I kind of like this, scale penalty free zone with short term median, and scale penalty zone (and fees) with long term median. Reduces minimum fee fluctuation by a LOT, while still making it costly for the short term median to bounce around so miners will still want to smooth out block weights. 19:02:20 And reflects tx urgency, since in the short term you might need a high fee to push up the short term median, but once it's higher then low priority tx will fit in. 19:10:12 UkoeHB The fees are based upon the effective short and long term medians which cannot go below the penalty free block weight of 300000 bytes 19:11:28 yes imagine the long term median gets to 200x the default penalty free zone, then suddenly short term median collapses back to 300kB 19:13:44 Then the fees are based on 300000 bytes. This is necessary to prevent the short term median from getting stuck 19:14:05 I feel like the long term median should actually be long term average, since if short term median collapses then after 35 days the long term median will abruptly change by a large factor 19:14:21 yes so Im saying scale the penalty free zone by the long term median 19:14:43 and fees as well, so fees always match the penalty zone* (not penalty free zone sorry) 19:15:33 penalty free zone may change in size rapidly, while penalty zone slowly changes as the long term median changes 19:16:24 I feel the assumption transactions are constructed soon before being published is untenable 19:16:49 Fees are currently based upon the penat one only 19:16:54 penalty 19:17:53 Yes, the penalty zone is the same size as penalty free zone currently. Im saying changing the fee algorithm should coincide with changing the penalty zone. 19:18:23 to escape the volatility problem which would make tx get stuck if short term median collapses for some reason 19:18:31 in high adoption scenario 19:20:02 That is why the current fee uses the minimum of the long term and short term medians 19:20:58 Right, so if the long term median gets really big then if short term median suddenly becomes very small, minimum fees will increase substantially. Tx made before the short term median falls will get stuck 19:21:11 The point of including the long term medium in the calculation of fees is to prevent fees from going down not from going up 19:22:15 Even high priority fees will not be enough if the short term median falls enough 19:22:38 e.g. when the volatility is beyond 25x 19:22:56 The Dec 25th scenario 19:23:46 this is more like a catastrophe scenario, when some world event shocks the tx volume into short term free fall 19:24:12 although normal fluctuations could have the same effect idk 19:25:15 Im guessing tx volume suffers around hard forks too 21:40:34 https://github.com/monero-project/research-lab/issues/70 23:22:57 Hi 23:23:01 When were subaddresses enabled? 23:23:07 It's not listed in the changelog at https://github.com/monero-project/monero 23:24:25 https://github.com/monero-project/monero/pull/2056 23:25:47 so probably v6 or v7 23:28:54 v7 23:29:15 Thank you UkoeHB_ 23:29:18 v6 came out in september 2017