00:48:50 <m-relay> <keepemup: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