01:21:08 <TrasherDK[m]> #8427 please 🙂 
01:21:09 <TrasherDK[m]> https://github.com/monero-project/monero/pull/8427
01:36:22 <selsta> TrasherDK[m]: thought about it but it's still quite new, would prefer in the next release
01:37:08 <selsta> it would be great if you can run it locally for multiple days and report back if you find any issues
01:39:25 <TrasherDK[m]> Okay 😢 Can I pull this into 17.3.2 ? I can't build master.
01:52:27 <ofrnxmr[m]> selsta:  have you tested 8426? (Jbermans 7760 + pr comments)
02:14:22 <selsta> ofrnxmr[m]: IMO it's good to merge but we will wait until the second release to include it so that it can get one last review
02:14:36 <selsta> if no one reviews it until the second release we will just include it
02:15:16 <selsta> second release will be less than a month away
02:36:32 <TrasherDK[m]> Nope. Can't pull 8427 into release-v17
04:14:29 <selsta> jeffro256[m]: do you know what is the minimum openssl version required to work together with the 3.0 api?
06:12:07 <selsta> ^ forget my question, seems we need 1.1.1 or newer
08:46:32 <selsta> .merge+ 8435
08:46:32 <xmr-pr> Added
08:46:47 <selsta> .merges
08:46:47 -xmr-pr- 7986 8414 8425 8432 8433 8435
08:52:17 <r4v3r23[m]> release day? :)
08:53:54 <selsta> did a GUI test build and with 8435 everything looks good
08:57:33 <selsta> jberman is doing some more testing for 8433
08:57:40 <selsta> but we can merge, branch and tag once luigi becomes available
09:01:10 <r4v3r23[m]> any chance 8426/7760 gets included in first release to make sure that all nodes run it
09:01:17 <r4v3r23[m]> some people might just skip a point release
09:04:45 <r4v3r23[m]> if its getting merged in 2nd release regardless or review or not
09:05:48 <r4v3r23[m]> s/or/of/
09:22:45 <selsta> since hardware wallet support will be added with the second release a lot of users will upgrade anyway
09:23:15 <selsta> i mean if it's up to me i'm fine with merging it now, but not sure what others think
11:46:24 <willshu[m]> Hello, I use the library `crypto.js` on `https://xmr.llcoins.net/addresstests.html` to generate the address.
11:46:42 * willshu[m] uploaded an image: (129KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/xEbZPgreVWOFGGZLhMreTMbe/Screen%20Shot%202022-07-14%20at%2019.46.30.png >
11:47:23 <willshu[m]> But when I run this function 70,000 times it throws this error: `Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 16777216, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.`
11:47:49 * willshu[m] uploaded an image: (90KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/sWldzeWhWOWLGHbCXNWpSdFF/Screen%20Shot%202022-07-14%20at%2019.47.39.png >
11:48:54 <willshu[m]> which I found in the `crypto.js`. I am not an expert in C++ but it seems the `Module._free` step failed and there is a memory leak.
11:49:28 <willshu[m]> Anybody knows a memory safe way to do the `sc_reduce32` step? Another js library?
11:55:00 <spirobel[m]> <willshu[m]> "which I found in the `crypto.js`..." <- can you post a link to the repo?
12:22:06 <TrasherDK[m]> I'm curious. How does this fit with lifecycle/garbage collection of the environment. 70K malloc/free in a tight loop, fells unhealthy.
14:13:05 <ofrnxmr[m]> <selsta> "i mean if it's up to me i'm fine..." <- Im ok with it now.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c109a4d31b9fe6f17d1b45e614a567c787f9c481)
14:15:25 <r4v3r23[m]> > <@ofrnxmr:monero.social> Im ok with it now.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4abfd8b31fbd58dc1c4652656d1d2d026a15f47b)
14:24:19 <nioc> ping for irc vtnerd__ ^^ see ofrnxmr[m] 
15:06:38 <vtnerd__> is anyone else having github loading issues? some pages are all jacked up on this laptop
15:07:33 <vtnerd__> the trouble I had with that connection fix issue was that there were too many "flags" and unnecessary code it seemed like
15:07:42 <vtnerd__> but that was at a quick glance. I still cant get the page to load
15:08:21 <vtnerd__> the ssl portion could also be done separately iirc
15:08:44 <vtnerd__> but wasn't completely fixed either as the loop was still racy if a throw occurs
15:12:07 <ofrnxmr[m]> https://github.com/monero-project/monero/pull/7760#discussion_r896745644
15:15:05 <vtnerd__> yeah I thought it should be separated from day 1 ... and seriously the page loads fine for you? wth is with firefox on this machine :/
15:15:15 <ofrnxmr[m]> Regarding:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/052c67ff734312485fbaab1ced8df5aefa7b8741)
15:16:40 <ofrnxmr[m]> vtnerd__:  the page is loading on my end, but i sent the relevant comments above 
15:17:21 <vtnerd__> yeah I fixed it, an incorrect date on thix box was causing partial ssl issues and so I was getting partial loads on github
15:17:44 <vtnerd__> yeah I guess it was a style thing; i just didn't like it as it seemed too cluttered
15:18:24 <vtnerd__> I'll look again after lunch, but there this should be a _potential_ dangling reference issue on throw; but it depends on the caller code so its extra annoying
15:18:43 <vtnerd__> fixing that required a much bigger chance, and I didn't even attempt that
15:18:47 <vtnerd__> *change
15:20:44 <ofrnxmr[m]> Jberman can comment further, but I believe perfect daemon plans to continue improvements.
15:20:44 <ofrnxmr[m]> But as it stands, without 7760 and 7999 my android nodes get killed in under 5 days, regularly. Or completely stop accepting connections with rpc-SSL=enabled
15:22:23 <ofrnxmr[m]> So, im not sure there are any drawbacks to merging.
15:22:23 <ofrnxmr[m]> vtnerd__: 
15:22:23 <ofrnxmr[m]> https://github.com/monero-project/monero/pull/8426
15:22:23 <ofrnxmr[m]> This is the updated version that addresses your original review 
15:33:38 <UkoeHB> vtnerd__: where is the potentially dangling reference defined?
15:34:53 <vtnerd__> ssl_options_t::handshake is given a reference to an asio socket
15:35:26 <vtnerd__> several of the callbacks will use this reference, but there's no "move" into a shared_ptr to guarantee that it remains live
15:36:34 <vtnerd__> so `poll_one` in that loop could throw while a callback is still active
15:36:47 <vtnerd__> whether it gets called on another thread depends on the caller setup, and multi-threaded, etc
15:37:05 <vtnerd__> iirc its plausible (but unlikely since there aren't _many_ exceptions) on server side only
15:37:09 <vtnerd__> client side should luck out
15:38:01 <vtnerd__> Im not 100% sure whether its possible due to way the server-side connections work, but its "dicey" just looking at the single code snippet
15:38:25 <vtnerd__> its not worse than the existing code though (and improvement, just not 100%)
15:50:41 <UkoeHB> Interesting, so if a reference is exposed to multiple threads and one thread throws, the throw will unwind the callstack and kill the reference but the other thread isn't aware and keeps using the resource?
15:51:52 <UkoeHB> the throw wouldn't kill the other threads?
15:53:33 <UkoeHB> Although I guess the stack unwinding itself could be a race between resource access and thread lifetime
15:53:53 <UkoeHB> or the threads could be defined above a try/catch
15:55:29 <UkoeHB> instantiated*
15:58:36 <tromp> what were the block rewards in monero blocks 0 (genesis) and 1 ? 
15:59:14 <UkoeHB> tromp: try a block explorer.. https://xmrchain.net/search?value=0
15:59:43 <tromp> i tried, but the results don't make sense, so I ask here
16:00:07 <UkoeHB> maybe you need a different question, because the block explorer has the answer
16:01:05 <tromp> it reports 17.592186 for genesis reward
16:01:25 <tromp> while i computed it as 17.592186044415
16:01:34 <UkoeHB> hmm maybe it's rounded?
16:01:48 <tromp> where can I see unrounded rewards?
16:02:05 <UkoeHB> tadah click on the miner tx https://xmrchain.net/tx/c88ce9783b4f11190d7b9c17a69c1c52200f9faaee8e98dd07e6811175177139/1
16:02:06 <tromp> explorers should not be rounding amounts
16:02:33 <tromp> ah, thanks
16:03:49 <tromp> for block 1 i computed it as 17.592152489984
16:04:07 <tromp> but that explorer gives 17.592169267200
16:05:53 <tromp> which appears to be too much
16:06:21 <tromp> (maxBound::Int64) - 17592186044415 = 9223354444668731392
16:06:43 <tromp> and 9223354444668731392 >> 19 = 17592152489984
16:06:45 <sech1> you should use uint64
16:07:13 <tromp> oops
16:07:56 <sech1> (MAX_UINT64 - 17592186044415) >> 20 = 17592169267200
16:09:05 <sech1> IIRC first blocks used >> 20 because it was 1 block per minute
16:09:35 <tromp> yep, i confused Int64 with UInt64 :(
16:14:20 <UkoeHB> Reading a little more, threads don’t propagate exceptions to other threads (unless you make extra effort to do so). So would this case be when the main thread throws and kills a resource that other threads hold a reference to?
16:16:23 <tromp> is it possible that miners claim less than the full reward? and thereby change the following rewards?
16:16:45 <sech1> it was possible, but not anymore
16:17:18 <sech1> I don't remember which hardfork disabled it
16:18:29 <sech1> #define HF_VERSION_EXACT_COINBASE               13
16:18:51 <sech1> so v13 hardfork, 2020-10-17
16:21:48 <tromp> block 1964 claimed a reward of 17.525041498439
16:22:18 <tromp> while 17.55926641562 was allowed
16:23:20 <tromp> so the max reward at given height can only be computed while replaying the whole history of coinbases?
16:23:32 <sech1> yes
16:23:48 <sech1> also because of block weight penalties
16:24:28 <tromp> when is supply expected to overflow 64 bits?
16:25:23 <sech1> may 2024 or so
16:25:43 <tromp> the reason for my reward calculations is, i'm trying to compute Monero's Average Soft Emission Time
16:26:18 <tromp> how long after launch the average soft monero  is emitted
16:26:25 <ofrnxmr[m]> Tromp #monero-research-lounge:monero.social  
16:53:44 <luigi1112> .merges
16:53:44 -xmr-pr- 7986 8414 8425 8432 8433 8435
16:56:43 <luigi1112> rest are sub 24 hours or are semi-final housekeeping
17:14:52 <ofrnxmr[m]> UkoeHB: , jberman:  and vtnerd__: 
17:14:52 <ofrnxmr[m]> What do you guys think about 8426 (7760), good to go? 
17:16:24 <jberman[m]> vtnerd__: the dicey-ness of `poll_one` throwing and the socket destructing seems present in the code before this PR too
17:16:40 <jberman[m]> Considering the PR does solve a dicey issue along similar lines (I'd argue the seg fault it solves seems dicier since it doesn't rely on a boost internal exception to trigger), I think it's worth shipping, even if it doesn't fully solve all dicey-ness
17:17:02 <jberman[m]> I understand why it would be preferred for a larger rewrite to tackle all issues like this, but zooming into just the handshake, it's not that much code in isolation (the handshake change is ~130 lines)
17:17:32 <jberman[m]> Even if the PR for just the handshake was separate, I would argue it's worth shipping today
17:19:11 <luigi1112> selsta et al, when do you want to branch?
17:19:18 <UkoeHB> ofrnxmr[m]: idk anything about 8426, just interested in the dangling reference from a c++ learning point of view
17:22:49 <selsta> only question is 8426, it has been tested a lot now by multiple users and it seems to work perfectly
17:23:26 <selsta> even with this worst case dangling reference remaining
17:24:48 <selsta> luigi1112: do you think you can branch and tag before you go to sleep?
17:25:00 <selsta> until then we will decide what to do with 8426
17:25:35 <luigi1112> today? sure
17:26:21 <selsta> and then gui tomorrow
17:26:40 <sech1> as soon as it's tagged, we can start reproducible builds, right?
17:26:46 <selsta> yep
17:27:14 <selsta> since we have new macos arm binaries we will also have to do some changes to the website
17:27:18 <sech1> nice, I've always enjoyed the privilege of running the release binaries days before everyone else :D
17:29:02 <rbrunner> Regarding 8246, my humble take: Reviews in honor, but it also must mean something if code runs flawlessly for many people for months
17:30:04 <selsta> i think i'm running it for close to year now
17:35:14 <rbrunner> And you would think with a coin stealer in there jberman would have found it when reviewing :)
17:44:10 <ofrnxmr[m]> gingeropolous @gingeropolous:monero.social:  runs as well (on a high bandwidth node) I believe? 
17:46:50 <gingeropolous> yeah, i've run that for a while now. wish i had an uptime log
17:49:08 <gingeropolous> thats the same as master beta right selsta ?
17:50:27 <ofrnxmr[m]> Yeah
17:50:43 <jberman[m]> The worst case with this code is that it introduces a way to much more easily DoS nodes than it already is. It patches some DoS vectors and clear daemon reliability issues as it stands, so arguably, not including the code is close to the same as the worst case
17:50:50 <jberman[m]> Obviously it's also a huge section of complex code and if there was a clean way to get ALL the benefits of this PR in a clean way, I would be all for it. I sat with it. I tried. I discussed with perfect-daemon. And after doing so, I arrived at the conclusion that the way it's structured has underlying reasoning that is justifiable
17:51:00 <jberman[m]> I'm for merging for the above reasons
17:52:03 <gingeropolous> as a random idea, it could go in the immediate point release. this way, it doesn't get 100% on the network.
17:53:04 <gingeropolous> i mean because the main job of the next release is to fork the network
17:53:41 <gingeropolous> well, this release. at least thats how i see it. 
18:00:55 <gingeropolous> but its on xmrchain now
19:06:01 <ofrnxmr[m]> I think we should get 7760 out of the way sooner rather than later (could have been merged months ago but was just lacking a completed review then eventual merge conflicts etc forced a resubmit)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a9340d879bef2c4c303beb72fac0504d57182e95)
19:12:05 <jberman[m]> I was planning on going through 7999 next
19:24:30 <UkoeHB> Has anyone actually pledged to review 7760/8426? sech1 vtnerd__ ? If no one plans to review it and more reviews are expected, then it will just go back into indefinite limbo. So either decide 'wait for pledged reviews' or decide between 'no more reviews just merge it' and 'limbo until more reviews are possible'.
19:38:31 <ofrnxmr[m]> UkoeHB: 
19:38:31 <ofrnxmr[m]> 7760 was reviewed and approved by jberman
19:38:31 <ofrnxmr[m]> 8426 is cosmetic changes to address vtnerd style choice
19:39:34 <ofrnxmr[m]> I vote option 2. No more reviews, just merge it.
19:39:34 <ofrnxmr[m]> Rbrunner7 did a fast review of 8246 to ensure no logic changes were made during the cosmetic changes 
21:00:12 <vtnerd__> jberman[m]: correct, as-stated it is no worse, it just doesn't fix all cases unfortunately. I had a separate patch that was simpler than this but stopped when I identified the second issue
21:00:51 <vtnerd__> or I guess simpler was subjective since it has its own deal of boilerplate
21:15:47 <ofrnxmr[m]> Vtnerd, how to translate that into "are we good to go?"
21:15:47 <ofrnxmr[m]> This patch has been run and tested for a year. 
21:22:10 <jberman[m]> I think the handshake solution is pretty clean/simple as is. It’s just this: https://github.com/monero-project/monero/commit/df0c7e6100235f3086e81ce7c7fff8bea0caa2f6
21:22:32 <jberman[m]> The read/write handling is a lot more involved. If you want to deeply review the read/write handling further for correction issues, then I think that would justify keeping the PR on hold
21:22:56 <jberman[m]> If you only see further subjective changes that don’t necessarily affect code correctness, then I think we merge and get the correctness fixes out for the hard fork, you implement the changes you want to see when you’re able, and I’ll review
21:24:53 <jberman[m]> Will review happily I will add