00:05:12 I want serai to work but not mordinals 00:09:56 ceetee[m]: both subaddresses and payment IDs are more-than-reasonable current uses of the tx_extra 00:13:05 Don't those things now have their own fields? 00:13:09 No 00:14:13 They will have specific fields in seraphis, but look a bit different than they do now thanks to a lot of refinement. 00:15:23 so removing tx_extra now would break both subadresses and payment ids? 00:15:29 yes 00:15:52 well, it would break all balance recovery since the tx pubkey for normal addresses is also stored there 00:16:01 Break > change 00:16:26 ofrnxmr[m]: only if new fields are added 00:16:43 Right 00:17:59 If we change the tx_extra field (either A or B3), we could add new fields 00:18:08 Removing without adding properly used fields for the data currently contained there isnt an option id ever imagine 00:19:16 ceetee[m]: the tx_extra debate is about how it will look in seraphis, there hasn't been much enthusiasm for updating the current protocol 00:20:17 Well then its even less of a question 00:21:14 my point is, without the tx_extra it's not a guarantee we'd have subaddresses right now 00:22:06 I don't question the historic relevance at all 00:22:45 but think the current state of XMR is advance enough that we know much better where we are going 00:22:57 Compared to a few years ago 00:23:27 that is very optimistic 00:26:29 If the question were what is more likely: we desperate need txextra for a feature or txextra will be abused for some bs, I'd bet on the second option 00:36:35 I think some people in this conversation are forgetting what exactly tx_extra is. We're not talking about smart contracts or even bitcoin-style scripting, instead just some arbitrary bytes. There is no additional functionality added to Monero by it, except for things like subaddresses which... (full message at ) 00:40:09 "If the question were what is..." <- And even if it *just* isn't abused for some BS, for example, even if there are developers making actually useful wallets that give additional features to their users assuming other users also use the same wallets, all this creates a plethora of mutually incompatible subecosystems, with the complexity and incompatibility only increasing over time. 00:41:35 This is the current state of the Bitcoin ecosystem. 00:42:15 But does removing tx_extra actually solve this? They'd just stuff outputs instead, which is way more harmful to us than a dedicated field 00:42:39 politicalweasel[: It doesn't solve this but it closes one of the doors that allows this. 00:43:02 And the outputs door is much less efficient to use, which naturally disincentivizes it. 00:44:06 A lot of use cases would only need 32 bytes anyway, as a commitment. And you're underestimating how much people will pay to do useless shit - loot at ordinals 00:44:10 look* 00:44:30 And also it worsens the senders privacy, if I understood correctly, so users are disincentivised to uses services that need bit stuffing 00:45:24 ceetee[m]: Correct, unless there's full range proofs, as per kayabanerve 00:46:28 People don't care. And it worsens privacy for everyone, ie those using the bloat outputs as decoys, not just the sender. 00:46:44 *membership proofs, not range proofs. 00:47:29 politicalweasel[: You're right but having tx_extra doesn't eliminate this issue. 00:47:47 It merely diverts most of the honest actors not to exploit it. 00:48:07 and how is that not a good thing? and what's the disadvantage of keeping it? 00:52:02 If you enable easy arbitrary data storage you enable not just use but abuse, as ceetee🇧🇪 alluded to. We have no way to predict how an arbitrary data field will be used, what sort of subchains and subecosystems will develop. Look at Bitcoin right now with hundreds of BIPs, incompatible wallets, multisigs, addresses, someone's stuffing NFTs, someone's mixing, others are rejecting those who are mixing etc etc. 00:53:39 I feel like Monero should be as narrowly-defined as possible, the protocol as strict and efficient as possible, for one purpose: decentralized, electronic, fungible (private) digital cash. 00:53:45 Bitcoin's situation is a product of refusal to do a proper (hard fork) update to clean itself up. And again, data storage is still possible without tx_extra. They'll just choose to do it in a way which is much more expensive to the network as a whole. 00:55:26 tx_extra doesn't expand Monero's functionality. It only makes it more extendable. Both for spam and legitimate uses which we don't know of yet. In both cases removal will either result in output spam or holding Monero back from its potential. Relying on Core to hard fork every possible use case into Monero is not a desirable future 00:55:29 To make an analogy, if you have two leaks in your boat you wouldn't make an argument that closing one leak is pointless because there's another leak, right? I understand that there doesn't exist a solution for the outputs exploit at the moment, but I haven't seen proof one way or the other that this is a solvable/unsolvable issue. 00:55:56 Point is, you're making an argument from is, not from ought. I'm making an argument from ought. 00:57:36 Tx_extra is a big but easily pluggable leak of arbitrary data. The outputs exploit is a much smaller leak, but more difficult to plug as well. 00:58:47 "Bitcoin's situation is a product..." <- WE are also refusing to clean up. I was surprised that the data for sub addresses and payment ides don't have their own fields yet, and are still in the tx extra. We should sort that out 00:59:23 ceetee[m]: I believe that this is implied in the seraphis upgrade assuming tx_extra is removed. Right UkoeHB ? 00:59:56 I could use the boat analogy back on you. Attackers can still spam regardless (a leak), but honest users would be forced to spam w/o tx_extra (a leak). You've been arguing that patching the latter doesn't have merit. 00:59:56 We can't force users to use Monero in the way we strictly define. Regardless that's arguably not even a good idea in the first place. Arbitrary data storage will always be possible. And I still don't understand why tx_extra is anywhere near as bad as output spam. 01:00:18 ceetee[m]: fair enough, those should have been given their own fields long ago 01:00:59 They dont, because of Txextra. Its like a junk drawer. Allows laziness 01:03:02 if Monero's dev team is lazy to the extent that it's legitimately causing harm to Monero, then that's not something which will be fixed by removal. besides it's not that "lazy", there just isn't a real reason to "fix" that which would frankly be a waste of dev power which coud've been used elsewhere. Doing it when we overhaul the tx format is a reasonable time 01:03:29 it's preferable to have dedicated fields, but not really a big deal 01:04:33 Im not calling ANYONE lazy. Lets make that clear first. 01:04:33 Leaving it in Txextra is lazy. Leaving depreciated addresses alive is lazy. 01:04:45 oh yes I agree 01:04:57 i guess i misinterpreted 01:05:19 as a user, i am against nfts on monero. yet im still currently spinning up a morbinal node just for the novelty of it. i shouldnt be able to do that. 01:05:50 mordinals would instead just exist by spamming outputs. Then we'd have the same problem at an even higher cost. yay? 01:05:59 > <@politicalweasel:matrix.org> I could use the boat analogy back on you. Attackers can still spam regardless (a leak), but honest users would be forced to spam w/o tx_extra (a leak). You've been arguing that patching the latter doesn't have merit. 01:05:59 > 01:05:59 > We can't force users to use Monero in the way we strictly define. Regardless that's arguably not even a good idea in the first place. Arbitrary data storage will always be possible. And I still don't understand why tx_extra is anywhere near as bad as output spam. 01:05:59 Yes but again, you're arguing is rather than ought. Do you believe that arbitrary data storage is desirable? 01:06:21 in some cases, yes, but in the case of ordinals and similar, no 01:06:28 No. Mordinals would be harder to develop and wouldnt be public on chain. 01:06:36 politicalweasel[: How would you police the cases absent a hard fork? 01:06:47 we don't live in a perfect world 01:06:54 you dont. only mitigate damage 01:06:55 Precisely. 01:07:01 you can't police use cases 01:07:12 its impossible 01:07:26 Its not policing. 01:07:34 ofrnxmr[m]: "harder" to what extent? And why wouldn't they> 01:07:40 ?* 01:08:30 can morbs be pruned out? should be easy to do righ 01:08:32 s/righ/right/ 01:08:44 Pruning takes io 01:08:53 tx_extra can (?) be pruned. outputs cannot, without manual blacklisting 01:09:44 if we have to have morbs id like them to be as pruneable as possible 01:10:36 politicalweasel: it's one thing to say "let's extend the Monero protocol because feature X is useful", it's another thing to say "let's make a dedicated field for anyone to be able to morph the protocol into whatever they like", which will lead to the same state as Bitcoin is at right now. It's true that if you want to write arbitrary data on the chain then it will become harder and more costly, but that's also kinda the 01:10:36 point of having a hyper-focused project: any usage of XMR outside of its primary usage is to be as inefficient as possible to maximize the efficiency of the primary usage. This is especially important given Monero's need to be fungible (hence, homogeneous) 01:11:43 ^^^ 01:11:52 Anyway.... (full message at ) 01:11:54 Like, it's true that I can encode the entire bee movie by registering a long-enough chain of twitter accounts. Doesn't mean Twitter should cater to being a file sharing service. 01:13:09 You can't have the first thing without the second*, that's the nature of flexibility. And you still haven't addressed the fact that removal doesn't stop spam, only makes it more harmful to the network. 01:13:09 *it's not really "whatever they want". Again, we're not talking about smart contracts. 01:13:37 ^^^ 01:14:29 It doesnt make it more harmful. 01:15:08 > <@politicalweasel:matrix.org> You can't have the first thing without the second*, that's the nature of flexibility. And you still haven't addressed the fact that removal doesn't stop spam, only makes it more harmful to the network. 01:15:08 > 01:15:08 > *it's not really "whatever they want". Again, we're not talking about smart contracts. 01:15:08 Removal doesn't stop spam, but neither does keeping it. I don't need to fix the outputs issue to argue against tx_extra. 01:15:15 Thats absolute fear mongering. (Or an accusation that good actors ate actually bad) 01:15:18 > <@ofrnxmr:monero.social> Anyway.... (full message at ) 01:15:23 If steg+output spam is worse than a small tx_extra field, and neither option stops abuse, then it's logically better to have a small tx_extra field 01:16:11 One incentives spam by making it a tool. The other ruins the blockchain. 01:16:22 Spam outputs harms everyone's privacy and bloat the enote set. Way more harmful than a few arbitrary bytes which can be ignored or even pruned 01:16:57 ofrnxmr[m]: Exactly. Tx_extra is a systemic issue while outputs are a rather minor exploit that's only feasible for some use-cases. 01:17:43 Alex|LocalMonero: But removal doesn't actually solve anything. It's not "patching" any "hole", just forcing water into the other one. Legit users would be forced to spam. 01:17:52 The damage to ring privacy is not "minor" 01:18:07 politicalweasel: those arent orbot users 01:18:08 By minor I meant arbitrary data storage. 01:18:10 Keeping it DOES patch a hole, that being legit users not having to spam 01:18:28 Keeping it doesnt patch anything. 01:18:40 It just names people use more tx to write their script 01:18:43 I just explained what it patches 01:18:55 politicalweasel[: That can be done without removal of tx_extra 01:19:23 And anyone who would, is, by definition, an attacker. 01:19:32 nikg83[m]: yes but why force honest usecases to do it? Would you rather 100 people die or 50? 01:19:33 ofrnxmr[m]: But that comes at a higher cost, which is an active incentive against it. System working as intended 01:19:42 politicalweasel[: Legit users doing tx need to spam ? 01:19:42 Not a good actor that is being forced to mixer babies 01:19:43 Murder* 01:20:05 merope: Steg does too 01:20:12 politicalweasel: but I believe that once you zoom out to the bigger picture, you'll see that keeping it will lead to the bitcoinization of Monero (by bitcoinization I mean that the ecosystem will be splintered, mutually incompatible in a lot of ways, many different address types and multisig and wallet setups and NFTs and so on like the Bitcoin ecosystem is now, where the harm for Monero is much worse because unlike 01:20:12 Bitcoin Monero has a goal of being fungible) 01:20:22 nikg83[m]: legit usecases for arbitary data, I mean. Or even non-legit ones, ie ordinals which don't explicity want to attack the network but also aren't really "legit" 01:20:26 politicalweasel[: Who is using tx_extra rn ? 01:20:46 Exchanges 01:20:57 nikg83[m]: see my earlier reply 01:20:58 And bad actors 01:21:02 I don't really buy the argument that removing tx_extra will cause people to spam useless outputs. 01:21:02 I'm sure there's the occasional motivated spammer who really wants their favorite meme on the blockchain no matter that it takes, but I'd bet most will just think "oh, there's nowhere to put it" and give up. 01:21:08 So yes politicalweasel I would rather that kaya uses outputs for his DEX than open the door for the bitcoinization of Monero 01:21:14 politicalweasel[: Is monero a currency or data storage network ? 01:21:36 Its ipfs 01:22:00 Alex | LocalMonero | AgoraDesk: agreed. But he wont. 01:22:14 Alex|LocalMonero: tx_extra doesn't do this though, that's a strawman. Nor does it harm fungibility, at least not any more than output spam. 01:22:16 nikg83[m]: A transaction data storage network. We are now arguing what types of data constitute "valid" transaction data, which includes an optional field 01:22:44 Yes sir 01:23:13 merope: A option field which can bloat the chain ? 01:23:15 nikg83[m]: currecy, but do you think people actually care and will respect that? And regardless, some data storage isn't mutually exclusive to a currency... if that were the case then we'd have to remove subaddresses, etc 01:23:28 politicalweasel[: Why do you think that it doesn't do that when we already have mordinals? 01:23:37 No we wouldnt have to remove subaddresses ! 01:23:44 Let that be clear 01:23:53 Thats nonsense. 01:24:13 Alex|LocalMonero: they can and will spam outputs instead, if it's actually a serious project that has serious intentions of doing what it's designed to 01:24:23 ofrnxmr[m]: that's my point 01:24:41 Its like "putting the dishes away", who would suggest just tossing them in the trash. .? 01:24:51 nikg83[m]: It can also be used to add features without requiring a hardfork every time someone wants to implement a new service thay requires it. And since chain bloat can be acheived even without tx_extra, the chain bloat argument loses value 01:26:10 politicalweasel[: That may be true, but you're, again, arguing how things *are* rather than how they *should* be. You're arguing that arbitrary data is desirable, but only when it's not mordinals. 01:26:17 I do t agree endor00: the arguement doesnt lose value. Quite the opposite 01:27:13 merope: If output exploits happen with or without tx_extra then the discussion should be focused purely on whether we want tx_extra or not. 01:27:13 Not really... I'm saying data storage is inevitable, though desirable in some cases. tx_extra just defines a way to do that while causing the least harm 01:27:31 A. Bad actors do bad actor things 01:27:31 B,3. A+ good actors think they are doing a good thing and will push more a d more 01:28:54 > <@ofrnxmr:monero.social> A. Bad actors do bad actor things 01:28:54 > B,3. A+ good actors think they are doing a good thing and will push more a d more 01:28:54 B3 bad actors have a "lower hanging fruit" way of doing bad things that actually reduces their harm, and good actors are not forced to act like bad actors to do the things they want 01:28:57 again, i'm not convinced that there's any real argument in favor of removal, aside from "following" vague principles according to one's own interpretation. There's not actual harm caused. 01:29:45 politicalweasel[: Would you also be against removing tx_extra if the outputs exploit didn't exist? 01:29:58 A. Legit users AND illegit users AND attackers all "attack" the network 01:29:58 B. Legit users AND illegit users don't attack, attackers still do 01:30:01 "It can also be used to add..." <- New service ? A 3rd party tool? Should monero blockchain be even used for that , for new core features I am sure we can always hf 01:30:01 Now that hf are so slow that most of these features would be well planned in advanced and won’t need such experimental fields 01:30:05 Alex|LocalMonero: If chain bloat happens with or without tx_extra, but its harm can be minimized *with* tx_extra, then tx_extra is the least harmful option 01:30:44 politicalweasel: what insane world do you live in where legit users to illegit things ? 01:30:44 merope: Chain bloat isn't the only variable when it comes to keeping/removing tx_extra. You're forgetting about the bitcoinization argument that I described. 01:30:44 Alex|LocalMonero: maybe. there's an argument to be made that data storage in general should not be outright banned in the first place 01:30:44 Thats what you call greed 01:30:57 ofrnxmr[m]: depends on how you define that 01:31:07 ofrnxmr[m]: That would be the case of Serai using output steg to encode their data 01:31:17 nikg83: 2 hard forks coming over the next 2-3 years 01:31:25 merope: Are you in the opinion we keep tx_extra but cap the size? 01:31:26 > <@busyboredom:monero.social> I don't really buy the argument that removing tx_extra will cause people to spam useless outputs. 01:31:26 > 01:31:26 > I'm sure there's the occasional motivated spammer who really wants their favorite meme on the blockchain no matter that it takes, but I'd bet most will just think "oh, there's nowhere to put it" and give up. 01:31:26 i think this way 01:31:27 And after seraphis we should be good for a while 01:31:46 nikg83[m]: No, I'm very much in the "remove" camp. 01:31:47 nikg83[m]: Yes, option B3 01:32:09 Oh, he was addressing you. 01:32:12 > That would be the case of Serai using output steg to encode their data+ 01:32:12 endor00: precisely. 01:32:12 That is a bad actor by definition 01:32:39 Alex|LocalMonero: Yah I know your stance already 👍 01:32:40 Alex|LocalMonero: Like politicalweasel said, it's a strawman argument 01:32:53 > <@ofrnxmr:monero.social> > That would be the case of Serai using output steg to encode their data+... (full message at ) 01:33:14 You cannot claim to support privacy, while intentionally harming it for profit, to the determent of tour customers 01:33:33 ofrnxmr[m]: forcing output spam IS harming privacy 01:33:41 Forcing spam? 01:33:51 ofrnxmr[m]: And here's an easy solution: relegate your harmful data in this nice optional tx_extra field! :D 01:33:57 (spam which could've otherwise been innocous tx_extra) 01:34:06 Why would someone develop something that is BROKEN BY DWSIGN 01:34:06 politicalweasel[: Nobody is forcing 😂 01:34:08 endor00: politicalweasel please answer the question: if output exploits weren't a thing would you be for tx_extra removal? 01:34:23 You cant force someone to write broken software on purpose 01:34:51 nikg83[m]: If there is no alternative to implement a needed feature, then you are effectively forcing people to break the system to get what they want 01:35:13 Endor: what they want being impossible by breaking it 01:35:31 merope: You don’t harm others privacy to achieve your goal, that’s called a bad actor 01:35:51 Alex|LocalMonero: Right now, no, but I wouldn't be nearly as hardline. Also keep in mind that I'm assuming there's no other harmful data storage method is available. Meaning could possibly be convinced otherwise. 01:36:42 "> <@busyboredom:monero.social> I..." <- i will bloat the chain with monerochans just because it is so simple to do -.- 01:37:16 politicalweasel[: That's important because it demonstrates that there's a difference in values. You don't value Monero's hyper-specialization factor as much as I do, so I feel like this isn't something we can ever reach consensus on. 01:37:49 Wen ccs to attack mainnet 01:39:18 Forcing Kaya to do it, forcing me to do it, whats the differencio. 01:39:18 Bad actors are going to act bad. 01:39:18 Either I have 2 routes, or 1 01:39:19 "endor00: politicalweasel..." <- No: like I said, leaving *some* room to implement features that can connect Monero to other ecosystems and implement advanced features. The risk of spam can be reasonably mitigated by designing tx_extra with some forethought (eg. size limits and/or fee cost). 01:39:19 But the real answer is that until someone figures out how to actually prevent output exploits, the question remains a pure thought experiment - and can therefore have no bearing on real-world decisions *today* 01:40:13 endor00: my full stance was remove in next hard fork, then possibly add back in a new /improved / studied form for Seraphis 01:40:43 Oops, cut off part of the message: * I believe leaving some room is a good idea 01:40:53 * monerobull[m] uploaded an image: (2KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/yOfVJzsWUYaFTKLNlLZpdfhL/grafik.png > 01:40:56 That's fair. I understand your point, but my argument is one of being flexible and reducing damage caused by certain use cases, even at the cost of comprising a strict code of principles. Of course, I do still value fungibility, privacy, etc. 01:41:02 Alex | LocalMonero | AgoraDesk: 01:41:14 (forgot to quote) 01:41:15 monerobull[m]: im gonna do it guys. ill abuse tx_extra just because its so easy 01:41:18 Its not removing any use cases aside from the ability to soft fork 01:41:28 Dooooooo it 01:41:36 its morbin time 01:41:37 Make em max size and dont stop for 6 months plz 01:41:39 Rip 01:41:42 You have to holes for arbitrary data. One gaping and easily-pluggable hole and one smaller hole. You have people who want to shove their arbitrary stuff through those holes. A bigger and free-to-access hole is much easier to shove stuff through, therefore it will be used extensively with massive amounts of stuff shoved through it. If that hole is closed the smaller hole will remain. Only the most determined hole-stuffers, 01:41:42 malicious or not, will utilize it, therefore less stuff will be stuffed. 01:41:42 If you believe arbitrary data is desirable then this argument won't convince you, but I would argue that if you believe that arbitrary data is desirable then perhaps Monero is not the best project for you. 01:41:57 two holes* 01:41:58 ofrnxmr[m]: how much would that even cost 01:42:21 I would thumbs up but only some people have that power in here #emojigate 01:42:37 monerobull[m]: 0.01c per tx, 2160tx/day 01:42:54 Send to yourself. Ie, almost nothing 01:43:02 wait what 01:43:05 > massive amounts of stuff shoved through it 01:43:05 Hence the proposal for a tight size restriction 01:43:14 no way arb data is that cheap 01:43:14 > <@alex:agoradesk.com> You have to holes for arbitrary data. One gaping and easily-pluggable hole and one smaller hole. You have people who want to shove their arbitrary stuff through those holes. A bigger and free-to-access hole is much easier to shove stuff through, therefore it will be used... (full message at ) 01:43:20 Yes cheaper than read data 01:43:22 Real 01:43:42 Also, if plugging one hole causes the other hole to explode and break stuff around it, then having two small but controlled holes is better 01:43:45 wtf im gona use monero as cloudstorage from now on /s 01:43:48 Arbitrary data of literally any kind is harmful to fungibility. And if reducing or eliminating arbitrary data means we don't get to "interact with other ecosystems" then so be it. Monero does its job just fine on its own without other ecosystems. 01:44:20 DiegoSalazar[m]: output spam is way more harmful though, which is the alternative 01:44:29 do morbs even harm fungibility 01:44:32 they use preset outputs no? 01:44:33 yes 01:44:44 * yes they harm fungibility 01:44:46 It only precludes interacting with other systems that absolutely necessitate data to be written into the Monero chain Diego Salazar . The overwhelming majority of other systems don't require that. 01:44:46 monerobull[m]: for ring members 01:45:18 DiegoSalazar[m]: But that's the point: removing tx_extra would not eliminate harmful data. Rather, it would force people to put it in an even more harmful place, causing bigger damage overall 01:45:36 It doesnt force people to. 01:45:44 politicalweasel[: Malicious actors can spam outputs regardless of tx_extra, we need to fix that issue as well. Sorry for repeating myself but I'm exhausted that the two holes get merged. 01:45:49 ofrnxmr[m]: you know what we mean :/ 01:45:52 Bad actors arent going to spam using Txextra, they are going to do both. 01:46:23 And good actors will unintentionally do more than bad actors simply by using the protocol the way it was designed 01:46:23 ofrnxmr[m]: explain. 01:46:25 Example 01:46:37 Kaya with 5000tx/day and view keys posted 01:47:03 If I have two bugs, one is easy to fix and one is hard to fix, I won't refrain from fixing the easier-to-fix bug just because the harder-to-fx bug exists politicalweasel . 01:47:03 ofrnxmr[m]: If they want to put it somewhere, they *will* put it there, because they can. So giving them a less harmful alternative is the preferable option 01:47:20 endor00: if an xmr based exchange wants to put it there, it wants to die fast 01:47:25 And kill monero with it 01:47:31 It's like giving clean needles to drug addicts: they still have a drug problem, but at least they avoid giving hepatitis to eachother en masse 01:47:39 So, its not even a realistic assumption 01:47:44 Alex|LocalMonero: but my point is that the easier-to-fix "bug" will just lends its "vulnerabilities" to the much more dangerous and harmful "bug" 01:48:03 Security through obscurity 01:48:29 Lets hope bad actors are nice and only use Txextra, and lets hope good actors are nice and dont steg 01:48:32 Both of those thought involve drugs 01:48:58 ofrnxmr[m]: You don't know that, and can't assume that 01:49:11 Dont know what? 01:49:21 ofrnxmr[m]: most arbitrary-data-users don't wish harm to Monero. only explicit attackers. 01:49:22 That it would die fast 01:49:24 That it wants to die? Or that it wants to put view keys up? 01:49:25 politicalweasel[: Yes but by leaving the easier-to-fix bug open you divert merely a subset of the damage away from the main damage-generating-bug. You just hope that the diversion of the good guys is enough to keep the damage by the bad guys below an acceptability threshold, which there is no reason to assume 01:50:03 merope: If you ran an exchange and poisened 60% of outputs via steg. Are you really going to use xmr to secure your liquidity? 01:50:06 Cmon now 01:50:23 Thats like opening a vegan steakhouse 01:50:25 Lets put aside those who want to do harm for a minute. I'd think leaving it in signifies to a lot of people, even well meaning ones, that it's OK to build a lot of things that would harm fungibility further. 01:50:50 DiegoSalazar[m]: Exactly! 01:50:59 ofrnxmr[m]: Users gonna use services without knowing how things work under the hood. If that service gets popular, it will do so regardless 01:51:02 Diego Salazar: I know it sounds like in poking at kaya but im not 😂. 01:51:02 Just the best metaphor I can use 01:51:05 Alex|LocalMonero: again, the existence of bad guys isn't an argument against mitigating damage caused by good guys 01:51:35 i'll be gone for 10-15 minutes 01:51:39 ...... good...guys.... dont 01:51:39 ... premedite... bad...behavior... 01:52:21 Diego Salazar: hence the proposal to keep the field but restrict its size to something like 128 or 256 bytes 01:53:10 politicalweasel[: Yes, but neither is ignoring the existence of bad guys 01:54:03 Unless you're arguing that the good guys are what will carry the output poisoning issue over the acceptability threshold, which I don't think you are. 01:54:25 You're only acknowledging that this is an issue that needs to be fixed. 01:54:49 > <@ofrnxmr:monero.social> ...... good...guys.... dont 01:54:49 > ... premedite... bad...behavior... 01:54:49 ofrn can you help me get morb running 02:01:00 The dynamic size limits are never more than 11 hours away from allowing ~30MB blocks, so long as the fees are paid to make it happen. 02:01:00 I suppose it is not impossible for something like this to make that happen. 02:01:00 My takeaway is to have a high performance node and mining rig ready. 02:01:41 s/to make it happen// 02:05:29 "Unless you're arguing that the..." <- the "acceptability thresehold" is 0. But 1 is better than 2. And 2 is better than 3. And so on. 02:05:51 > <@spackle_xmr:matrix.org> The dynamic size limits are never more than 11 hours away from allowing ~30MB blocks, so long as the fees are paid. 02:05:51 > I suppose it is not impossible for something like this to make that happen. 02:05:51 > My takeaway is to have a high performance node and mining rig ready. 02:05:51 isn't there a long-term dynamic blocksize cap which prevents taht 02:05:53 "Diego Salazar: hence the..." <- 128, but enforced on all tx should be fine to keep uniformity & removal/further reduction to be studied till seraphis/w.e next big hf comes 02:06:16 * isn't there a long-term dynamic blocksize cap which prevents that 02:06:42 nikg83[m]: I was kind of thinking all tx extra should be padded then, yeah. 02:06:43 I'm not a fan of enforcing on all txn's. Needlessly increasing tx sizes 02:07:08 Fungibility above all else. 02:07:27 DiegoSalazar[m]: That option was also considered, but most people seemed against it 02:07:28 DiegoSalazar[m]: Security? Censorship resistance? Reliability? Sustainability? 02:07:47 not that tx_extra directly impacts all of those, but still 02:07:50 32 bytes max. Anything they want to say can be said in that space. :P 02:08:21 politicalweasel[: Yes. 02:09:09 We already have "secure" blockchains (for some definition of secure) 02:09:18 We already have "reliable" blockchains. 02:09:27 We have no other fungible blockchains. 02:10:05 so then we should just remove the blockchain and have Monero operate on "I send you 1 XMR"? Completely fungible. 02:11:57 "> <@spackle_xmr:matrix.org..." <- That is the long-term cap taking effect.... (full message at ) 02:13:06 Here's a simulation I wrote off that document, if you feel like checking my work: https://github.com/spackle-xmr/Dynamic_Block_Demo/blob/main/Dynamic_Blocksize_v16.py 02:13:48 politicalweasel[: Lol. Then it wouldn't be a blockchain. It must be a fungible blockchain. Not just a fungible. 02:14:57 spackle_xmr: wait so the long term cap is 50x? Am I reading that correctly? 02:15:28 Diego Salazar: fine, then we'll have a blockchain consisting of "XXX sends user XXX 'XXX' XMR" 02:16:29 politicalweasel[: Once the penalty median M_N is no longer restricted by the short term median, it is restricted by 50 * M_L. 02:16:29 Then the maximum possible block size is 2 * M_N, assuming that enough fees are paid. 02:16:29 Note that the amount of fees required for this is absolutely massive. 02:16:30 * Diego Salazar: fine, then we'll have a blockchain consisting of "Unknown user sends unknown amount to unknown user" 02:16:55 politicalweasel[: This isn't the gotcha you think it is, as the goal is indeed to make it as close to this as possible to an outside observer who is not either party in the transaction. 02:18:17 DiegoSalazar[m]: Then let's do it. Hard fork next month to remove all this "cryptography" crap 02:18:42 I understand your hyperbole extends even to the parties in the tx, because then it is completely 100% fungible. But the concessions to let it be used as a currency mean the parties themselves must see what's going on. 02:19:20 Beyond the necessary concessions that let it be used as a currency, nothing else should be considered that would weaken fungibility. 02:19:48 Tx extra is not needed for currency functionality. 02:19:56 that's not the point. it's that a "currency" who's only property is fungibility is not really a currency 02:20:45 DiegoSalazar[m]: Again, output spam DOES weaken fungibility, which is the alternative to tx_extra. 02:20:57 "Fungibility above all else" doesn't mean we have nothing else in there. :P it means that when we come to a crossroads, and one path harms fungibility, we prefer the alternate path. 02:21:24 Okay that's at least a more reasonable statement 02:22:39 Ye. Sorry for my desire to be "twitter brief and punchy" robbed me of the nuance I needed to get the point across well. 02:33:40 > that's not the point. it's that a "currency" who's only property is fungibility is not really a currency 02:33:40 What properties must a currency have ? 02:34:52 Currency is a service to be exchanged for goods and services. 02:34:52 Currency as a service is fungible transfer of value. 02:38:59 well for one, security. currency is pointless if it is insecure, ie if it can be duplicated or trivially stolen. A fungible coin is worthless if I can magically steal it from you or magically turn it into 10. 02:47:44 So turn up the hashrate 04:23:42 "the "acceptability thresehold..." <- 1 is better than 2 but 2 with no tx_extra that closes the biggest door on bitcoinization is better than 1 that swings the bitcoinization door wide open, would you grant me that? :) 05:05:59 You still haven't really solidly explained why tx_extra will result in "bitcoinization". There are 2 main "branches" of bitcoinization, as I see it.... (full message at ) 05:06:44 oops didnt finish #1: ...like I said, Monero should be simple and standard but extenable 05:07:09 s/extenable/extendable and flexible/ 05:08:35 When you say extendable and flexible, you mean on-chain, right? But you can't have a simple and standard and extendable chain at the same time, or am I misunderstanding something? It would seem to me that if you allow anyone to soft fork with tx_extra you inevitably reduce simplicity, do you not? 05:10:16 Monero's baseline format should be simple, but also flexible to be built upon and extended by external users 05:10:33 I guess that's a slightly better way to say it 05:12:29 Right, but if you're talking about that capability being on-chain then I don't see how you won't end up in the same place that Bitcoin did. The xkcd about standards comes to mind: https://xkcd.com/927/ which is projected in the BIP library :) https://github.com/bitcoin/bips 05:16:12 So if a protocol can/will be used/abused to its maximum extent, it would seem to me that that abuse needs to be limited/discouraged/disincenticized to the greatest possible extent, by closing any potential doors. And while one may say that you can never really close all the doors that feels to me like making the perfect the enemy of the good. 05:18:26 I'm not really talking about standards though. There should be one standard address format, and one standard transaction format, with very little or no exception. Simple. I'm talking about things like DEX's or atomic swaps and so forth, where Monero itself isn't being changed but built upon to create something with it. Users generally shouldn't have to deal with non-standard "stuff" unless they explicitly seek it out. 05:19:37 (unlike bitcoin, with its several address/transaction formats) 05:19:49 * its several standard address/transaction formats) 05:20:24 But if you allow tx_extra then you necessarily allow a similar address fragmentation to develop. Recall that integrated addresses are just base address + tx_extra. 05:22:02 It would seem to me that you're not advocating for tx_extra (arbitrary data field) specifically but for a field that can be dedicated for, say, DEX interfacing. 05:23:05 Also, recall that Haveno, a DEX, does not require tx_extra. And IIRC atomic swaps don't need it either. 05:29:35 Fair point, but I think subaddresses should have been made standard long ago, and integrated addresses disabled. It's probably not worth it at this point with Seraphis approaching, but whatever. That's something we need to do as a community, not something that should be preemptively blocked by strictly solidifying the tx protcol. Allowing subaddresses to be phased in via tx_extra wasn't the worst thing in the world, but 05:29:36 it should have been temporary. 05:29:36 You can't predict use cases, though. Just because what exists now doesn't require tx_extra, doesn't mean it can't be useful. But again, either way, there's an argument to be made that discouraging output spam alone is enough to justify tx_extra as a "put your crap here instead of outputs" thing. 05:33:38 in fact come to think of it, this situation has a parallel with OP_RETURN. Core tried limiting it to 80 bytes, so ordinal spammers just used the segwit loophole instead. Luckily for Bitcoiners, it isn't too harmful besides the raw blockspace, but that's not the case for us. On-chain ordinals won't fit on Monero either way, but smaller 32 or 64 commitments definitely could 05:34:04 people will find a way around restrictions if they want to 05:35:01 * in fact come to think of it, this situation has a parallel with OP_RETURN. Core tried limiting it to 80 bytes, so ordinal spammers just used the segwit loophole instead. Luckily for Bitcoiners, it isn't too harmful besides the raw blockspace, but that's not the case for us. On-chain ordinals won't fit on Monero either way, but smaller 32 or 64 byte\ commitments definitely could 05:35:05 * in fact come to think of it, this situation has a parallel with OP_RETURN. Core tried limiting it to 80 bytes, so ordinal spammers just used the segwit loophole instead. Luckily for Bitcoiners, it isn't too harmful besides the raw blockspace, but that's not the case for us. On-chain ordinals won't fit on Monero either way, but smaller 32 or 64 byte commitments definitely could 05:36:20 Would you agree that defining the Monero protocol as strictly and simply as possible with maximizing transaction efficiency (in the sense of monetary transactions: medium of exchange, store of value, global monetary base) while maintaining decentralization and fungibility (which necessitates confidentiality and homogeneity) should be the prime directive? 05:38:11 I mean I don't think a flag to include either 0 or 256 bytes of tx_extra is a massive complication. We aren't talking about smart contracts here. I value simplicity, but also see value in the extensibility I was talking about earlier 05:38:37 (or 128 bytes, or however many) 05:38:48 that part doesn't really matter 05:39:09 Well, as mentioned previously even 16 bytes is enough to have address fragmentation (IIRC integrated addresses use just 16 bytes of tx_extra). 05:40:12 well in theory you could do it with just 4 if you're ok with "only" having ~4 billion addresses to choose from. That kind of misses the point though 05:41:56 So you can't have tx_extra, especially not one as large as 256 bytes, and not have the potential (or, perhaps more accurately, have the guarantee) for address fragmentation. 05:47:35 The *potential* yes. Though if we were really desperate for some reason then a new address format could also use spam outputs, but that's not my point. 05:47:35 Integrated addresses were hastily strapped onto CryptoNote, and it shows. We, as a community, are responsible for maintaining a clean protocol. If we can't do that then we're screwed anyway, tx_extra or not. The legacy system of CryptoNote and integrated addresses and wishy-washy tx_extra and so on wasn't kept clean, and Seraphis is a new start. We've cleanly solved the fundamental problem that integrated addresses poorly 05:47:35 solved, so that issue isn't likely to arise again. 05:49:27 After all Monero started out as another low-effort fork of ByteCoin. Even in post-RingCT Monero there are remnants of that. Seraphis will basically not have any 05:49:39 s/post-/current / 05:52:02 politicalweasel: are there any chains that eliminated the vulnerability of output spamming? 05:52:18 no, because it's impossible 05:52:39 well, not without just banning all transactions lol 05:54:03 So, this issue is separate to having tx_extra or don't. If someone seriously wants to attack Monero will do it no matter the cost 05:54:36 this was discussed already 05:54:48 there's more to it than that 05:55:58 Ok, I just wanted to be clear 05:59:55 By the way politicalweasel , spamming outputs is only a privacy issue while we don't have full membership proofs, which may change soon. We're left with it being costly to stuff arbitrary data into the chain as opposed to arbitrary data costing the same as any other data in the case of tx_extra. 06:00:21 s/We/Without the privacy issue, we/, s/tx_extra/tx\_extra/ 06:01:09 Which, to me, is a desirable outcome. 06:03:47 So, if you have tx_extra then address fragmentation is not disincentivized. If in order to have a wallet app with address fragmentation you need to generate more outputs you'll have to pay a disproportionally higher cost than wallets that are using the standard Monero protocol, hence, your wallet is outcompeted by the standard implementation. 06:07:17 Do full membership proofs require accessing the enote set at all, or only a constant-sized "root" of some sort? If so, then that's still worse than tx_extra. If not then I'd probably be okay with removal, but we'll cross that bridge when we come to it. There is still a higher cost due to verifying rangeproofs, but that's not the end of the world. 06:07:17 Using tx_extra should be more expensive than not, so there's not really a significant change there. But again, that's a community responsibility. 06:07:50 "if so" as in still having to access the enote set 06:08:29 I dont like that political weasel is making arguements based on feelings and mixing in alot of assumptions or "what ifs" 06:08:42 Where there are real answers to some of said assumptions 06:09:16 like what? what's a "what if" I've used which isn't reasonable? 06:09:21 Example 06:09:21 Why are you voting "its ok because Seraphis is coming" 06:09:21 When is Seraphis coming? 06:09:21 Exavtly. Its not ok to just wait around 06:10:27 I didn't mean it's something to not care about, but that since Seraphis is approaching anyway it's likely not worth the effort to change anything unless we have a hard fork in-between anyway (ie for BP++) 06:10:46 Exactly = you dont know. 06:10:46 It could be 2 years, it could be 6, it could have been a year ago 06:11:25 "Likely" not worth the effort. You're just speaking your opinion. 06:11:56