02:50:30 <twatwa_> Outstanding job day in and day out ya'll
05:54:36 <rbrunner> testnet is slowly crawling back to a healthy number of nodes, but it could use one or the other miner more right at the moment until difficulty comes down again
06:53:44 <TrasherDK[m]> `on testnet, smart mining at 106 H/s, net hash 4.16 kH/s, v16, 5(out)+0(in)`
06:53:49 <TrasherDK[m]> 🙂 
06:58:40 <al800[m]1> Synced 94293/2044753 (4%, 1950460 left)
06:58:40 <al800[m]1> Soon...
11:42:28 <baro77[m]> Dealing with dependencies, everytime I see rapidjson submodule I cannot avoid thinking it comes from WeChat's PRC Tencent..
11:43:15 <baro77[m]> maybe I'm just too biased, sorry
12:00:30 <moneromooo> jeffro256[m]: I don't really care either way, but consistency is better.
12:16:09 <rogu157[m]> Hello, dear Monero Dev Team! In our pool we use python binding to monero source (commit: 26bfd7045953) for functions: `parse_and_validate_block_from_blob`, `get_block_hashing_blob`, `calculate_block_hash`. Please tell us if we will have problems with these functions after the fork? Do I need to update their sources? Thank you ❤️
12:18:06 <sech1> rogu157[m] you should test your python binding on testnet
12:19:28 <rogu157[m]> Full source of this bindings: https://paste.debian.net/hidden/5b04cbe0/
12:19:55 <sech1> it should work if you recompile with the latest Monero code
12:20:54 <rogu157[m]> So it is necessary to recompile? Is it breaking changes here in this functions?
12:25:14 <sech1> it's better to recompile to be sure
12:25:18 <sech1> but you can first check it on testnet
12:30:08 <rogu157[m]> It confuses me that the supportxmr sources were not updated: https://github.com/Snipa22/nodejs-pool before the fork. So everything should work without changes?
12:30:29 <sech1> not everything
12:34:25 <sech1> moneromooo jberman[m] not sure why, but I'm getting a lot of duplicate tx notifications via ZMQ:  https://p2pool.io/u/b76134a5bda6e565/p2pool_puke.png - probably because mempool is crowded now (1500+ transactions, 15 MB)
12:38:48 <sech1> my node's mempool: https://paste.debian.net/hidden/322dd885/
12:38:56 <sech1> it hit the 10 MB limit I set in command line
12:40:07 <sech1> so maybe when mempool gets limited by --max-txpool-weight parameter, ZMQ starts sending duplicates?
12:40:47 <moneromooo> I imagine if --max-txpool-weight gets hit, some tx gets kicked from hte pool, but it will then be received again by nodes sending it to you...
12:41:22 <sech1> sounds plausible
12:41:34 <sech1> I'll restart my node without the limit
12:41:43 <moneromooo> If mining a blck causes that tx to still not be mined, but to now sit below the --max-txpool-weight limit, it'll get added to the pool, but soon kicked again as better paying txes keep arriving.
12:45:17 <sech1> looks like it helped
12:48:46 <moneromooo> There is a "send me txes I do nto have" P2P call. Maybe it should have an optional fee/byte, below which it doesn't want txes.
12:48:50 <moneromooo> That should help with that if it's the reason.
12:49:52 <sech1> I'm not getting duplicate tx notification without --max-txpool-weight
13:51:58 <ErCiccione> stagenet superslow or stuck? https://stagenet.xmrchain.net/
13:53:24 <ErCiccione> and now it's ok again. (24 minutes no blocks)
13:59:33 <sethforprivacy> Someone is spamming mempool: https://xmrchain.net/page/5
13:59:33 <sethforprivacy> Note the majority of TXs in each block have incremementing input counts per block
14:00:16 <sethforprivacy> Now sending max-sized transactions in each block.
14:00:56 <sethforprivacy> Clearly evident with avg size of TXs exponentially increasing: https://pooldata.xmrlab.com/
14:02:50 <sethforprivacy> Dynamic block size is slowly growing as a result as well. Nothing we can do, of course, but interesting nonetheless
14:03:01 <sech1> it's minexmr
14:05:46 <sethforprivacy> Ohhhh
14:05:47 <sethforprivacy> Interesting...
14:05:54 <sethforprivacy> Really odd way to approach it but I suppose that makes sense
14:06:08 <ofrnxmr[m]> Lol @ the incrmwwnting
14:06:08 <ofrnxmr[m]> 13-14-15-16 etc lolll
14:06:47 <sethforprivacy> Yeah really odd way to send things, like a bad script or something
14:07:05 <sethforprivacy> Cool to see dynamic block size doing its thing to help clear it faster, though 🙂 Already up to 310kb median 😄
14:08:14 <sethforprivacy> The 194/2 transactions appear over so should clear soon.
14:09:02 <ofrnxmr[m]> Yeah, mempool down from 10mb-4mb
14:34:07 <rogu157[m]> moneromooo: What do u think about my problem? https://matrix.to/#/!LmpzSzbSMKFmPbCpHe:monero.social/$P_5m0vZuRXBzkUxJmiSL9-lLpuubCQkPD54XgzQTIfo?via=libera.chat&via=matrix.org&via=monero.social A little bit stuck with compile new static libs versions. Thank you)
14:35:42 <selsta> can you share logs on https://paste.debian.net/ ?
14:37:46 <moneromooo> I dunno, I wouldn't click on a link looking like that :P I tend to be paranoid maybe.
14:37:58 <moneromooo> I'd totally load paste.debian.net.
14:38:08 <selsta> yea the link looks more shady than usual
14:38:32 <rbrunner> Will teleport you right into the Matrix
14:39:02 <byteskeptical> lol
14:43:21 <rogu157[m]> > Hello, dear Monero Dev Team! In our pool we use python binding to monero source (commit: 26bfd7045953) for functions: parse_and_validate_block_from_blob, get_block_hashing_blob, calculate_block_hash. Please tell us if we will have problems with these functions after the fork? Do I need to update their sources? Thank you ❤️
14:44:52 <moneromooo> That patch has nothing to do with python AFAICT.
14:45:13 <selsta> like sech1 said the easiest way to find out is testnet
14:45:17 <moneromooo> The third function is pretty new, so if you already use it, you're probably already fine.
14:46:10 <rogu157[m]> I mean should I update the source monero functions that I listed above
14:46:30 <rogu157[m]> To be sure is it okay to work with a new fork.
14:47:29 <moneromooo> Just pull it all, ideally from the last tagged version on the release-v0.18 branch.
14:47:41 <moneromooo> Pulling just some parts is a recipe for problems.
14:48:11 <hardenedsteel[m]> <sech1> "it's minexmr" <- i wonder why they making new transaction for each payment while they can send up to 16 address.
14:48:17 <moneromooo> The python functions are just thin glue calling the matching RPC on the node/wallet.
14:53:57 <rogu157[m]> I try to build my python bindings use this docker file: https://paste.debian.net/hidden/4f61c8c0/ But got following error during release-static: https://paste.debian.net/hidden/c17c7232/
15:03:04 <selsta> rogu157[m]: you have to compile static unbound, similar to https://github.com/vtnerd/monero-lws/pull/39/files
16:57:51 <rogu157[m]> selsta: sorry for interrupt you again.  almost finished binding on the new version of Monero. This source code: https://paste.debian.net/hidden/516aafea/ And this how I build it: https://paste.debian.net/hidden/4bc028da/ Now I got error when import my python module: https://paste.debian.net/hidden/0e5ce017/ Could you help me because I'm stocked?
17:00:18 <selsta> it seems to be a completely different dockerfile now?
17:02:04 <moneromooo> About the last paste, this symbol is from a new-ish wallet lib, libwallet-crypto (IIRC). Maybe you just need to link against it.
17:02:29 <moneromooo> build/Linux/master/release/src/crypto/wallet/libwallet-crypto.a
17:02:53 <rogu157[m]> >it seems to be a completely different dockerfile now?
17:02:53 <rogu157[m]> I use my old dockerfile
17:02:56 <moneromooo> It's not used by the daemon though, which uses the original crypto code.
17:03:03 <rogu157[m]> * > it seems
17:05:06 <selsta> rogu157[m]: try setting -DMONERO_WALLET_CRYPTO_LIBRARY=cn https://github.com/monero-project/monero/issues/6774
17:12:58 <rogu157[m]> I added link to wallet-crypto and now got:
17:12:58 <rogu157[m]> >ImportError: /usr/local/lib/python3.8/site-packages/pymonero.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZN10cryptonote27get_transaction_prefix_hashERKNS_18transaction_prefixERN6crypto4hashE
17:13:25 <rogu157[m]> Is it missing link again?
17:15:23 <moneromooo> Yes, cryptonote_basic
17:16:41 <rogu157[m]> https://paste.debian.net/hidden/88e7bf80/
17:16:46 <rogu157[m]> hm I got it 
17:17:08 <rogu157[m]>  * hm, I got this link
17:18:51 <moneromooo> Try cryptonote_core then, some stuff got moved for randomx purposes, this one might have been...
17:19:37 <moneromooo> No, still seems to be in _basic. Maybe wrong link order then.
17:20:08 <moneromooo> Most linkers are one pass, so you need to supply the caller first, callee last.
17:20:32 <moneromooo> Though cmake does some auto ordering too I believe.
17:21:33 <moneromooo> And monero has a couple cyclical deps unfortunately. Not sure how that works in practice beyond giving a lib twice on the link line...
17:21:58 <rogu157[m]> Tried cryptonote core. Still got this error.
17:22:30 <rogu157[m]> I'm not versed in code. It is difficult to understand what order of linking should be. I would be grateful if you help.
17:25:47 <moneromooo> Well, I believe cmake tries to put them in the right order anyway, but I'd go, roughly: wallet core ringct basic crypto others
17:28:13 <rogu157[m]> If I place crypto-wallet on top of cryptonote_basic/ cryptonote_core I will take error:  undefined symbol: monero_crypto_amd64_64_24k_generate_key_derivation
17:28:56 <selsta> did you try setting -DMONERO_WALLET_CRYPTO_LIBRARY=cn ?
17:29:27 <rogu157[m]> With this settings It is unnecessary to link crypto-wallet, yea?
18:09:20 <rogu157[m]> Tried `ENV MONERO_WALLET_CRYPTO_LIBRARY=cn` : still got `undefined symbol: monero_crypto_amd64_64_24k_generate_key_derivation`
18:12:05 <moneromooo> Might need a -D MONERO_WALLET_CRYPTO_LIBRARY=cn on the cmake command line. This is using cmake, so who knows how one is supposed to specify this.
18:12:21 <selsta> yes it does not work as env var
18:12:24 <moneromooo> From looking at the source, it sets it, but the text hints it's a user steting.
18:12:34 <moneromooo> So maybe yo uhave to modify it in src/wallet/CMakeLists.txt.
18:12:52 <moneromooo> For all autofools is annoying, at least it's known.
18:57:05 * monerobull[m] uploaded an image: (4KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/LKfDiXmlhePFcImldzJgmRrg/grafik.png >
18:57:06 <monerobull[m]> ?
19:58:26 <woodser[m]> I'm getting `undefined reference to `mainnet_hard_fork_version_1_till'` among others, building with monero libs on ubuntu. it works on mac. I'm linking against libhardkforks.a, so I don't see how this reference can be undefined
19:58:50 <woodser[m]> s/`/'/
19:59:19 <moneromooo> Link order maybe ?
19:59:52 <woodser[m]> hm ok I will try that
20:54:51 <woodser[m]> yes rearranging the linking worked. thanks
20:55:37 <woodser[m]> rogu157 I was also getting `undefined symbol: monero_crypto_amd64_64_24k_generate_key_derivation` until I moved some crypto libraries later in the linking
20:56:19 <woodser[m]> cncrypto and libwallet-crypto
22:14:20 <selsta> .merges
22:14:20 -xmr-pr- 8299 8323 8333 8352 8359 8379 8381 8415 8419 8427 8428 8442 8444 8450 8460 8462 8464 8465 8490 8491
23:44:29 <theresreallyawo4> Is zero to monero meant to be read first edition, then second edition? Or is the second edition an updated version? Let me know if this is the wrong channel to ask, thanks
23:45:35 <selsta> second edition is more up to date
23:46:00 <theresreallyawo4> thank you