02:57:22 <luigi1111w> .merges 02:57:22 -xmr-pr- 7873 7874 7886 7890 7891 7911 7917 7923 7925 7928 7929 7930 7933 7934 7942 7945 7952 7961 7964 03:03:32 <luigi1111w> vtnerd would you mind approving 7873 if your comments have been addressed sufficiently? 03:07:13 <selsta> they were addressed 03:09:58 <selsta> or wait, hmm 03:11:06 <selsta> yes, they were addresses 03:11:15 <selsta> github ui seems buggy 03:14:08 <luigi1111w> I demand rubber stamp 03:14:26 <selsta> ... 03:14:26 <selsta> ok 03:15:26 <luigi1111w> 03:21:40 <luigi1111w> should 7910 be merged? 03:22:14 <selsta> let's do it next time 03:24:59 <luigi1111w> hello it's me, next time 03:25:13 <selsta> still want to check something with 7910 so I removed it for now 03:31:15 <luigi1111w> ok bye 03:32:24 <selsta> q.q 03:33:58 <luigi1111w> <3 03:37:56 <selsta> zoomer loogi 03:44:20 <luigi1111w> zoomer whisperer 07:16:07 <tauntaum> hello 07:18:18 <tauntaum> this 2 pulls https://github.com/monero-project/monero/pull/7803 https://github.com/monero-project/monero/pull/7891 has small conflicts 07:22:23 <tauntaum> wfaressuissia here? 07:24:33 <sech1> 7803 and 7891 conflict only in cryptonote_core.cpp (lines 1066-1067) 07:24:40 <sech1> the other conflict is with something else 07:24:55 <sech1> cryptonote_core.cpp conflict seems to be easy to solve 07:25:27 <tauntaum> why 7803 is not inserted yet 07:25:36 <sech1> don't ask me 07:25:38 <tauntaum> strange because is very important 07:41:06 <tauntaum> src/wallet/wallet2.cpp line 2967 conflict too 13:18:13 <hyc> is there going to be another 0.17 release? 13:18:37 <hyc> if so, some PRs recently merged to master prob should also be in release branch 14:38:23 <rbrunner> I try to get an understanding of the high-level structure and working of wallet2::refresh, and run into a number of puzzling questions, like this one: 14:38:49 <rbrunner> The method first get the pool transactions from the daemon, but does not yet process them 14:39:09 <rbrunner> Then it fetches blocks from the blockchain that it does not yet have 14:39:25 <rbrunner> Finally it processes the pool transactions that it got in the first step 14:40:01 <rbrunner> The question that pops up: Assuming that fetching and processing blocks from the blockchain can take any amount of time, because there are many to fetch 14:40:30 <rbrunner> Aren't the pool transactions from the first step pretty outdated when the method finally gets around to process them? 14:41:42 <rbrunner> Maybe they are, but it does not matter because soon we will refresh again, and get again pool transactions? 14:51:19 <rbrunner> Or is my assumption wrong that the second step may take a long time, because that will always be an incremental refresh with a small number of blocks, say single-digits? 14:56:22 <BigmenPixel[m]> hi. is there any plans to support wayland protocol? 14:56:23 <BigmenPixel[m]> ? 14:56:27 <BigmenPixel[m]> * hi. is there any plans to support wayland protocol? 14:57:19 <moneromooo> IIRC there was a timing issue that required reordering things. Improve if you can. 14:57:41 <moneromooo> Wayland is in... windowing server ? 14:58:15 <moneromooo> If so, doesn't apply to monero. Might apply to various Monero using programs, ask them. 14:58:24 <rbrunner> There is also an interesting comment there concerning a privacy leak if the pool transactions are processed right away, yes 14:59:23 <BigmenPixel[m]> moneromooo: yes 14:59:52 <rbrunner> I am on the way with an attempt to improve things, by implementing a new RPC call that basically fetches the pool *and* blocks together, in one go 15:00:15 <rbrunner> But it proves tricky to find out how this will influence and change current structure of wallet2::refresh 15:00:32 <rbrunner> And without having a basic grasp what the thing does it's probably pretty hopeless :) 15:02:04 <rbrunner> I think I will have a look using log outputs how many blocks the second step I mention typically has to get, to further my understanding. 15:24:02 <Rucknium[m]> rbrunner: Does the issue you are looking at affect mixin selection for construction of transactions? 15:28:02 <rbrunner> Most probably not. It's the syncing part of the wallet, nowhere near any tx construction. 15:28:43 <rbrunner> Speeding up syncing by compressing 4 RPC roundtrips to the daemon into one: https://github.com/monero-project/monero/issues/7571 15:29:19 <Rucknium[m]> rbrunner: A wallet cannot construct a tx until it is fully synced up to the current block height, right? 15:29:32 <rbrunner> Think so, yes. 15:30:01 <rbrunner> Well, technically it could of course, but it does not, as far as I know, and insists on syncing to top first 15:31:02 <Rucknium[m]> But the reference wallet enforces this? If the wallet doesn't wait, then the mixins will effectively come from older blocks than they should come from. 15:32:02 <rbrunner> Yes, it is enforced as far I know. Just could not point you the exact lines in code just like that ... 15:32:14 <rbrunner> Exactly because of the problem that you mention 15:33:13 <Rucknium[m]> Of course, other wallets are not necessarily constrained in this way. 15:33:27 <rbrunner> Quite in general, I better not mess wallet sync with anything I do. I plan to do some careful testing after implementing. 15:34:19 <rbrunner> I would suspect that check in wallet2 already, and that's pretty hard to avoid. 15:35:06 <jerfo> Hey is anyone having problems with some monerod log messages not showing up, especiialy when built in debug mode ? 15:35:13 <Rucknium[m]> We suspect, based on some evidence, that there are "rogue wallets" operating out there. 15:35:32 <Rucknium[m]> We being jberman, myself, isthmus, probably others. 15:35:55 <rbrunner> Yeah, I just synced my daemon half an hour ago, and what do I get somewhere on the way? "Transaction spends at least one output which is too young" 15:36:45 <rbrunner> I see what you mean. Would of course be quite easy to doctor wallet2, compile, and have fun. 15:36:50 <Rucknium[m]> That's the 10 block restriction? 15:37:00 <rbrunner> Think so, yes. 15:37:46 <jerfo> rbrunner: blocks w/ txs that have outputs that are too young are invalid, correct? 15:38:40 <rbrunner> Hmm, suddenly not sure. Maybe that tx is only in the pool, somehow hard to believe that we would have invalid blocks because of this. 15:39:24 <rbrunner> By the way, can't wait to read details about the results of the tx flood analysis :) 15:39:50 <jerfo> Oh yeah, who's doing that? 15:40:35 <rbrunner> Or such a tx *tried* to enter the pool but was rejected by my daemon. 15:40:56 <rbrunner> Can't let such a thing get very far, right? 15:41:20 <Rucknium[m]> jerfo: The tx flood analysis? Isthmus, Neptune, myself, jberman, and Carrington 15:42:49 <Rucknium[m]> gingeropolous helped too, mostly with hardware support. 15:43:22 <jerfo> rbrunner: yeah I assume the message is generated when the tx enters the pool, and the daemon is effectively warning that it will have to sit in timeout until the outputs mature 15:44:01 <jerfo> Ruckinum: that's awesome! What hardware support was needed? 15:44:24 <rbrunner> That will be better than CSI on TV :) 15:45:45 <Rucknium[m]> jerfo: It's gigabytes of data. Need to extract certain data from the blockchain and manipulate it 15:48:44 <rbrunner> jerfo: After some quick glance at the code it does look like it's not rejected, yes. But as Rucknium[m] said, makes one wonder who constructed that tx, and how, and why 15:48:50 <Rucknium[m]> gingeropolous hosts a server, neptune pulls relevant data via https://github.com/neptuneresearch/ring-membership-sql I think 15:49:39 <Rucknium[m]> In fact, gingeropolous is planning to put together a CCS for a more powerful, fully-featured server for greater statistical analysis and so forth. 17:45:48 <tauntaum> this 2 monero-project/monero #7803 monero-project/monero #7891 has small conflicts 18:14:02 <Rucknium[m]> If I put a colon in my CCS proposal title, is it going to break something? I suppose I could test by trial and error. 18:18:05 <luigi1111w> might need to quote the title 18:19:32 <Rucknium[m]> Backticks or normal ""? 18:22:04 <luigi1111w> normal 18:22:19 <luigi1111w> but keeping special stuff out works too 18:22:39 <luigi1111w> people like to put their name in the title but there's an author field too... 18:24:25 <Rucknium[m]> My title shall be "OSPEAD: Fortifying Monero Against Statistical Attack" 18:24:49 <Rucknium[m]> What is OSPEAD, you may ask? You'll have to read the proposal once it is posted :) 18:25:34 <luigi1111w> k 18:26:00 <luigi1111w> if it doesn't show up in fr if/when merged we'll figure it out 18:26:32 <Rucknium[m]> Ok great. Thanks for the tips. 18:40:44 <gingeropolous> Operational Statistics for Proactive Enhanced Anonymity Development 18:41:48 <UkoeHB> +1 18:42:30 <Rucknium[m]> gingeropolous: Wow, that's a pretty good "backronym" 🤔 18:43:13 <Rucknium[m]> I am actually tempted to change it lol 18:46:20 <Rucknium[m]> My intended acronym is "Optimal Static Parametric Estimation of Arbitrary Distributions", which doesn't sound as cool as "Operational Statistics for Proactive Enhanced Anonymity Development" 18:49:59 <gingeropolous> lulz.