00:48:50 <m-relay> <k​eepemup:matrix.org> Thanks, sech1
15:26:48 <Kapun> After mining a block I will pass it to monerod and got error:
15:26:49 <Kapun> `{'code': -7, 'message': 'Block not accepted'}`
15:26:49 <Kapun> Is any change to see the reason in logs or more debug information?
15:37:15 <moneromooo> Yes, on log level 1.
15:37:41 <moneromooo> If you can't repro it, then no.
15:38:18 <moneromooo> Was this mined with the node's builtin miner ?
15:40:07 <Kapun> No, by xmrig
15:41:29 <moneromooo> I suppose you can restart monerod with --log-level 1 --fixed-difficulty 1000 and mine another block. If it fails again, you'll know why.
15:41:59 <moneromooo> Of course that block will be invalid, but you can "pop_block N" when done and restart without --fixed-difficulty 1000 to resync to the network.
15:42:34 <moneromooo> It might be a broken db. In which case it'll likely be repeatable, and likely need a full resync.
15:44:18 <Kapun> I don't want to restart production node.
15:44:18 <Kapun> So I will make a request:
15:44:19 <Kapun> `curl http://127.0.0.1:38081/set_log_categories -d '{"categories": "*:INFO,net.p2p.msg:WARNING,net.p2p.traffic:WARNING,"}' -H 'Content-Type: application/json'`
15:46:53 <Kapun> btw is it bad to run production mining node with prune enabling? can be latency here for accept blocks / create templates?
15:47:47 <moneromooo> It is not bad. 
15:48:17 <moneromooo> You're unlikely to find a block in a reasonable amount of time to test this fwiw. Hence fixed difficulty.
15:48:48 <moneromooo> I guess you can mdb_copy the db elsewhere to run a node with --fixed-difficulty 1000 on the copy.
15:49:06 <moneromooo> (and I do mean mdb_copy, not cp)
15:49:58 <Kapun> its fine, I rent nh power to test it.
15:49:59 <Kapun> Some blocks accepted and some is not due to code -7, and coming to be orphaned.
15:50:00 <Kapun> Want to know why
16:06:23 <sech1> There is testnet for this
16:06:42 <sech1> What's the point to rent nh power to mine real blocks if you're not sure your setup works 100%?
16:32:44 <Kapun> Yes, you are right.
16:35:41 <Kapun> Is adding extra data to a coinbase transaction the only method to distribute unique work to miner by a mining pool ?
16:35:41 <Kapun> In some cases, Monero blocks contain numerous transactions in candidate, and computing the Merkle tree and hashing for each of the thousands of miners can be time-consuming.
16:35:42 <Kapun> Is there a way to optimize this process?
16:43:51 <sech1> Updating the extra nonce can be done in O(logN)
16:44:22 <sech1> Coinbase tx hash changes, then you need to calculate logN hashes to update the Merkle root
16:57:12 <Kapun> I thought you need to recalculate full merkle for each coinbase change.
17:23:42 <sech1> I said Merkle root
17:23:58 <sech1> And you need to recalculate it because it's a part of the hashing blob
18:55:53 <selsta> .merges
18:55:53 -xmr-pr- 9023
19:01:45 <selsta> .merge+ 9060 9061 9059 9056 9052 9053
19:01:45 <xmr-pr> Added
19:04:35 <Kapun> What is the maximum length of a fork chain in Monero? Can it be something like 8 blocks before being reorganized into the longest chain?
19:08:46 <moneromooo> I think it can go up to 500000000. It'd have to start at the genesis block though.
19:08:55 <moneromooo> 8 blocks is valid, yes.
19:14:08 <Kapun> And how the net decide to which one is pick as the main?
19:16:24 <moneromooo> The one with most cumulative work.
19:16:45 <moneromooo> If there is a draw, keep the first one you see.
19:39:35 <selsta> .merge+ 9049
19:39:35 <xmr-pr> Added