Outstanding job day in and day out ya'll

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

`on testnet, smart mining at 106 H/s, net hash 4.16 kH/s, v16, 5(out)+0(in)`

🙂

Synced 94293/2044753 (4%, 1950460 left)

Soon...

Dealing with dependencies, everytime I see rapidjson submodule I cannot avoid thinking it comes from WeChat's PRC Tencent..

maybe I'm just too biased, sorry

jeffro256[m]: I don't really care either way, but consistency is better.

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 ❤️

rogu157[m] you should test your python binding on testnet

Full source of this bindings: paste.debian.net/hidden/5b04cbe0

it should work if you recompile with the latest Monero code

So it is necessary to recompile? Is it breaking changes here in this functions?

it's better to recompile to be sure

but you can first check it on testnet

It confuses me that the supportxmr sources were not updated: github.com/Snipa22/nodejs-pool before the fork. So everything should work without changes?

not everything

moneromooo jberman[m] not sure why, but I'm getting a lot of duplicate tx notifications via ZMQ: p2pool.io/u/b76134a5bda6e565/p2pool_puke.png - probably because mempool is crowded now (1500+ transactions, 15 MB)

my node's mempool: paste.debian.net/hidden/322dd885

it hit the 10 MB limit I set in command line

so maybe when mempool gets limited by --max-txpool-weight parameter, ZMQ starts sending duplicates?

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...

sounds plausible

I'll restart my node without the limit

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.

looks like it helped

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.

That should help with that if it's the reason.

I'm not getting duplicate tx notification without --max-txpool-weight

stagenet superslow or stuck? stagenet.xmrchain.net

and now it's ok again. (24 minutes no blocks)

Someone is spamming mempool: xmrchain.net/page/5

Note the majority of TXs in each block have incremementing input counts per block

Now sending max-sized transactions in each block.

Clearly evident with avg size of TXs exponentially increasing: pooldata.xmrlab.com

Dynamic block size is slowly growing as a result as well. Nothing we can do, of course, but interesting nonetheless

it's minexmr

Ohhhh

Interesting...

Really odd way to approach it but I suppose that makes sense

Lol @ the incrmwwnting

13-14-15-16 etc lolll

Yeah really odd way to send things, like a bad script or something

Cool to see dynamic block size doing its thing to help clear it faster, though 🙂 Already up to 310kb median 😄

The 194/2 transactions appear over so should clear soon.

Yeah, mempool down from 10mb-4mb

moneromooo: What do u think about my problem? matrix.to/#/!LmpzSzbSMKFmPbCpHe:mon…at&via=matrix.org&via=monero.social A little bit stuck with compile new static libs versions. Thank you)

can you share logs on paste.debian.net ?

I dunno, I wouldn't click on a link looking like that :P I tend to be paranoid maybe.

I'd totally load paste.debian.net.

yea the link looks more shady than usual

Will teleport you right into the Matrix

lol

> 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 ❤️

That patch has nothing to do with python AFAICT.

like sech1 said the easiest way to find out is testnet

The third function is pretty new, so if you already use it, you're probably already fine.

I mean should I update the source monero functions that I listed above

To be sure is it okay to work with a new fork.

Just pull it all, ideally from the last tagged version on the release-v0.18 branch.

Pulling just some parts is a recipe for problems.

<sech1> "it's minexmr" <- i wonder why they making new transaction for each payment while they can send up to 16 address.

The python functions are just thin glue calling the matching RPC on the node/wallet.

I try to build my python bindings use this docker file: paste.debian.net/hidden/4f61c8c0 But got following error during release-static: paste.debian.net/hidden/c17c7232

rogu157[m]: you have to compile static unbound, similar to vtnerd/monero-lws #39/files

selsta: sorry for interrupt you again. almost finished binding on the new version of Monero. This source code: paste.debian.net/hidden/516aafea And this how I build it: paste.debian.net/hidden/4bc028da Now I got error when import my python module: paste.debian.net/hidden/0e5ce017 Could you help me because I'm stocked?

it seems to be a completely different dockerfile now?

About the last paste, this symbol is from a new-ish wallet lib, libwallet-crypto (IIRC). Maybe you just need to link against it.

build/Linux/master/release/src/crypto/wallet/libwallet-crypto.a

>it seems to be a completely different dockerfile now?

I use my old dockerfile

It's not used by the daemon though, which uses the original crypto code.

* > it seems

rogu157[m]: try setting -DMONERO_WALLET_CRYPTO_LIBRARY=cn monero-project/monero #6774

I added link to wallet-crypto and now got:

>ImportError: /usr/local/lib/python3.8/site-packages/pymonero.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZN10cryptonote27get_transaction_prefix_hashERKNS_18transaction_prefixERN6crypto4hashE

Is it missing link again?

Yes, cryptonote_basic

hm I got it

* hm, I got this link

Try cryptonote_core then, some stuff got moved for randomx purposes, this one might have been...

No, still seems to be in _basic. Maybe wrong link order then.

Most linkers are one pass, so you need to supply the caller first, callee last.

Though cmake does some auto ordering too I believe.

And monero has a couple cyclical deps unfortunately. Not sure how that works in practice beyond giving a lib twice on the link line...

Tried cryptonote core. Still got this error.

I'm not versed in code. It is difficult to understand what order of linking should be. I would be grateful if you help.

Well, I believe cmake tries to put them in the right order anyway, but I'd go, roughly: wallet core ringct basic crypto others

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

did you try setting -DMONERO_WALLET_CRYPTO_LIBRARY=cn ?

With this settings It is unnecessary to link crypto-wallet, yea?

Tried `ENV MONERO_WALLET_CRYPTO_LIBRARY=cn` : still got `undefined symbol: monero_crypto_amd64_64_24k_generate_key_derivation`

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.

yes it does not work as env var

From looking at the source, it sets it, but the text hints it's a user steting.

So maybe yo uhave to modify it in src/wallet/CMakeLists.txt.

For all autofools is annoying, at least it's known.

?

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

s/`/'/

Link order maybe ?

hm ok I will try that

yes rearranging the linking worked. thanks

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

cncrypto and libwallet-crypto

.merges

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

second edition is more up to date

thank you