02:57:22 .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 vtnerd would you mind approving 7873 if your comments have been addressed sufficiently? 03:07:13 they were addressed 03:09:58 or wait, hmm 03:11:06 yes, they were addresses 03:11:15 github ui seems buggy 03:14:08 I demand rubber stamp 03:14:26 ... 03:14:26 ok 03:15:26 03:21:40 should 7910 be merged? 03:22:14 let's do it next time 03:24:59 hello it's me, next time 03:25:13 still want to check something with 7910 so I removed it for now 03:31:15 ok bye 03:32:24 q.q 03:33:58 <3 03:37:56 zoomer loogi 03:44:20 zoomer whisperer 07:16:07 hello 07:18:18 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 wfaressuissia here? 07:24:33 7803 and 7891 conflict only in cryptonote_core.cpp (lines 1066-1067) 07:24:40 the other conflict is with something else 07:24:55 cryptonote_core.cpp conflict seems to be easy to solve 07:25:27 why 7803 is not inserted yet 07:25:36 don't ask me 07:25:38 strange because is very important 07:41:06 src/wallet/wallet2.cpp line 2967 conflict too 13:18:13 is there going to be another 0.17 release? 13:18:37 if so, some PRs recently merged to master prob should also be in release branch 14:38:23 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 The method first get the pool transactions from the daemon, but does not yet process them 14:39:09 Then it fetches blocks from the blockchain that it does not yet have 14:39:25 Finally it processes the pool transactions that it got in the first step 14:40:01 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 Aren't the pool transactions from the first step pretty outdated when the method finally gets around to process them? 14:41:42 Maybe they are, but it does not matter because soon we will refresh again, and get again pool transactions? 14:51:19 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 hi. is there any plans to support wayland protocol? 14:56:23 ? 14:56:27 * hi. is there any plans to support wayland protocol? 14:57:19 IIRC there was a timing issue that required reordering things. Improve if you can. 14:57:41 Wayland is in... windowing server ? 14:58:15 If so, doesn't apply to monero. Might apply to various Monero using programs, ask them. 14:58:24 There is also an interesting comment there concerning a privacy leak if the pool transactions are processed right away, yes 14:59:23 moneromooo: yes 14:59:52 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 But it proves tricky to find out how this will influence and change current structure of wallet2::refresh 15:00:32 And without having a basic grasp what the thing does it's probably pretty hopeless :) 15:02:04 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 rbrunner: Does the issue you are looking at affect mixin selection for construction of transactions? 15:28:02 Most probably not. It's the syncing part of the wallet, nowhere near any tx construction. 15:28:43 Speeding up syncing by compressing 4 RPC roundtrips to the daemon into one: https://github.com/monero-project/monero/issues/7571 15:29:19 rbrunner: A wallet cannot construct a tx until it is fully synced up to the current block height, right? 15:29:32 Think so, yes. 15:30:01 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 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 Yes, it is enforced as far I know. Just could not point you the exact lines in code just like that ... 15:32:14 Exactly because of the problem that you mention 15:33:13 Of course, other wallets are not necessarily constrained in this way. 15:33:27 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 I would suspect that check in wallet2 already, and that's pretty hard to avoid. 15:35:06 Hey is anyone having problems with some monerod log messages not showing up, especiialy when built in debug mode ? 15:35:13 We suspect, based on some evidence, that there are "rogue wallets" operating out there. 15:35:32 We being jberman, myself, isthmus, probably others. 15:35:55 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 I see what you mean. Would of course be quite easy to doctor wallet2, compile, and have fun. 15:36:50 That's the 10 block restriction? 15:37:00 Think so, yes. 15:37:46 rbrunner: blocks w/ txs that have outputs that are too young are invalid, correct? 15:38:40 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 By the way, can't wait to read details about the results of the tx flood analysis :) 15:39:50 Oh yeah, who's doing that? 15:40:35 Or such a tx *tried* to enter the pool but was rejected by my daemon. 15:40:56 Can't let such a thing get very far, right? 15:41:20 jerfo: The tx flood analysis? Isthmus, Neptune, myself, jberman, and Carrington 15:42:49 gingeropolous helped too, mostly with hardware support. 15:43:22 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 Ruckinum: that's awesome! What hardware support was needed? 15:44:24 That will be better than CSI on TV :) 15:45:45 jerfo: It's gigabytes of data. Need to extract certain data from the blockchain and manipulate it 15:48:44 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 gingeropolous hosts a server, neptune pulls relevant data via https://github.com/neptuneresearch/ring-membership-sql I think 15:49:39 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 this 2 monero-project/monero #7803 monero-project/monero #7891 has small conflicts 18:14:02 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 might need to quote the title 18:19:32 Backticks or normal ""? 18:22:04 normal 18:22:19 but keeping special stuff out works too 18:22:39 people like to put their name in the title but there's an author field too... 18:24:25 My title shall be "OSPEAD: Fortifying Monero Against Statistical Attack" 18:24:49 What is OSPEAD, you may ask? You'll have to read the proposal once it is posted :) 18:25:34 k 18:26:00 if it doesn't show up in fr if/when merged we'll figure it out 18:26:32 Ok great. Thanks for the tips. 18:40:44 Operational Statistics for Proactive Enhanced Anonymity Development 18:41:48 +1 18:42:30 gingeropolous: Wow, that's a pretty good "backronym" 🤔 18:43:13 I am actually tempted to change it lol 18:46:20 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 lulz.