09:12:44 <euri10> Greetings, I'm currently using monero-python and I have questions about the way people test their code when it deals with monero. 
09:12:44 <euri10> 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.
09:12:44 <euri10> 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.
09:12:44 <euri10> 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 ?
09:12:47 <euri10> 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)
09:12:50 <euri10> 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.
09:12:53 <euri10> thanks for the read !
09:29:27 <sech1> euri10 use --fixed-difficulty parameter for monerod to mine faster
09:29:57 <euri10> yep already set at 1
09:30:59 <sech1> then it should be very fast to mine 60 blocks
09:32:33 <moneromooo> There's a generate_blocks RPC, you tell it how many blocks to mine. See tests/functional_tests.
09:33:08 <moneromooo> Also, set MONERO_FASTER_POW=1 if you don't care about verifying the PoW from another program. It'll use keccak IIRC.
09:35:27 <moneromooo> Ah nvm that never got merged. You can apply it from my "crash" branch if you don't mind running a slightly patched daemon.
09:36:04 <euri10> ok ok :) good infos here, will definitely check that
09:37:38 <moneromooo> https://git.townforge.net/townforge/townforge/commit/d8e4f4078598221a2f7320564a507c9d5bbce6a3 is the one with keccak, it doesn't seem to be in my crash branch. Should be easy to merge.
09:38:42 <moneromooo> Also, generate_blocks only works in regtest mode for some reason, but I doubt that'll be a problem here.
09:39:17 <euri10> what is regtest mode ?
09:40:03 <moneromooo> A global state set by --regtest IIRC, which enables that and a "delete chain before we start".
09:40:40 <euri10> ok ok, with all that hopefully I can speed up my test suite, many thanks
09:40:45 <moneromooo> 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.
13:27:00 <euri10> @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: https://github.com/monero-ecosystem/monero-python/issues/117
13:47:48 <moneromooo> It is possible, but not expected.
13:48:13 <moneromooo> IIRC the python functional tests use that mode, so it RPC didn't work, all tests would fail. They do not.
13:48:56 <euri10> ok I'll dig into it then thanks
13:49:26 <moneromooo> Make sure you're sending to the correct port, just in case.
13:49:36 <moneromooo> ie, check netstat
13:50:03 <moneromooo> regtest is a mainnet base, so the default port would be 18081, if you did not override it.
13:51:19 <euri10> 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`
13:51:52 <euri10> will try with a mainnet base and report
14:00:42 <euri10> ok that was the --stagenet flag that somehow was clashing with regtest
14:07:04 <moneromooo> Oh, one difference regtest has: it always starts from the latest known mainnet fork.
14:07:47 <moneromooo> So you'll likely have BP+ etc, if you have recent code.
14:11:01 <MajesticBank> can high fee be a possible result of bug rather then malicious node?
14:11:22 <MajesticBank> is there a check in monerod preventing from sending high fee estimation?
14:14:22 <nikg83[m]> MajesticBank: Don’t think so, maybe Monerod shouldn’t relay a tx with say 10x avg fee ; so these malacious nodes will become useless 
14:55:48 <nikg83[m]> * > <@MajesticBank:libera.chat> is there a check in monerod preventing from sending high fee estimation?
14:55:48 <nikg83[m]> Don’t think so, maybe Monerod shouldn’t relay a tx with say 10x avg fee ; so these malacious remote nodes will become useless 
14:56:57 <ooo123ooo123[m]> <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
15:00:22 <MajesticBank> was under impression that custom fee was banned on consensus level
15:06:52 <MajesticBank> and we couldn't find malicious node so far
15:07:20 <ooo123ooo123[m]> <MajesticBank> "was under impression that custom..." <- source ?
15:07:25 <moneromooo> All fees are allowed.
15:08:16 <moneromooo> The wallet will send a tx with more than x10 fee if asked by priority setting.
15:08:37 <moneromooo> You need to do that in order to push your tx in the face of a glut that fills blocks.
15:08:40 <ooo123ooo123[m]> MajesticBank: code of decentralized project should work under any conditions, no need to find any malicious node, just write code properly
15:08:53 <moneromooo> Though a wallet change could allow you to get away with less than that, the code just quantizes atm.
15:12:36 <MajesticBank> custom fee make transaction look different on blockchain
15:12:58 <MajesticBank> so CEX can use custom fee to make their transactions different from others
15:13:22 <MajesticBank> they can also use faulty decoy algorithms
15:15:05 <MajesticBank> just pointing some future places for improvements 
15:16:09 <UkoeHB> MajesticBank: we had some discussion about using 'discretized fees' (probably for seraphis)
15:16:49 <ooo123ooo123[m]> Who is supposed to use different fee from minimum one ?
15:17:01 <UkoeHB> https://github.com/monero-project/meta/issues/691
15:20:50 <UkoeHB> 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.
15:22:29 <moneromooo> 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.
15:22:37 <UkoeHB> 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).
15:23:07 <moneromooo> Why is it difficult ?
15:23:36 <moneromooo> Integer math for the gamma function ?
15:24:32 <UkoeHB> yes, there would be lots of edge cases that are hard to validate
15:25:46 <ooo123ooo123[m]> UkoeHB: do you already know at least one such edge case that is hard to validate ?
15:26:51 <UkoeHB> I mean hard to validate in total, i.e. identify all the edge cases, understand them, and make sure they don't cause problems.
15:27:44 <ooo123ooo123[m]> UkoeHB: If cryptography can be squashed and merged without any validation, why not to do the same here ?
15:27:46 <ooo123ooo123[m]> hahahaha
15:28:50 <moneromooo> What does that mean ?
15:31:33 <UkoeHB> 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.
15:32:25 <moneromooo> Oh no I meant the squashing cryptography line :)
15:32:52 <UkoeHB> 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).
15:33:54 <moneromooo> Oh, it was just some snark, nothing actually useful ? nvm then.
15:34:45 <ooo123ooo123[m]> moneromooo: or not a snark, who knows
15:34:57 <moneromooo> Well, explain :)
15:35:31 <UkoeHB> yes, please offer a solution instead of expecting other people to solve your problems for you
16:02:35 <hyc> should the wallet implement a check, like "are you sure?" when the fee is larger than txn amount?
16:03:43 <UkoeHB> hyc: seems like a good idea, or even like 10-25% of the txn amount
16:05:50 <moneromooo> 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).
16:06:07 <moneromooo> (am I forgetting an input that makes it go up ?)
16:06:34 <moneromooo> Actually, not a fair bet. That'd imply ~50% chance. I mean a sure bet :)
16:07:58 <UkoeHB> hmm good point
18:15:12 <jeffro256[m]> hyc Would you be willing to review https://github.com/monero-project/monero/pull/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
18:15:15 <jeffro256[m]> Or anyone else who is comfortable with OpenSSL
18:23:50 <hyc> sure
18:28:19 <jeffro256[m]> thanks I appreciate it! You set me straight on the other PR
18:42:41 <selsta> .merge+ 8321
18:42:41 <xmr-pr> Added
19:38:53 <selsta> .merge+ 8312
19:38:53 <xmr-pr> Added
19:53:17 <hyc> selsta I actually have one more cleanup patch incoming for 8312
19:53:40 <hyc> should be no big deal, just cosmetic in depends pkg descriptions
19:53:41 <selsta> ok will remove it for now
19:53:45 <selsta> .merge- 8312
19:53:45 <xmr-pr> Removed
21:29:08 <hyc> selsta: 8312 ready for another try anyway
21:30:53 <selsta> ok will try
21:36:49 <luigi1112> .merges
21:36:49 -xmr-pr- 8046 8220 8226 8235 8262 8277 8278 8279 8280 8281 8293 8300 8301 8302 8304 8321
21:51:50 <sgp_> How much faster does this make syncing? https://github.com/monero-project/monero/pull/8262
21:54:08 <sgp_> What are the community nodes? https://github.com/monero-project/monero-gui/pull/3897#issuecomment-1114004700
21:56:19 <luigi1112> I would guess not more than a few %
21:58:25 <jeffro256[m]> @sgp The community node list isn't a thing *yet* but it would replace the Monero GUI using random nodes in simple mode
22:02:14 <plowsof[m]> feather wallets list : https://github.com/feather-wallet/feather/blob/master/src/assets/nodes.json