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.