Removing or restricting tx_extra will be discussed at tomorrow's Monero Research Lab meeting 15 February, 17:00 UTC.
[02-15-2023 17:03:38] <UkoeHB> whoops meeting time
[02-15-2023 17:03:52] <Rucknium[m]> UkoeHB: Ready to start meeting? [02-15-2023 17:03:57] <UkoeHB> https://github.com/monero-project/meta/issues/797 [02-15-2023 17:03:57] <UkoeHB> 1. greetings [02-15-2023 17:03:57] <UkoeHB> hello [02-15-2023 17:04:04] <tevador> Hi. [02-15-2023 17:04:08] <rbrunner> Hello [02-15-2023 17:04:12] <one-horse-wagon[> Hello! [02-15-2023 17:04:14] <kayabanerve[m]> Hello [02-15-2023 17:04:14] <dangerousfreedom> Hello [02-15-2023 17:04:17] <Rucknium[m]> Hi [02-15-2023 17:04:22] <isthmus> Heya [02-15-2023 17:05:01] <AlexanderSchmidt> Hallo [02-15-2023 17:05:04] <Alex|LocalMonero> Hi [02-15-2023 17:05:31] <UkoeHB> 2. updates, what's everyone working on? [02-15-2023 17:05:35] <ArticMine[m]> Hi [02-15-2023 17:05:51] <Stnby[m]> Heya [02-15-2023 17:05:56] <isthmus> 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. [02-15-2023 17:05:56] <isthmus> 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. [02-15-2023 17:06:39] <jeffro256[m]> hello! [02-15-2023 17:06:53] <Rucknium[m]> 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 [02-15-2023 17:07:07] <vtnerd> jo [02-15-2023 17:07:09] <vtnerd> hi [02-15-2023 17:07:23] <plowsof11> hi [02-15-2023 17:08:19] <Monegro> Is this the tx_extra discussion? I just came to watch. [02-15-2023 17:08:35] <vtnerd> 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 [02-15-2023 17:09:00] <vtnerd> someone just needed lws stuff with a very high priority (or so they claim) [02-15-2023 17:09:02] <rbrunner> Monegro: Yes, in a bit [02-15-2023 17:09:12] <UkoeHB> 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. [02-15-2023 17:09:21] <one-horse-wagon[> Monegro: yes [02-15-2023 17:09:34] <vtnerd> ukoehb is it published anywhere? I can give immediate feedback [02-15-2023 17:09:45] <vtnerd> it will take my mind off going through the math you want me to go through :/ [02-15-2023 17:09:59] <vtnerd> I will comment on the read/lock thing you did, a couple of trivial comments [02-15-2023 17:10:03] <endogenic> UkoeHB: does it make sense to focus on that at this second? i bet parallelization could be added later [02-15-2023 17:10:05] <UkoeHB> vtnerd: https://github.com/UkoeHB/monero/tree/seraphis_lib/src/async [02-15-2023 17:10:16] <UkoeHB> endogenic: don't know, don't care! [02-15-2023 17:10:22] <endogenic> wonderful [02-15-2023 17:10:28] <endogenic> forget asking me for feedback then [02-15-2023 17:11:25] <UkoeHB> 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. [02-15-2023 17:11:46] <vtnerd> yeah the allocations and locking usually kill that [02-15-2023 17:12:11] <UkoeHB> 3. discussion, today we are supposed to talk about possible consensus rule changes around the tx_extra [02-15-2023 17:12:13] <vtnerd> its typically better to have largish tasks for a system like that [02-15-2023 17:13:30] <rbrunner> People may have seen my idea to talk about alternative ways to get consensus about such consensus rule changes, see the meeting issue [02-15-2023 17:13:51] <rbrunner> At least as an additional thing to discuss [02-15-2023 17:14:01] <UkoeHB> 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 [02-15-2023 17:14:30] <Alex|LocalMonero> rbrunner: Can we do this next time please? There's no point in this last minute change [02-15-2023 17:15:03] <Rucknium[m]> 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. [02-15-2023 17:15:11] <rbrunner> If there is some progress today, we can easily move that weeks. If not I see it getting important. [02-15-2023 17:15:13] <kayabanerve[m]> 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. [02-15-2023 17:15:13] <kayabanerve[m]> 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. [02-15-2023 17:15:31] <tevador> 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? [02-15-2023 17:15:38] <vtnerd> no [02-15-2023 17:15:43] <jeffro256[m]> no [02-15-2023 17:15:52] <rbrunner> No [02-15-2023 17:15:56] <jtgrassie> no [02-15-2023 17:15:59] <tobtoht[m]1> no [02-15-2023 17:16:00] <kayabanerve[m]> Nope [02-15-2023 17:16:00] <Alex|LocalMonero> no [02-15-2023 17:16:05] <Guest26> no [02-15-2023 17:16:05] <vtnerd> and projects publicly listing their decryption keys for new tx_extra, is also not ideal [02-15-2023 17:16:17] <tevador> So we can have at least some consensus. [02-15-2023 17:16:18] <Alex|LocalMonero> so steg [02-15-2023 17:16:35] <vtnerd> if the steg is public, its the same problem as public decryption keys [02-15-2023 17:16:36] <UkoeHB> I have a hard time estimating what is ideal and not logically impossible [02-15-2023 17:16:39] <kayabanerve[m]> I see that the same as view keys @vtnerd [02-15-2023 17:16:49] <vtnerd> steg has to remain private to work, thats the difference between it and cryptography [02-15-2023 17:17:01] <UkoeHB> but I'll accept 'could be improved' [02-15-2023 17:17:13] <vtnerd> monero doesn't advocate that large projects publish their view keys publicly [02-15-2023 17:17:28] <kayabanerve[m]> Any public output set is a privacy issue so long as we have subset membership proofs. [02-15-2023 17:17:42] <vtnerd> at least afaik, like many people are on edge about MyMonero and privacy, and don't want it worsened, etc [02-15-2023 17:18:05] <kayabanerve[m]> And her we do explicitly state view keys can be shared for verifiability. [02-15-2023 17:18:10] <vtnerd> which is irrelevant to what Im saying [02-15-2023 17:18:19] <vtnerd> thats just whataboutism on some next level crypto talk [02-15-2023 17:18:24] <kayabanerve[m]> and yet [02-15-2023 17:18:40] <Alex|LocalMonero> 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 [02-15-2023 17:19:11] <endogenic> there are researchers working on this stuff right now [02-15-2023 17:19:16] <endogenic> why doesnt this room care? [02-15-2023 17:19:17] <vtnerd> the problem is this DEX (thats whats tx_extra) cannot market itself as a privacy solution, only a decentralized exchange [02-15-2023 17:19:21] <endogenic> they're the experts [02-15-2023 17:19:40] <kayabanerve[m]> 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. [02-15-2023 17:19:55] <vtnerd> provided the community understands this, its probably no worse than Kraken having a bunch of view_keys and info [02-15-2023 17:20:07] <ArticMine[m]> Can we find a compromise on TX extra? [02-15-2023 17:20:23] <vtnerd> just include it with a fixed size, thats probably the most reasonable thing to do at this stage [02-15-2023 17:20:29] <kayabanerve[m]> There's an active PR to make it ~2kb [02-15-2023 17:20:33] <Alex|LocalMonero> ArticMine: why is a compromise with arbitrary data injeciton desirable? [02-15-2023 17:20:38] <kayabanerve[m]> I'd advocate 255b. [02-15-2023 17:20:47] <jtgrassie> I thought that's what #8733 is, a compromise [02-15-2023 17:20:49] <vtnerd> tevador? [02-15-2023 17:20:50] <rbrunner> If we can achieve a rough consensus that compromising is within reach. [02-15-2023 17:20:56] <isthmus> I really like the Zcash approach - fixed size encrypted memo on *every transaction so that no transaction with a memo sticks out. [02-15-2023 17:21:01] <rbrunner> If people are not ready to compromise ... [02-15-2023 17:21:08] <ArticMine[m]> Along the lines of a limited number of fixed sizes [02-15-2023 17:21:36] <tevador> Some options are: 1. Limit the size. 2. Make it fixed-size. 3. Make it optional with a fixed size. [02-15-2023 17:21:43] <Alex|LocalMonero> isthmus: this means that 99% is paying additional 15% tx fees (not to mention space and bandwidth) for the benefit of the application layer [02-15-2023 17:22:05] <isthmus> Correct, it's for uniformity and everybody's privacy [02-15-2023 17:22:22] <Alex|LocalMonero> Yeah, or tx_extra can just be dropped for even more uniformity and privacy [02-15-2023 17:22:22] <isthmus> No free lunch [02-15-2023 17:22:23] <vtnerd> Alex|LocalMonero : yup :/ and I agree with tevadors condensed description, thats really what the debate is over [02-15-2023 17:22:27] <ArticMine[m]> And pusedo enforcement of randomness via node relay [02-15-2023 17:22:33] <tevador> #8733 is a stop gap measure before Seraphis can change tx_extra. [02-15-2023 17:23:01] <Alex|LocalMonero> vtnerd: why isn't removing it an option? [02-15-2023 17:23:05] <blankpage[m]> Mandatory blob of fixed size would have very low computational/verification cost, yes? Downside would be purely storage/bandwidth [02-15-2023 17:23:15] <jtgrassie> moo had a patch a while ago that did that (fixed size extra) if IRC [02-15-2023 17:23:19] <Alex|LocalMonero> blankpage: fees [02-15-2023 17:23:45] <rbrunner> And a terrible hit rate, very few people wanting to store something there, and doing so [02-15-2023 17:23:46] <ArticMine[m]> One of the size choices can be zero [02-15-2023 17:24:06] <kayabanerve[m]> As distinct discussion, if tx extra is kept, I believe it should be prunable and prunes by pruned nodes [02-15-2023 17:24:06] <Rucknium[m]> Just reduce minrelayfee by 15% and the fee issue disappears [02-15-2023 17:24:07] <vtnerd> your right, there's no reason why we cannot force steg approaches, even though they are suboptimal [02-15-2023 17:24:37] <Monegro> Would forcing steg reduce the frequency of usage? [02-15-2023 17:24:38] <jtgrassie> #8733 should be a nobrainer whilst other things are worked out [02-15-2023 17:24:42] <Alex|LocalMonero> vtnerd: they are suboptimal for arbitrary data, which makes monero more optimal for tx data [02-15-2023 17:24:44] <kayabanerve[m]> As a, pruned by [02-15-2023 17:24:50] <vtnerd> Monegro: probably, as its much harder to do [02-15-2023 17:25:03] <Alex|LocalMonero> Monegro: A higher cost of arbitrary data injection disincentivizes its usage [02-15-2023 17:25:05] <ArticMine[m]> Rucknium[m]: Not that simple [02-15-2023 17:25:09] <kayabanerve[m]> Alex | LocalMonero | AgoraDesk: Not definitively [02-15-2023 17:25:14] <UkoeHB> 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 [02-15-2023 17:25:14] <UkoeHB> 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%). [02-15-2023 17:25:14] <UkoeHB> 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). [02-15-2023 17:25:18] <vtnerd> the problem is that theoretically monero could support some application layer stuff without being a privacy sieve [02-15-2023 17:25:23] <kayabanerve[m]> Re: optimality [02-15-2023 17:25:39] <vtnerd> I believe thats why tevador tentatively agreed to keeping tx_extra around - theres a way to use the memo field "properly" [02-15-2023 17:25:44] <endogenic> does no one care that actual qualified researchers specialize in this [02-15-2023 17:25:49] <endogenic> and that we have blinders on [02-15-2023 17:25:56] <endogenic> we could invite them into the room as a community [02-15-2023 17:26:02] <endogenic> but we choose to wander in the dark [02-15-2023 17:26:08] <vtnerd> I think we have a handle on this [02-15-2023 17:26:14] <endogenic> no you dont [02-15-2023 17:26:27] <endogenic> you cant predict the future of tech or you'd be those researchers [02-15-2023 17:26:40] <endogenic> besides [02-15-2023 17:26:40] <Rucknium[m]> endogenic: Sure. Invite them. [02-15-2023 17:26:55] <endogenic> what kind of nonsense is it to not decide we need people who actually specialize in this [02-15-2023 17:26:57] <vtnerd> and researchers are never wrong? please, dont waste our time [02-15-2023 17:27:03] <endogenic> what motives do you have exactly? [02-15-2023 17:27:04] <Alex|LocalMonero> 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 [02-15-2023 17:27:09] <nikg83[m]> endogenic: The room is open, feel free to invite “them” [02-15-2023 17:27:10] <endogenic> vtnerd what a ridiculous argument [02-15-2023 17:27:13] <jeffro256[m]> > Can we find a compromise on TX extra? [02-15-2023 17:27:13] <jeffro256[m]> 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 [02-15-2023 17:27:13] <jeffro256[m]> 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 [02-15-2023 17:27:13] <jeffro256[m]> 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. [02-15-2023 17:27:14] <Rucknium[m]> I have invited plenty of researchers here. Some have showed up. [02-15-2023 17:27:19] <endogenic> i have invited them [02-15-2023 17:27:25] <endogenic> they often feel disregarded [02-15-2023 17:27:26] <endogenic> surprise [02-15-2023 17:27:30] <endogenic> that's why i said as a project [02-15-2023 17:27:33] <vtnerd> if it were fixed size, and always encrypted by all parties, its no worse than ring signatures [02-15-2023 17:27:38] <endogenic> none of you seem to value their free contributions [02-15-2023 17:27:45] <isthmus> +1 vtnerd [02-15-2023 17:28:04] <vtnerd> the more options allowed, the more problematic it becomes [02-15-2023 17:28:12] <jtgrassie> +1 [02-15-2023 17:28:18] <ArticMine[m]> Interesting [02-15-2023 17:28:25] <Alex|LocalMonero> vtnerd: it is worse because its an extra added on top that everyone has to pay for whether they use it or not [02-15-2023 17:28:28] <vtnerd> using steg approaches works, but its funky [02-15-2023 17:28:30] <UkoeHB> endogenic: if you have something to say, be specific [02-15-2023 17:28:35] <endogenic> i have [02-15-2023 17:28:38] <endogenic> stop strawmanning [02-15-2023 17:28:45] <kayabanerve[m]> jeffro256's idea has a pointless component, otherwise I'd have a similar option [02-15-2023 17:28:47] <Rucknium[m]> endogenic: Give us some names [02-15-2023 17:28:49] <vtnerd> Im not talking about cost, Im talking about privacy, which is why isthmus gave me the +1 [02-15-2023 17:28:53] <endogenic> koe has names [02-15-2023 17:29:02] <endogenic> and there are more of them too [02-15-2023 17:29:05] <ArticMine[m]> I suggested one of the options being zero [02-15-2023 17:29:10] <endogenic> dont think i'm talking out of my ass [02-15-2023 17:29:18] <moneromooo> endogenic: please be useful or shut the fuck up. [02-15-2023 17:29:19] <endogenic> i'm not that flush with free time [02-15-2023 17:29:22] <endogenic> i am [02-15-2023 17:29:23] <vtnerd> from a stat perspective, a symmetricall encrypted field is not going to be worse than the ECDH madness [02-15-2023 17:29:26] <endogenic> try to listen [02-15-2023 17:29:32] <kayabanerve[m]> vtnerd: Fine with me, if 256b (> than a jamtis addr) [02-15-2023 17:29:40] <moneromooo> Link us to whatever work is there, fr instance. Dont' say "why don't we listen to them". [02-15-2023 17:30:07] <kayabanerve[m]> It's a bit bloated, but it solves the privacy, usability, and soft fork discussions [02-15-2023 17:30:08] <endogenic> i habe [02-15-2023 17:30:09] <endogenic> habe [02-15-2023 17:30:10] <endogenic> have [02-15-2023 17:30:13] <endogenic> it has been ignored [02-15-2023 17:30:25] <ArticMine[m]> I believe a compromise is possible here [02-15-2023 17:30:27] <endogenic> and it's notable there are individuals with conflicts of interest here [02-15-2023 17:30:27] <moneromooo> Sorry, I missed it then. I'll re-read. [02-15-2023 17:30:32] <kayabanerve[m]> We can also make TX extra prunable to help there [02-15-2023 17:31:18] <kayabanerve[m]> If referring to me, I don't mind disclosing, yet I'll comment I am minimally effected by this discussion. [02-15-2023 17:31:22] <Alex|LocalMonero> 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) [02-15-2023 17:31:22] <Alex|LocalMonero> 2. if it's optional then fungibility is harmed as we have what are essentially subchains [02-15-2023 17:31:22] <Alex|LocalMonero> 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 [02-15-2023 17:31:39] <blankpage[m]> 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 [02-15-2023 17:31:40] <kayabanerve[m]> But sure, I work on a real world use case of TX extra for arb data. [02-15-2023 17:31:55] <moneromooo> I re-read, no link or similar searchable info. [02-15-2023 17:32:27] <ArticMine[m]> We can have a limited number of anonymity sets like we do with tx outputs [02-15-2023 17:32:29] <tevador> Alex|LocalMonero: 2. is not much worse than 3. because transactions with more than 2 outputs already stand out. [02-15-2023 17:32:36] <UkoeHB> 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). [02-15-2023 17:32:47] <vtnerd> 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 [02-15-2023 17:33:06] <Alex|LocalMonero> tevador: txs with more than 2 outputs standing out sounds like a separate protocol issue to be fixed [02-15-2023 17:33:20] <Alex|LocalMonero> vtnerd: less optimal for arbitrary data, so who cares? [02-15-2023 17:33:35] <kayabanerve[m]> I have a question [02-15-2023 17:33:39] <Alex|LocalMonero> arbitrary data isn't monero's design goal [02-15-2023 17:33:40] <endogenic> moneromooo: it has been over the past year [02-15-2023 17:33:42] <tevador> Alex|LocalMonero: and 2. is much better for scalability than 3. [02-15-2023 17:33:47] <endogenic> i will dm you [02-15-2023 17:33:49] <kayabanerve[m]> Who here actively wants to remove, not fix, TX extra? [02-15-2023 17:34:08] <moneromooo> I am not the one that'll do the work anymore. Link it here please. [02-15-2023 17:34:40] <endogenic> the record can be searched. time for you guys to stop trampling on people [02-15-2023 17:34:41] <kayabanerve[m]> 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 [02-15-2023 17:35:07] <Lyza> 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 [02-15-2023 17:35:07] <rbrunner> I support that question. Full removers, please wink. [02-15-2023 17:35:12] <Alex|LocalMonero> 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 [02-15-2023 17:35:21] <john_r365[m]> +1 remove - it sounds like arbitrary data can be added in other ways [02-15-2023 17:35:23] <Lyza> some people might know what you're talking about <endogenic> but I would wager most of us do not [02-15-2023 17:35:25] <ArticMine[m]> ... but if people insist on uniformity adding 128 bytes to each tx is less than 2 months of Neilsen's law [02-15-2023 17:35:30] <Alex|LocalMonero> +1 remove [02-15-2023 17:35:38] <rbrunner> Because getting full removal out of the way, per way of compromise, would be progress [02-15-2023 17:35:53] <jeffro256[m]> > the record can be searched. time for you guys to stop trampling on people [02-15-2023 17:35:53] <jeffro256[m]> For everybody's sake could you please link it if it's relevant? I want to know about formal research around this topic if it exists. It would be helpful to everyone who is not on here 24/7 [02-15-2023 17:36:22] <rbrunner> Two votes so far for full removal. Any more? [02-15-2023 17:36:30] <one-horse-wagon[> +1 remove [02-15-2023 17:36:31] <jtgrassie> remove [02-15-2023 17:36:35] <hbs[m]> +1 remove [02-15-2023 17:36:47] <Alex|LocalMonero> ArticMine: nielsen's law sure but what about fees? [02-15-2023 17:36:52] <endogenic> Lyza: i have been laboring for years to bring that research here [02-15-2023 17:37:08] <endogenic> now when i've been treated like i'm the asshole i have to forget all that? [02-15-2023 17:37:13] <ArticMine[m]> The impact on fess is minimal [02-15-2023 17:37:14] <blankpage[m]> How about hard-limiting tx_extra as a immediate action, and then jeffro256's idea could be further thought through to see if it covers all use cases? [02-15-2023 17:37:22] <Lyza> smh ok don't share it then but if you're not trying to be helpful waht are you doing here [02-15-2023 17:37:30] <rbrunner> Hmm, with 5 removal votes compromise will probably be difficult ... [02-15-2023 17:37:32] <UkoeHB> As meeting leader, I'm going to slow this down (getting a little too chaotic). Let's get a read on everyone's stance. I will list some options, then everyone should reply with the number they like best, and a small comment justifying your position. [02-15-2023 17:37:32] <UkoeHB> 1. get rid of tx extra and be done with it [02-15-2023 17:37:32] <UkoeHB> 2. mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) [02-15-2023 17:37:32] <UkoeHB> 3. mandate optional fixed-length tx extra size + encrypt by default [02-15-2023 17:37:32] <UkoeHB> 4. mandate fixed-length tx extra for all txs + encrypt by default [02-15-2023 17:37:33] <UkoeHB> 5. other (specify) [02-15-2023 17:37:44] <jeffro256[m]> I would be okay with a fixed-length mandatory encrypted field [02-15-2023 17:37:45] <Alex|LocalMonero> 1 [02-15-2023 17:37:47] <tevador> I personally don't mind removal (that was my original proposal), but I'm open for compromises (since pretty much anything is better than what we have now). [02-15-2023 17:37:49] <moneromooo> Some of the latest work of Moreno Sanchez, he said in private. In case someone wants to search/read. [02-15-2023 17:37:54] <isthmus> All NRL research points towards tx_extra being Monero's Achilles heel as of 2023. While the most straightforward solution would be to remove it, I also understand that there are valuable ecosystem components coupled to this, so I am also very open to discussing improvements. Anything better than currently. [02-15-2023 17:37:55] <ArticMine[m]> This is like 5% of tx size [02-15-2023 17:37:59] <jtgrassie> the case for keeping seems to be only for unknown future use cases [02-15-2023 17:38:01] <jeffro256[m]> I'm also fine with removal [02-15-2023 17:38:05] <Lyza> thx moo [02-15-2023 17:38:07] <UkoeHB> please no more comments other than replying to me for 4 minutes [02-15-2023 17:38:20] <UkoeHB> I need to moderate this [02-15-2023 17:38:40] <blankpage[m]> 4 [02-15-2023 17:38:44] <Alex|LocalMonero> UkoeHB: 1 [02-15-2023 17:38:52] <kayabanerve[m]> blankpage: There's a PR for a hard limit [02-15-2023 17:38:55] <dangerousfreedom> 1 [02-15-2023 17:39:01] <moneromooo> Kinda conflicted between 1 and 3. [02-15-2023 17:39:07] <hbs[m]> 1 [02-15-2023 17:39:08] <kayabanerve[m]> 2,3,4 [02-15-2023 17:39:15] <isthmus> 1, 4, open to others' 5 [02-15-2023 17:39:20] <fredsmith> 1 , possibly 4 [02-15-2023 17:39:21] <vtnerd> jtgrassie: fair point, and we could always bring it back in a hard-fork [02-15-2023 17:39:29] <rbrunner> 2 because length restriction, plus the encryption from 3 [02-15-2023 17:39:30] <jtgrassie> vtnerd: exactly [02-15-2023 17:39:31] <tevador> 1 or 3 are probably the best. [02-15-2023 17:39:38] <jeffro256[m]> UkoeHUB: In order of perference, best to worst: 4, 1, 3, 2 [02-15-2023 17:39:38] <ArticMine[m]> 3 [02-15-2023 17:39:39] <andytoshi> /iwn 21 [02-15-2023 17:39:41] <andytoshi> sorry [02-15-2023 17:40:01] <one-horse-wagon[> 1. remove. Better for uniformity of transmissions. [02-15-2023 17:40:12] <tobtoht[m]1> 1 or 3 [02-15-2023 17:40:17] <john_r365[m]> 1. Fallback 4 [02-15-2023 17:40:20] <UkoeHB> 3 [02-15-2023 17:40:46] <jtgrassie> hence #1 is the ideal and #2 at least nudges in the right directon (quick change) [02-15-2023 17:40:53] <Rucknium[m]> Like I said, I don't have a strong opinion because of the complicated tradeoffs. If I have to choose a single option, I would choose (1). [02-15-2023 17:41:43] <unwantedfondue[m> 2 [02-15-2023 17:42:28] <endogenic> Lyza: this is the help the project needs. the people here repeatedly throw away connections i've made. i'm not going to name names [02-15-2023 17:43:09] <Alex|LocalMonero> 4 minutes are up, shall we tally? [02-15-2023 17:43:33] <moneromooo> Oh. 1 would also prevent merge mining fwiw. But I'm biased of course. [02-15-2023 17:43:58] <UkoeHB> 1 [alex, jeffro, dangerous, moo, hbs, isthmus, fred, tevador, tobtogh, john, jtgrassie], 2 [kaya, rene, jtgrassie, uwanted], 3 [moo, kaya, tevador, artic, koe, tobtoht], 4 [jeffro, blank, kaya, isthmus, fred, john], 5 [isthmus] [02-15-2023 17:43:58] <tevador> We have to keep tx_extra for coinbase in any case (at least a fixed size one). [02-15-2023 17:44:31] <isthmus> Sorry, I forgot to include a comment explaining my votes: I said 1 & 4 because they maintain transaction uniformity (central to user safety) and preserve a single anonymity pool. I am open to others’ suggestions for 5 if they maintain transaction uniformity. [02-15-2023 17:44:47] <kayabanerve[m]> It sounds like due to fragmentation among 2,3,4, 1 is the most popular option there [02-15-2023 17:44:51] <fredsmith> +1 isthmus [02-15-2023 17:44:57] <kayabanerve[m]> tevador: For merge mining or yet something else? [02-15-2023 17:45:14] <tevador> extra nonce [02-15-2023 17:45:21] <one-horse-wagon[> UkoeHB: You didn't count my vote for 1. [02-15-2023 17:45:28] <jtgrassie> kayabanerve[m]: the field is used for additional pub keys [02-15-2023 17:45:31] <UkoeHB> sorry I may have missed a couple [02-15-2023 17:45:31] <kayabanerve[m]> TIL That's how that works [02-15-2023 17:45:47] <Rucknium[m]> kayabanerve: If we had ranked-choice "voting", the vote-splitting between similar options would be less of an issue [02-15-2023 17:45:51] <ArticMine[m]> Yes but a binary vote keep or not would be helpful [02-15-2023 17:45:52] <UkoeHB> 1 [alex, jeffro, dangerous, moo, hbs, isthmus, fred, tevador, tobtogh, john, jtgrassie, onehorse, rucknium], 2 [kaya, rene, jtgrassie, uwanted], 3 [moo, kaya, tevador, artic, koe, tobtoht], 4 [jeffro, blank, kaya, isthmus, fred, john], 5 [isthmus] [02-15-2023 17:46:02] <blankpage[m]> Democracy is irrelevant here IMO. No one has technical objections to limiting the size so let's just do that. Then if the ideas like jeffro256's turn out to be infeasible or not useful then we remove it completely in the future. [02-15-2023 17:46:03] <moneromooo> kayabanerve[m]'s idea (link to TF above) ensures uniformity and allows arbitrary encrypted data. So I also like 5 :D [02-15-2023 17:46:21] <jtgrassie> we have t keep it till the tx structure is changed, hence why #2 is a good stop-gap to #1 [02-15-2023 17:47:04] <tevador> The current PR #8733 is a soft-limit for tx_extra. It cannot be removed right now because it contains mandatory public keys. [02-15-2023 17:47:06] <rbrunner> I think when Seraphis comes near we will have tons of things to discuss. I would love to decide this today. [02-15-2023 17:47:13] <kayabanerve[m]> We already immediately have a PR to limit size. I believe this is discussing changes to make at time of seraphis. [02-15-2023 17:47:19] <rbrunner> To get it out of the way, so to say. [02-15-2023 17:47:52] <Alex|LocalMonero> Seems like removing it is the option the most people find acceptable. Not that this matters to the technical soundness of it. [02-15-2023 17:48:01] <kayabanerve[m]> We can either: [02-15-2023 17:48:01] <kayabanerve[m]> - Remove [02-15-2023 17:48:01] <kayabanerve[m]> - Call for a ranked choice vote [02-15-2023 17:48:01] <kayabanerve[m]> - say one IRC Nick != one vote [02-15-2023 17:48:22] <kayabanerve[m]> Though as noted, coinbase will still need extra [02-15-2023 17:48:23] <sech1> I said it before, and I say it again: voting is idiotic in a technical matter [02-15-2023 17:48:39] <Alex|LocalMonero> @sech1 where do you stand? [02-15-2023 17:48:42] <sech1> whatever path forward is taken, it must be justified [02-15-2023 17:48:43] <kayabanerve[m]> ... That'd be option #3 :p [02-15-2023 17:48:52] <sech1> I prefer option #1 eventually (after HF) [02-15-2023 17:49:02] <sech1> all needed like tx pubkeys can be moved to separate fields [02-15-2023 17:49:11] <Alex|LocalMonero> I thought this discussion was meant to mean removing it post seraphis? [02-15-2023 17:49:24] <Alex|LocalMonero> Did people discuss removing it now? [02-15-2023 17:49:34] <rbrunner> Why would that matter? [02-15-2023 17:49:45] <Alex|LocalMonero> Time for people to swithc [02-15-2023 17:49:54] <rbrunner> The "when" is a separate question [02-15-2023 17:49:56] <sech1> I mean #1 after seraphis [02-15-2023 17:50:01] <tevador> Seraphis already moves public keys from tx_extra, so it would be purely for arbitrary data then. [02-15-2023 17:50:07] <Siren[m]> UkoeHB: I also vote 1, if my vote counts [02-15-2023 17:50:07] <moneromooo> What would we do with payment ids ? Some poeple like it even with subaddresses available. [02-15-2023 17:50:13] <sech1> before that, it can be size-limited and have higher fee per byte [02-15-2023 17:50:25] <ArticMine[m]> Voting on keeping it or not should be separated from how to keep it [02-15-2023 17:50:31] <isthmus> +1 artic [02-15-2023 17:50:35] <Siren[m]> moneromooo: Deprecate it :)) [02-15-2023 17:50:38] <tevador> moneromooo: payment ids have been deprecated/replaced by encrypted address tags [02-15-2023 17:50:43] <Monegro> Just to be clear a "no change" option is not what anyone wants, correct? Everyone thinks something should be done? [02-15-2023 17:50:45] <jtgrassie> +1 ArticMine [02-15-2023 17:51:15] <kayabanerve[m]> So, it sounds like the agreeable option is remove with Seraphis. The only way to threaten this is to call for a ranked choice vote or to call voting idiotic [02-15-2023 17:51:15] <Alex|LocalMonero> Exactly, as moneromooo points out its very impractical to remove tx_extra prior to seraphis [02-15-2023 17:51:15] <UkoeHB> I think 1 is a strong option. We can divide the options into two categories: A) remove, B) keep in some form. The reason for keeping it is 'all the things we don't know in advance and don't want to depend on a hardfork for'. [02-15-2023 17:51:16] <rbrunner> Monegro: Looks like it, "doing nothing" only got "nos" earlier in the meeting [02-15-2023 17:51:36] <Alex|LocalMonero> ArticMine: -1, there's no point in discussing how to keep it if we decide not to keep it [02-15-2023 17:51:58] <moneromooo> I did not intend to weigh in on the timing fwiw. [02-15-2023 17:51:59] <ArticMine[m]> Of course [02-15-2023 17:52:08] <UkoeHB> From a protocol longevity standpoint, keeping it is better because it reduces the need/desire for future hardforks. [02-15-2023 17:52:12] <rbrunner> At least A) or B) would give a clearer picture after the vote [02-15-2023 17:52:12] <sech1> also, did anyone do a research on how tx_extra is used now? [02-15-2023 17:52:26] <ArticMine[m]> We vote first on whether to keep it [02-15-2023 17:52:27] <MajesticBank> yes wanted to ask do anyone use it for something [02-15-2023 17:52:32] <Lyza> what are the chances rn of having another HF before Seraphis? tx_extra aside [02-15-2023 17:52:40] <tevador> Yes: https://github.com/noncesense-research-lab/monero_tx_extra/blob/master/ascii_data.md [02-15-2023 17:52:50] <Alex|LocalMonero> UkoeHB: soft forks have proved themselves to be a disaster for BTC, hard forks have proved themselves to be a blessing for XMR [02-15-2023 17:52:56] <sech1> tevador 2020 != now [02-15-2023 17:53:02] <ArticMine[m]> Then only if the decision is to keep them we work on the technical details [02-15-2023 17:53:09] <MajesticBank> data might be encrypted [02-15-2023 17:53:34] <tevador> now it's mostly bee videos (anecdotally) [02-15-2023 17:53:59] <isthmus> This room was bridged to tx_extra for a few hours a while back [02-15-2023 17:54:08] <kayabanerve[m]> *a Script for a bee video [02-15-2023 17:54:12] <rbrunner> I am in the "keep" camp mostly for softforks as an emergency option. Not terribly important to me personally what people do with it otherwise [02-15-2023 17:54:24] <MajesticBank> is there info how much data is in tx_fields in total on blockchain? [02-15-2023 17:54:41] <fredsmith> i think the softfork for emergency option can be maintained with tx_extra in coinbase only [02-15-2023 17:54:43] <Alex|LocalMonero> Softforks led to massive fragmentation and tribalization of the BTC network, which doesn't even rely on fungibiliy to work. [02-15-2023 17:54:53] <Alex|LocalMonero> rbrunner: [02-15-2023 17:54:58] <ArticMine[m]> Also we separate coinbase [02-15-2023 17:55:09] <sech1> Does anyone know what's the max size for legit tx_extra usage now? Not counting tx pubkeys? [02-15-2023 17:55:10] <jeffro256[m]> I am also not concerned with soft forks regarding tx_extra. There is good reason why Monero never soft forks: it's bad for uniformity. The community/dev team has always gone with the principle of fast deprecation for non conforming transactions, which is a good thing [02-15-2023 17:55:25] <jtgrassie> size restriction (per #8733) is the ideal stop-gap. One can still do non-standard "experiments" using extra. It may also help in future discussions on whether to keep or kill it. [02-15-2023 17:55:29] <Alex|LocalMonero> soft forks are incongruent with fungibility [02-15-2023 17:55:32] <tevador> If coinbase tx_extra is kept, we can still have a soft fork. [02-15-2023 17:55:34] <rbrunner> I am talking about *emergency softforks for problems that can't wait for a hardfork. [02-15-2023 17:55:35] <kayabanerve[m]> We could keep a 64b extra to hedge against wallet protocol updates? It'd be a minimal size [02-15-2023 17:55:35] <isthmus> There have been some outliers (e.g. 1028 kB tx_extra for one of the txns mentioned above) [02-15-2023 17:55:48] <isthmus> We have size data, though I don't have a summary handy [02-15-2023 17:56:06] <isthmus> NRL uses len(tx_extra) as a go-to fingerprint for clustering transactions [02-15-2023 17:56:15] <Lyza> asking again: if we do this before seraphis, would we be hardforking primarily for tx_extra, or what else might we be trying to do in a pre-seraphis HF? [02-15-2023 17:56:30] <fredsmith> oh boy thats a can of worms [02-15-2023 17:56:56] <blankpage[m]> Removing is easy and good for fungibility, so I change my vote to 1 unless there is a fully sketched out plan of how to keep it in a useful way similar to jethro's idea at a point X months before seraphis [02-15-2023 17:57:30] <rbrunner> Do people want an A) or B) vote? To simplify, and getting a clearer picture? [02-15-2023 17:57:35] <blankpage[m]> basically, it could be useful for unknown applications but unless someone goes the work then it is better to have it gone than as-is [02-15-2023 17:57:47] <tevador> I don't think a hardfork is planned before Seraphis. I think we can survive with #8733 until Seraphis. [02-15-2023 17:57:51] <ArticMine[m]> Yes [02-15-2023 17:57:56] <jtgrassie> yes [02-15-2023 17:57:58] <tobtoht[m]1> I'm for merging 8733 now. We have more time to work out what do with tx_extra in seraphis. [02-15-2023 17:58:26] <UkoeHB> Alex|LocalMonero: hard forks work well for privacy and scalability upgrades, which is all they have been used for up to this point. The tx extra represents utility, so this debate is about A) all future utility changes/innovations that require on-chain data should be supported by hard fork (a change in hard fork policy), B) some future utility flexibility should be baked into the tx extra. [02-15-2023 17:58:37] <Rucknium[m]> Lyza: Possibly ending user-determined output lock time. Improvements to the decoy selection algorithm can be implemented without worrying much about creating anonymity puddles with wallets using different algorithms. I think there are more. [02-15-2023 17:59:00] <moneromooo> I'm going for a bit, so https://dblp.uni-trier.de/pid/128/4640.html has the list of Pedro Moreno Sanchez papers, not obvious which one it might be that suggests an extra solution, I wasn't told. But it's his "latest" work if someone wants to look. [02-15-2023 17:59:04] <ArticMine[m]> Fee scaling updates [02-15-2023 17:59:07] <jeffro256[m]> Before merging 8733, we need wallet-side error checking!! I can PR that today, but we need a mechanism for the wallet to know the tx_extra size limit before constructing and attempting to broadcast a non-conforming transaction [02-15-2023 17:59:10] <Alex|LocalMonero> UkoeHB: the only utility monero should be concerned about is utility as a decentralized electronic and fungible currency [02-15-2023 17:59:20] <tevador> tobtoht[m]1: it would be good to make a decision now because Seraphis is already (mostly) implemented. [02-15-2023 17:59:50] <one-horse-wagon[> Are we going to vote again on "A" or "B" option? [02-15-2023 17:59:52] <rbrunner> After almost 3 years we all deserve a decision [02-15-2023 18:00:02] <sech1> 8733 could be a nice workaround until the actual tx_extra solution [02-15-2023 18:00:14] <Alex|LocalMonero> I don't mind 8733 either. [02-15-2023 18:00:23] * isthmus is 100% OK with relay rules as temporary measures, but notes that relay rules are not a good long-term replacement for consensus rules [02-15-2023 18:00:29] <Lyza> +1 8733 seems like a fine stopgap [02-15-2023 18:01:08] <Alex|LocalMonero> But I agree with rbrunner that this question needs to be solved for the sake of seraphis [02-15-2023 18:01:15] <Alex|LocalMonero> Solved now ideally [02-15-2023 18:01:26] <jeffro256[m]> jeffro256 agrees with isthmus but doesn't know how to talk in third person with the little blue text [02-15-2023 18:01:28] <UkoeHB> one-horse-wagon[: I'd like to table further temperature checks until next meeting. This week I'd like people to ruminate on the A/B distinction specifically, and on the consequences of each one. [02-15-2023 18:01:37] <isthmus> "/me <text>" [02-15-2023 18:01:40] <UkoeHB> this has already been a long meeting [02-15-2023 18:01:50] <tevador> If there are just two options keep/remove, I'd lean towards remove (keep only for coinbase). [02-15-2023 18:02:13] <Lyza> I think my position is that if we don't have a solid use case for it now, something most of the community wants that only can be done with tx_extra, we ditch it. I do think killing the ability to merge mine with monero is worth considering, for sure [02-15-2023 18:02:17] <UkoeHB> tevador: the options are remove or keep 'in some as-yet-undetermined form' [02-15-2023 18:02:24] <Alex|LocalMonero> And by the way @ArcticMine even a 0.1% difference in fees is enough to justify competition in the global financial markets, so 5% is massive. [02-15-2023 18:02:28] <Lyza> not sure if proposals for payments channels used tx_extra or not [02-15-2023 18:02:49] <jeffro256[m]> Let's vote then! Ppurely between A) remove entirely or B) keep is some undetermined form [02-15-2023 18:03:09] <rbrunner> Just want to say that fundamentalist approaches (and I see removal as that) rarely play out well. [02-15-2023 18:03:16] <tevador> Lyza: merged mining would still be possible because coinbase would keep tx_extra (it has to). [02-15-2023 18:03:24] <ypavtv97lx[m]> just remove that garbage and be over with it..... it's used by lazy devs that could do better without it. [02-15-2023 18:03:25] <jeffro256[m]> I mean voting shouldn't decide it, but just to guage what smarter people than me have so say [02-15-2023 18:03:26] <Alex|LocalMonero> rbrunner: was RandomX not a fundamentalist approach? [02-15-2023 18:03:51] <Lyza> next meeting sounds okay if koe thnks so (gotcha tevador, ty) [02-15-2023 18:04:12] <Alex|LocalMonero> I'm old enough to remember everyone decrying that we need to compromise with ASICs [02-15-2023 18:04:15] <UkoeHB> to summarize: [02-15-2023 18:04:15] <UkoeHB> A) [remove tx extra]: tx utility flexibility tied to hardfork (or steganography) [02-15-2023 18:04:15] <UkoeHB> B) [keep tx extra in some optimized form]: uniformity and scaling trade-offs depending on the solution [02-15-2023 18:04:23] <blankpage[m]> Binary referendums where one option is not clearly defined often end in unsatisfying ways [02-15-2023 18:04:35] <UkoeHB> let's end the meeting here, it is past the hour so we should not do any voting [02-15-2023 18:04:39] <UkoeHB> thanks everyone [02-15-2023 18:04:55] <fredsmith> thank you UkoeHB [02-15-2023 18:04:56] <isthmus> Thanks much @UkoeHB [02-15-2023 18:04:59] <ArticMine[m]> Thanks [02-15-2023 18:05:02] <Monegro> ++ [02-15-2023 18:05:03] <Alex|LocalMonero> thanks UkoeHB ! [02-15-2023 18:05:06] <tobtoht[m]1> thanks [02-15-2023 18:05:06] <jeffro256[m]> Thanks y'all [02-15-2023 18:05:08] <hbs[m]> thx [02-15-2023 18:05:09] <rbrunner> I vote for thanking :) [02-15-2023 18:05:12] <jeffro256[m]> Especially koe [02-15-2023 18:05:16] <Lyza> +1 to giving thanks [02-15-2023 18:05:18] <Rucknium[m]> Thank you :) [02-15-2023 18:05:20] <one-horse-wagon[> Thanks. [02-15-2023 18:05:27] <tevador> Thanks [02-15-2023 18:05:36] <ofrnxmr[m]> Thanks Koe [02-15-2023 18:05:48] <fredsmith> when tx_extra tshirts [02-15-2023 18:05:53] <john_r365[m]> Thanks koe and all [02-15-2023 18:05:56] <gonbatfire[m]> Regular user hopping here: [02-15-2023 18:05:56] <gonbatfire[m]> Limiting the size of tx_extra may incentivize users to attach data some other X way [02-15-2023 18:05:56] <gonbatfire[m]> - What would this X way look like? What effects would it have over the network? [02-15-2023 18:05:59] <tevador> The note on A) is not entirely true, you can attach extra data in a soft fork by putting a merkle root into the coinbase tx_extra. [02-15-2023 18:06:53] <UkoeHB> tevador: I think that's cheating lol [02-15-2023 18:07:00] <UkoeHB> but interesting idea [02-15-2023 18:08:23] <kayabanerve[m]> Thanks y'all