07:01:13 A proposal regarding the MRL meeting later today: https://github.com/monero-project/meta/issues/797#issuecomment-1430847786 07:02:08 "Doing the same over and over again and hoping for a sudden change in outcome is madness" 14:28:25 Since all the arguments have been made over and over "ad nauseum" for years, couldn't we just have a vote today to throw out or keep "tx_extra"? Why is everyone so afraid to make a decision? 14:29:07 This isn't a democracy, so our vote doesn't really matter. It's about convincing the core team. 14:29:25 And it shouldn't be a democracy either. 14:30:24 You are right. It is not a democracy. But, the MRL can come up with a consensus by voting, can't they? 14:30:33 Setting up a precedent for these sorts of decisions to be decided by a majority vote is a very damaging prospect. 14:31:09 a majority vote isn't consensus. maybe a 2/3 vote or something but simple majority no way 14:31:29 something near a 50/50 split is the opposite of consensus, it's contentious 14:32:01 voting on a purely technical question is idiotic 14:32:07 Even 2/3 vote is trash. 2+2=4 even if 2/3rds vote that it isn't. And you'd be surprised at how many people would vote that 2+2=5. 14:32:12 sech1: Exactly. 14:32:32 also true though I'm not sure this is a structly technical question 14:32:37 strictly 14:32:45 O.K. So don't call it voting. Call it a poll. 14:33:15 the technical question is to gather all current uses of tx_extra and replace them with something else that doesn't let users embed bee movie scripts into transactions 14:34:12 There's one easy question that can be posed to determine your position on tx_extra, as I've mentioned in the issue: are you for or against arbitrary data in Monero? Personally, I'm strictly against it. 14:35:42 And I believe that Monero's design principles and goals are against it as well. 14:37:52

"Since all the arguments have..." <- The best projects are benevolent dictatorships, and other pretty much crumble 14:39:49 If we want privacy by default transaction uniformity matters more than the flexibility tx_extra offers 14:41:40 That is not quite right: to determine your position on tx_extra [...] are you for or against arbitrary data in Monero? 14:42:39 You could have a fixed encrypted blob attached to every tx. This would allow arbitrary (within some small size constraint though) data, without tx extra, or more generally without the ability to tell whether any data is in or not. 14:43:05 You could also embed data in existing tx data (though it has other drawbacks). 14:43:25 moneromooo: Wouldn't doing this keep both parties happy? 14:43:47 moneromooo: So now everyone pays for extra tx fees regardless of whether its utilized or not, essentially making txs that don't utilize that field be unproductive. 14:44:22 If both parties are "people who want arbitrary data" and "people who want to remove extra", then yes. 14:44:40 Alex|LocalMonero: that is a very poor excuse... 14:45:29 "voting on a purely technical..." <- ^^^^ 14:45:54 moneromooo: Excuse for what? 14:46:28 For being against a mandatory fixed size encrypted addition. 14:46:35 Fees are already tiny. Too tiny, probably. 14:46:53 moneromooo: Yes if those people who want to remove tx_extra do so for uniformity reasons 14:47:06 fees are not tiny 14:47:18 they make any amounts below 0.00001 XMR useless 14:47:35 Are there any downsides to having fixed sized encrypted blob to every tx? 14:47:35 even below 0.00003 XMR 14:47:48 That's less than a USD cent. Tiny. 14:48:17 moneromooo: Permanent unnecessary space requirements and fees on the potential future standard currency of the globe? Can you imagine how many equivalents of trillions of dollars this scales out to? 14:48:19 is 1 XMR = $1,000,000 it's $10 14:48:23 *if 14:48:34 Yes, increases size, so storage space and bandwidth. Also can be unprunable, depending. Also fees, at a push. 14:50:07 Not to mention that this now incentivizes people to utilize the field since they'll be paying for it anyway, which will direct them to sub-chains and applications, creating fungibility risks. 14:50:31 Alex|LocalMonero: that is a stupid argument. 256 bytes is like 15% of an tx size. If 15% of a tx fee becomes trillions, what does the 85% become ? 14:50:59 You'll get priced out by the tx before you get priced out by such an addition. 14:51:18 Other things will have to be worked out before then to survive this. 14:51:31 moneromooo: 15% extra transaction costs for the global economy won't scale out to trillions equivalent in your mind? 14:51:39 Re-read. 14:52:10 (I mean, this is not what I said) 14:52:59 I know what you said, I don't think you understood what I said. 14:53:24 Over the long run, if the currency becomes a global standard, an extra 15% in tx costs is a massive point of friction. 14:53:59 And a currency that offers the same but without the extra 15% tx costs will easily win over. 14:54:01 Then I was replying about this specifically: "So now everyone pays for extra tx fees regardless of whether its utilized or not, essentially making txs that don't utilize that field be unproductive." 14:54:23 I did not calculate any absolute value, as it's not relevant to what I intended to say. It may end up being trillions, or not. 14:55:23 OK. I accept your argument. I do not agree with your characterization that it is too large a problem. Which I think you implied ? 14:55:56 I do imply that it's a large problem in the context of Monero competing on the global currency market for dominant status. 14:56:25 Any point of friction will be outcompeted by a more efficient currency. 14:56:33 I don't think something being 15% cheaper is ever going to be remotely enough to overcome network effect 14:57:13 Lyza: Wise and other international payments providers are easily overcoming SWIFT's network effect by being cheaper. 14:57:19 Are there many people or applications who depend on tx_extra? Is it a must for someone? 14:57:54 As far as I know there is nothing using tx_extra yet, if we exclude the pub key which could be moved to another field 14:58:07 that's a different situation because each of those networks can move the same currencies. Only XMR network can move XMR 14:58:19 I think seraphis does this. 14:59:42 Lyza: That's not an important distinction for the argument, though. What I'm saying is tx fees matter. Unnecessary friction makes a currency less competitive. 15:00:07 Re-reading, to be clear, when I said "I accept your argument", I mean it as "I understand your argument", not "I agree with it". Just to be sure :) 15:00:12 I think that being able to add public and arbitrary data to the transaction could be very interesting, especially for NFTs and decentralized domain names; however, I think that Monero, as a currency, should not allow adding chain bloat. There are other blockchain specifically made for this kind of things. 15:01:06 I agree with this ^ 15:01:20 Exactly. 15:01:34 to be clear I'm in favor of removing tx_extra in whatever hard fork would happen next and don't fully understand the need to embed arbitrary data myself. but I'm definitely trying to hear arguments the other way 15:01:40 Somewhat too. I had high hopes for extra being used for interesting stuff, but it did not, and ended up really pointless in practice. 15:02:17 anyone know offhand if the proposals that have been made for payment channels with XMR use tx_extra? 15:02:37 "That is not quite right: to..." <- Technically everything is arbitrary data. it would just be gibrish to anyone else 15:03:06 ghostway[m]: You can split it into chunks. But it would be really expensive 15:07:20 "Somewhat too. I had high hopes..." <- I fully believe in trying things. Sometimes they succeed and sometimes not. At some point, you do have to move on from those that didn't work out. 15:08:10 I believe Monero succeeeds very well in not repeating Bitcoin's mistakes. Let's not break that tradition by keeping tx_extra 15:09:46 I wouldn't be surprised that if tx_extra is kept we will eventually see "litenero" which will advertise itself as a Monero that's cheaper to use. 15:10:04 Now that's appeal to fear. 15:10:15 And takes less space, less bandwidth etc. 15:10:39 I hope tx_extra gets removed in the next big release 15:10:52 And AFAIK Bitcoin does not have an extra equivalent (and people started using a hack to add arbitrary data). 15:10:57 It's not appeal to fear or greed. It's a statement of fact if the efficiency of Monero is not optimized for transactions. 15:11:01 That might also work with monero actually... I wonder... 15:11:22 I think it is possible actually :) 15:11:39 moneromooo: Bitcoin is one big tx_extra field essentially. 15:11:50 I’m not convinced that a fixed size helps much for the problem of arbitrary data stored on the chain. If we consider the ‘opt out privacy’ principle, what we have now already satisfies that - the default is an empty tx extra (ignoring ephemeral pubkeys). Using a fixed size encrypted field just means the default for new uses of the field is to be hidden among old default-conformant uses (not necessarily a bad thing 15:11:50 to aim for - the trade-off is chain bloat). The thing with opt-out privacy is it does literally nothing if you choose to opt out. For tx extra and ‘pasting in data’ in general, the only thing you can do to counter opt-out usage is increasing fees (1. Increase the tx extra fee rate so it matches the equivalent fee cost of steganography, 2. Increase the base fee rate). Everything else amounts to making it harder to 15:11:50 opt-out, which is not a good argument (your whole effort evaporates as soon as someone publishes an open source tool). I’m personally in favor of tuning the fees as best we can, and feel skeptical about the chain bloat implied by a fixed size field (mainly considering how little the tx extra is actually used outside the default). 15:13:08 maybe Light Nodes get more attention too https://github.com/monero-project/research-lab/issues/69 15:17:07 Is there a reason not to have all-or-nothing? Zero length or length N? Then most txs would have a zero-length tx_extra. Protocols/wallets/users that use it would all have the same tx_extra length. There would be a reduction in tx uniformity compared to fixed length for all tx, but it would just split the anonymity pool into two ponds instead of having many puddles when users can use any length. 15:17:57 Good point, UkoeHB, fixed length doesn't make sense 15:18:45 Rucknium[m]: not a bad idea, I had a similar thought just now lol (to specify a tx extra value type that’s fixed length and generic) 15:18:45 I don't think there is a reason beyond the one you mention already. 15:19:51 So if it's zero or N, doesn't this hurt fungibility? 15:20:09 Aren't we segregating the chain into two subchains? 15:20:12 That *is* the reason Rucknium[m] mentioned. 15:20:40 So if fixed length doesn't make sense and zero or N hurts fungibility, then zero wins? 15:22:01 Alex|LocalMonero: the chain is already split into puddles based on ‘default’ vs ‘nondefault’ use of the tx extra, so 0vsN would be an improvement in the current default (I like orienting design decisions against what we have now) 15:23:27 tx_extra length wouldn't be the worse source of tx uniformity defects. I would put wallet fee algorithms and decoy selection algorithms above tx_extra length probably. (The Seraphis upgrade will help reduce fee diversity by discretizing fees.) 15:23:28 UkoeHB: so basically we're close to a "Zero or N" state now, recognize that it's a fungibility problem, recognize that a more perfect zero or N state is also a fungibility problem, therefore, if we move, we should move to zero? 15:25:15 Any downsides to having zero length other than the possibility that someone can use tx_extra in the future? In that case can't people simply fork Monero and introduce this field? Is there a point in caring? 15:25:17 0vsN would be a significant improvement since all non-null fields would be private by default (within the set of default-confirming N-size fields). 15:25:20 Rucknium[m]: It's not just length but also content, though. Eve can see which txs are related to what apps. Some regulators might start requiring their local exchanges to encode national IDs onto txs of their users withdrawing. 15:26:21 kayabanerve has already made the point that people can put arbitrary data that reduces tx uniformity into others parts of Monero txs. 15:27:09 Fake out pubkeys ? :) 15:27:25 There is a discussion underway on whether statistical checks on tx_extra contents can in effect make the tx_extra field be encrypted 15:28:54 If something reduces tx uniformity I'd much rather it be stegged into the chain so as to look normal to any observer that isn't in the know than out in the open 15:29:10 And also, how would the stegger excludes txs that have fake out pubkeys that accidentally match his format @moneromooo? 15:29:22 s/fake/real/ 15:30:00 I do not understand that question. Can you rephrase ? 15:30:13 Alex|LocalMonero: if fixed length were mandated then it would be encrypted by default 15:30:14 who are you defeating, with steganography? afaik it takes very little analysis to extract steg data 15:30:43 hyc: you defeat constraints on the tx extra 15:30:52 Hypothetically 15:31:31 If a stegger wants to encode things onto the chain in order to access it later how can the stegger, when later reading the chain, exclude the noise (outputs that match his format by chance despite being genuine)? 15:33:28 You could include a bit that tells you that. 15:33:43 So ECC 15:34:04 Well, in the case where Alice sends to Bob and Bob reads, at least. I did not think about the case where Alice sends to Bob and Alice reads. 15:34:06 how is ECC related to steg.? 15:34:22 Hiya 👋... (full message at ) 15:34:34 It's not ECC fwiw (though you can use it too). 15:34:44 pls ban that scammer 15:35:08 @kenzie_jonn:matrix.org 15:35:16 endor00 15:38:12 moneromooo: not sure I understood your answer. If you include a bit for noise that bit itself can also match the noise, can't it? Maybe I'm just not getting something. 15:38:38 Also, "afaik it takes very little analysis to extract steg data" <- I think you're thinking about hiding stuff in low significant bits of structured data 15:39:02 Well, no. You include a bit that does NOT match the noise. 15:39:17 It just has to be equiprobable for an attacker. 15:39:39 Are you assuming that Bob knows which tx he needs to read? 15:39:57 I'm thinking in terms of a decentralized data transmission network. 15:40:04 I do this in a monero fork, and AFAIK an observer cannot tell which txes have embedded data and which don't, and the receiver can tell with certainty which do and which don't. 15:40:25 Bob will see which txes are for him, like he normally does. 15:40:46 Do you mind linking how you do that? 15:41:03 Ah, I think I see what you're saying: this requires an output to go to Bob. 15:41:15 * moneromooo goes look for a link 15:41:22 Right. 15:42:39 https://git.townforge.net/townforge/townforge/commit/27bcb3586b5805d10fcb544d97e31c03d02edbf7 15:42:51 Thx 15:43:10 and https://git.townforge.net/townforge/townforge/commit/7c70d0ef6e4900434e54cb7cf071074d3d4da66b 15:43:26 First is the bit that monero could share, second is the "application layer". 15:43:43 (it has drawbacks though, no free lunch) 15:45:39 moneromooo: from the commit description it sounds like the only drawback is ringsize reduction for the receiver 15:48:05 AFAIK, yes. 15:48:54 Well, I guess from your point of view there's another drawback, which is a whole new tx's worth of fee :) 15:49:04 The input mixring also allows you to embed arbitrary data up to (num_rings * (num ring members - 1) * log256(total chain outputs)) bytes, which also poisons everyone else's decoy selection. Once we tackle tx_extra, this should be the next target IMO 15:50:40 moneromooo: I don't mind that if something looks like a tx, walks like a tx and talks like a tx and pays a tx fee is a tx on chain. I do mind things on top of a tx that are added regardless of whether the end user is utilizing it or not and thus needs to pay extra 15:51:12 Oh yes, that make sense. 15:52:23 jeffro256 can you, though? you can't just add arbitrary ring members, they need to exist on-chain (and belong to the same hardfork as the other ring members for that tx type) 15:53:03 The data is in the index, not in the referenced public key. 15:53:06 You can stuff low bits with your data. 15:53:28 I'm not sure how it poisons other people's rings though ? 15:53:51 right 15:54:40 Because obviously bad decoy selection = tx that stands out with its own outputs = less "real" transactions borrowing your outputs as decoy inputs 15:55:36 Why the last implication ? 15:55:53 > jeffro256 can you, though? you can't just add arbitrary ring members, they need to exist on-chain (and belong to the same hardfork as the other ring members for that tx type) 15:55:53 Hence the log256(total num of outputs on chain), you can make the indexes anything as long as they're less than the total number of outputs on chain 15:56:42 > Why the last implication ? 15:56:42 I guess the same reason why p2pool is bad for decoy selection and output flooding is bad for decoy selection. More junk outputs = more junk decoys for real transactions 15:57:21 Junk outputs here meaning outputs from transactions which obviously stand out for a certain application, embedded with public data 15:57:23 Ah, because you're assuming someone will always use this system for all their txes ? Fair enough. 15:58:31 Yeah without automated checks for these transactions to avoid using them as decoys, normal wallets will statistically use them more, reducing the effective decoy input size 15:59:19 All this will presumably get fixed with: https://github.com/monero-project/research-lab/issues/100 15:59:49 They'd use them at the same rate I think. 16:00:24 > All this will presumably get fixed with: https://github.com/monero-project/research-lab/issues/100 16:00:25 This could be also fixed with the determinstic output binning right? 16:00:31 tevador: are you aware of any arbitrary data injection techniques in zk_SNARKs? 16:00:36 The reduction would come from the fact that another person would not use the system, therefore an observer would remove outputs from a tx using the system (assuming the sender always uses the system). 16:01:21 Am I missing a reason why normal wallets will statistically use them more ? 16:01:21 Alex|LocalMonero: no and also Seraphis won't support the method moneromooo mentioned 16:01:30 Yes, sorry I wasn't clear. I meant "more" as in more than if they didn't exist 16:02:45 today's meeting is in 1hr 16:03:20 UkoeHB Does output binning as implemented now use the Hash-to-distribution method, or are the bins still picked manually by the transaction creator? 16:05:24 AFAIK the current impl has 16 bins that are indexed the same way as current decoys, so user-selectable. 16:09:52 tevador: right 16:10:06 Wasn't there problems making the distribution function reproducible against floating point hardware? 16:10:07 *across 16:10:32 Well it’s one challenge you’d face 16:11:25 What were the other challenges if you don't mind me asking? 16:14:43 Thoroughly understanding the edge cases, and getting locked into a heuristic-laden algorithm 16:14:48 not to discourage an answer but here's the research lab issue https://github.com/monero-project/research-lab/issues/87 16:19:31 If we adopt a next-gen membership proof with a reference set size of 2^40, there is no need to have a decoy selection algorithm anymore. 16:19:48 Indeed. 16:20:50 Lyza That's a good thread which I haven't yet seen. I was talking about https://github.com/monero-project/research-lab/issues/84, but that's also an interesting idea to discuss 16:22:48 yeah 87 also links to 84 and 86 (: 16:23:07 all kinda related 16:35:01 + 17:03:38 whoops meeting time 17:03:52 UkoeHB: Ready to start meeting? 17:03:57 https://github.com/monero-project/meta/issues/797 17:03:57 1. greetings 17:03:57 hello 17:04:04 Hi. 17:04:08 Hello 17:04:12 Hello! 17:04:14 Hello 17:04:14 Hello 17:04:17 Hi 17:04:22 Heya 17:05:01 Hallo 17:05:04 Hi 17:05:31 2. updates, what's everyone working on? 17:05:35 Hi 17:05:51 Heya 17:05:56 I’m chatting with Rucknium about providing support on OSPEAD computational work. The plan is to have one of my engineers convert the R prototypes to a compiled language, and then we’ll run the faster code for tens of thousands of CPU hours on GL’s scientific computing infra. The benefit of being able to process more rings will be better precision in the final OSPEAD parameterization. 17:05:56 The plan is that we’ll first build a little demo for Rucknium pro bono, showcasing the relevant engineering skills, and then move the CCS forward for the main project. Even though we’re still in the pre-CCS demo phase, I went ahead and uploaded a draft of the CCS proposal (#375) in case anybody is curious wants to take a peek at the details in the interim. 17:06:39 hello! 17:06:53 me: Learning how to connect C++ and R. I left a comment on isthmus's proposal: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/375 17:07:07 jo 17:07:09 hi 17:07:23 hi 17:08:19 Is this the tx_extra discussion? I just came to watch. 17:08:35 Ive been working on webhook support for lws, which is not really mrl related. unfortunately no recent progress on bp++, but I pushed back the 2nd feature set for webhooks to get some bp++ time in the upcoming weeks 17:09:00 someone just needed lws stuff with a very high priority (or so they claim) 17:09:02 Monegro: Yes, in a bit 17:09:12 me: I've been building an experimental tasking system which may or may not be useful in the seraphis wallet migration project. My threadpool appears to have comparable performance to the current one tools::threadpool, but lets you 'sleep' on tasks inside the pool which increases throughput drastically if you have tasks that would normally hang to sleep for a long time. 17:09:21 Monegro: yes 17:09:34 ukoehb is it published anywhere? I can give immediate feedback 17:09:45 it will take my mind off going through the math you want me to go through :/ 17:09:59 I will comment on the read/lock thing you did, a couple of trivial comments 17:10:03 UkoeHB: does it make sense to focus on that at this second? i bet parallelization could be added later 17:10:05 vtnerd: https://github.com/UkoeHB/monero/tree/seraphis_lib/src/async 17:10:16 endogenic: don't know, don't care! 17:10:22 wonderful 17:10:28 forget asking me for feedback then 17:11:25 vtnerd: I haven't been able to figure out how to do very small tasks quickly unfortunately.. might be unavoidable overhead of the extra things I have in there. 17:11:46 yeah the allocations and locking usually kill that 17:12:11 3. discussion, today we are supposed to talk about possible consensus rule changes around the tx_extra 17:12:13 its typically better to have largish tasks for a system like that 17:13:30 People may have seen my idea to talk about alternative ways to get consensus about such consensus rule changes, see the meeting issue 17:13:51 At least as an additional thing to discuss 17:14:01 re: tx_extra there has been considerable debate in these places https://github.com/monero-project/monero/issues/6668 https://github.com/monero-project/meta/issues/797 17:14:30 rbrunner: Can we do this next time please? There's no point in this last minute change 17:15:03 I read all 150 comments on tevador's GitHub issue. I don't have a strong opinion on the matter due to the tradeoffs between different options. 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. 17:15:11 If there is some progress today, we can easily move that weeks. If not I see it getting important. 17:15:13 My summary is: Steganography has multiple performance impacts and is a uniformity trade off, not solution. I personally appreciate TX extra. I'd advocate a 255 byte limit, and wouldn't mind a statistical check/ASCII ban. 17:15:13 There's a lot of further discussions possible, and I'm unsure, per rbrunner, we'll actually reach consensus. I'd advocate either we take steps to limit it, which have minimal disagreement, we vote, or we drop the discussion entirely for consensus process discussions. 17:15:31 The current situation is that we have tx_extra as an arbitrary size field for arbitrary data. Does anyone think the current state is ideal? 17:15:38 no 17:15:43 no 17:15:52 No 17:15:56 no 17:15:59 no 17:16:00 Nope 17:16:00 no 17:16:05 no 17:16:05 and projects publicly listing their decryption keys for new tx_extra, is also not ideal 17:16:17 So we can have at least some consensus. 17:16:18 so steg 17:16:35 if the steg is public, its the same problem as public decryption keys 17:16:36 I have a hard time estimating what is ideal and not logically impossible 17:16:39 I see that the same as view keys @vtnerd 17:16:49 steg has to remain private to work, thats the difference between it and cryptography 17:17:01 but I'll accept 'could be improved' 17:17:13 monero doesn't advocate that large projects publish their view keys publicly 17:17:28 Any public output set is a privacy issue so long as we have subset membership proofs. 17:17:42 at least afaik, like many people are on edge about MyMonero and privacy, and don't want it worsened, etc 17:18:05 And her we do explicitly state view keys can be shared for verifiability. 17:18:10 which is irrelevant to what Im saying 17:18:19 thats just whataboutism on some next level crypto talk 17:18:24 *and yet 17:18:40 If arbitrary data is to be stored it should be stored in a way that makes it look just like any other tx to the greatest possible extent 17:19:11 there are researchers working on this stuff right now 17:19:16 why doesnt this room care? 17:19:17 the problem is this DEX (thats whats tx_extra) cannot market itself as a privacy solution, only a decentralized exchange 17:19:21 they're the experts 17:19:40 Somewhat? I'm more trying to comment this isn't an issue unique to extra and I don't care to premise this extra discussion on it. 17:19:55 provided the community understands this, its probably no worse than Kraken having a bunch of view_keys and info 17:20:07 Can we find a compromise on TX extra? 17:20:23 just include it with a fixed size, thats probably the most reasonable thing to do at this stage 17:20:29 There's an active PR to make it ~2kb 17:20:33 ArticMine: why is a compromise with arbitrary data injeciton desirable? 17:20:38 I'd advocate 255b. 17:20:47 I thought that's what #8733 is, a compromise 17:20:49 tevador? 17:20:50 If we can achieve a rough consensus that compromising is within reach. 17:20:56 I really like the Zcash approach - fixed size encrypted memo on *every* transaction so that no transaction with a memo sticks out. 17:21:01 If people are not ready to compromise ... 17:21:08 Along the lines of a limited number of fixed sizes 17:21:36 Some options are: 1. Limit the size. 2. Make it fixed-size. 3. Make it optional with a fixed size. 17:21:43 isthmus: this means that 99% is paying additional 15% tx fees (not to mention space and bandwidth) for the benefit of the application layer 17:22:05 Correct, it's for uniformity and everybody's privacy 17:22:22 Yeah, or tx_extra can just be dropped for even more uniformity and privacy 17:22:22 No free lunch 17:22:23 Alex|LocalMonero : yup :/ and I agree with tevadors condensed description, thats really what the debate is over 17:22:27 And pusedo enforcement of randomness via node relay 17:22:33 #8733 is a stop gap measure before Seraphis can change tx_extra. 17:23:01 vtnerd: why isn't removing it an option? 17:23:05 Mandatory blob of fixed size would have very low computational/verification cost, yes? Downside would be purely storage/bandwidth 17:23:15 moo had a patch a while ago that did that (fixed size extra) if IRC 17:23:19 blankpage: fees 17:23:45 And a terrible hit rate, very few people wanting to store something there, and doing so 17:23:46 One of the size choices can be zero 17:24:06 As distinct discussion, if tx extra is kept, I believe it should be prunable and prunes by pruned nodes 17:24:06 Just reduce minrelayfee by 15% and the fee issue disappears 17:24:07 your right, there's no reason why we cannot force steg approaches, even though they are suboptimal 17:24:37 Would forcing steg reduce the frequency of usage? 17:24:38 #8733 should be a nobrainer whilst other things are worked out 17:24:42 vtnerd: they are suboptimal for arbitrary data, which makes monero more optimal for tx data 17:24:44 *As a, pruned by 17:24:50 Monegro: probably, as its much harder to do 17:25:03 Monegro: A higher cost of arbitrary data injection disincentivizes its usage 17:25:05 Rucknium[m]: Not that simple 17:25:09 Alex | LocalMonero | AgoraDesk: Not definitively 17:25:14 From a protocol design standpoint, our goal is privacy by default (i.e. opt-out privacy). It is impossible to mandate privacy, so any proposals with that goal should be discarded. What are the default-usage privacy defects of tx extra? Lack of uniformity among tx extra users (non-users are uniform in that they all have 'empty' fields [excluding ephemeral pubkeys]). Assuming we want to keep a tx extra in some form, we 17:25:14 can A) improve uniformity globally by mandating all txs have identical-looking tx extras by default (fixed-size and encrypted by default), B) improve scoped uniformity by mandating all txs have EITHER no tx or a fixed-size tx extra (encrypted by default). (A) is better than (B) in terms of uniformity, and (B) is better than (A) in terms of scalability (a fixed-size tx extra would be a big chunk of txs, maybe 25%). 17:25:14 Option (C) is deleting the tx extra if we decide it isn't a feature needed by default (steganography could be implemented as a non-default alternative). 17:25:18 the problem is that theoretically monero could support _some_ application layer stuff without being a privacy sieve 17:25:23 Re: optimality 17:25:39 I believe thats why tevador tentatively agreed to keeping tx_extra around - theres a way to use the memo field "properly" 17:25:44 does no one care that actual qualified researchers specialize in this 17:25:49 and that we have blinders on 17:25:56 we could invite them into the room as a community 17:26:02 but we choose to wander in the dark 17:26:08 I think we have a handle on this 17:26:14 no you dont 17:26:27 you cant predict the future of tech or you'd be those researchers 17:26:40 besides 17:26:40 endogenic: Sure. Invite them. 17:26:55 what kind of nonsense is it to not decide we need people who actually specialize in this 17:26:57 and researchers are never wrong? please, dont waste our time 17:27:03 what motives do you have exactly? 17:27:04 vtnerd: "proper" use of the arbitrary data field is an oxymoron if the design goal of monero is to be the best possible digital cash 17:27:09 endogenic: The room is open, feel free to invite “them” 17:27:10 vtnerd what a ridiculous argument 17:27:13 > Can we find a compromise on TX extra? 17:27:13 I'll summarize the idea I had for tx_extra. I discussed it with kayabaNerve, but didn't make it public. Disclaimer: kayabaNerve doesn't necessarily support this idea. Make tx_extra a public ed25519 point + signature (proving knowledge of private scalar corresponsding to aforementioned point) which reduces the amount of arbitrary data possible to encode into a transaction limited to just a few brute-forced bits. However, any 17:27:13 arbitrary data could be privately verified to be "attached" to this transaction by hashing to the point provided in the transaction. This tx_extra is small and fixed size but allows for off-chain verification of arbitrary data. ALSO, for data availability, "archival" nodes would relay and save corresponding blobs which match the tx_extra of certain transactions. Full nodes would also relay and save for up a week (this period 17:27:13 could be determined later). This solves the data availability problem, the DEX problem, and increases transaction uniformity. It does have tradeoffs, but I like this solution. 17:27:14 I have invited plenty of researchers here. Some have showed up. 17:27:19 i have invited them 17:27:25 they often feel disregarded 17:27:26 surprise 17:27:30 that's why i said as a project 17:27:33 if it were fixed size, and always encrypted by all parties, its no worse than ring signatures 17:27:38 none of you seem to value their free contributions 17:27:45 +1 vtnerd 17:28:04 the more options _allowed_, the more problematic it becomes 17:28:12 +1 17:28:18 Interesting 17:28:25 vtnerd: it is worse because its an extra added on top that everyone has to pay for whether they use it or not 17:28:28 using steg approaches works, but its funky 17:28:30 endogenic: if you have something to say, be specific 17:28:35 i have 17:28:38 stop strawmanning 17:28:45 jeffro256's idea has a pointless component, otherwise I'd have a similar option 17:28:47 endogenic: Give us some names 17:28:49 Im not talking about cost, Im talking about privacy, which is why isthmus gave me the +1 17:28:53 koe has names 17:29:02 and there are more of them too 17:29:05 I suggested one of the options being zero 17:29:10 dont think i'm talking out of my ass 17:29:18 endogenic: please be useful or shut the fuck up. 17:29:19 i'm not that flush with free time 17:29:22 i am 17:29:23 from a stat perspective, a symmetricall encrypted field is not going to be worse than the ECDH madness 17:29:26 try to listen 17:29:32 vtnerd: Fine with me, if 256b (> than a jamtis addr) 17:29:40 Link us to whatever work is there, fr instance. Dont' say "why don't we listen to them". 17:30:07 It's a bit bloated, but it solves the privacy, usability, and soft fork discussions 17:30:08 i habe 17:30:09 habe 17:30:10 have 17:30:13 it has been ignored 17:30:25 I believe a compromise is possible here 17:30:27 and it's notable there are individuals with conflicts of interest here 17:30:27 Sorry, I missed it then. I'll re-read. 17:30:32 We can also make TX extra prunable to help there 17:31:18 If referring to me, I don't mind disclosing, yet I'll comment I am minimally effected by this discussion. 17:31:22 1. If it's fixed length and encrypted then everyone is overpaying and overusing resources for the benefit of the few (and the junk outputs are still exploitable) 17:31:22 2. if it's optional then fungibility is harmed as we have what are essentially subchains 17:31:22 3. if arbitrary data injectors are forced to make their data look as txs then they effectively are txs and for all intents and purposes are a legitimate use of the Monero chain 17:31:39 I read the discussion of jeffro256s idea recently and I think it is very interesting. I do wonder if there are use cases which are only serves by the arbitrary data being on chain though, rather than a hash representation of what is happening in a mempool of blobs 17:31:40 But sure, I work on a real world use case of TX extra for arb data. 17:31:55 I re-read, no link or similar searchable info. 17:32:27 We can have a limited number of anonymity sets like we do with tx outputs 17:32:29 Alex|LocalMonero: 2. is not much worse than 3. because transactions with more than 2 outputs already stand out. 17:32:36 jeffro256[m]: my take is your proposal implies quite a large engineering effort (maybe more than is justified by a field that's barely used right now). Uniformity isn't really improved if you can just connect archived data to txs (there is no way to upload a tx and archive data at the same time without linking them). 17:32:47 Alex|LocalMonero the problem is that the steg approach are almost certainly less optimal than the encrypted approach, thus why we keep going in circles 17:33:06 tevador: txs with more than 2 outputs standing out sounds like a separate protocol issue to be fixed 17:33:20 vtnerd: less optimal for arbitrary data, so who cares? 17:33:35 I have a question 17:33:39 arbitrary data isn't monero's design goal 17:33:40 moneromooo: it has been over the past year 17:33:42 Alex|LocalMonero: and 2. is much better for scalability than 3. 17:33:47 i will dm you 17:33:49 Who here actively wants to remove, not fix, TX extra? 17:34:08 I am not the one that'll do the work anymore. Link it here please. 17:34:40 the record can be searched. time for you guys to stop trampling on people 17:34:41 If we can limit this discussion to improvements, which we can discuss incrementally, that may be more effective as right now we're exhibiting the concerns stated before this started 17:35:07 I also interested in this research or whatever, I don't see the point in complaining without bothering to share what you're trying to talk about 17:35:07 I support that question. Full removers, please wink. 17:35:12 tevador: scalability of arbitrary data? Again, who cares? We should be optimizing he scalability of tx data. The 0.01% usage of application layer data being unoptimized is not a concern 17:35:21 +1 remove - it sounds like arbitrary data can be added in other ways 17:35:23 some people might know what you're talking about but I would wager most of us do not 17:35:25 ... but if people insist on uniformity adding 128 bytes to each tx is less than 2 months of Neilsen's law 17:35:30