03:00:11 -xmr-pr- jeffro256 opened pull request #8715: wallet2: speed up pick_preferred_rct_inputs and get_output_relatednes
03:00:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8715
03:01:57 <jeffro256[m]> At least GH has that “Co-authored-by:” feature
14:45:11 -xmr-pr- moneromooo-monero opened pull request #8716: wallet2: add on_reorg callback
14:45:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8716
17:17:01 <jeffro256[m]> moneromoooo How do you want to do the pick_preferred_rct_inputs PR? What if I add both commits you pushed, plus the patch I added on top for a total of 3 commits and you close the other PR? I just don't want 2 PRs open for the sake of the reviewers.
17:18:35 <moneromoooo> Alright then. But you'll lose my sigs if you get to rebase so would have to ping me then.
17:21:12 <rbrunner> What exactly do you mean with "losing sigs"? I have a similar situation where I merged a PR into one of my PRs, which now has two commits
17:21:23 <rbrunner> And I did have to rebase
17:22:10 <moneromoooo> A signature signs not only the patch contents but the tree it applies to. Roughly. So even if the patch itself doesn't change, the sig would be stale.
17:23:04 <rbrunner> So this is only about signed commits, signed with your key?
17:23:10 <moneromoooo> Yes.
17:23:25 <moneromoooo> If you don't sign commits, you don't care.
17:23:33 <rbrunner> Ah, ok. Thanks, I didn't sign, and neither did j-berman who made the PR to my PR.
17:25:28 <moneromoooo> I don't really like PRing other people's stuff because it kinda implies I vouch for it.
17:25:43 <moneromoooo> I did it when people went awol but it feels a bit wrong.
17:26:18 <moneromoooo> Well, I guess it doens't really imply it, but in my mind it kinda does.
17:29:36 <rbrunner> I see what you mean. I also hesitated in my case to merge, but it seemed, as an exception, the way of least resistance.
19:40:51 <UkoeHB> jeffro256[m]: added a unit test demoing tx validation result caching in seraphis https://github.com/UkoeHB/monero/blob/a8eeef8a8aba17c9437ff7925e8dfa85e22bc770/tests/unit_tests/seraphis_tx.cpp#L227
20:56:52 <jeffro256[m]> try_get_tx_contextual_validation_id doesn't include any  data from the validation context in the hash. Is this intentional?
20:56:53 <jeffro256[m]> I assume this is the Seraphis analouge of the mix ring 
21:45:16 <UkoeHB> Jeff jeffro256[m] it doesn’t?
21:51:59 <jeffro256[m]> Oops I was looking at the coinbase version my bad
21:53:34 <jeffro256[m]> I've got a lot of reading to do lol
22:00:02 <UkoeHB> lol yeah coinbase tx validation is contextless since I decided that block reward and block height validation should be done more ad hoc
22:01:24 <UkoeHB> the block reward depends on tx fees anyway
22:02:45 <UkoeHB> idk, I suppose the validation context could also be used to check coinbase height and reward, guess we will see if that's needed in practiced
22:02:57 <UkoeHB> practice*