03:53:09 I'm not sure I can attend the next meeting in its entirety, but in case unlock_time ignoring will come up as a discussion item (not saying it should), I wrote up my thoughts here: https://github.com/monero-project/research-lab/issues/125#issuecomment-2487284037 14:54:02 chaser: I removed unlock time from this week's agenda, but it can be discussed if desired. 14:54:17 MRL meeting in this room in two hours. 15:28:11 Sorry, I will be on a plane today and cannot attend the meeting ;( . I don't really have anything to comment except that the pyramids in Teotihuacán were definitely worth visiting 17:00:40 Rucknium: only desired if other items allow time for it. 17:00:53 Meeting time! https://github.com/monero-project/meta/issues/1112 17:01:01 1) Greetings 17:01:10 hello 17:01:11 Hi 17:01:14 Hello 17:01:30 hi 17:01:37 Howdy 17:01:47 <0​xfffc:monero.social> Hi everyone 17:03:14 2) Updates. What is everyone working on? 17:04:05 me: I put up a docs website for my `xmrpeers` R package: https://rucknium.github.io/xmrpeers/reference/index.html . The txpool archiver now stores key images, too, so it is easier to retrospectively measure intentional or unintentional double spend attempts. 17:04:35 finished up span changes in monerod, working on merging PRs in LWS, and frontend for LWS 17:05:24 My Monerotopia talk "Hard Data on Banking the Unbanked through Cryptocurrency" is up: https://vimeo.com/1029005523 https://github.com/Rucknium/presentations/blob/main/Rucknium-Monerotopia-2024-Banking-the-Unbanked.pdf . Thanks to xenumonero for voicing it. To answer the question from last time, the estimated aggregate spending on goods and services in the EU in 2022 using cryptoc urrency was €4.1 billion. (90% confidence interval: €1.7 to €6.6 billion). 17:06:34 Scaling changes to support FCMP++ One the questions I am looking at are changes in TX size when an additional layer is added to the FCMP++ 17:07:38 Two CCS proposal that we have discussed are now on the Ideas page: "Audit monero-serai and monero-wallet" https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/518 and "Gingeropolous 1TB MRC upgrade" https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/516 17:07:38 Declare your thoughts with your thumbs. 17:09:13 Someone brought up an interesting question at the conference: FCMP++ unifies all anonymity pools, including pre-RingCT. How much money is actually tied up in unspent pre-RingCT outputs? I believe we can actually answer this question with 0 uncertainty if take the sum of "amount*(num_outs_of_amount-num_rings_of_amount)" for each amount. This is because previously, we only allowed r ings to contain inputs of equal amount 17:09:54 Can anyone see a problem with this approach? I'll work on a script today that calculates it just for fun 17:10:16 Hello 17:10:36 Hi sgp 17:10:46 *waves* 17:11:07 Sorry I might be a sporadically available dealing with a personal issue atm 17:11:48 jeffro256: I don't know enough about how the pre-RCT protocol works, but your idea sounds very interesting. 17:12:39 Usually my first step when building the Monero tx database is to delete pre-RingCT data :D 17:14:55 Regarding the CCS proposals, since multiple researchers have need for higher compute requirements, I'm totally okay with the 1TB upgrade CCS 17:15:33 jeffro256: This should be doable with zero error. I also believe it is important to preserve the pre-ring CT block chain data and to make it easily available to the public in order to not give the blockchain surveillance companies an advantage 17:15:59 3) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS 17:16:00 https://gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898 https://github.com/monero-project/research-lab/issues/100#issuecomment-2433524326 17:16:26 Is kayabanerve available for this agenda item? 17:18:41 Anyone else have thoughts about introducing a MAX_INPUTS limit and/or changes to the current MAX_OUTPUTS limit, with the FCMP++ hard fork activation? 17:20:30 I'm generally in favor of any of the limits (except 2/2) in order to increase tx uniformity 17:21:21 I defer to kayaba's analysis and opinion on this 17:21:50 Good thing I have these typing notifications, or I would have moved on to the next item already :P 17:22:20 I actually did this at one point, could dig it out again, I remember there been quite a bit still there 17:22:57 4) Making transaction weight a function of number of inputs, outputs, and `tx_extra` length instead of number of bytes. 17:24:39 IMHO, the protocol currently already has an implicit tradeoff value between verification time and tx size because of the Bulletproofs clawback. Does anyone know of any meeting logs or anything where the tradeoff was discussed? 17:24:42 My preference with this is to eliminate TX weight entirely out of consensus 17:25:19 This should be addressed if needed at the node relay level 17:26:23 It is redundant especially with the proposed input and output proposals 17:26:55 I was by the way involved in the tx weight department 17:27:10 Development 17:27:15 Doesn't consensus need some concept of tx weight to decide how much of the tail emission is not emitted when a miner mines a block above the aggregate penalty weight? 17:28:10 We just use the actual transaction size in bytes 17:28:40 No need to add an additional weight for verification time 17:29:20 The latter was the idea behind the tx weight s 17:29:40 Verification time would still not directly be related to transaction size though right? 17:29:41 Note that this would break economically if the transaction format ended up being malleable 17:30:46 If the concern is a possible attack this can be dealt with by node relay 17:31:12 Consensus seems like a far preferable way to address this to me 17:31:34 For the potential malleability issue, I think you can just set a safeguard limit on tx size with respect to the input/output/tx_extra size 17:33:10 And then we end up hitting arbitrary limits during the next stressnet ;) 17:33:27 With the proposed limitations in numbers of inputs and outputs 4 maybe 8 or 16. I really do not see the point 17:34:08 It just adds un necessary complexity to consensus 17:34:43 ... and the potential for bugs 17:35:15 I think jeffro256 means "malleable" as if the tx fee is set by the number of inputs and outputs, and someone figures out how to pack more data into the input or outputs than expected, then tx size could be very large. A little like Ordinals getting a discount on data when putting it in the SegWit part of BTC blocks. 17:36:10 Yes 17:36:18 Malleable was the wrong word 17:36:40 But we have a consensus limit on the number of inputs and outputs to certain discreet values 17:36:43 I'm for skipping unnecessary complexity, but my understanding is that verification time cost can still be detached from size by a meaningful amount 17:36:59 If the tx fee is set by number of bytes, it will be much easier for an adversary to guess which wallet software constructed each tx because wallet developers do not exactly match the reference software fee algorithm. 17:37:13 I'm wading through kayaba's writings in search for the right numbers to compare 17:38:04 Weights does not help with this 17:39:19 The reason this was introduced is that at the time there was a choice between 1 and 16 outpouts 17:40:36 Now the choice could at most between 4 and 16 outputs 17:41:13 With no other choices in-between 17:41:18 My suggestion is not to go with weights, as they exist today. But to set tx fees as a function of inputs, outputs, and tx_extra length. Two txs with the same ins/outs and tx_extra today can have different tx weights because the number of bytes is different, by chance. 17:41:22 The reason kayaba recommended the specific multiplier in the transaction is to enforce specific fees, in this proposal per the weight. In theory it could be against size as ArticMine wants, afaict 17:43:43 Maybe we need data on how different verification time is versus size for various transaction combinations before making a decision. Kayaba may have already done that but it's hard for me to read. If there's a single digit % difference then I lean ArticMine's way of simplicity 17:44:33 Fees belong in node relay., and outside of consensus 17:45:36 Not sure I understand. Then somebody can mine themselves a tx with any fee? 17:45:40 then a miner could still “stuff” a longer to verify tx in a block? I don’t see anything wrong with doing it at both levels 17:47:06 The miner can always do this by providing an off chain rebate or recruiting an off chain payment 17:48:21 This is why fees must never be baked into consensus 17:48:34 Yeah but this would allow a discernable on-chain, publicly-visible mark on transactions. Isn't that something we should at least try to make more difficult? 17:49:23 The goal isn't to prevent miner fee sillyness (off chain dealing etc), it's transaction uniformity 17:50:21 This issue is and can be addressed by node relay 17:50:24 Consensus is baked into fees, I guess. The consensus rules on block size increase are activated by the interaction of fees and miners' self-interest. So the fees have to be set with the consensus rules in mind. 17:50:45 Yes of course 17:51:35 ... but the fees have also to keep in mind the free market 17:51:42 consensus would require the majority of miners to agree to stupid fees; it would not allow a specific rogue miner to act stupidly like relay would do 17:53:01 Fees can become really stupid over time 17:53:32 Look, I might be in the minority here, but I'm much much less worried about uniformity with FCMP++ since now the EXTERNAL impact is very much mitigated. It used to be that weird fees cause everyone's privacy to suffer, but that largely is less true anymore. We should start focusing on UX (off chain reimbursements in this case) when considering tradeoffs IMHO. A relay rule would p revent silly mistakes for people who aren't colliding with miners 17:54:29 I agree 17:54:41 Tho I do agree that vtnerd's point is valid : adding heavy txs would basically be free to a miner, but cause a lot of network load if fees aren't asserted at consensus 17:55:52 ...but we do have and will have consensus rules on the number of inputs and outputs 17:57:06 We can also limit the size of discretionary fields at consensus 17:57:24 I guess that's not a NEW concern: spam is free up to the penalty-free zone limit. It's just that that 300KB can be packed with more compute requirements 17:58:13 the only cost before then is opportunity cost, consensus rule or no 17:59:04 jeffro256: "I'm much much less worried about uniformity with FCMP++ since now the EXTERNAL impact is very much mitigated." I agree with this. IMHO, you can group a lot of de-anonymization "heuristics" into a class of "set intersection attacks". The ring size 16 is a set. Then you intersect that with the set of nonstandard fees. Then other sets if you have the data on it. The origi nal ring size 16 makes the other set intersection operations much more powerful for an adversary. With FCMP, that initial set size is they whole chain. On the other hand, having as much tx uniformity as possible (especially to prevent against attacks that no one has anticipated yet) is a good goal IMHO. 18:00:19 And IP address is a set, by the way 18:00:37 Yes uniformity is always a good thing, but you've also got to factor in the difference in the size of the total FCMP set if you bring in more people because of enabled use cases , UX, etc 18:00:39 So you combine the nonstandard fee with the probable IP origin of a tx. 18:01:59 I don't understand the UX issue involved here 18:02:52 UX would be an issue only if terrible multipliers were chosen imo. Eg if moving up to the next tier costs 100x more 18:03:48 The interaction of the fee tiers, users' economic behavior, and the block size adjustment algorithm is quite untested IMHO. 18:04:38 Literally untested on mainnet until this year with March spam. A patch to wallet2 had to be released to get the wallet fees to automatically increase 18:05:08 Wonder how an approach to test that could look, with user behavior in there ... 18:05:48 You could estimate some demand curves from behavior on other chains, probably 18:05:49 There is some limited information from early 2017, and also from some of the times that we have gone over the penalty free zone 18:07:03 What I have seen in those cases is that users have not responded to the market efficiantly 18:07:35 IIRC, this paper does some empirical demand estimation on BTC: Huberman, G., Leshno, J. D., & Moallemi, C. (2021). Monopoly without a Monopolist: An Economic Analysis of the Bitcoin Payment System, The Review of Economic Studies, 88(6), 3011–3040. https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=78 18:07:36 They for example tend to pay a fee that is too low 18:07:38 imo we have two real options. Pick sane multipliers and strongly enforce, or decide to allow truly arbitrary fees like Bitcoin 18:08:14 Picking multipliers and then weakly enforcing seems like the worst of both worlds imo 18:09:34 Any fee multiplayer enforcement has to be at node relay and not at consensus 18:09:47 Apologies. I'm off by about an hour. That's on me. 18:10:48 That's not true though right? Kayaba demonstrated how you can do at consensus right? Are you speaking about a miner reimbursing out of band which is a different problem with different considerations? 18:11:33 I think people pick a fee that is too low since they don't know that the txpool is congested. They just expect it not to be, as it almost always is like that. The auto fee increase in the patch this year helped a little with that. 18:13:11 My argument was for the fee per weight to be embedded in the TX, not the fee. In order for the TX to balance, the wallet must correctly calculate the TX weight. 18:13:13 It can be done at consensus. It is not a good idea, because a miner can always circumvent off chain. This then can lead to centralized control 18:13:24 Sorry y'all , I have to dip out for the time being, but will catch up on the chats later. Thanks everyone for participating 18:13:49 We can still, at node relay rules, penalize specific TX patterns and demand they require a higher fee rate. 18:13:54 Of course, the question with the auto fee increase is how high should it go? IIRC, right now it moves from the first to the second tier, and doesn't go higher unless manually changed by the user. 18:14:18 But forcing wallets to calculate the weight correctly should prevent them from being non-uniform with weight calculation. 18:15:21 My proposal is to simply use the physical size in bytes of the tx and eliminate any weights 18:16:56 KISS in consensus 18:17:12 That isn't inherently incompatible with my proposal. 18:17:30 I think it's wrong though as it harms certain functionality and is annoyingly complicated. 18:17:55 If we define a simplified weight formula, we never have the annoyance of what a varint is in practice. 18:18:07 That's where wallets are currently being wrong, causing fingerprinting issues. 18:18:25 What we are doing is not trying to price verification time 18:19:05 It also harms pre-signed TXs (transaction chaining). If I sign a TX now, and go to publish it in a year, and the tree has grown a layer, I'll have signed a TX for byte length X and it'll now be byte length Y. 18:19:26 This is appropriate if we limit the numbers it inputs and outputs 18:19:32 By using a simplified weight formula dependent on input/output count, we become agnostic to how big the membership proof is in practice. 18:20:21 I'd agree if we did 4/4 and transaction uniformity. I disagree if we allow 16 outputs. That justifies a clawback existing, as we have now, IMO. 18:20:37 *I'd agree we don't have to price verification time 18:21:06 Thanks kayaba this is helpful 18:21:19 I still think weight shouldn't equal bytes due to the pre-signing usecase I mentioned and the complexities of calculating TX size ahead of time 18:22:39 Yes this is a serious issue. The fee has to remain the same after a layer change 18:23:10 Since a layer change always increases the amount of bytes, that requires we pay by input count or prefix size, not by TX size. 18:23:50 Prefix size should be a valid alternative but it is a really really broad thing to do as it makes inputs as expensive as outputs, when by verification time, it's no where close. 18:24:34 Speaking of KISS, is there a reason _not_ to use powers of 2 as the allowed multipliers? And to set the default fee selection logic to be in effect "pick the lowest power of 2 that's likely to get me into the next block" 18:25:25 We are twenty-five minutes over the hour. We can end the meeting time here, but feel free to continue discussing. Maybe someone could make a `research-lab` issue about it. We didn't get to the "Preventing P2P proxy nodes" item today, but we can get to it next meeting. 18:26:40 There are two ways of doing this. One is to normalize the proof size by using weights to the initial number of layers. So the transaction weight does not change. The other is to change the minimum penalty free zone size. 18:26:40 I really do like weighting the proof size to the initial number of layers 18:26:42 The larger the multiplier differences, the greater the incentive there is to work with a mining pool on a fee rebate etc 18:27:56 sgp_: AFAIK, two potential issues with that: 1) We don't know how well block size auctions actually work with just discrete bids allowed. Right now the 4-tiers are just a wallet convention, but wallets software can be changed easier than consensus rules. 2) If fees are discrete but weight is not, then users who happen to have a high tx weight (but the same fee as others) will be s tuck at the back of the confirmation queue for a long time. Maybe until the txpool empties completely. 18:29:33 So yes using a fixed weight instead of the actual size for the proof size would be the most elegant way to deal with the proof Bauer issue 18:29:35 Miners are given a block weight to fill though right? Not a true, byte block size? 18:29:49 Correct 18:29:51 Right now the default block template creation behavior is first-in/first-out for txs on the same fee-per-weight tier 18:31:06 since the fee per weight is the same, and miners pick (by default) for fee per weight, I don't quite get the back of the queue issue 18:32:16 AFAIK, the raw fee in Seraphis was supposed to be an exponential power. That does not get you discrete fee-per-weight since weight is basically continuous. 18:32:49 So you would have to define the discrete fee as fee-per-weight, not the raw fee. 18:33:21 AFAIK, the Seraphis fee _field_ in the tx was supposed to be an exponential power. 18:33:50 that's similar to what we are discussing here, right? Defining the fee per weight (the multiplier) in the tx. And I'm suggesting specifying a power of 2 in there 18:35:52 IIRC, txs do not say what their size nor weight is. You have to calculate that "manually". So you would have to change how that is handled in the data that txs carry. 18:39:19 ArticMine: Then we're back at not using TX size yet a formula dependent on the amount of inputs, outputs, and length of TX extra 😅 18:39:59 Because we're proposing using input_proof_base_cost * inputs instead of those actual proof sizes. 18:40:35 It doesn't have to be a complicated and long formula. I just wanted something better defined than 'build and test serialize a TX and also know how to handle XYZ variable length fields properly'. 18:41:03 If we define all the constants in the formula to be the byte lengths seen within a TX, that's still a massive step up. 18:41:51 What we could do is set a fixed weight for the transaction excluding any discretionary fields based upon the number of inputs and outputs. This weight would be used instead of the proof and non discretionary fields size. In determining the TX weight . I would leave any discretionary fields if they are allowed outside of this calculation. 18:42:12 input_proof_base_cost + (input_ additional_cost * inputs) + output_proof_base_cost + (output_additional_cost * outputs) + tx_extra_len 18:42:27 Where cost can simply be the byte length expected for such items 18:43:13 As long as we define actual constants, and the only variables are inputs/outputs/length of TX extra, I'd be significantly happier. 18:43:25 Yes based upon the initial proposed number of layers in the proofs 18:44:06 This will also make me much happier 18:44:22 Cool 18:44:51 As of right now, fee, decoy selection, is in the way. 18:45:04 Even after FCMP++, the reference block and associated tree will be in the way. 18:46:25 *the fee field is a varint meaning calculation of the fee itself affects the fee as the calculated fee may have a distinct length than used in the calculation 18:47:23 What I see is that we need defined weights for each allowed combination of inputs and outputs and any other required fields 18:49:16 Tx extra if allowed would also have to have defined limits in bytes 18:50:33 So this effectively makes transaction weights discreet at consensus, which is fine 18:51:13 ... and solves the layer issue on scaling 18:52:57 So all I would need is the proposed weight of a 4 in 4 out tx with no additional discretionary fields. 18:54:23 ... and the appropriate estimated actual size with the initial number of layers in the proofs 19:06:27 If we have discrete tx weights then we have discrete fees at each fee level 19:09:50 https://github.com/kayabaNerve/fcmp-plus-plus/blob/develop/crypto%2Ffcmps%2Fsrc%2Flib.rs#L127 19:09:50 This code exists for the FCMP itself (which is not the entire set of FCMP++ proofs).