00:26:16 <m-relay> <t​obtoht:monero.social> sech1: can you try this build. release-v0.18 + boost 1.84: https://github.com/tobtoht/monero/actions/runs/13380438243
00:26:59 <SyntheticBird> sure
00:27:05 <SyntheticBird> F*CK wrong alt
01:23:03 <m-relay> <v​tnerd:monero.social> Damn, and I removed some sketchy casting that was in existing code too. What's left should've been straightforward
03:30:05 -xmr-pr- x64x2 opened issue #9806: transaction build cannot add output
03:30:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9806
06:18:53 <m-relay> <0​xfffc:monero.social> no crash here: https://github.com/tobtoht/monero/actions/runs/13380438243
06:50:59 <m-relay> <t​obtoht:monero.social> 0xfffc: can you also test this one to rule out a compiler bug: https://github.com/tobtoht/monero/actions/runs/13380562426
07:16:50 <sech1> tobtoht https://github.com/tobtoht/monero/actions/runs/13380438243 doesn't crash for me
07:17:46 <sech1> https://github.com/tobtoht/monero/actions/runs/13380562426 crashes
07:17:55 <sech1> so it's probably a boost bug, not a compiler bug
07:34:55 <sech1> or maybe it's still a compiler bug that's present in both compiler versions
07:40:13 <tobtoht_> sech1: did you check if the issue is also present in gitian on release-v0.18? it uses an older version gcc
07:44:29 <m-relay> <0​xfffc:monero.social> tobtoht:  https://github.com/tobtoht/monero/actions/runs/13380562426 crashed
07:44:30 <sech1> I'll restart the gitian build now
07:52:15 <tobtoht_> can you try release-v0.18 + boost 1.67: https://github.com/tobtoht/monero/actions/runs/13385369440
08:06:39 <m-relay> <0​xfffc:monero.social> tobtoht:  https://github.com/tobtoht/monero/actions/runs/13385369440 no crash, syncing without issue
08:08:01 <sech1> gitian build crashes
08:08:27 <tobtoht_> can you share logs?
08:08:50 <sech1> It's just a silent crash, nothing in the logs even at level 2
08:09:19 <sech1> https://github.com/tobtoht/monero/actions/runs/13385369440 crashed for me 
08:41:51 <tobtoht_> sech1: release-v0.18 + revert 9800 sanity check: https://github.com/tobtoht/monero/actions/runs/13386066774
08:47:00 <sech1> no crash so far (synced first 50k blocks 2 times)
08:47:51 <sech1> 3 times, no crash
08:47:59 <tobtoht_> ok, good
08:51:16 <tobtoht_> i have release-v0.18 gitian builds running in ci now
09:06:37 <tobtoht_> "gitian build crashes" <- oh, haven't had enough sleep. i interpreted that as gitian builds failing
09:08:20 <sech1> So it's a combination of boost and some GCC versions that crashes (GCC 14.2.0 works fine with this boost version)
09:08:40 <sech1> Either some bug in boost, or too complex code for older GCC versions (bug in GCC)
09:08:44 <tobtoht_> the msys2 build? it doesn't use boost 1.66
09:08:53 <sech1> oh
09:09:06 <sech1> What does it use?
09:09:18 <tobtoht_> 1.87.0
09:11:39 <tobtoht_> so with crashes on three versions of gcc i think this is a boost bug
09:11:55 <tobtoht_> i'm not sure how much farther we can update boost on release without breaking gitian builds. and this might introduce other issues. a revert seems like the safest option for now
09:15:34 <sech1> I took a quick glance at #9800
09:16:05 <sech1> I has "const auto results = resolver.resolve(...); ... results.begin()->..." pattern in several places
09:16:13 <sech1> without checking that results is not empty
09:16:16 <sech1> not a safe approach
09:16:45 <sech1> *It has
09:17:38 <sech1> It does have "if(results.empty())" checks in a few other places
09:17:43 <sech1> Very concerning
09:18:21 <sech1> This is in contrib/epee/include/net/abstract_tcp_server2.inl
09:20:06 <sech1> "m_endpoint = *resolver.resolve(udp::v4(), m_device_host, std::to_string(m_device_port)).begin();"
09:20:10 <sech1> That's very optimistic :D
09:22:28 <sech1> tobtoht_ but latest master branch didn't crash for me, so it's some combination of boost + GCC versions + surrounding code that crashes. Must be a compiler bug, or an undefined behavior.
09:23:10 <tobtoht_> master uses boost 1.84
09:23:34 <sech1> that explains it
09:23:52 <sech1> Boost is the culprit :D
09:24:55 <sech1> vtnerd Can you add the checks that "resolver.resolve" returns non-empty list of results everywhere you call it? 9800 looks inconsistent in this department.
09:31:24 <m-relay> <0​xfffc:monero.social> boost is abomination!
09:31:40 <m-relay> <0​xfffc:monero.social> CMake used to be abomination. But it is better these days!
10:36:30 <m-relay> <s​yntheticbird:monero.social> so...
10:36:50 <m-relay> <s​yntheticbird:monero.social> does anyone have any idea why levin signature is categorized as "Bender's nightmare" ?
10:37:57 <m-relay> <s​yntheticbird:monero.social> I tried to search but Futurama is a big series, hard to find which episode this is referring to
10:38:02 <m-relay> <s​yntheticbird:monero.social> cc luigi1111
10:44:53 <midipoet> that's a good one
12:37:36 <tobtoht_> sech1: can you try release-v0.18 + boost 1.69: https://github.com/tobtoht/monero/actions/runs/13390257229
12:41:50 <sech1> no crash so far (3 times x 50k first blocks)
12:42:04 <tobtoht_> ok great
12:42:10 <sech1> I will test more
12:42:16 <tobtoht_> ty
12:42:26 <luigi1111> Hmm idk Syntheticbird
12:42:47 <sech1> 2025-02-18 12:42:23.547	6248	INFO	global	src/daemon/main.cpp:309	Monero 'Fluorine Fermi' (v0.18.4.0-af84f7cc6)
12:42:52 <sech1> just to confirm it's that commit
12:43:13 <tobtoht_> yep
12:55:20 <plowsof> "i thought i saw a 2"
12:56:20 <m-relay> <o​frnxmr:xmr.mx> What
12:57:17 <selsta> https://github.com/monero-project/monero/issues/9806 is this issue complete AI hallucination?
13:01:09 <selsta> luigi1111: can you block them from org ^?
13:01:18 <tobtoht_> they posted some incomprehensible image on a pr earlier, then deleted it. might be a bot?
13:01:38 <selsta> yes seems to be a troll who opens nonsensical issues and PR
13:04:43 <luigi1111> Can tob do that? I'm not in office
13:05:08 <tobtoht_> oh let me check
13:07:21 <tobtoht_> block user menu item doesn't appear for me
13:11:33 <sech1> wow, first time I see such an elaborate attempt
13:11:55 <sech1> "xmrrpcunsafe" is nowhere to be found in Monero/Monero GUI code, and it even mutates into "zrpcunsafe" on one line
13:15:05 -xmr-pr- tobtoht opened pull request #9807: depends: boost: update to 1.69.0 [0.18]
13:15:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9807
13:20:00 <tobtoht_> sech1: here is a gitian build for that pr: https://github.com/tobtoht/monero/actions/runs/13390257256
13:30:34 <sech1> no crash
13:30:43 <tobtoht_> perfect
13:31:36 <m-relay> <w​oodser:monero.social> happy to run more tests when there's a fix for PR 9460 (it works with `--max-connections-per-ip 10` but not by default)
13:38:05 <m-relay> <o​frnxmr:xmr.mx> I think max connections might be intended behavior
13:38:58 <m-relay> <o​frnxmr:xmr.mx> Its 1 by default, so it shouldnt have allowed incoming connection from the same ip as outgoing to begin with (but it was, pre 9460). Seems like 9460 fixed that "bug"
13:40:22 <m-relay> <o​frnxmr:xmr.mx> Running a private testnet should require increasing max-connections-per-ip to allow 127.0.0.1 to have multiple in/out connections from the same ip
13:40:22 <m-relay> <w​oodser:monero.social> ah ok, so people shouldn't run into that problem in the wild. I'll update scripts to use that flag
13:42:47 <m-relay> <o​frnxmr:xmr.mx> vtnerd  does this sound right?
13:44:27 <m-relay> <o​frnxmr:xmr.mx> I dont think there is any exceptions for localhost, so i'm surprised it ever worked before :/
16:54:18 <m-relay> <v​tnerd:monero.social> sech1: I recall verifying the presence of `.empty()` checks when using an ASIO resolver. Maybe I missed one
16:57:25 <m-relay> <v​tnerd:monero.social> oops, definitely did not add checks in abstract_tcp_server2.inl
16:58:30 <m-relay> <v​tnerd:monero.social> this should’ve been a problem previously though, it doesn’t look like i removed in existing checks (just copied missing checks behavior)
17:01:50 <m-relay> <v​tnerd:monero.social> yeah there’s a `.empty()` check in the one place that definitely needs it, and some non-checks in the init code (which may be the culprit, but looking unlikely)
17:02:20 <m-relay> <v​tnerd:monero.social> I’m busy over the next two days with things, but might be able to sneak in a fix if someone deems it necessary
17:02:46 <m-relay> <v​tnerd:monero.social> I’m a bit surprised we concluded it was Boost - do we even know why at this point?
17:13:11 <m-relay> <v​tnerd:monero.social> and [@ofrnxmr:xmr.mx](https://matrix.to/#/@ofrnxmr:xmr.mx)yes, the daemon should've never allowed more than 1 incoming p2p connection per ip
17:14:46 <sech1> Reverting #9800 fixes the crash, changing Boost version also fixes the crash. Changing compiler version doesn't fix the crash
17:15:34 <sech1> vtnerd yes, I found several missing checks in abstract_tcp_server2.inl and constructions like "*resolver.resolve(udp::v4(), m_device_host, std::to_string(m_device_port)).begin();" in other files
17:25:36 <tobtoht_> vtnerd: there are a few suspicious fixes between boost asio 1.68 and 1.69, tho not sure if related
17:25:42 <tobtoht_> https://github.com/boostorg/asio/commit/ad8cc21d599f2f3622650896bff4fde3c7294caa
17:25:47 <tobtoht_> https://github.com/boostorg/asio/commit/b9add379a7a9628f2255564197b00a476313514e
17:26:36 <tobtoht_> there were no changes between boost asio 1.67 and 1.68 and 1.67 still had the crash
17:28:20 <m-relay> <v​tnerd:monero.social> oh yikes!
17:29:41 <m-relay> <v​tnerd:monero.social> yeah the code relies on `resolve.empty()` in a few places.
17:29:53 <m-relay> <v​tnerd:monero.social> what terrible bug to sneak into ASIO
17:30:39 <m-relay> <v​tnerd:monero.social> we could change from `.empty()` to a comparison against a default iterator in a few places
17:31:33 <m-relay> <v​tnerd:monero.social> the other option is to remove the `boost::system::error_code` argument to `resolve(…)`. The documentation says a successful call to resolve always has non-empty results
17:56:19 <m-relay> <v​tnerd:monero.social> sech1: The documentation stated that the result was non-empty if no errors. I’m not sure if no results found is considered an error though
17:56:20 <sech1> tobtoht_ yeah, the crash I had was a null pointer dereference when I tried to debug it
17:56:49 <m-relay> <v​tnerd:monero.social> The .empty() check would explode in those Boost versions though
17:57:41 <sech1> How does it return an error? Through an exception?
17:57:54 <sech1> Then it should be wrapped in the try...catch block
17:58:42 <m-relay> <v​tnerd:monero.social> Yes, those sections are
17:59:09 <m-relay> <v​tnerd:monero.social> the only place I’m seeing no explicit `iterator == end_iterator` or `results.empty()` checks are in `abstract_tcp_server2.inl`
18:00:24 <m-relay> <v​tnerd:monero.social> and those are wrapped with catch blocks. We may want to add an explicit check since the documentation isn’t 100%, otoh this behavior was actually unchanged by 8400
20:31:09 <m-relay> <o​frnxmr:xmr.mx> Bitcoin has a configurable option for the min fee that the node will relay. I dont think monero has a setting for this, but do we have a minimum? Or can custom wallets send 0 fee tx that will be relayed and confirmed?
20:33:50 <plowsof> 0 fee is rejected by node in monero-core
20:34:12 <plowsof> custom node can accept + mine to block a 0fee
20:35:18 <m-relay> <j​effro256:monero.social> There is a minimum fee per weight value calculated by the daemon as a function of previous blocks, and for a new transaction to pass relay rules, the tx's fee must be greater than that value multiplied by its weight
20:35:28 <m-relay> <j​effro256:monero.social> It's only a part of relay rules, not consensus
20:36:02 <m-relay> <j​effro256:monero.social> https://github.com/monero-project/monero/blob/97c0ce73c4f67d0effc68d35f6b9711ff131ffc5/src/cryptonote_core/blockchain.cpp#L3646
20:42:17 <m-relay> <o​frnxmr:xmr.mx> Ty sir
20:43:00 <m-relay> <o​frnxmr:xmr.mx> sirs*
22:58:30 <m-relay> <s​yntheticbird:monero.social> OGs
22:58:35 <m-relay> <s​yntheticbird:monero.social> who is Antonio Juarez ?
22:58:47 <m-relay> <s​yntheticbird:monero.social> when did he disappear?
22:58:51 <m-relay> <s​yntheticbird:monero.social> is he still alive?
22:59:30 <m-relay> <s​yntheticbird:monero.social> cc selsta
23:01:36 <selsta> afaik some made up name from bytecoin time
23:02:17 <m-relay> <s​yntheticbird:monero.social> ouch, unlikely to find him again then
23:03:23 <m-relay> <o​frnxmr:xmr.mx> ask zano
23:03:48 <m-relay> <s​yntheticbird:monero.social> doedl?
23:04:01 <m-relay> <o​frnxmr:xmr.mx> nah zoidbergn
23:04:03 <m-relay> <s​yntheticbird:monero.social> is he part of zano?
23:04:24 <m-relay> <s​yntheticbird:monero.social> funny
23:04:27 <m-relay> <s​yntheticbird:monero.social> you made me laugh
23:04:38 <m-relay> <s​yntheticbird:monero.social> good job
23:04:40 <m-relay> <o​frnxmr:xmr.mx> Crypton zoidberg is guy who says he developed bytecoin
23:04:56 <m-relay> <o​frnxmr:xmr.mx> I'm not joking
23:05:08 <m-relay> <s​yntheticbird:monero.social> lmao this cannot be a coincidence
23:05:25 <m-relay> <s​yntheticbird:monero.social> thx, i'll try to find him
23:05:38 <m-relay> <s​yntheticbird:monero.social> I was on the verge of making a reddit post
23:13:04 <m-relay> <o​frnxmr:xmr.mx> There was also a long post on bitcointalk about this
23:13:24 <m-relay> <s​yntheticbird:monero.social> really?
23:57:39 <m-relay> <s​yntheticbird:monero.social> really? (he responded)