16:58:45 Meeting in a bit more than 1 hour 18:00:02 Meeting time. Hello! https://github.com/monero-project/meta/issues/1194 18:00:57 *waves* 18:01:13 Hey 18:02:31 Alright, what is there to report from last week? 18:02:34 Inspired by last week's MRL meeting I started to study the daemon's peer selection and management code, but I don't know yet whether I will reach a point where I will be able to code a new algorithm 18:02:48 Howdy 18:03:02 finally managed to make a PR to [monero](https://github.com/monero-project/monero/pull/9915) and [monero-gui](https://github.com/monero-project/monero-gui/pull/4437) 18:03:12 Wow, nice 18:04:17 Let the reviews flow :) 18:05:50 Did code cleanup , bug fixes, and supporting of multiple txs for the Carrot+FCMP CLI `transfer` command : https://github.com/seraphis-migration/monero/pull/32 18:05:59 I plan to do some reviews next, before I start with the next step of my CCS proposal: "replace wallet2 with the Wallet API in simplewallet" 18:06:36 I could advertise the Wallet API a bit some day last week, maybe you saw 18:06:46 Linked to your PR 18:06:59 Spent a good portion of last week hardening an algorithm to calculate weight for FCMP++'s membership proofs, aiming to share details on it today, and rest of this week working with jeffro to get all the outstanding PR's ready to go 18:07:00 yes, thank you for that :) 18:08:13 I can't remember exactly, do we already have our famous loose consensus how many inputs, and how many outputs we will allow for FCMP++ transactions? What did you actually code now, jeffro256 ? 18:09:51 I'd have to go dig up reasoning for it, but the limit we've settled on at the moment 8/8 18:10:15 Nice how you have a tester now with "ComputerPony" 18:10:36 Yeah its really really nice 18:10:45 Original gist: https://gist.github.com/kayabaNerve/dbbadf1f2b0f4e04732fc5ac559745b7 18:10:52 Still trying to figure out the top block mismatch bug 18:11:28 Yeah, the proposal in that gist is indeed 8/8 18:11:59 I guess soon things will be stable enough to allow more people to start with testing 18:12:12 Many community people are unhappy with `MAX_INPUTS = 8`. 18:12:42 Sure, understandable 18:13:14 The last time this was discussed, people at the meeting wanted to wait until we have the optimized code for benchmarking. 18:13:28 Soon it will at least be possible to play around with the count and try higher limits with some reasonable code 18:13:47 I may ask a stupid question but afaik MAX_INPUTS = 8 limit is because of performance requirement. But I also hear that the FCMP++ library is a constant-time implementation, which make sense for construction. Surely a var time one could be used for verification? 18:14:54 i have the assumption that var time is faster than constant time 18:14:56 SyntheticBird: Yes we discussed this for the FCMP crypto competition , but its a huge maintainability burden 18:15:27 I'd say we can re-look at the limit with hardened figures, especially after the optimization contest. Recent tests took my solid ryzen 175ms to verify a membership proof with 8 inputs. That's a long time to get a node doing work 18:16:30 So a block with 100 txs or so could take up to 20 seconds to verify? 18:16:41 IIRC, a node already takes over 1000ms to verify a 143-input RingCT tx, which are allowed on mainnet now. 18:17:06 IIRC, jeffro256 had the comparison benchmarks 18:17:09 Surely tx verification is batch 18:17:13 Yes, but it's not that easy to produce such txs ... 18:17:16 or is that only possible with Curve forests? 18:17:35 (143 input txs) 18:18:16 No, I'd have to re-look at batch verification figures, it scales logarithmically not linearly 18:18:29 Ah, I see. 18:20:38 Allowing 1s verification on a single tx today doesn't sound great to me either. Especially while nodes hold a lock doing that verification 18:22:01 Though the latter could be dealt with 18:22:04 They don't have to hold a lock depending on the design. You could simply copy the root while holding the lock , then verify against that local variable 18:22:59 Maybe some determined and adventurous soul will put up a competing stress net with higher limits to prove a point :) 18:24:01 Alright. jberman , you wanted to give some details about tx weight calculation? 18:25:00 Unfortunately I have a bit more fine-tuning on it, but I can share general goals of the approach 18:26:39 I think a core property we want to maintain for the weight calculation is let's say you want to spend N outputs. There shouldn't be incentive to spend those N outputs across multiple txs, compared to spending them in 1 tx 18:29:30 One 16-member CLSAG takes 4ms to verify on my machine , which doesn't include the balance check, fetching ring member data, or BP+ verification, so 1 second total for a 143 input CLSAG tx sounds within the right ballpark 18:29:55 As long as N <= 8, right 18:30:33 Right (or whatever the max is) 18:31:10 I would disagree IF verifying a 2-in tx plus 1-in tx was all-told cheaper than a single 3-in 18:32:12 Isn't that a bit improbable? 18:33:23 AFAIK, the function of FCMP verification time is roughly affine in the number of inputs. A fixed cost is paid regardless of the number of inputs, then the cost per input is linear: 18:33:24 `f(x) = alpha + beta * x`. 18:34:06 But I don't know how batch verification would change things. But batch verification may not be very relevant for txs in the txpool. Maybe only on initial sync 18:36:06 In my tests, verifying 2-in and 1-in is actually slightly faster than a 3-in, but there are a couple more things to consider here: 18:36:06 1) This creates at least 2 more outputs that would be spent later on and cannot be pruned 18:36:08 2) Taking size into consideration, the byte size of 2-in + 1-in is significantly larger than 3-in (something like 1.8x larger, have to double check) 18:36:32 Not really, Bulletproof-based proofs' verification time is linear to the next highest power of 2 statements that the proof is proving. For example, for our BP+ range proofs, verifying a 3-out is just as expensive as a 4-out. So breaking up a 3-out TX into a 2-out and 1-out reduces total verification time for the range proofs. 18:36:50 Interesting 18:37:16 But FCMPs are a bit more complicated because of the number of layers variable, so they don't necessarily act this way 18:38:28 The number of "statements" for a FCMP is a weird function of the tree depth and input count 18:38:52 So good that soon we will be able to play around with such txs 18:39:47 You can play around sending XMR right now with: https://github.com/seraphis-migration/monero/pull/32 18:39:54 Because of these 2 points, which I believe should both hold for all input combinations, I think it's reasonable to maintain the property that there shouldn't be incentive to spend the same number of outputs (<= max allowed) across multiple txs, compared to spending them in 1 tx 18:40:55 Of course I did not yet look deeper into this, but right now I tend to agree: Filling the blockchain quite a bit faster for a small performance gain does not sound very attractive IMHO 18:41:30 Given that the txs will be a lot larger anyway, right? 18:42:05 right 18:42:34 @jeffro: So current state of the FCMP++ staging repo plus PR 32 enables tests? 18:43:57 What kind of tests do you want to do ? 18:44:22 I mean, that will give a working system? 18:44:42 So I can transact, and try 1 input, 2 input, and so on 18:44:58 Yup! 18:46:32 The CLI transfer command doesn't explicitly allow you to do input selection , but if you wanted to try 3 input time, you could send 3 outputs to account 1 and set your sending account as 1 18:46:40 Maybe I will be crazy enough to try :) 18:46:51 This property doesn't conflict with the suggestion that all txs with the same in/out permutation with the same fee priority level (1-4) should cost the same, right? 18:47:17 I don't recommend connecting it to mainnet though lol 18:47:31 Is that even technically possible? Don't think so 18:48:22 Rucknium: as in all txs with 1-in/2-out and fee priority level 1 should all cost the same (assuming same tx extra also)? 18:48:31 If you edit your hard fork table , you can do anything you want. You'll probably get kicked by your peers though 18:48:36 (as one example) 18:48:48 I see 18:50:09 Yes. And you don't necessarily have to have valid arithmetic properties. Let me try to explain 18:51:43 You can still maintain the "cost the same" requirement even if a 4in/4out does not cost double the fee as a 2in/2out 18:52:24 The fee also depends on the "dynamic fee base estimate" returned by the daemon which IIRC is a function of the mempool state, so probably not 18:53:14 Isn't it a function of recent median block size? 18:53:33 Looking now... 18:54:01 IIRC, the txpool state affects whether an "automatic" fee gets bumped from the cheapest level to the next-cheapest (fixed during the suspected spam attack). 18:54:56 Just focusing in on membership proof weight for a second: any call to the weight calculation will be the same for a given number of inputs 18:55:13 And I think only the most-expensive level is affected by recent median block size. IIRC, it is affected because the most-expensive level is supposed to "pay for itself" by expanding the short-term block limit when the block subsidy is sacrificed 18:55:16 And the property is strictly focused on the membership proof weight 18:55:18 Yes you're right 18:56:16 So, overall, will it probably play out correctly? 18:56:32 To expand on this: the entire tx weight is a function of only three numbers: number of inputs, number of outputs, and tx_extra size 18:56:51 (Proposed for FCMP++, not at the moment) 18:57:13 And the membership proof is by far the largest component of that weight calculation 18:57:47 Simply because of its size in bytes? 18:58:43 If going off just byte size alone even, yes, and this weight calculation is *also* going to take in verification time 18:58:52 similar to how BP's does it 19:02:30 It's ~5kb for a 1-in membership proof, the SAL proof and BP+ are something around ~1kb I believe (have to double check) and then the rest of the tx is going to be a lot less than that 19:03:02 Let `f`, `g`, and `h` be some functions transforming the number of inputs, number of outputs, and tx_extra size. Then, the transaction weight does _not_ necessarily have to be of the form `w(in, out, tx_extra) = f(in) + g(out) + h(tx_extra)`. This would give more flexibility to make sure that the new weight calculation has "the property that there shouldn't be incentive to spend t he same number of outputs (<= max allowed) across multiple txs, compared to spending them in 1 tx". 19:04:11 I am just saying you can think outside the box if needed 19:04:26 I see, true and agree 19:04:56 While still maintaining the same property of same fee for the same in/out/tx_extra arguments. 19:05:47 Ok, I learned, and refreshed, a lot during this meeting. Do we have anything important left to mention for today? 19:07:16 Does not look like it. Thanks everybody for attending, read you again next week! 19:07:32 thanks everyone 19:11:22 In other words, you do not necessarily need the weight function to be additively separable: https://calculus.subwiki.org/wiki/Additively_separable_function 19:11:35 Or we could assert that for all valid values of `out`, `tx_extra`, and for each valid `in_1` < `in_2` that `w(in_2, out, tx_extra) < w(in_1, out, tx_extra) + w(in_2 - in_1, out, tx_extra)` 19:12:48 It's likely feasible to test every single possible combination in a unit test 19:15:09 There's only N=8*7*1600 possible permutations for transaction weight, and I already test monotonicity against each variable for every single value in the unit tests, so we would just need to use the max/min values in the right place and we only need to do 8*N iterations (one for each input value) 19:16:39 That's supposed to be 8 times 7 times 1600, not 871600 btw, formatting messup 19:29:40 There's one other property I've been mulling over and not sure if we really need it: making sure that as n inputs increase, the membership proof weight increases as well 19:29:55 The core benefit is that it's mentally easier to model. Users might be confused seeing a tx with more inputs having a lower weight 19:30:17 I can't think of a better reason that txs *must* maintain this property 19:30:31 It's also worth noting that membership proof sizes actually can decrease as inputs increase depending on size of the tree, so the proofs do inherently have this property on the size front (I haven't observed this for verification time) 19:31:00 the proofs do *not have this property on the size front