13:56:23 https://github.com/monero-project/monero/blob/master/src/wallet/wallet_rpc_server.cpp#L71 13:56:23 When will multisig wallet loose it’s ‘experimental feature’ status? Are there still many known bugs or is it secure already? 14:32:46 #monero:monero.social 14:34:01 ofrnxmr[m]: Do you mean it’s better to ask the question there? 14:34:01 Yes 14:34:07 Thanks 14:35:01 Not to leave a question unabswered: It will be removed after multisig has gone through a full security analysis 14:38:37 ofrnxmr[m]: Is there a ongoing audit ? 14:40:27 Nope 16:00:34 I cant make it to today's meeting but from my side I started working in a transaction history component (drafted some basic ideas and started implementing it) and opened a [CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/377). The plan is to build this component and integrate the knowledge proofs into the wallet using half of the time of the proposed CCS. The other half I would be working on 16:00:34 building necessary functions that needs to be done after discussing it in the #no-wallet-left-behind channel. I thank you for your comments. 16:17:17 Meeting .75hr 16:54:54 Shoot, I’m getting pulled into another meeting at the top of the hour. I may be able to drop into the MRL meeting later. Only two quick notes from my end: 16:54:58 (1) Geometry Labs produced a small workflow demo codebase showing how to connect R to C++, as part of gearing up to potentially contribute to OSPEAD computations. I will be chatting with Ruck about iterating the workflow and planned roadmap. We can skip talking about CCS today, as these discussions are ongoing and I’ll be updating the proposal. 16:55:15 (2) If tx_extra comes up, just want to reiterate my stance concisely: In the long run I will support any solution where the consensus rules / protocol / format results in a single anonymity pool of uniformly indistinguishable transaction. This includes, but is not limited to: 16:55:15 - removing tx_extra (in which case Monero’s scope is narrowed to store and transfer of value, i.e.making xmr just be a currency with no bells and whistles) 16:55:15 - a fixed-length encrypted field with consensus enforcement 16:55:15 (of course when I say “tx_extra” what I mean is not the literal field, but rather having a field designed for arbitrary data blobs) 16:55:15 Also, I am OK with relay rules as short-term measures, but never as a long-term replacement for consensus rules. 17:00:44 meeting time https://github.com/monero-project/meta/issues/803 17:00:45 1. greetings 17:00:45 hello 17:00:48 Hi 17:00:53 Hello 17:01:04 Hello. 17:02:10 Hi 17:04:04 2. updates, what's everyone working on? 17:06:43 I posted a few updates about the new curve cycles, there are a few options available: https://github.com/monero-project/research-lab/issues/100 17:07:09 Hi 17:07:57 Sent C++ test for R wrappers to isthmus. The returned code passed the tests. Exceeded expectations, in fact. Writing R code to gather ring data by RPC. Spent my allocated 8 hours on researching possible statistical tests of encrypted tx_extra contents. Made some progress on that, but not as much as I would have liked. 17:08:45 me: I merged dangerousfreedom's draft of seraphis knowledge proofs to seraphis_lib and updated it to production quality. Now I'm working on refactoring enote scanning into a state machine that will be more flexible/reusable in the long run. After this and further refactoring to use block checkpoints, I will work on the seraphis paper. 17:11:29 3. discussion, we are slated to discuss tx_extra some more today 17:12:39 Did any discussions happen between last meeting and this one? I didn't see any 17:12:41 Can we narrow down tx extra to A or B3? 17:12:56 Well, discussions went on right after the meeting 17:13:28 as a reminder, here is the choice matrix: 17:13:28 A) [remove tx extra]: tx utility flexibility tied to hardfork (or steganography) 17:13:28 B) [keep tx extra in some optimized form]: uniformity and scaling trade-offs depending on the solution 17:13:29 1) leave as unlimited-size TLV field 17:13:29 2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) (option: encrypted by default) 17:13:29 3) mandate optional fixed-length tx extra size + encrypt by default 17:13:29 4) mandate fixed-length tx extra for all txs + encrypt by default 17:13:30 5) other 17:14:16 Can we just go ahead and vote. I vote for A. Get rid of it. 17:15:06 I prefer a vote to narrow down to A or B3 first 17:15:06 B3 sounds like a good compromise 17:15:10 With the few people here? That's a bit optimistic. We could vote, but the vote would probably get ignored ... 17:15:17 A means removing it for regular transactions, not for coinbase? 17:15:18 I see this problem as being a conflict between three of Monero's core design goals: privacy, scalability, and longevity. 17:15:29 sech1: yes, coinbase would keep it 17:15:35 A in the long term, B3 short term 17:15:53 B3 gives only 2 anonymity puddles 17:16:08 What is "long term" for you, sech1? 17:16:15 Seraphis fork 17:16:27 This decision is for the Seraphis fork. 17:16:33 then A 17:16:47 but if A, we need to gather all current uses of tx_extra 17:16:50 from all parties 17:17:08 Pre-Seraphis, we have this: https://github.com/monero-project/monero/pull/8733 17:17:25 B3 would also probably need to gather all uses of tx_extra as some may exceed the fixed-length that B3 would install 17:17:51 UkoeHB: Isn't it Security, Privacy, and Decentralization? https://www.getmonero.org/resources/about/ 17:17:53 B3 256 bytes 17:17:58 We had 256 bytes on the table. Is something important known that would not fit? 17:18:40 Because I would, so far, gladly agree to narrow down to A versus B3 256 bytes for a vote 17:18:42 A means a permanent increase in the chance of future hardforks - increased power of the core team. 17:19:09 Rucknium[m]: decentralization isn't really a property 17:19:17 it's just a fancy word that sounds good 17:19:37 the goal of 'decentralization' is longevity 17:19:37 We can vote for A or B3 256 Now Then announce the final vote between A and B3 256 17:19:41 B3 would also remove the ability for public data fwiw, which ew have now. Like "add this hash of some timestamped data". 17:20:18 Well, any such "public" service could publish their fixed key? 17:20:24 Does it affect atomic swaps in any way? Or Seraphis will fix it in another way? 17:20:35 No. You can have longevity with a totally centralized system. They're orthogonal. 17:21:05 AFAIK none of the atomic swap protocols for Monero need tx_extra. 17:21:14 good 17:21:20 rbrunner: may be hard to say, but for example this is a tx coming out of a CEX, where tx_extra has 323 bytes: https://localmonero.co/blocks/search/06b4837aaebf9c9dc011cf4ad8c51463d0f6715337f01fef9b4833bf12bedca2 17:21:38 By the way, I was brainstorming about a vote not in a particular meeting, but in a GitHub issue during one week, say 17:22:18 hbs[m]: this is due to the tx public keys, there are no extra data in that tx. 17:22:22 Because meetings tend to have attendance problems 17:22:22 We have to narrow this down first 17:22:39 Of course 17:22:52 "where tx_extra has 323 bytes" <- I think it's because of additional pubkeys (one per output) 17:23:01 they can be moved to a dedicated tx field 17:23:12 They are, in Seraphis, no? 17:23:19 tevador: Ok then, thanks for clarifying, I had not checkd the actual content, just checked the size. 17:23:44 Yes, Seraphis already separates tx pubkeys. tx_extra would be only for "extra" data then. 17:24:17 So we can maybe vote today what exactly we put up for a vote? 17:24:19 #define TX_EXTRA_MYSTERIOUS_MINERGATE_TAG 0xDE 17:24:25 the only thing I found about actual usage :D 17:24:34 coming from scam pool minergate 17:24:35 rbrunner: Yes 17:25:11 Something like a first derivative :) 17:25:32 Maybe we can agree that the options are A or B3. If we advertise the next meeting on reddit, hopefully more people will come. 17:25:32 I like B3 because it is an incremental improvement in privacy and longevity, and only a minor regression for scalability. The other options are more significant regressions in at least one property (other than 'do nothing'). 17:25:39 I propose A or B3 256 17:25:44 Good lord, reddit... 17:26:02 Do we have a clear plan for implementation of B3 256? Has monerod ever changed the criteria for relaying transactions outside of a hard fork? 17:26:09 Im solidly in group A 17:26:09 Perhaps should be noted that wownero HF's to 1kb limit soon 17:26:27 You can only vote today what we put up for a vote, seems to me 17:26:51 Well, we haven't yet voted whether there should be a vote. 17:27:02 I second ArticMine's A or B3 256 as the only two options to vote on 17:27:09 I do too. 17:27:10 B3 is my choice as well 17:27:10 For the update, I'm trying to make more tests to reveal more bugs in my code. I think it is ok. Will commit and push in the coming days for another round of reviews from koe 17:27:25 Rucknium[m]: we have PR #8733 17:27:27 I would expect that we would have a leaky sieve: many old version nodes would allow those tx. If the tx gets to a miner who is running an old version node, then the relay rules are ineffective 17:28:05 Voting whether having a vote is a bit circular ... 17:28:16 Rucknium[m]: there is not a concrete design for B3 yet, it would require some discussion. 17:28:24 A or B3 will be implemented with Seraphis, which is a mnadatory hard fork. 17:29:01 rbrunner: Being like the US system lol 17:29:02 It narrows down the debate 17:29:20 If we have, by any chance, an earlier hardfork still, we could introduce even earlier, if somebody goes the extra mile to modify the old tx format 17:29:27 It would be nice to see less discussion about voting and more focus on design goals/philosophy. 17:29:43 +1 koe 17:30:34 I am pretty sure that an analysis would show we have pretty much the same goals, but weight them differently, hence the long standstill 17:30:56 Because goals conflict in this case as I understand them 17:31:04 can't analyze comments that don't exist 17:31:26 I just do not see consensus possible for any other options 17:32:02 So we can narrow the field 17:32:52 A/B3 , can we agree that these are the goals? And progress from there 17:33:03 I'd rather have a consensus on the reasons for making a choice, than force a decision to be made. 17:34:11 Does anyone favor any other B apart from B3? 17:35:22 the people in favor of other options are not in this meeting 17:36:12 https://libera.monerologs.net/monero-research-lab/20230215#c205874 17:37:11 Hmm, looks like it 17:38:11 Rene appears to be the only one who did not have a vote for a or b3 17:38:21 I see 3 people there who did not specify either A or B3. 17:38:49 Yes, back then. I can easily compromise on B3 256, and would agree to vote on that. 17:38:49 + "unwanted" and "blank" 17:38:58 Out of how many? 17:39:43 At least 20 17:39:46 tevador: thanks, I missed those 👍 17:40:08 So really like American politics? First round of voting with *all* options, open for 1 week, second round with the two top voted from the first round? 17:40:37 If we declare this meeting as not complete enough to decide what to vote on ... 17:41:12 I think the support for anything other than A or B3 is not there. We can narrow it down to A or B=B3. 17:41:43 tevador: That is my point 17:44:44 Now, the resident Core Team member could throw in his authority and announce a vote A versus B3 ... ? 17:45:41 In some way to discuss further 17:46:51 We can open a MRL issue with these two choices and schedule the final decision for the next meeting. 17:47:16 I think this whole thing is good evidence that being unable to operate without core is not healthy for the project in the long run. 17:48:18 This is not a core team issue 17:48:54 Maybe, but I think we still compare quite favorably with other projects. We don't routinely bumb into such difficult decisions like this one 17:49:03 *bump 17:49:12 We should be able as a group to narrow this down 17:49:49 Well, we don't miss much right now. Still nobody explicitely spoke out against putting up that vote. 17:50:00 being able to operate without centralized decision making * there 17:50:23 We could roll a d20. 17:50:56 The last digit of the hash of the next XMR block decides. 17:54:05 Come on, give yourself a jolt, if enough people agree on that vote, we have at least something :) 17:55:15 I remain more interested in design philosophy than voting. 17:55:36 I agree that A and B3 seem to be the best ones to choose from. Whether a vote is the best idea though, not sure. 17:56:10 The least bad idea? To break out of a 2 year checkmate situation? 17:56:13 UkoeHB: I see that question as flexibility without a hard fork 17:56:26 ArticMine[m]: yes 17:56:33 So let's open an issue for it, narrowed down to A or B(3). Some arguments for each choice will be gathered for the next meeting. 17:57:36 I support tevador 's plan 17:57:44 I understand UkoeHB interest in design philosophy, but frankly, I am afraid such discussion would be even more difficult 17:58:16 Btw, we can still have a soft fork with option A. It has been discussed before. 17:58:18 that just sounds lazy, we should not make decisions out of laziness 17:58:40 How does narrowing down the vote preclude the philosophy question 17:59:22 it's mostly a distraction, since philosophy logically precedes choice 17:59:34 notice how we wasted 40 minutes 'narrowing it down' 17:59:38 I guess UkoeHB thinks that the "right" philosophy would naturally decide the tx_extra question 18:00:56 We are at the end of the hour, so I'll call it here. We can tentatively narrow the choices to A/B3 pending further direction changes. 18:01:02 Well, I think this meeting was more than just a waste of time. If we really put up that issue, that is. 18:01:10 next meeting let's try to have more concrete arguments 18:01:13 thanks everyone 18:01:24 The fact that this has been open for 3 years proves that it's not something that has an easy "natural" answer. 18:01:41 I don't think we will be able to agree on that :) 18:01:52 (That 3 years "prove" something.) 18:04:09 rbrunner: What is the "natural" answer then? If you seem to think there is one. 18:05:18 Not exactly. I think we are in a messy situation, because humans, and that the way out is, unfortunately, a primitive vote 18:05:48 Some notes on using statistical tests to exclude non-encrypted tx_extra contents: 18:05:57 If we start to discuss overarching design goals, we get into each other's hair about *those* 18:05:59 The statistical power of a test is one minus the probability of type II error. Type II error is the probability of failing to reject the null hypothesis when the null hypothesis should be rejected. It's a false negative, basically. Many factors determine the power of a test, including the contents of the data itself. We would want the test(s) with the highest power. 18:06:06 how much space would B3 allow for? 18:06:16 A simple standard test for uniform randomness of discrete items is the chi-squared test. It only tests the _proportions_ of random items. If we test at the bit level, a chi-squared test would just evaluate the proportions of 1's and 0's. This test has low power because it does not evaluate the _sequence_ of bits. For example, "00001111" has a clear sequential structure, but an equal number of ones and zeros and would easily pass 18:06:16 a chi-squared test. 18:06:21 I tried the chi-squared test on isthmus's tx_extra list here: https://github.com/monero-project/monero/issues/6668#issuecomment-670978771 . I converted the data into bits. At the 5% level of significance, it only rejected about 30% of the tx_extra contents as non-random. 18:06:31 ASCII characters have a clear sequential structure since the last bit of the byte is 0. File types like jpeg also tend to have a sequential structure. Compressed files may have a sequential structure sometimes (need to investigate further). More thorough tests of cryptographic randomness of sequences try to detect non-randomness in the sequential structure. 18:06:43 Here is where my research time expired. These more powerful tests do not have many easy-to-use implementations. And generally you need to give them some specific parameters that I don't fully understand. Some of the tests that I am looking at include: binary matrix rank test, book stack test, birthday spacings test. They tend to target cyclical non-randomness, which is what we would expect with ASCII, jpegs, and other file 18:06:43 format. 18:16:51 Interesting thanks Rucknium[m] 19:07:17 moneromooo: to me, longevity means persistence (long-lived) and consistency (continuing to satisfy the same invariants/promises over time). A centralized organization has the inherent *potential* to break longevity, even if it doesn't in practice. Since there is no way to know in advance if a centralized project will break longevity, decentralization is seen as a more effective strategy. 19:10:51 M7in[m]: probably 128-256 bytes per tx output 19:11:22 Did you encounter interesting examples in history that illustrate that, or is this more a result of logical reasoning? 19:12:53 Interesting that you mention "per tx output". I assumed, maybe wrongly so, fixed 256 bytes, period, independently of the number of outputs. 19:12:55 so-called constitutional republics are prime examples of broken promises 19:13:15 if it's encrypted, it has to be encrypted for someone to read 19:14:30 Yeah, but for example a DEX could use a single key for all tx_extra entries of transactions that go in and out. Doesn't have to mean encrypted per receiver. 19:14:31 wasn't there some monero fork that just recently announced it was watering down its privacy? 19:15:12 Not sure, there are not that many left as far as I know 19:16:05 rbrunner: that's not a generic solution 19:17:45 Anyway, with 256 bytes *per output* I easily make a 16-out tx, giving me room for my highly problematic 4 KB JPEG. That's no limit, man :) 19:17:57 The field could probably be bimodal. Either encrypted at 128 bytes per-output (for example) or the entire field encrypted with a custom scheme. When a user decrypts their enote's extra field, if the decrypted bytes don't conform to TLV format then the field is ignored. 19:18:19 Sorry for late response: group A 19:18:37 I was also assuming global, as currently. Per output optional means you leak more than one bit. 19:18:54 It's more adaptable though. 19:18:55 moneromooo: it would be either all outputs get a field or none 19:19:43 OK, seems fair given the high prevalence of 2 out txes. 19:20:05 rbrunner: ok, and where does your argument fit into the design philosophy framework? 19:20:21 Which argument exactly? 19:21:28 the implied argument that the goal is to stop arbitrary data from being put in the chain 19:22:26 What would be the purpose of a memo field on a change output of a 2-out tx? 19:22:44 tevador: for the case where you want to send a memo to yourself 19:23:02 You can make a self-send for that. 19:24:04 I don't follow, are you not supposed to send a memo to yourself in txs where you send funds to other people? 19:24:26 that seems like the primary use-case for a self-directed memo 19:24:38 Not sure I understand the question. I just weight serveral arguments pro and contra forbidding arbitrary data, and *my* *personal* sum is net positive for allowing a reasonable amount 19:24:51 The use case is "back it up on everyone's disks in case I lose my wallet cache" ? 19:25:19 Those arguments are all well known already and open on the table, I just weight a bit differently than other people 19:26:35 Why would a self-memo need to be recorded on the blockchain? 19:26:40 Your personal sum, UkoeHB, seems also to be net positive to allow some reasonable amount, as I currently understand 19:27:06 tevador: why would any memo need to be recorded? the point is we don't know 19:27:44 That is a false dichotomy. 19:27:46 It makes some sense in the case of the recipient. It doesn't make sense for the sender. 19:33:17 Anyway, my "design philosophy" for things I personally design includes "make it flexible, to be able to counter any unforseen problems" 19:33:45 So I have the tendency to want my XMR coming with some technical flexibility. I would probably not get consensus for that, I think. 19:42:39 If the option B3 was meant to be per-output, 64 bytes would be more in line with PR #8733 (~1K for 16 outputs). 2-out transactions could have just one 128-byte field for the recipient. 20:34:08 Regarding B3 - I agree with UkoeHB points around it being an incremental improvement in privacy. 20:34:08 However, I did note isthmus and sech1 voiceds concerns that if tx_extra is optional, it impacts transaction uniformity. 20:34:08 Granted, B3 would improve uniformity vs the status quo. 20:34:08 So I'm just wondering what the counter argument for the uniformity issue is? Is worry about an optional encrypted tx_extra field, a worry about nothing? 20:35:50 It leaks one bit. vs 0 for option A. vs... a lot more, but unquantified, for current state. 20:36:52 Well, it leaks one bit unless some jerk starts putting unencrypted stuff in it I suppose. 20:38:22 john_r365[m]: making it optional reduces the average tx size increase of moving to a fixed-size field. By itself, an optional fixed-size field leaks very little information if the field is encrypted. 20:39:29 More information may be leaked in tx tree analysis, if an enote with a memo is more/less likely to be spent in a tree containing relatively more/less memos. 20:41:31 However the strength of tx tree analysis is asymptotic in the ring size, so an optional field would have strong privacy if global membership proofs are implemented. 20:45:00 tevador: how would the cost/benefit of moving away from ed25519 change if you contrast a global membership proof (~2^40 to 2^45 members) with an epoch-based proof (2^16 to 2^20 members)? 20:50:15 moneromooo: your last point about "jerks adding unencrypted stuff" - is that because it's not possible for nodes to validate if data is actually encrypted? 20:51:52 Yes. 20:54:19 2^16 members is less than 1 day, I don't think that would make a big difference. The point of the 2^40 membership proof is to completely get rid of any statistical attacks that are based on the decoy set. 20:55:41 tevador: I'm just interested from a technical point of view, the efficiency differences 20:58:18 I can't speak for PLONK, which I don't fully understand, but Curve Trees would have a very small difference between 2^20 and 2^40. The paper lists some benchmarks as: 2^20 = 24 ms, 2^40 = 43 ms. This is without batching. 20:58:45 ^ verification time of the proof 20:59:09 john_r365: This is still being discussed. You cannot _prove_ something is encrypted if you don't have any of the keys (public or private). However, encrypted data should have an approximately uniform random distribution. Unencrypted data does not have a uniform random distribution. We are researching possible statistical tests that could reject obviously unencrypted data. 20:59:29 hmm I see, close to linear in the exponent 21:00:38 I'm assuming SNARKs would have a similar characteristic 21:00:59 I think it's a waste of time, especially for large numbers of small sets like 128 bytes or 256 bytes, unless you're doing this for fun. 21:01:19 (about guessing whether somehting is encrypted) 21:01:27 Yeah it may be a waste of time 21:02:41 You don't want false negatives at all, so that'll send false positives through the roof, making it useless. 21:03:33 (and you don't want false negatives at all because Alice doesn't want to be told "your perfectly good tx is rejected because law of large numbers said someone had to be punched") 21:04:29 I suppose the wallet can retry if the encryption is non deterministic... 21:05:15 OK, I revise my earlier opinion from "waste of time" down to "not convinced". 21:07:12 Any secure encryption method must use randomization, so if the test deterministic, false positives are a non-issue. 21:09:14 Do you mean for things like the same message being encrypted twice yielding the same ciphertext, or other ? 21:09:53 (because the plaintext can be prefixed by things like the key images being spent etc to ensure uniqueness) 21:10:37 Scratch that. I don't know enough here to have a useful conversation about it. 21:14:55 I forgot to say something at the meeting. MoneroKon is doing early review and approval of top-ranked presentations starting Friday: https://reddit.com/r/Monero/comments/11cgnnk/monerokon_2023_call_for_reviewers_round_1/ 21:15:30 So if you want your proposal to be considered for approval before the submission deadline, submit by Friday. 21:20:22 Option B (formerly B3) seems like an ideal compromise from my perspective. It reduces the "fungibility puddles" resulting from tx_extra from infinite to two, which is a lot better than variables such as number of outputs/inputs. It successfully allows for soft forks, removes one of the biggest fungibility weaknesses, and doesn't enforce mandatory size increase to all transactions. 21:22:22 I also think that voting is pointless on this issue and loose consensus around B seems likely when all the arguments have been put on the table 21:23:43 I also think statistical test for randomness/encryption are pointless if encryption is the default in all reputable wallets, as a "fungibility" attack by using plaintext would have similar scaled costs as a flood spam attack 21:23:58 Just my 2 piconeros on the whole thing 21:24:12 I'm wondering if applying statistical tests truly accomplishes the desired results. If someone declares a standard of using another part of a transaction as an one-time pad for tx_extra, I would think they can enter data that passes the statistical tests as they please. 21:24:12 Even if the statistical tests are assumed to be perfect, they can only inconvenience the behavior, not ban it. 21:24:12 Am I wrong to think this way? 21:25:06 No. 21:27:58 I agree is only inconveniences bad behavior. Circumventing the default encryption would be similar to how some wallets are known to currently use nonstandard fees which has a similar impact on fungibility. Public shunning of such wallets is just as helpful as a wonky statistical test. 21:36:56 Btw, the ZKP based membership proofs have one cool side effect: light nodes can verify it without needing to store all historical outputs. All they need is the Merkle root. 21:43:36 Ok. I will stop looking into statistical tests until we decide that it should be looked into again.