00:26:12 <afungible[m]1> One quick question. If I want to improve some aspect of the /monero code, should I create a direct pull request for review OR first create a PR/improvement suggestion & then work on it? It could be small but I'd never know if it'd be desired/will be merged.
00:41:31 <selsta> afungible[m]1: there is no rule, do what makes sense to you
00:41:59 <selsta> if it's a "controversial" or larger change it makes sense to discuss it beforehand
00:42:10 <selsta> otherwise just open a PR directly
00:43:30 <monerobull[m]> And don't be discouraged if your stuff doesn't get merged for months
00:44:15 <afungible[m]> Thanks guys.
00:44:39 <monerobull[m]> There arent many reviewers and they often have more important stuff to do
00:47:06 <afungible[m]> I am new to the show & I'd be happy to review any code. esp. smaller patches to begin with.
12:14:00 <ErCiccione> are the tests for https://github.com/monero-project/monero/pull/8076 expected to fail?
12:16:23 <rbrunner> The failures seem to occur very early in the build process, but I am not well versed at reading that stuff. Looks really strange. selsta?
12:17:57 <rbrunner> I see the commit number 8482 in there. Maybe that's a side effect from the PR that you accidentally opened and closed again right away?
12:19:03 <rbrunner> 42 Error: fatal: couldn't find remote ref refs/pull/8482/merge
12:19:34 <ErCiccione> indeed seems to be a problem of git. I wouldn't know how another  pr could affect the bots
12:19:57 <ErCiccione> my pr on haveno's monero seem to be building fine: https://github.com/haveno-dex/monero/pull/6
12:20:24 <rbrunner> Yes, my PR also built - originally. I did not see any error when jberman approved.
12:20:46 <ErCiccione> selsta if you have powers could you retrigger the buildbots for 8076?
12:21:35 <ErCiccione> might be some weird github bug triggered by me closing the wrong pr before it completed the tests
14:01:52 <woodser[m]> <selsta> "woodser: can you revert https..." <- I confirm my issue is resolved by reverting this PR
14:15:11 <woodser[m]> opened an issue for exporting/importing outputs breaking the wallet since #8179: https://github.com/monero-project/monero/issues/8484
15:01:57 <jberman[m]> submitted the PR for pools to update node-cryptonote-util for the hf (I haven't tested it myself -- getting a dev env set up hasn't been the most straightforward): https://github.com/Snipa22/node-cryptonote-util/pull/7
15:02:23 <jberman[m]> going to move over to this 8484 issue^^
15:09:08 <selsta> rbrunner: you have to force push the restart CI
15:33:59 <ErCiccione> Would be better to simply retrigger the builds
15:36:44 <ErCiccione> luigi1111 has powers for sure. Could you retrigger the builds for https://github.com/monero-project/monero/pull/8076
15:37:03 <ErCiccione> in any case the pr is fine. my pr built with no issues
15:39:46 <rbrunner> Seems to me I would have to change something for a force-push, resulting in a new commit hash. Not sure that's a good idea just for those borked builds ...
15:40:44 <ErCiccione> yeah that's why i suggest to simply retrigger. it's a matter of clicking one button
15:41:19 <ErCiccione> always better avoid a force push after a big pr has been reviewed if it's not strictly necessary 
15:41:22 <ErCiccione> 🙂
15:41:54 <rbrunner> Funny how those hyper-complex things like this CI always behave in a similar way: If they work, it's almost magic, if not, you fall into a deep hole.
16:00:47 <luigi1112> i did something
16:14:10 <rbrunner> Thanks, but it looks to me like it ran into the same problem as the first attempt:
16:14:41 <rbrunner> ErCiccione opened a second PR for #8076, #8482, and deleted it shortly afterwards: https://github.com/monero-project/monero/pull/8482
16:15:09 <rbrunner> But now this seems to confuse CI somehow on the original PR 8076, as I believe to see in the error messages
16:15:21 <rbrunner> No idea however how to rectify this if true ...
16:16:06 <rbrunner> (ErCiccione simply was in the wrong repo when opening, they intended to open a Haveno PR.)
16:18:20 <rbrunner> Seems to me luigi1112 needs to apply some more powerful magic :)
16:21:50 <luigi1112> :shrug:
16:32:13 <selsta> don't see a way to fix this apart from closing and reopening a new PR
16:47:50 <rbrunner> Do you mean the PR as such is somehow broken now, which may later lead to troubles when merging, or only the CI is totally lost for this PR?
16:50:49 <selsta> I don't know what happens when merging, but I was only talking about CI on that PR.
16:52:47 <rbrunner> Alright. I propose to just wait and see then. In any case I know that the PR builds, and jberman could probably confirm. Is it already noted for merge, by the way?
17:11:45 <selsta> .merges
17:11:45 -xmr-pr- 8323 8352 8359 8379 8415 8419 8427 8428 8442 8444 8450 8451 8454
17:14:37 <selsta> moneromooo: could you take a look over this PR? It is well tested already, just would like another code review: https://github.com/monero-project/monero/pull/8465/
17:17:40 <selsta> rbrunner: it will conflict with https://github.com/monero-project/monero/pull/8427
17:18:41 <rbrunner> I see. So first merge that one, then I solve the conflicts, and then the way might be clear?
17:19:09 <selsta> yes, plus I will test your PR on my node now
17:20:25 <rbrunner> All clear. I will keep an ear on the ground :)
17:20:58 <selsta> stagenet forked to v15 without issues, v16 fork in 16h
21:14:17 <afungible[m]> Can someone explain in simple terms, what determines generation of a "key image" for a transaction? 
21:14:17 <afungible[m]> And if 2 same "key images" were to be found in lmdb, would that indicate a double spend?
21:30:35 <selsta> .merge+ 8299 8483
21:30:35 <xmr-pr> Added
21:32:06 <UkoeHB> afungible[m]1: each input has a key image computed from the input's onetime address like this: `ko * Hp(Ko)`, with the special hash-to-point algo `Hp()`
21:32:50 <UkoeHB> if two identical key images were found in lmdb, that would probably be a critical bug
21:40:50 <afungible[m]> So, Input's one-time addr. = sub-addr at an index, in an account? And what is 'ko'?
21:40:50 <afungible[m]> ps: not a hardcore math guy, bt will try to get this. Thanks.
21:46:33 <UkoeHB> ko is the onetime address private key. A onetime address is an address or subaddress spend key plus a DH-based extension defined by the tx author.