09:52:15 <Snipa> .merges
09:52:15 -xmr-pr- 6600 6613 6660 6690 6693 6731 6739 6746 6752 6753 6757 6760 6761 6762 6763 6766 6767 6771
10:08:04 <Snipa> .merges
10:08:05 -xmr-pr- 6600 6693 6739 6757 6760 6761 6762 6763 6766 6767 6771
12:46:15 -xmr-pr- selsta opened pull request #6783: repo: update "sponsor" link
12:46:15 -xmr-pr- > https://github.com/monero-project/monero/pull/6783
13:06:51 <moneromooo> Any objection to switching testnet to v13 on, say, sunday ?
13:07:18 <moneromooo> snipa will merge the clsag PR next, then I don't think there's anything consensus to change.
13:08:35 <selsta> sounds good
13:08:46 <sarang> grydz: anything need to be changed with Ledger Monero-side code?
13:09:18 <sarang> IIRC the Trezor folks expected one Trezor-specific PR on the Monero codebase after the CLSAG merge
13:10:09 <moneromooo> OK, we'll wait then.
13:15:43 <grydz> sarang, I need this patch at least: https://gist.github.com/grydz/dc34efb7e3cd6f91189bf27c2ce62b0b
13:18:04 <grydz> (Just updated the gist, I removed the modification for v13)
13:18:16 <dEBRUYNE> What about next weekend? Or would that be too late
13:21:50 <grydz> For us, the later the better...
13:25:22 <grydz> Still debugging why I get a correct CLSAG sig at the end but can't pass the sanity check
13:26:45 <sarang> Once CLSAG is merged, I'll let the Trezor team know
13:29:04 <moneromooo> One thing which helped me debug this is to set all randomness to 0, then give the same inputs with and without changes, and see where it starts diverging.
13:29:21 <moneromooo> So you'd do that once with your code and once with the upstream code.
13:31:47 <dEBRUYNE> .merges
13:31:47 -xmr-pr- 6600 6693 6739 6757
13:39:32 <grydz> Is there an easy way to do that? Or should I tweak functions like skGen()?
13:40:07 <moneromooo> That's the easy way.
13:40:42 <moneromooo> I suppose you can hack the PRNG in random.c too, but that might zero randomness you'd want... not sure.
13:41:31 <grydz> Alright, thanks!
14:08:47 <selsta> Would there be an issue with updating testnet even if some Ledger / Trezor changes are missing?
14:09:14 <selsta> Once Ledger / Trezor has PRed their fixes they can be merged.
14:09:35 <selsta> Testnet participants will have to compile from source (or use inofficial bins) anyway.
14:09:57 <moneromooo> Depends if they change consensus code. I expect they won't, but you never know, it might be our bug :)
14:10:37 <selsta> Right but if there is a bug like this we have to rollback testnet anyway?
14:10:37 <selsta> not sure
14:10:52 <moneromooo> If it already switched, yes.
14:15:09 <sarang> My understanding is the Trezor PR will not alter consensus
14:15:23 <sarang> I can't speak to Ledger
14:16:07 <dEBRUYNE> ^ grydz ?
14:19:47 <grydz> Do you think my patch could be integrated in the PR?
14:19:56 <grydz> This is just simples fixes.
14:20:17 <grydz> In that way, we could also use testnet for debugging.
14:21:32 <grydz> (patch here: https://gist.github.com/grydz/dc34efb7e3cd6f91189bf27c2ce62b0b)
14:23:47 <moneromooo> What is this value it does not encrypt now ?
14:24:24 <moneromooo> Also you removed bounds checking. Is that on purpose ?
14:53:57 <grydz> moneromooo, the value z was not created on the HW, we can't encrypt it.
14:55:05 <grydz> It's derived from the private view key (which was exported).
14:55:44 <moneromooo> If it doesn't leak info, and the bounds checking is restored (unless it was redundant), then the patch looks ok to me.
14:56:02 <grydz> What bound checks?
14:56:06 <grydz> On the Monero app?
14:56:22 <moneromooo> Writing to buffer_send.
15:01:09 <grydz> Do you mean sending &this->buffer_recv[offset] instead?
15:03:07 <moneromooo> I admit I don't know much of the ledger code, but AFAICT &this->buffer_recv[offset] is unrelated ?
15:03:37 <moneromooo> recv is ledger to wallet2, send is wallet2 to ledger, right ?
15:04:07 <grydz> Yes.
15:05:44 <moneromooo> Well, it's not what I meant, and I don't see the relevance of your comment so I might be missing somthing.
15:06:05 <moneromooo> I just meant you removed the bounds checking code on the send buffer, and this looks dangerous at first glance.
15:06:17 <moneromooo> Bounds chekcing being checking you don't write after the buffer.
15:06:36 <moneromooo> It might be that other code already checks this, in which case it'd be fine.
15:08:37 <grydz> (My comment was not relevant at all I just don't see where I removed a bound check!)
15:08:55 <moneromooo> -        this->send_secret(z.bytes, offset);
15:08:56 <moneromooo> +        memmove(this->buffer_send+offset, z.bytes, 32);
15:08:56 <grydz> Is this when I replaced send_secret() with memmove?
15:08:59 <grydz> Ok!
15:09:03 <moneromooo> send_secret has:
15:09:09 <grydz> I see now.
15:11:45 <selsta> moneromooo: please rebase 6111
15:12:18 <selsta> .merge+ 6769
15:12:18 <xmr-pr> Added
15:16:15 -xmr-pr- vdo opened issue #6784: Error building RandomX in a RPi
15:16:15 -xmr-pr- > https://github.com/monero-project/monero/issues/6784
15:56:37 <moneromooo> selsta: done
16:55:57 <moneroist> Hi, how can I get transaction inputs from monerod rpc call? I am using get_transaction_pool rpc method call but I can not find there inputs, there are no input (previous output) address in response json
16:59:05 <selsta> hyc: sech1: could you review the "core: fix mining from a block that's not the current top" commit in PR 6111?
17:07:09 <hyc> will try to get to it soon
17:07:32 <hyc> looks a bit more involved than I can spare right now
17:08:24 <selsta> thanks
17:21:03 <sech1> I did a quick look and it looks ok on the surface, but I don't know if it actually works as intended. I assume it's covered by tests?
17:21:25 <moneromooo> It is. The tests are the reason I needed this.
17:27:34 <selsta> https://www.irccloud.com/pastebin/8WgOhtnZ/
17:27:40 <selsta> I get this but I might be invoking it incorrectly
17:30:08 <moneromooo> That usually means the daemon died or hanged.
17:30:08 <selsta> mining test passes
17:33:03 <selsta> it happens every time, any logs that would be useful?
17:42:15 <moneromooo> I'll try here first. Maybe the two patches don't agree with each other.
18:24:16 <selsta> it passed on github ci and also on the mac mini, seems like to only happen on my system
18:31:15 * moneromooo helpfully raises the corner of the carpet and waits expectantly
18:37:31 <caralho> rip daemon
18:38:24 <selsta> .merge- 6757
18:38:25 <xmr-pr> Removed
18:59:17 <cohcho> moneromooo: that delay was due to core::update_checkpoints() within core::handle_incoming_block(). After added --disable-dns-checkpoints unknown delay stays within 100ms.
18:59:55 <moneromooo> Oh really. I did not remember this being synchronous.
19:00:05 <moneromooo> Worth removing, IIRC it's on a timer.
19:00:46 <moneromooo> (and on another thread)
19:00:59 <moneromooo> Thanks for finding it
19:01:11 <cohcho> Yeah, it would be helpful. I've disabled it at all as a workaround.
19:01:37 <cohcho> What's about reported delay, Are there any places for optimizations?
19:02:19 <moneromooo> Verification could be parallel. IIRC atm it's per tx.
19:02:44 <moneromooo> So you typically get 2 threads (one per output) to verify rct IIRC.
19:03:12 <moneromooo> Nothing else big comes to mind atm.
19:03:26 <moneromooo> Oh, switching the blockchain lock to a rw lock.
19:03:32 <moneromooo> But that's a big change.
19:03:41 <Snipa> 6739 (CSlag) merged.
19:03:46 <Snipa> Thank you moo. :D
19:03:48 <moneromooo> ty
19:04:19 <moneromooo> There might also be some redundancy in tx checking in txpool.
19:04:39 <Snipa> .merges
19:04:39 -xmr-pr- 6600 6693 6739 6769
19:04:40 <moneromooo> Erring on the side of caution.
19:07:20 <selsta> Snipa: 6600 can be merged too I think
19:07:24 <selsta> the others are still
19:07:30 <selsta> not fully clear
19:10:11 <Snipa> 6600 needs a rebase, same reason 6739 did.  13's going to have a bunch of lockouts it looks like.
19:10:16 <Snipa> Was just looking it over.
19:22:27 <cohcho> Verification of all inputs/outputs of block transactions can be trated as N indepedent tasks or they can be dependent on each other?
19:23:00 <selsta> sarang: please rebase #6600
19:31:41 <cohcho> moneromooo: This task to make transaction verification as fast as possible with more threads was postponed due to high complexity or low priority?
19:31:56 <cohcho> Do you expect it should be simple to speed up it with more threads?
19:49:28 <dEBRUYNE> Anyone willing to redo 5686? OP seems MIA
19:49:32 <dEBRUYNE> If not, I suppose we should close the PR
21:08:18 <moneromooo> It depends which parts of txes. Range proofs can be done as parallel as you want (and indeed they currently are). Other things are harder. Some things can only be done in parallel if they only depend on old enough data (ie, you're not trying to verify A and B in parallel when B depends on A).
21:08:41 <moneromooo> Faster verification is not postponed, which would imply it is scheduled to be done.
21:09:03 <moneromooo> As so many things, it's diminishing returns.
21:09:39 <moneromooo> So, at a first approximation, it's now less simple to speed up more than it was, and for less gain.
21:10:31 <moneromooo> I guess I can rebase that, seems simple enough.
21:23:27 <cohcho> Is it easy to find an example of v12+ block with inner dependencies between transaction?
21:24:58 <moneromooo> There won't be deps within a block. Usually at most 10 blocks away, though you might find just one block away, a wallet does this IIRC.
21:25:11 <moneromooo> I don't have an example though.
21:25:48 <cohcho> 1064ms has been spent on block 2173586 here. Does this block has inner dependencies between txs or any other obstacle that prevent fully parallel txs verification?
21:25:58 <cohcho> block have *
21:26:00 <selsta> moneromooo: aren’t 10 blocks a consensus rule now?
21:26:24 <moneromooo> Can't recall. Either v12 or v13.
21:26:38 <cohcho> It's v12 now.
21:26:44 <selsta> ah true but when syncing it will still happen for older blocsks?
21:26:54 <moneromooo> I mean for when the 10 block rule gets enforced.
21:27:00 <selsta> yes
21:28:11 <cohcho> It would be enough for mining to optimize v12+ verifications
21:29:19 <cohcho> Can you describe all known obstacles to verify v12+ txs in parallel?
21:35:29 <sarang> selsta: rebased, CI in progress
21:36:58 <moneromooo> A couple are lock contention (would be fixed by the rw lock I mentioned) and dependencies between txes in a span (doesn't apply when you get txes when mining though).
21:37:34 <moneromooo> Also, having to add code to do so, which might not be worth the gains.
21:38:37 <moneromooo> One thing that might be a fairly easy win:
21:38:56 <moneromooo> When a tx is received, mining gets paused, the tx gets verified, mining resumes.
21:39:21 <moneromooo> A very early step in tx verification is PoW verification, which is comparatively lengthy, and not parallelizable.
21:39:48 <moneromooo> But it could be done without the blockchain lock, so you can still mine (for not much if the block ends up valid though).
21:41:04 <moneromooo> Otherwise I'd have to look at the code for a while to see what can still be parallized. Again, I've done some, and the Pareto principle applies.
21:44:19 <cohcho> I'm about mining with separate application connected via rpc to monerod. Inner miner isn't my target.
21:45:18 <moneromooo> Then the miner presumably submits only blocks which meet the right difficulty, so... very seldom, right ?
21:45:59 <moneromooo> In which case, you should not care much about parallelism. it'd just take about the same amount of CPU time, just on the same core rather than several.
21:46:12 <moneromooo> Is that not the case ?
21:47:01 <moneromooo> Oh. I suppose you might be after the latency when your miner finds a block at the same time a tx is verifying.
21:47:15 <moneromooo> Very seldom but still annoying I guess.
21:47:36 <moneromooo> In those cases, chances are your block is an orphan anyway.
21:47:58 <moneromooo> (assuming I'm not missing your point)
21:48:43 <cohcho> The aim is to reduce time between events p2p_received_fluffy_block and block_accepted (job propogation delay).
21:49:04 <moneromooo> Ah, so I did miss your point.
21:49:18 <moneromooo> It's for your own block. Fair enough. Then you do want parallel indeed...
21:50:41 <moneromooo> I suppose you can already skip PoW validatrion, on account of having submitted a block because you found a nonce that matches.
21:51:30 <moneromooo> I suppose you could indeed relay the block at once, before calling handle_....
21:51:53 <moneromooo> Assuming it's from a block template that same daemon created.
22:04:46 <selsta> hmm core tests failed for the CLSAG PR
22:06:14 <selsta> multisig functional tests also failed
22:06:18 <moneromooo> I should... avoid making tests...
22:06:26 <selsta> moneromooo: can you take a look? https://github.com/monero-project/monero/runs/1038290819 (... -> View raw logs)
22:07:15 <selsta> gen_bp_tx_valid_2, gen_bp_tx_valid_3, gen_bp_tx_valid_16, gen_bp_txs_valid_2_and_2, gen_bp_txs_valid_2_and_3_and_2_and_4
22:07:18 <selsta> sounds serious :P
22:08:54 <moneromooo> Not really. It's the "doesn't use full reward" change.
22:16:41 <kayabaNerve> moneromoo: Isn't a language with static typing all the testing you need? It tests the pieces fit together!
22:17:28 <kayabaNerve> Jokes aside, it is nice to hear there's not a major problem here. Really keeping an eye on this new hard fork :)