00:04:06 "By keeping the field but size..." <- If the size is fixed then every user will be paying for tx_extra regardless if they're using it or not, which means that, say, 99% of honest users are paying more fees due to 1% non-financial usage. If the size is not fixed and can be zero then you end up breaking fungibility. Both scenarios also lead to bitcoinization. 00:05:06 "Preventing steg is impossible..." <- You don't need to make steg impossible, you only need to make it impractical. 00:35:52 tx chaining is independent from the 10 block lock 00:36:28 Alex|LocalMonero: yes, which is why i favor B2/3 over B4 00:36:48 Alex | LocalMonero | AgoraDesk: It's not "breaking" fungibility, for the reasons already mentioned. Besides, things like Ordinals dox their own relevant tx's anyway so they're identifiable regardless. You can't prevent people from degrading their own privacy if they really want to, and trying to shoot them down will just be an endless cat-and-mouse where bystanders are caught in the crossfire. Restricting to 2 outputs is 00:36:49 another example of this. All it does is hurt UX and needlessly bloat the chain, meanwhile spammers just make use of chained transactions. Or maybe their protocol uses self-sends anyway, so it doesn't even affect them. You say that these speed bumps will discourage abuse but... no, it won't. 00:36:49 Someone correctly pointed out earlier that these minor annoyances are just one library away from being easily defeated. And, again, if someone is going through the trouble of creating a new app or whatever in the first place, they'll probably accept the 5 minutes it takes to bypass all of these limits. Preventing spam will be a never ending witch hunt of removing functionality when we could just define a way to do it 00:36:49 which causes the least damage. 00:37:45 Like bitcoin 00:38:09 Looks like a lovely blockchain right now. So many real tx /s 00:38:48 politicalweasel[: stopping people ruining their own privacy is different to users degrading others privacy 00:39:07 that's why tx uniformity is important 00:39:54 How? If those real tx are being exposed to the public as fake 00:39:59 yes, but part of my argument is that the improvement to tx uniformity is negligible in practice and outweighed by the damage caused by output spam 00:40:38 Uh. Look at btc and tell me more out output spam 00:41:03 What about it? 00:41:06 https://mempool.space/mempool-block/150 00:41:42 I still don't get the point 00:41:49 ofrnxmr[m]: because it's not the odd individual here, its a protocol being aiming to mass (ab)use the Monero blockchain 00:42:12 Serai uses Txextra and posts view keys 00:42:36 which I also think is harmful 00:42:47 Nfts use Txextra and will do the same 00:43:10 again, which I think is harmful 00:43:17 Output spam? Without full membership proof these use cases are useless 00:47:06 If someone wants to steal my car, they will do it. So ill just leave it unlocked with the keys in the ignition so that they can borrow it instead 00:47:55 That way, they wont break my window. 00:49:31 that's not an accurate analogy, the point is that removing tx_extra doesn't actually solve the problem while making the damage worse. 00:49:47 That is exactly what I daid 00:49:58 Txextra is lending my car to strangers 00:50:26 But removing it is doing the same. There's no meaningful difference 00:50:28 Disabling it doesnt stop people from stealing it. They can steal and damage my car whether I leave the keys or not 00:50:31 unless having the keys to a car 00:50:44 unlike* 00:51:46 If someone wants to steal my car to go do burnouts, theyre going to do it. 00:51:46 Im not offering my car for purposes that damage it 00:52:10 Output spam is mitigated by simply limiting the number of outputs. With tx chaining this limit won't even matter it would seem. Keeping tx_extra only reduces output spam under a very specific circumstance that there's no limit on outputs and the degraded data storage efficiency burden is economically feasible to overcome to make your app competitive in the market. These are very tough conditions to satisfy. So keeping 00:52:10 tx_extra only eliminates a narrow "honest" subset arbitrary-data-injecting of output spammers, while doing absolutely nothing to mitigate malicious actors (the security assumption) and contributing to a permanent degradation of fungibility as well as bitcoinization on top of that. 00:52:10 The "cure" that jtgrassie and co are proposing seem to be not only worse than the disease but also don't even cure the disease. 00:54:11 I'm not suggesting a "cure", merely steps that can be taken to mitigate the issue 00:54:39 Step 1 remove 00:54:39 Step 2 membership proof 00:54:39 Step 3 revisit 00:55:09 Step 1 incentivize 00:55:09 Step 2 panic 00:55:09 Step 3 membership proof 00:55:31 Because Alex, even restricting to only 2-outs and no tx-extra, still doesn't "cure" the issue 00:56:41 Bad outputs arent as big of an issue if real tx volume was higher, or the decoy selection also was better, or if we excluded coinbase from ringmember etc 00:56:50 Alex | LocalMonero | AgoraDesk: "With tx chaining this limit won't even matter it would seem" ... thus it doesn't matter for output spammers either. If you can limit outputs while relying on chaining to maintain a good UX for users, then the same is true of spammers. 00:56:50 Again, you're underestimating the money people are willing to waste. Ordinals spammers are already paying tens of dollars just for the meme. And Monero fees are astronomically cheaper. 00:57:21 And yes ofrnxmr, a full membership proof certainly more desirable, but that's some way away 00:57:29 jtgrassie: Correct. But it maximizes transaction uniformity, fungibility, disincentivizes arbitrary data storage to the greatest possible extent, and mitigates bitcoinization. 00:57:41 ofrnxmr[m]: not if the enote set must still be scanned by nodes to verify a transaction, and/or if they cannot be pruned. 00:58:17 which may be the case of full-membership proofs, to be fair, but I don't know enough to speak on that 00:58:27 or NOT be the case, rather 00:58:57 Alex|LocalMonero: yes, but it's downsides are no more batching 00:58:59 Im saying high tx volume + large blocks + nfts might not be bad. 00:59:00 Low tx volume = spam outputs 00:59:47 and the car analogy still doesn't work. The car is getting stolen anyway, tx_extra or not. Giving the keys has no effect. 00:59:56 Itbdoes have an effect 01:00:30 Leaving the keys = for some reason my tires wear a lot faster 01:00:43 Probably because im offering free wheels to whoever wants it 01:01:06 you still havent addressed the fact that removing tx_extra solves nothing 01:01:44 and isntead of "keys" it's more accurate to say you get to choose between them using a bazooka or a baton to get into your car 01:01:57 Everybody knows you can steal a car. Only bad actors do it 01:01:57 If you have access to borrow a car, you will do that. 01:01:57 The demographic of borrowers and thiefs are not the same 01:02:07 Thieves 01:02:16 > <@politicalweasel:matrix.org> Alex | LocalMonero | AgoraDesk: "With tx chaining this limit won't even matter it would seem" ... thus it doesn't matter for output spammers either. If you can limit outputs while relying on chaining to maintain a good UX for users, then the same is true of spammers... (full message at ) 01:02:42 jtgrassie: With tx chaining you have what is essentially batching. Ask tevador 01:02:44 Will someone who wanted to borrow your car just steal it if you dont offer the keys? Sure. But we call that a wrench attack 01:05:00 Thats not a friend who wants to borrow a car, thats a thief. Thats not someone who wanted to use your car for valid purposes, its someone who doesnt care about you or your car 01:05:13 Alex|LocalMonero: chaining doesn't achieve quite the same thing as batching. Presently batching allows paying 16 different people in a single tx 01:05:32 chaining doesn't do that 01:06:30 It kinda does, though. Albeit slightly less efficiently, depending on the actual implementation. 01:07:04 yes I understand that, but it's more costly, so hurts honest users 01:07:14 Alex | LocalMonero | AgoraDesk: 1. Then you do 1 steg per tx, each being a self-send. Simple. 2. I'm not convinced it's that much of a cost difference, though maybe I'm wrong. Also we're talking more like 10 cents vs 30 cents, if anything. Unless you're okay with "bitcoinization" where simple transactions cost 10's of dollars. Output spam also has a higher cost to the *network*, which isn't factored in with raw tx fees to 01:07:14 the spammer 01:08:11 steg is actually quite limited currently, due to the output count restriction 01:08:15 jtgrassie: the overwhelming majority of users will not be batching transactions, see how few txs there are with more than 2 outputs 01:08:45 sure I get that, but exchanges and pools are still honest users 01:09:10 ofrnxmr: but again you're not "giving the keys". It makes it sound as if theres a sort of solid moral reason to object in defense of your property rights, when there's not. with tx_extra, you're not giving keys, you're either giving them or a baton or they'll use their bazooka regardless. There's no getting around it 01:09:37 No. You're giving them keys. You're inviting usage 01:09:39 jtgrassie: Not really. Current RingCT steg could do more than B3 would provide, easily. 01:09:46 (256 bytes) 01:09:55 You're saying "heres 256bytes. Go wild" 01:10:58 but the "keys" of tx_extra don't open the car. They can get in with their own "universal remote" 01:11:06 jtgrassie: As a representative of a business that batches our withdrawals, but also as someone who wants Monero to be the best it can be with maximum fungibility and tx uniformity, I can say that we can easily shoulder the slight increase in fee for the fungibility/privacy benefit that all our users will get when there's tx chaining that their outputs no longer standout as being part of a batched transfer most likely done 01:11:06 by a pool/exchange/trading_platform. 01:11:12 politicalweasel[: "could do more than B3 would provide, easily"<- depends on size of B3 01:11:30 politicalweasel[: Called breaking the window and hotwiring it 01:11:41 true 01:11:42 uh no 01:11:46 Alex|LocalMonero: indeed, which is why I do not disregard your comments 01:11:58 * true (to jtgrassie ) 01:12:04 Yes. Steg = breaking the window 01:12:12 And taking the car anyway 01:12:28 Just with a bit more work and damage 01:12:57 And more importantly, demographic 01:13:14 ofrnxmr[m]: ^^^The part that seems to go over everyones heads 01:13:43 jtgrassie: It was very costly for us to switch from integrated addresses to subaddresses (when we launched subaddresses didn't exist) but we did so to maximize our users' privacy by preventing off-chain linking. Assuming we have tx chaining available to us, it becomes realistic to process our withdrawals in a way that every user's withdrawal tx looks exactly the same as any other tx and doesn't stand out like batched 01:13:44 withdrawals do on the network. 01:14:21 And because of Txextra, exchanges can still opt to say eff subaddresses and use integrated addresses 01:14:22 ofrnxmr: You still haven't defined the actual real difference as it applies to Monero. We can argue back and forth about analogies all day, which is what we're already doing. Unless you can make a legitimate logical case against tx_extra then I have to assume you're arguing emotionally, which ironically is what you were accusing me of doing earlier 01:15:03 Politicslweasel its hard to talk to you because you dont seem to understand what youre trying to speak on 01:15:07 Alex|LocalMonero: yes I'm aware, again, reasons why I don't disregard your comments 01:15:14 Which is why everyone turns to metaphors 01:15:36 ofrnxmr[m]: tx_extra is, like, miners adding extra transactions, right? /s 01:16:14 Alex|LocalMonero: so you're strongly in favor of 2-outs and removal of tx_extra? 01:16:25 Yup. 01:16:25 seriously though if you can't address me then that's not my fault 01:16:39 2-outs assuming there's tx chaining. 01:17:26 Alex|LocalMonero: I don't think you need the chaining caveat, as code can create batches of txs 01:18:12 If I say it isnt your fault, I would be insulating you intentionally. So ill just leave it at that. You said it, not me. 01:18:15 Enforcing 2 outputs just turns one transaction into several. this is true of both spammers and regular users 01:19:22 yes, but it does limit the effectiveness of steg for things like inscriptions 01:19:25 unless there's an argument that enforcing 2 outputs itself, outside of this whole discussion of spam, has a significant impact on fungibilty. 01:21:40 jtgrassie: not really, just draws them out. On-chain jpeg inscriptions wouldn't practically fit on Monero regardless, whether we do A or B3. 01:21:56 unless B3 has a very high size 01:22:48 "Alex | LocalMonero | AgoraDesk..." <- Unfortunately due to the 10-block-lock it's a big risk that if you create batches of txs you'll run out of outputs and users will need to wait 20 minutes. 01:23:35 I managed to build morbius, this is what I did:... (full message at ) 01:23:53 Nfts coming asap 01:24:48 Ill let them know about the 256byte limit so that can efficiently spam the network 01:25:10 Them meaning us 01:25:56 If its going to be supported, im not cancelling anybody who wants to use it for whatever they choose within morals and law 01:26:21 If monero is intended to be used to burn outputs for nfts, so be it 01:27:03 you're now clearly arguing emotionally. I keep making the point that removing tx_extra doesn't actually solve anything, but you're pretending that I'm "a monster who supports mordinals" 01:27:18 Im not 01:27:38 You think im joking? 01:28:09 There are other conversations going on as we speak yknow 01:30:11 People arent trying to build the software because they are emotional. They are trying to build it because, afaic its a community project 01:30:40 Or a part of our ecosystem, and the code seems to be available. 01:31:14 Emotional is boycotting them. Were just embracing the fact that we ignored nfts for years because we wanted monero to be pure 01:49:52 "you're now clearly arguing..." <- Why would removing tx extra still not stop NFTs on the chain? I want to understand why was it such a difficult discussion in the first place in 2020 01:50:51 No to technical, but like I’m 5 haha seem like in the other chat it’s a complex discussion with many pov, 3 years worth of consideration 01:52:47 XMR Priest: long story short, they would be put into outputs instead which causes even MORE damage than using tx_extra. Of course I recommend that you read the entire discussion over the past several days but I know it's long and boring and technical so I don't blame you if you don't want to 01:53:43 I see, is there no way to avoid them putting them in the outputs and can’t they do that right now if they really wanted too 01:54:09 there are many complex arguments for and against removal, but I'm against removing 01:54:20 And thank you, yea I was scrolling through and didn’t know where it started haha but I’ll give it a shot 01:54:37 How about limiting to a smaller amount 01:54:51 Of space possible to put in the chain 01:54:52 XMRPriest[m]: no they could do it now, but they currently have tx_extra instead so they don't have to 01:55:34 Makes sense, is there no way to avoid or prevent usage of outputs other then transaction amounts ? 01:55:36 Yes, the pro-tx_extra crowd (including me) most favor restricting to 256 bytes. 01:55:47 no, there's no way around it 01:56:05 * "I see, is there no way to avoid them putting them in the outputs and can’t they do that right now if they really wanted too" Yes, the pro-tx\_extra crowd (including me) most favor restricting to 256 bytes. 01:56:15 * "How about limiting to a smaller amount" Yes, the pro-tx\_extra crowd (including me) most favor restricting to 256 bytes. 01:56:18 politicalweasel[: Why is that ? 01:56:57 Txextra uses outputs. Smh 01:56:58 Guess it seems like picking the least worse situation 01:56:59 because there simply isn't a foolproof way to detect it. It can theoretically mitigated but not actually prevented 01:57:07 Its just ON instead of IN 01:57:12 ofrnxmr[m]: tx_extra is transaction-wide 01:57:29 not tied to a specific output 01:57:30 you cant use Txextra without generating a tx 01:57:40 yes 01:57:53 Is there better privacy if they put them in the output then the tx extra ? 01:57:56 Im frustrated 01:58:13 Since the output would mimic a normal transaction ? 01:58:16 Or would it fuck things up more 01:58:18 XMRPriest[m]: that's part of the argument 01:59:07 Yea I think it comes down to how do both rings look during chain analysis a NFT in tx extra or output and which one maintains privacy 01:59:07 ofrnxmr[m]: we all are. we all want what's best for Monero and the lack of agreement is frustrating to everyone 01:59:49 Im frustrated because of typing 01:59:56 A real meeting this is an easy deal 02:00:06 Bunch of noise and I feel bad for everyone involved 02:00:19 Hard to explain stuff in a format like this 02:00:38 I’m just mad that this is something we can’t prevent or stop but need to deal with 02:01:00 Only trolls and threats want NFTs on monero and we can’t do anything about it 02:01:51 Noooo 02:01:56 Supported feature, EFF off 02:25:41 i know its apples and oranges, but the "stuffing data on-chain is inevitable so we might as well" feels similar to "ASICs are inevitable, so we might as well". again, there are obvious, *obvious* differences, but it just makes me ponder if something clever just hasn't been imagined yet 03:04:17 "We have Kaya here telling us..." <- What happens in a scenario where Kaya uses his abilities to build Serai and use steg. We can't stop Kaya from doing this unless we remove both tx-extra and the ability to peform steg by smart people like Kaya, which seems difficult to remove both of these in practice. But then no-one uses Serai. The ouput set will suffer minimal damage. I can see a world where even 03:04:17 if Kaya builds Serai, people don't use it because they avoid UTXO's of any chain like the plague and only transact with physical objects or encrypted blobs (Monero outputs). All UTXO chains gradually fall to zero as the market finds out the value of privacy. This hasn't happened yet and empirically UTXO chains have done well because many individuals don't understand the cost of giving up their privacy assuming that they 03:04:17 are compliant with all rules and regulations and thus have nothing to hide. I think the days of people enjoying their material and financial resources as they see fit while they are known to a variety of indebted adversarial thiefs are numbered, and so are the days of high market caps for UTXO chains 03:13:14 "Just because we arent being..." <- This is the root of the issue. 03:26:21 "Monero is here for one reason..." <- Agree. That's why I wonder in a future environment where all banks accs and UTXO coins are captured (taxed into oblivion) why there would need to be a liquid market for either of these things. Now if the gov is somehow able to remove green pieces of paper from circulation and physical cash is no longer the most marketable currency, then perhaps Serai will have a use 03:26:21 for moving from UTXO currencies to Monero. Having liquidity for bank dollars to xmr will become moot as banks will just begin seizing assets if they think you are suspicious, aka you interact with Monero 03:32:01 "The group of people who aren't..." <- Who would use Serai? Nobody currently needs a UTXO chain currency or bank dollars in our current society. If you can readily convert back in forth between green pieces of paper (these can even be deposited at banks for utilities) and Monero (you can transact with anyone online in a private, anonymous, cheap, censorship resistant, fast manner), then you don't need 03:32:01 any other currency - or liqudity for them. If green pieces of paper are somehow recalled by the gubermint, then the need for people to flow from taxed compliant currencies to Monero and back becomes real and maybe then Serai would have users. 03:35:06 "If you incentivize them to act..." <- Then so be it. The question is whether the service they construct will have utility in the market place. If it does then it will hurt privacy to some extent, but it's better than tx_extra IMO currently. If individuals in the market don't need Serai or use it, then it won't hurt privacy via steg 03:45:07 "That* is essential" <- Good point. All that is essential is people can convert effcevtively from physical fiat to Monero and back. Because my argument is that physical fiat can be used to pay for anything, even if it must be deposited at a bank to pay a utility company who doesn't have an office nearby where you can pay cash. 03:51:35 "> <@kayabanerve:matrix.org..." <- How? Monero without tx extra as a stand alone system works perfectly fine without tx extra. Tx_extra doesn't improve Monero's decentralization in any way that I'm aware of. 03:55:13 Enabling another form of decentralized on/off ramp? I said improves, not is necessary. 03:56:53 Just read the rest of your comments and I now realize it probably wasn't meaningful to chime in. I'm going to sleep. Bye. 04:23:37 It would seem to me that kaya and others who are advocating for a fixed-size but prunable tx_extra are actually hurting decentralization, perhaps even to a significant extent, because the majority of node operators won't want to be free decentralized storage/database platform for applications, and hence most will want to set their node into "prune tx_extra" mode, leaving the full node operators (which are necessary for 04:23:37 chain integrity) as a small subset of the total running nodes. 04:28:07 And, of course, you can't have the default node setting to be pruned mode because that would mean that you're pushing software that's centralizing by default. So you'll end up in a situation where for the majority of people the default config is suboptimal and you increase the complexity for the node running person as they have to read the docs and understand that they want to set that option, which, to me, seems like bad 04:28:07 design because sane defaults are defaults that should fit the most amount of people with no extra configuration. 04:49:48 "i know its apples and oranges..." <- I get the exact same vibe from this issue. 04:59:59 "It would seem to me that kaya..." <- You are definitely right, we should’nt let a start up project threaten or dictate the full direction of monero development IMHO and threats to use other ways to hurt the network is even less warranted and shouldn’t be tolerated 05:13:54 You guys should take a break from this topic for a while, it’s taking on a toxic atmosphere that does not belong in this channel. 09:49:59 agreed. i think it might not even be a research related thing at this point. 10:01:02 Its multiple choice 10:02:26 I said to plowsof that it seems we all forgot about lounge 10:05:57 #monero-research-lounge:monero.social for those unaware 14:14:56 Alex | LocalMonero | AgoraDesk: dang, wanted to ping u on the lounge thingy instead but u not there :/, anyways, so like, regarding your argument about pruned nodes, i just remember reading a long while ago that technically the network would still be in a healthy state even if ran with only pruned nodes, not sure how accurate that is but that was coming from mrl people so like.. /shrugs 14:16:59 also last month on that mrl meeting, the question that was being voted on was regarding the tx_extra but maybe the right question would have been how to prevent mordinals instead of focusing on that tx_extra which according to the discussion, removing it wouldnt prevent them anyways so maybe just figure other ways instead, idk 21:20:36 Has output scanning being variable time ever been discussed from a privacy standpoint? 21:22:13 Yes. 21:22:43 I remember some changes to mitigate what a remote adversary could learn, but it is mitigation. 21:23:10 I do not remember talk about local attacks. 21:23:55 Seems to be more relevant to hardware wallets, and those might be using constant time ? 21:23:58 Yeah, I'm curious about with regards to remote nodes. 21:24:02 Have a link to any issues/PRs? 21:24:21 I'll look for the one I remember. 21:27:28 d5472bd87b8e93706295d8aa7ff99e5ad594277d, though from the commit message it seems like a weak leak. I'm vaguely certain (quite an interesting wording there) there's more to find, but that's the one I remember. 21:28:04 Maybe googling the name in the commit message will get you more meat. 21:29:20 And well, this was just about human delay, which isn't what you asked. I did not remember this when I first replied :) 21:40:01 kayabanerve: Not in detail, but: https://libera.monerologs.net/monero-research-lab/20221214#c177149 21:42:16 Rucknium: Yeah, exact same Q 21:42:25 I may add a constant time scanner to my work for the paranoid 22:12:44 Regarding tx chaining, is it reasonable to say the biggest benefits from this are to users who are starting with 1 output, and wish to pay >15 recipients in the same block, assuming we maintain the 16 per-tx output limit? And after all those new outputs are made, they're still locked for the 10 block lock limit? And I assume chaining will create inputs that stand out as a different class of inputs because they have no history? 22:13:21 tevador: UkoeHB ^ 22:17:01 sgp: TX chaining has no relevancy to the 10-block lock nor will they appear distinct on chain. 22:18:05 The Seraphis membership proof outputs a key, which then needs a proof of its linking tag's accuracy + ownership. 22:18:40 TX chaining is premised on the ability to decide outputs, and create a spend for a given enote creating those outputs, without having created the membership proof yet. 22:19:36 So a chained TX will later have a membership proof created, and because the membership proof is created after the fact, it can select from the full output pool for its decoys. 22:19:37 (90% sure, get someone else to confirm) 22:21:55 Is the reason the real input doesn't appear as the clear spend because decoys are selected normally that are <10 blocks old? I don't fully follow that part 22:22:48 > Combining these yields ‘transaction chaining by delegation’, where the author of transaction B authorizes the transfer of funds from an e-note that doesn’t exist in the chain, then gives their partial transaction (without a membership proof) to the author of transaction A (which creates that e-note), who can complete transaction B and submit it after they have completed and submitted transaction A. 22:23:13 Whoever creates the membership proof knows the real spend. On-chain, you can't tell a chained TX from a non-chained TX. 22:23:14 *That's from the Seraphis paper and confirm what I'm saying. 22:24:53 Are transaction A and B in different blocks? 22:26:28 Yes. Transaction B is published after transaction A is on a block and after any 10-block lock occurs. Then, B has its membership proof created, and is published on chain. 22:27:21 Okay, thank you. Sorry, I had a very different perception of the benefits of this based on how this was described to me 22:29:17 Seraphis 1.3 and 4.8 23:22:26 the main benefit is atomic swaps and multisig