07:27:09 Regarding minimum fee binning. We have to e very careful in situations where the minimum fee is rising (both long term and short term medians are falling) with a tx that pays the minimum fee does not get relayed because a node calculats the fee as below the minimum fee. 07:30:10 There is a simple solution to the time stamp issue. Have the wallet calculate the low fee slightly above the minimum fee so that any randomness that is introduced to obfuscate the time stamp still keeps the low fee above the minimum fee 07:31:36 awesome work! 07:31:51 Instead of rounding, think rounding up or binning think binning up 07:32:14 What is the currebt state of evaluating the benefits of different ring sizes? 07:32:23 current* 07:35:39 My take on the time stamp issue is that the fee paid cannot be deterministic so introducing some randomness in the fee paid can help mitigate this. 07:36:49 The idea is to have the distribution for the low fee above the minimum fee so that the minimum fee can still be enforced 07:40:26 Ring size is a trade off between tx size / cost and privacy, in particular when dealing with Alice spends to Eve who in turn spends to Bob and Alice and Bob collude 07:46:48 Sure. but is 10K ring members significantly better protection than 512? or 128? At some pount there are dimimishing returns here. 08:02:17 Also, some of these woukd requite migration to a new output pool if I understand it correctly. Wondering what the practical and privacy implications of thst would be. Is it Like sending from a zec shielded pool to another zec shielded pool? 08:11:41 It comes down to can we keep tx size and verification time comparable to what we have now. 08:13:41 We would have to keep backwards compatibility for existing outputs for any migration 12:16:32 Inge-, the migration doesn't concern me. We did it before when migrating to ringct 12:16:42 i don't remember there being a big hullabaloo then 14:34:37 I guess going from non-ringct to ringct was increase in privacy from the 2nd transaction :)