Greetings, I'm currently using monero-python and I have questions about the way people test their code when it deals with monero.

So far I have setup a private test network in a container, that runs 2 daemons, and creates 2 wallets with deterministic adresses, and uses a low difficulty.

My test suite then setup a pytest fixture that runs the container, starts mining on one of the 2 addresses, waits for the wallet to have enough xmr to spend.

The "issue" I'm facing is the following: mining takes time. Afaik the first mined xmr becomes available only at height 60, is it something I can tweak to increase speed ?

Another question is : can I mine up to a given height and stop mining once reached ? I didn't see an rpc command parameter for that (up to x height)

But after I made all those questions, I'm reaching that point where I'm just wondering if integrated testing is the way to go and if I should not mock the various monero part I'm interested in interacting with.

thanks for the read !

euri10 use --fixed-difficulty parameter for monerod to mine faster

yep already set at 1

then it should be very fast to mine 60 blocks

There's a generate_blocks RPC, you tell it how many blocks to mine. See tests/functional_tests.

Also, set MONERO_FASTER_POW=1 if you don't care about verifying the PoW from another program. It'll use keccak IIRC.

Ah nvm that never got merged. You can apply it from my "crash" branch if you don't mind running a slightly patched daemon.

ok ok :) good infos here, will definitely check that

git.townforge.net/townforge/townfor…4078598221a2f7320564a507c9d5bbce6a3 is the one with keccak, it doesn't seem to be in my crash branch. Should be easy to merge.

Also, generate_blocks only works in regtest mode for some reason, but I doubt that'll be a problem here.

what is regtest mode ?

A global state set by --regtest IIRC, which enables that and a "delete chain before we start".

ok ok, with all that hopefully I can speed up my test suite, many thanks

Which made me add a --keep-fake-chain because useful, especially to investigate when stuff went wrong. So not sure why this mode exists in the first place.

@moneromooo as soon as I add the regtest flag to the daemon command, it seems the daemon is not accepting rpc connections anymore, is that possible ? I raised an issue here, maybe you have better insights: monero-ecosystem/monero-python #117

It is possible, but not expected.

IIRC the python functional tests use that mode, so it RPC didn't work, all tests would fail. They do not.

ok I'll dig into it then thanks

Make sure you're sending to the correct port, just in case.

ie, check netstat

regtest is a mainnet base, so the default port would be 18081, if you did not override it.

ok I'm trying with 28081 but I'm using `monerod --stagenet --no-igd --hide-my-port --data-dir stagenet/node_01 --p2p-bind-ip 127.0.0.1 --log-level 1 --rpc-bind-ip 0.0.0.0 --add-exclusive-node 127.0.0.1:38080 --confirm-external-bind --detach --fixed-difficulty 1 --p2p-bind-port 28080 --rpc-bind-port 28081 --zmq-rpc-bind-port 28082`

will try with a mainnet base and report

ok that was the --stagenet flag that somehow was clashing with regtest

Oh, one difference regtest has: it always starts from the latest known mainnet fork.

So you'll likely have BP+ etc, if you have recent code.

can high fee be a possible result of bug rather then malicious node?

is there a check in monerod preventing from sending high fee estimation?

MajesticBank: Don’t think so, maybe Monerod shouldn’t relay a tx with say 10x avg fee ; so these malacious nodes will become useless

* > <@MajesticBank:libera.chat> is there a check in monerod preventing from sending high fee estimation?

Don’t think so, maybe Monerod shouldn’t relay a tx with say 10x avg fee ; so these malacious remote nodes will become useless

<nikg83[m]> "Don’t think so, maybe Monerod..." <- Before adding some changes to decentralized cryptocurrency it's better to think whether it's resistant to any abuse

was under impression that custom fee was banned on consensus level

and we couldn't find malicious node so far

<MajesticBank> "was under impression that custom..." <- source ?

All fees are allowed.

The wallet will send a tx with more than x10 fee if asked by priority setting.

You need to do that in order to push your tx in the face of a glut that fills blocks.

MajesticBank: code of decentralized project should work under any conditions, no need to find any malicious node, just write code properly

Though a wallet change could allow you to get away with less than that, the code just quantizes atm.

custom fee make transaction look different on blockchain

so CEX can use custom fee to make their transactions different from others

they can also use faulty decoy algorithms

just pointing some future places for improvements

MajesticBank: we had some discussion about using 'discretized fees' (probably for seraphis)

Who is supposed to use different fee from minimum one ?

MajesticBank: we also have talked about 'binning' for decoy selection, where the ring members are divided into bins with a small on-chain range. If someone's 'decoy selection algorithm' is badly implemented (i.e. selecting the bin locations), then at least the decoy members within the real bin will add some obfuscation.

The wording was oddly reminiscent of "they can do it on purpose". But if they want to do that, nothing can help since they can just make public a list of their txes.

One idea is to bake the larger decoy selection algorithm into consensus, but IMO that's too difficult to get right (both choosing the algorithm and then making it robustly deterministic).

Why is it difficult ?

Integer math for the gamma function ?

yes, there would be lots of edge cases that are hard to validate

UkoeHB: do you already know at least one such edge case that is hard to validate ?

I mean hard to validate in total, i.e. identify all the edge cases, understand them, and make sure they don't cause problems.

UkoeHB: If cryptography can be squashed and merged without any validation, why not to do the same here ?

hahahaha

What does that mean ?

I didn't try to implement deterministic decoy selection, and don't plan to, but if someone wants to try I will look at it of course.

Oh no I meant the squashing cryptography line :)

It's pretty misleading to say 'without any validation' when it's really 'without validation that meets my standards' (which we'd probably get closer to if you participated instead of hiding behind your indignation).

Oh, it was just some snark, nothing actually useful ? nvm then.

moneromooo: or not a snark, who knows

Well, explain :)

yes, please offer a solution instead of expecting other people to solve your problems for you

should the wallet implement a check, like "are you sure?" when the fee is larger than txn amount?

hyc: seems like a good idea, or even like 10-25% of the txn amount

FWIW, the base tx fee goes up only with average block reward. It's probably a fair bet it won't ever go above 110% of the current base tx fee (within current consensus rules).

(am I forgetting an input that makes it go up ?)

Actually, not a fair bet. That'd imply ~50% chance. I mean a sure bet :)

hmm good point

hyc Would you be willing to review monero-project/monero #8322? My OpenSSL is kind of spotty, but it appears to work well. I hope it would be kind of hard to be able to fake SHA-256 lol

Or anyone else who is comfortable with OpenSSL

sure

thanks I appreciate it! You set me straight on the other PR

.merge+ 8321

Added

.merge+ 8312

Added

selsta I actually have one more cleanup patch incoming for 8312

should be no big deal, just cosmetic in depends pkg descriptions

ok will remove it for now

.merge- 8312

Removed

selsta: 8312 ready for another try anyway

ok will try

.merges

How much faster does this make syncing? monero-project/monero #8262

What are the community nodes? monero-project/monero-gui #3897#issuecomment-1114004700

I would guess not more than a few %

@sgp The community node list isn't a thing *yet* but it would replace the Monero GUI using random nodes in simple mode

feather wallets list : github.com/feather-wallet/feather/blob/master/src/assets/nodes.json