16:27:56 Meeting here in 30 minutes. 17:01:22 meeting time https://github.com/monero-project/meta/issues/801 17:01:22 1. greetings 17:01:22 hello 17:01:36 Hello. 17:01:48 Hi 17:01:51 Hello 17:01:52 Hi 17:01:54 Hi 17:02:14 Hello 17:02:31 hello 17:03:15 2. updates, what's everyone working on? 17:03:32 Hello 17:05:11 me: OSPEAD coding work. Also set up a little C++ exercise for Geometry Labs/isthmus. 17:07:13 me: trying to catch up with the new curve discussion and structuring what needs to be done for the wallet transaction history 17:07:26 me: getting back into my todo list, these are the major items on it: refactor enote store to use block id checkpoints, refactor enote scanning to use a re-usable state machine that can be adapted to scanning backends, review dangerousfreedom's seraphis knowledge proofs PR, then finally update the seraphis paper 17:08:42 me: need to push my mocks to github(the mocks should demonstrate a way to use 2 different transaction classes) 17:10:32 What are these "two different transaction classes" for? 17:10:53 3. discussion; today we were supposed to return to the tx_extra discussion, however the lower turnout makes me unsure if we can resolve it in this meeting 17:12:04 In any case, I have a question there, because I lost track a bit in all the discussion 17:12:16 So currently we are using a single transaction class, but with seraphis we are adding a new transaction class, and we want a nice way to treat both of them, without, for example, save in each place that treats transaction two lists, one for storing cryptonote transaction classes and second for storing seraphis transactions 17:12:26 There was the proposal to mandate encryption for the tx_extra data 17:12:34 And check that with some heurisitic 17:12:49 Where does that discussion stand? Is that reasonably possible to achieve? 17:13:34 I don't know. We shouldn't use a heuristic by the way. Do a rigorous statistical test. 17:14:12 I meant to include that. I am pretty sure you can't prove something is encrypted 17:14:28 I think what you can hope for is an algorithm that says "This is probably encrypted" 17:14:41 I scratched the surface of cryptographic randomness tests. It can be complicated. If we treat it as just an unordered set, it is pretty simple Chi-squared test or similar. If it is an ordered sequence , then it gets more complicated. 17:14:44 and then hope that this does not fail and reject properly encrypted stuff sometimes 17:15:15 You can set the rejection probability by choosing the p-value to reject below 17:15:23 That's what a p value is 17:15:23 My take is you can't force people to not opt-out of privacy. In the case of a statistical test you can mask your payload with a fixed random bytestring for example. 17:15:37 It's the probability of a false positive 17:16:05 Thanks shalit I remember reading this in the chat at some point now that you've explained 17:16:07 UkoeHB: Yeah. There is a question of how someone might try to directly fool the test 17:16:17 That would almost count as encryption, no? 17:16:49 You probably want some form of deniable encryption then 17:16:59 I see this more as a political question: If the Monero Project gets attacked, we can show that we took reasonable precautions to ask for encryption 17:17:18 Attacked in the sense of politics: Somebody wants to throw mud at us 17:17:29 'political precaution' isn't in the design goals of the project 17:17:37 :) 17:18:21 Alright, but I got my personal question answered: That question is not settled, I can't assume encryption enforcement is on the table as option 17:18:31 If you wanted an answer on the feasibility of a statistical test, I could have researched it in more depth for this meeting. 17:19:13 anyway, here is the choice matrix for the tx_extra, we can at least discuss it with the people here 17:19:13 A) [remove tx extra]: cost is tx utility flexibility tied to hardfork (or steganography) 17:19:13 B) [keep tx extra in some optimized form]: cost is uniformity and scaling trade-offs depending on the solution 17:19:13 1) leave as unlimited-size TLV field 17:19:13 2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) 17:19:13 3) mandate optional fixed-length tx extra size + encrypt by default 17:19:13 4) mandate fixed-length tx extra for all txs + encrypt by default 17:19:14 5) other 17:19:19 I don't think that would be important enough, if only I am curious about this, while forming my opinion about tx_extra removal yes/no 17:19:43 I said last meeting "If there is a need/desire for a statistical check of the randomness (encrypted status) of the tx_extra field, I can help search for an appropriate statistical test." Maybe I should have asked for an affirmative "yes" if that statement was ambiguous. 17:20:25 Guilty. I somehow missed that. 17:20:40 Encrypting by default makes sense. Everyone who wants that privacy will have it without thinking. Trying to enforce does not make sense. If someone is trying to flood the network with identifiable outputs, they can just publish they don't need tx_extra for that in the first place so I don't see what the randomness check buys us. 17:20:54 So that's now a "no" from me: I don't think that merits further investigation right now. 17:20:57 here, but late, sorry 17:21:01 They can just publish their view key* 17:21:09 sorry Rucknium[m] your comment may have been lost in all the activity of last meeting 17:21:33 It's fine. No offense taken at all. 17:22:10 In that matrix you propose, can we mix the points 1 to 5? I would like maximum length plus an attempt at asking for encryption 17:23:05 Looks like that would be a new, additional number 17:23:29 Just an outsider's opinion: to me, the optional fixed-length tx_extra (with encryption on top) seems like the best compromise between all options. Users who don't need it don't have to pay extra fees and there's less bloat, and those who do will be still indistinguishable from eachother, so we'll have no idea what they're actually doing. Yes, it's still technically a puddle, but it would be a uniform puddle 17:23:34 a maximum or fixed? 17:23:54 My take is to narrow it down to A or B3. Thoughts 17:24:06 rbrunner: B) 2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) (option: encrypted by default) 17:24:07 actually maximum makes most sense 17:24:18 I think it may be hard to require changes to tx_extra by changing node relay rules. About half of all nodes were running old software in the August hard fork. At best, the mining pool and p2pool nodes (maybe) would reject the txs when they came to them if they were running new new-rules nodes. 17:24:57 Also, the pros and cons of each point can be hashed and rehashed ad infinitum. I think the best option is to choose an arbiter (either an individual, or a small group) that we "trust", who will make a final decision on the matter 17:25:15 And that decision will be final 17:25:17 basically tevador was on the right track with that pr, as per usual lol 17:25:23 The problem of max size is that it really leads to tx fingerprinting 17:25:27 UkoeHB: That 2) sounds good to me :) 17:25:29 I kinda like the stego option, despite the ring size decrease to the recipient (and only the recipient). 17:26:09 yeah but you gotta know what your doing if you dont follow the guidelines posted by core 17:26:24 as in core will set guidelines for tx_extra, and so forth 17:26:28 "stego option" does not look like an option to me, just the likely consequence of removing tx_extra 17:26:43 so you can make it variables size with a cap, but we'll set a tighter spec for normal usage 17:26:53 Otherwise B3. 17:27:07 Max size (instead of FIXED size) would lead to all sorts of fungibility puddles 17:27:47 yeah but youre just destroying your own privacy first, everyone elses second 17:27:53 Yes, but still progress, as the most blatant nonsense is prevented 17:28:31 blankpage[m]: 👍 17:29:13 Just to make sure: In any fixed size discussion, it's already assumed that tx_extra is ONLY there if somebody puts something there? 17:29:27 I.e. the "normal" uses we have today are away 17:29:44 With additional keys and such, don't remember exactly 17:29:47 Yes 17:30:25 rbrunner: that is the difference between B3 & B4 surely 17:31:01 Hmm, not sure, I think it's a technicality that does not yet occur here 17:31:15 But anyway, it's important to understand the proposal 17:31:22 vtnerd: the tx_extra as a generic field has a broad range of 'default behavior'. Since our goal is 'private by default', imo we should think about all natural uses of the tx_extra as part of the design scope - which includes any field someone adds for their personal project, etc. That what B3 and B4 are all about - setting up the field so all default-conforming uses (both 'not using it at all' and 'using it with some 17:31:22 personal field but following spec') have a higher degree of privacy than we have now. 17:32:02 Selecting coinbase outputs in rings might be having more effect on reducing effective ring size right now than tx_extra ever will. And we haven't made real moves to address it besides sech1's work on p2pool output efficiency: https://github.com/monero-project/research-lab/issues/109 17:32:21 a lot of words ukoehb, but you might be in the minority atm 17:33:27 Maybe 17:33:27 the project is about continually improvement, sometimes it takes a while ... anyone enough rambling from me 17:33:36 *anyway 17:33:48 The option is 0 (effective) A or a small fixed size say 256 bytes. This is enforced by consequences. 17:33:48 Randomness Is enforced only by default encryption and multiple randomness tests via node relay 17:33:49 vtnerd: to be more blunt, design choices have to be focused on our design goals 17:34:10 which are: privacy, security, scalability, longevity 17:34:20 Enforced by consensus 17:34:28 Well, discussing our design goals would probably end in a similar going round and round ... 17:35:15 As soon as I try to add "flexibility" or "real-world usefulness" in there probably ... 17:35:25 I believe we can start by eliminating options a clear majority disagree with 17:36:00 rbrunner: those are secondary goals, I listed the primary goals 17:36:07 The difference between B3 & B4 (whether the fixed soze encrypted blob is mandatory or not) comes down to scaling of storage requirements, because these blobs have very low verification costs. It seems to me that scalability of verification is likely to cause problems long before scalability of storage/bandwidth. 17:36:45 I’d vote to remove the tx_extra field (A) and enforce a certain number of outputs for each transaction (2,4,8,16) to prevent output stego 17:37:09 I think you might be out voted on that now xmrack[m] 17:37:11 xmrack[m]: that doesn't prevent output stegonography 17:37:24 yeah exactly, and it doesn't solve the problem 17:37:34 I only see B) 1) as having clear majority against right now ... 17:37:51 Actually bandwidth is the biggest scaling challenge 17:37:51 Verification can be processed in parallel 17:37:51 This is why I do not like B4 17:38:21 And B) 5, we seem to have no other clear proposals 17:39:22 Anyway, from the pro fixed size voters, what do you imagine as a reasonable fixed size? 17:40:05 0 or 256 bytes 17:40:13 Maybe we could make those proposals a bit more precise for a vote in the near future 17:40:56 ArticMine[m]: I was wondering if maybe 128 bytes per output would be more useful (2-out txs would be 256 bytes) 17:41:04 If the consensus is for something in option B. I’d prefer either 3 or 4 17:41:32 Ah, per output is of course a possible variant 17:41:48 128 bytes or 0 is fine 17:42:25 But then people may produce many dummy output to get their GIF or JPEG into there, surely 17:42:51 Per output is messy 17:42:53 In my scratch of the surface at cryptographically randomness tests, most tests had O(N^2) complexity at worst case. That may matter if we want a fixed/max size + statistical test of randomness. 17:44:00 We have the nodes pick a test at random from a set that can change over time 17:44:00 ArticMine[m]: how so? 17:44:23 256 is a nice round number. Anybody here who thinks they cannot live with that? 17:44:39 Randomness test is only useful as a sanity check for stupid clients. Someone can still "encrypt" with a well known secret key, which should defeat any statistical test (that works). 17:44:55 If the blob is fixed per output, it would require fees per output to scale much quicker than now surely 17:45:09 moneromooo: That is the point 17:45:25 As an outsider that might consider integrating with Monero, I'd find a fixed tx_extra with encryption to be the better choice. 0 or 256, 1000, whatever. If you think you can actually validate randomness efficiently then that'd be fine. I'd just rather not suffer random failures because of this. 17:45:39 The only safe way is encryption 17:46:49 I don't really understand how a statistical test is useful if the default wallet behavior is to encrypt the field. 17:47:16 Otherwise you stand the risk of being caught by some "randomness" test 17:47:20 Kicking third party wallets in the butt till they bother encrypting :) 17:47:30 shades of opting out? seems like a pointless exerciese 17:47:54 Well, I am sure lawyers have a nice term for that, "reasonable effort" (of the project) maybe, but anyway, that's again "political" :) 17:48:01 There are going to be random failures of valid (encrypted) tx_extra contents. The failure rate can be set by the p value. If you set the p very very low, then you will have more false negatives (i.e. let a transaction through yet tx_extra is not encrypted). 17:49:06 So you could set p to 0.00001 or something and we would expect 0.001% of all valid tx_extra contents to not be relayed by nodes. 17:49:41 Is this also dependent on the length? Is the false positive danger bigger with shorter lengths? 17:49:56 Yes. If you have 1 bit, then... 17:49:57 in my view it's fairly black and white: either an implementer tries to be default-conforming, or he doesn't and all bets are off. If encrypting is too much of a pain, then the implementer will just find some cheap workaround to a statistical test. 17:50:10 I like using extreme values as a sanity check. 17:50:14 I agree that statistical tests seem relatively pointless. The effort for someone to create a blob of the correct length with clear text identifiable text is much higher than typing troll comments in the tx_extra field as it is now 17:50:47 We make the default encryption 17:50:50 rbrunner: The false negative danger would be greater when the length is shorter. Usually with these tests you, the decider, set the false positive probability (that's the p value). 17:51:36 Yeah, moneromooo's 1 bit argument is pretty convincing. But I guess with 256 bytes we get something working reasonably. 17:52:20 So if the tx_extra byte length is really short, then it might be pointless to do a test since you would have to set p to be low and only catch really unencrypted text rarely 17:52:49 Yes, but even that cheap workaround will prevent we have blatant nonsense in the blockchain open for everybody to pick up trivially 17:53:11 This is just general statistical theory that almost certainly applies to a more specific test. I have not looked deeply into what specific tests could be used 17:53:35 But here are some materials I was looking at: 17:53:37 The statistical test sounds “hacky” and bad UX for those handful of users 17:53:40 https://cran.r-project.org/web/packages/CryptRndTest/vignettes/CryptRndTest.pdf 17:53:40 https://raw.githubusercontent.com/terrillmoore/NIST-Statistical-Test-Suite/master/assets/nistspecialpublication800-22r1a.pdf 17:53:40 https://github.com/terrillmoore/NIST-Statistical-Test-Suite 17:53:40 https://cran.r-project.org/web/packages/RDieHarder/vignettes/RDieHarder.pdf 17:53:43 rbrunner: that is a bad argument, there are many trivial ways to put nonsense in the blockchain with a statistical test 17:54:06 Intuitively the shorter the field, the more failures you'd have. Probably deserves some research. All for an encrypted fixed length field if you send it. 17:54:07 for example, you can XOR each set of 32 bytes with one of the key images; trivial to decrypt 17:54:12 Ok, maybe I am not used to think like an adversary ... 17:55:15 Testing for "randomness" doesn't stop determined individuals from harming their privacy. Seems the only practical impact is causing occasional tx failure. Just making encrypt the default is good enough. 17:55:16 I agree that there are multiple ways to get around these types of statistical tests by a determined programmer. 17:55:26 Can't we solve that random failure problem easily? Allow to hash after encryption, have a counter how many times you hashed, hash until the test is ok 17:55:40 in the end we'd just look stupid for trying, if some one-liner is all you need to decrypt the field 17:56:12 You can't, since 000000...00000 is very likely a valid ciphertext. 17:57:10 Zcash has an encrypted memo field. I'm not sure how they do it. Maybe they encrypt with users' private keys. 17:57:48 Which immediately takes away much of its usefulness for our tx_extra if true. 17:57:48 They are looking to improve it by the way for messaging: https://forum.zcashcommunity.com/t/rfp-zcash-memo-field-secure-messaging-extension/44069 18:00:11 “Zcash lacks several essential features necessary for secure messaging, such as being signed to verify the origin of messages” 18:00:11 Doesnt sound like they use their private key 18:00:34 we are at the end of the hour so I'll call it here, we will return to the tx_extra discussion in the next meeting 18:01:04 thanks everyone 18:01:06 Anyway I vote b3 or b4, leaning towards b3. My reasoning is that two puddles is not as good as one puddle, but perhaps on a practical level two puddles is good enough considering the space savings compared to mandatory fixed size blobs. And two puddles is much better than potentially hundreds of puddles of the present situation. 18:01:32 Does anyone want me to research options for statistical tests for next meeting? 18:01:46 Maybe xmrack and I could do it together. 18:02:32 I'm personally not excited by the idea of a statistical test 18:02:55 It's not clear to me what problem the statistical tests would be truly solving 18:03:22 Rucknium[m]: are you arguing for one in consensus, or just as a "look out, moron" sanity check on daemon RPC ? 18:03:50 Not a technical one, if you ask me. A psychological one, and maybe even a juristic one 18:04:32 moneromooo: I am just trying to be a resource for the discussion. I think it would be probably not a good idea to put it in consensus. Node relay level is where we were discussing it I think. 18:04:37 Rucknium[m]: Within reason. If the probability of failure can be kept say below 0.001% for valid encryption 18:05:03 And if the wallet can re-roll automatically. 18:05:14 While getting rid of almost all the junk 18:05:20 We are here in the MRL alright, but out in the world lazy exchanges search for pretexts to drop XMR support. We could show we are *seriously* against some abutes. 18:05:31 *abuses 18:05:39 And take some wind out of their sails. 18:06:41 This is about the legal case of reasonable efforts 18:06:42 I think if someone wants an excuse to drop monero, there are various compelling ones in existence. 18:06:52 Ok I will put in maybe 8 hours into researching what the options are. Focusing on options that would be good to block an "adversary" that is trying to defeat the test with filler text or something. 18:07:00 Seems the answer on "how often will tests mess up legitimate txns" depends on the tx_blob length, which has not been agreed at this stage. I guess as a warning for users it makes sense, but maybe a low priority issue. 18:07:02 Yes, and maybe I am too optimistic there that we can make a real difference 18:07:53 blankpage: It depends on the p-value, which can be set directly in software. 18:08:06 If anything, dropping tx_extra altogether would probably the strongest possible action in this particular regard 18:09:33 rbrunner are your concerns here about illegal/obscene content on the chain? My understanding is this already exists on BTC and others and there have been no consequences. Also a size limit would seem to stop most possibility of this. 18:10:19 Mostly, yes. To this I would say we are not BTC which by sheer size and momentum is currently immune to almost anything 18:11:10 "BTC does it, so we can as well" is maybe a bit optimistic 18:11:18 Zcash memo is encrypted using the transaction view key. 18:11:18 “exactly 512 bytes long. If a sender doesn’t specify a memo, then the memo that is sent is all zeroes (before encryption), and if the sender includes a memo shorter than 512 bytes, then the remaining space is padded with zeroes (before encryption)…. The encrypted memo is visible only the to recipient, unless the transaction view key for the transaction gets shared” 18:12:53 But I think a size restriction to 256 bytes would already go a long way here. Not much porno fits into 256 bytes :) 18:13:54 Midget porn maybe ? 18:13:55 xmrack: Thanks! But do they verify somehow that the contents are actually encrypted? 18:13:56 * moneromooo flees 18:14:01 Have we discussed if the encrypted tx_extra is only for the sender or if the recipient should be able to decrypt it by default? 18:14:26 Rucknium: I’ll check 18:14:27 rbrunner: Porno no. But there is plenty of room to advertise illicit web sites, sad to say. 18:14:44 Anyway, I have a hunch that a professional mediator / arbitrator would probably try to find some compromise, and B)3 or B)4 look like compromisable. 18:15:16 bitcoin debated OP_RETURN in 2013-2014 I think. Could we find some wisdom in the archives? 18:16:26 one-horse-wagon: true 18:16:45 UkoeHB: A 18:16:46 Sorry for the slowness 18:17:14 tx_extra has got to be available to the recipient, no? Seems like a lost opportunity if not. 18:17:50 There's so much time wasted on the tx_extra question when its already been discussed to death, core team should just make a determination and let's be done with it. 18:17:58 There's nothing new proposed by anyone. 18:18:07 kgsphinx: one would think, but I dont think it has been discussed 18:18:56 rbrunner: Stop compromising with Ethereum-wanting-devs. Monero is not that project. 18:18:57 How is that, history punishes the latecomers :) 18:19:18 I got it that I am not waving your favorite viewpoint. 18:19:37 Alex | LocalMonero | AgoraDesk: I agree with you on the removal but it seems the general consensus is to move towards options B3 or B4. I’m happy with the progress towards a definitive solution 18:20:13 B3 is fungibility killing, B4 is efficiency killing. 18:20:16 B4 with a fixed length of 0 is A 18:20:21 Any B is a B solution 18:20:28 Hmm, maybe not enough people in the meeting today to make a good judgement about current "general consensus" 18:21:24 rbrunner: Exactly 18:21:31 The general consensus was best shown in the first meeting as that had the most traction. 18:21:35 By the way, for me it's my decision how I waste my time today. 18:21:46 That's true. 18:22:27 Monero means money, mostly it turns out 18:23:18 I'm sure the public is going to love to hear that everybody will have to pay extra fees on each tx if B4 is implemented, why? Because 0.1% of the chain users want to inject arbitrary data we'll tell them. 18:23:38 Jesus, again... 18:23:46 Can we narrow this down to: 18:23:46 A 18:23:46 B3 256 bytes or 0 bytes? 18:24:02 Yup, Monero: compromising with the 0.1% for the detriment of the 99.9% 18:24:29 And please take good note of the "or": It's *not* true everybody would pay extra fee. 18:24:48 rbrunner: Was talking about B4 which is fixed length mandatory 18:25:01 B3 is a fungibility nightmare with infinite subchains 18:25:14 Ah, ok. 18:25:35 I support B4 with 0 bytes That is equivalent to A 18:25:38 Alex|LocalMonero: What do you mean by this? 18:25:43 Please, can we get that argument a bit less dramatic? 18:26:18 2 sorts of transactions, one with and one without tx_extra, is already a nightmare? 18:26:30 Fixed length of course 18:26:34 and probably encrypted 18:27:02 Yup. It effectively makes everyone outside of the without tx_extra chain stand out 18:27:03 ArticMine @articmine:monero.social: why do you favor a mandatory tx_extra with zero length over removing the field entirely? Just to keep the option of bringing it back later? Or do I misunderstand you? 18:27:11 B3 with 2 options is 2 subchains 18:27:24 I support putting up A versus B3 256 bytes to vote, in any case 18:27:30 Seems more like we'd be reducing from infinity to 2 with B3. 18:27:30 Or, if, tragically, tx_extra will be used for a soft fork then we'll end up in a situation where those who arent attaching tx_extra will stand out 18:27:39 kgsphinx[m]: Not really if we remove tx_extra 18:28:48 B3 is an option that includes tx_extra 18:29:17 Yeah and I'm against keeping it. 18:29:17 I get it :) 18:29:19 I'm saying that B3 will break fungbility. 18:29:26 As compared to not having it 18:29:54 Can't break what's already broken though.. we have tx_extra and it's not limited. 18:30:09 Sure we can limit it now, but post-seraphis it should be removed 18:30:32 I thought this was a discussion on the final fate of tx_extra and not on the provisional state? 18:30:44 blankpage[m]: It may be easier to implement transition wise but in reality it is equivalent to A from a practical point of view 18:31:36 Realistically it is A or B3 in my view 18:31:55 ..and then go to vote 18:32:30 ArticMine: what's the consensus inside the core team on this? Do you have an internal majority for removing or keeping tx_extra? 18:32:32 I just do not see a consensus around the other options 18:33:13 It has not been discussed Other than here 18:33:39 Well perhaps you should. In the end this is a core team dictatorship. 18:34:04 And that's a good thing, by the way. 18:34:40 As for core team members here I see one for A and for voting between A and 3B 18:34:51 B3 18:35:52 CCS is a core team dictatorship, and so is merge authority on github. I don't think anything else is really. 18:36:12 It should not be 18:37:55 . . Realistically this is not a core team issue 18:38:03 blankpage[m]: Merge authority in github is effectively all you need if your github is what everyone is pulling from. 18:38:59 I doubt that most people outside the core community (which is mostly the same people year in year out) will care if the core community disagrees with the core team and forks away. 18:40:01 See: BTC/BCH civil war 18:41:02 Alex|LocalMonero: They have fundamental structural problems we do not have 18:41:38 In any case we are way off topic 18:42:16 Whatever the outcome of this contentious tx_extra issue is, I'm pretty sure that if the "losing" side forks away it's not going to get mass adoption. 18:42:24 Yes. Arguments by volume aren't very helpful. 18:42:45 I agree. 18:42:54 Act it then, please. Thanks. 18:43:25 Sorry, I'll just keep saying the same arguments over again like the rest of us. 18:43:44 Alright. Plonk time. 18:43:55 Shold have done that earlier I guess. 18:44:06 Please no 18:44:11 I jest 18:48:06 Did we talk about the drawbacks of the effective ring size decrease when using stego in sigs (kayabaNerve's method) ? I kinda remember having a talk about this, maybe here, not sure, and I kinda talked myself out of it IIRC. 18:48:28 But it'd be a great replacement for extra if the loss is deemed acceptable. 18:49:12 As a reminder, you can stuff about 31.5 bytes per ring member, which decreases the effective ring size by 1 for the recipient (but not for Eve). 18:49:27 Though of course if Eve is the recipient, she might publish that info. 18:49:55 Are there privacy implications beyond the recipient? Can't Eve always publish which outputs are true? 18:50:09 I am unsure how this would work for sending messages to more than one recipient in a tx though, if that is wanted. 18:53:02 didn't read all. Regarding encrypted/randomness test, can't wallet run this test before sending a tx and regenerate it if it fails? That will solve the random false negatives 18:53:27 Yes, it could. 18:56:12 sech1: the test isn't useful for core code, which would encrypt by default 18:56:34 even default encryption can fail the statistical test sometimes 18:56:47 oh your point is just for handling failures 18:57:09 Similar to the tx sanity check, which fails sometimes (and checks for a sane enough output age median). 18:57:55 That was to try and slap silly clients that used obviously wrong fake out selection. I think I didn't make it retry at first, but someone else added it (thanks). 18:59:16 So, no opinion on that stego thing. Guess most people left. Oh well. I'll try next time if I remember. 19:01:06 Removing tx_extra would simplify the protocol and save us a lot of time arguing about how to implement it. 19:04:18 The protocol doesn't care much about extra. It's just serializing an array of bytes. 19:04:40 So technically true for the first part, but by epsilon :) 19:07:33 If we wanted to make it prunable, there could be additional complexity around txid calculation. 19:08:26 Possibly a new tree branch here: https://github.com/UkoeHB/monero/issues/8#issuecomment-1430207423 20:32:01 Sorry for missing the meeting. CLSAG steganography eliminates decoys to the recipient. A static random pad used to 'cheat' a statistical test is cheating by encrypting it. My vote on the matrix is B3. 20:32:38 I'd like to distinctly note if we keep TX extra, it should be prunable, as discussed at the end. 20:38:31 I agree on both points, if that matters 20:40:26 If we can agree on a vote A versus B3 256 or very similar, with enough attendance of course, today's meeting would have a very good result 20:48:51 rbrunner: if B3-256, 1. Why do you believe that the sacrifice of fungibility is worth it and 2. What do you think of the notion that an optional tx_extra field might become a mandatory field in case of a soft fork? 20:52:08 A "static pad" won't work in practice. It will fail the test with some probability (as any encryption), so it can't be "static". 21:01:52 Alex|LocalMonero: I only repeat an argument, I know, but I see it fit: We are living 8 years with tx_extra that is much more potent than B3 256 and the sky didn't fall 21:02:24 That's true but we're not the world's reserve currency yet. 21:02:30 We're kinda under the radar. 21:02:30 But anyway, yes, for me a fungibility that is somewhat reduced is worth it compared with what I hope to gain. 21:03:28 You can argue basically anything with future scenarious where nobody can prove they will happen, nor prove the opposite. 21:04:08 You argue with future world reserve currency, I argue with possible breakdown that we can only avert by using tx_extra. Checkmate :) 21:06:01 That's why, much to sech1's dismay, we will have to resort to some crude vote to decide the future course. It seems technical arguments alone won't convince enough. 21:06:29 Because you can *judge* those arguments in different ways. 21:06:46 Or better said, weight them differently 21:12:02 By the way, I have no fear that actually on the brink of becoming the world's reserve currency we wouldn't be wise enough to re-judge some things differently 21:12:46 The B3 option is a net improvement over what we have. Banishing it will only encourage steganography approaches in the case somebody needs extra bytes, which will cause bloat and reduce fungibility as well. Hence the reasonably sized, encrypted, 0 or N byte option seems pretty optimal. 21:13:14 Did somebody say "compromise" ... :) 21:15:46 kgsphinx[m]: I don't think it's reasonable to call something that conforms with a definition of a tx as bloat. One can argue that the definition of a tx needs to get stricter but one cannot use the laxness of a tx definition as an argument to support further laxness. 21:16:51 "Because you can *judge* those..." <- The argument needs to be judged against the principles of Monero's design, not against the personal desires of certain devs. 21:29:07 I unselect my preference for CLSAG stego, since it doesn't carry over to seraphis, that was mentioned last week and I had forgot. 21:30:21 Bloat to me is whatever adds unnecessary bytes to the chain. I think you're saying that HOW fungibility is impacted is also important to you. So weird looking transactions are ok, in fact better than a 1 in 2 out transaction with extra data. Just not sure I agree. I also don't think it's "lax" to have a field like this. 21:30:40 Alex | LocalMonero | AgoraDesk: you keep mentioning that the B3 option would *completely* break *fungibility*. Could you elaborate how, exactly? Obviously we can distinguish between the (few) txes that have tx_extra from those that don't - but what other information could an external observer gather? 21:30:40 - How would it impact the *privacy* of that transaction? 21:30:40 - Would it reduce its effective ring members, or reveal any additional information about the contents of the tx in question? 21:30:40 - How would it impact other transactions that include this transaction's outputs among its ring members (whether as a real spend or a decoy)? 21:31:35 We have other examples of things that put transactions is different pools, like fees.. that's not killing the project either. Take the net gain man! 21:31:41 It would not *completely* break *fungibility*, that's appeal to fear again. 21:31:59 s/is/ib/ 21:32:01 s/is/in/ 21:32:23 I certainly never said that it would completely break fungibility, just that it hurts it. 21:32:31 moneromooo: I agree, that's hence my questions 21:32:45 Sure, just answering it :) 21:32:46 Lax is leaving tx_extra as is. 21:32:47 Still, how does it hurt fungibility? 21:33:47 You've explained it yourself. There's two distinct pools of txs now: ones that utilize the tx_extra field (a minority I assume <1%) which will stand out, and ones that don't utilize it. 21:33:48 And this is, of course, assuming that there is no soft fork. 21:34:27 A lot of people involved in these discussions seem to think that soft forks are a good thing and hence tx_extra is good to keep around. 21:34:28 Depends on the details, but it's a much less extreme version of "Alice uses 2 monero fee for every tx". Some people/usages will be more likely to have the option on than others. 21:34:40 It might break perfect transaction uniformity, but I don't see how it would break fungibility, per se 21:35:03 (I am assuming a hard fork scenario, if that helps) 21:35:04 So you can have a better than random chance to predict things. Maybe not much better, but still better. 21:35:39 So the problem is deciding whether that small loss is worth the added ability. 21:35:57 I mean, outputs that are consistently involved with tx_extra are clearly not good candidates for decoys anymore. 21:36:00 That's... subjective. 21:36:31 They would have to be excluded from the decoy selection. moneromooo do you see my messages or not? it's hard to understand who you're replying to 21:36:35 Like, you see a ring signature where a (small) number of outputs comes from txes that had a tx_extra, and the rest come from "normal" transactions. How would that impact the protection of the ring signature? Would it allow you to exclude certain decoys? 21:36:36 I mean both sides are subjective. 21:36:43 Alex|LocalMonero: I do now, request from UkoeHB. 21:37:01 Thanks, I asked 21:37:30 Sorry I'll get to your thread after I finish with endor 21:40:47 merope: So, it's basically impossible to predict all the scenarios in the future since tx_extra opens a pandora's box of possibilities that are hard to predict, so I'll simplify to two cases:... (full message at ) 21:43:45 But the premise was that the field is encrypted/obfuscated somehow, so the only thing an external observer could see is that the field is there, but not what it's used for 21:44:33 (Unless you literally have a single application using it, which would make it trivial) 21:45:04 You say that bloat are unnecessary bytes to the chain. First off, which bytes are welcome on the chain? As far as I understand the goal of Monero is to be digital cash. This goal is strict and narrow in definition, therefore any other application layer functionality is to be implemented on other chains or databases. So, if all but money transfers are deemed as acceptable on the Monero chain, then any other data that is to 21:45:04 be injected as a consequence of a not-strict-enough tx definition is undesirable data and hence its a good thing that its not efficient 21:45:31 So you'd have no way to tell if that tx was involved in a dex, or if it's a secret message, or it's the bee movie mp4 uploaded in very tiny chunks 21:45:55 And let's not forget that the good-natured applications of writing data into the chain will only take a tiny proportion of the overall txs so they really "bloat" the chain only a little bit, hence a tiny price to pay to maintain efficiency and fungibility 21:46:48 merope: Yeah but just because it's encrypted doesn't preclude the DEX from publishing the keys. 21:48:11 > <@alex:agoradesk.com> So, it's basically impossible to predict all the scenarios in the future since tx_extra opens a pandora's box of possibilities that are hard to predict, so I'll simplify to two cases:... (full message at ) 21:48:58 That's the idea. 21:49:14 Alex|LocalMonero: That falls outside the scope of Monero itself though. By that logic, I could also choose to publish my wallet's viewkey and spendproofs: that might impact the privacy of those who pick my outputs as decoys, but it wouldn't *completely* break fungibility - just slightly weaken individual ring signatures. The protocol itself would still be sound 21:49:59 There's a difference between controlling one wallet and publishing the keys and controlling an entire subchain application and publishing the keys. 21:50:09 * Got it, got it.. I like your hardcore attitude but I still like the tradeoff of the utility. If a DEX would rather not use this field then they could try steganography instead to claim "superior fungibility". 21:50:28 Are there any subchain applications that do this? 21:50:46 Or would actually choose this approach? 21:50:50 Not to mention the keys needs to be published for the DEX to work, as was mentioned by kayaba. 21:52:17 fluffy put it better than me: steg is a small price to pay for being rid of the tx_extra field. 21:53:10 So a necessary condition for building a dex that supports Monero is to publish the dex's viewkeys? And there's no other alternative approach (whether using tx_extra in an alternative way, or some other system entirely)? 21:53:30 (Like direct p2p transactions, even?) 21:54:01 Actually no, it's not a necessary condition to build a DEX at all, but one of the main proponents of keeping the tx_extra field in these discussions showcases his DEX as why tx_extra should be kept. 21:54:11 There is another DEX: Haveno, which doesn't utilize tx_extra at all. 21:54:26 I see 21:54:28 In fact, there's nothing within the concept of a DEX that necessitates having an arbitrary data field in Moner. 21:54:40 s/Moner/Monero/ 21:55:18 * There is another DEX: Haveno, which doesn't utilize tx_extra at all (as far as I know). 21:58:52 So right now, this specific application of tx_extra potentially weakening ring members due to the data it publishes outside of the chain, is purely a hypothetical future scenario? 21:59:52 No, it's a real scenario. Some people proposed excluding outputs in txs that employ tx_extra this way from the decoy selection algorithms. 22:00:23 The soft fork scenario is hypothetical, though. Monero never had a soft fork that I know of. 22:00:46 But there's plenty of soft fork fragmentation evidence in the BTC chain. 22:01:12 As I said before, soft forks can be done without tx_extra, so it's not an argument for keeping it. 22:01:31 (Yeah I'm completely ignoring the soft fork scenario, I'm assuming a hard fork where everybody follows the same rules) 22:01:31 Serai 22:01:59 tevador: True, but tx_extra certainly makes soft forks easier. 22:04:42 Alex|LocalMonero: Are there applications that weaken ring signatures due to the data they publish in tx_extra+elsewhere, today? The only one I'm aware of that causes some issues is p2pool - but at least that is relegated to coinbase transactions. Are there any others? 22:13:15 How much harder is it to hide data elsewhere? Harder than "just use Litecoin/mW" or a sidechain? If its too much trouble, id imagine they'd use something more efficient 22:14:56 "Are there applications that..." <- Yes, Serai already exists, and there are other applications like thorchain: https://github.com/monero-project/monero/issues/6668#issuecomment-831976735 22:15:05 ofrnxmr[m]: That sidechain data would have to be referenced into the main chain through tx_extra - otherwise you're just sending data out-of-band 22:16:01 ofrnxmr[m]: The truth is that its not that hard. The world financial markets developed around gold which didn't have a decentralized distributed database of scannable arbitrary data storage and there was no internet. 22:19:13 I apologize for repeating myself but I think UNIX philosophy applies to Monero's design goal: do one thing (be digital cash: decentralized, electronic, fungible) and be good at it. Any additional utilities make Monero less efficient at its core utility, that's just the nature of reality. You can't be a master of all trades, just look at how inefficient Ethereum is because it tries to be everything at the same time. 22:19:36 I don't have the details of how various apps use tx_extra, but instead of including metadata in the tx_extra field, they could be included off chain and tx_extra could simply contain a hash of those metadata, so their integrity could be checked and they would not bloat the chain, assuming tx_extra is there. So using tx_extra for direct inclusion of metadata for apps like DEXes seems like the wrong thing to do. 22:20:54