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.

afungible[m]1: there is no rule, do what makes sense to you

if it's a "controversial" or larger change it makes sense to discuss it beforehand

otherwise just open a PR directly

And don't be discouraged if your stuff doesn't get merged for months

Thanks guys.

There arent many reviewers and they often have more important stuff to do

I am new to the show & I'd be happy to review any code. esp. smaller patches to begin with.

are the tests for monero-project/monero #8076 expected to fail?

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?

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?

42 Error: fatal: couldn't find remote ref refs/pull/8482/merge

indeed seems to be a problem of git. I wouldn't know how another pr could affect the bots

my pr on haveno's monero seem to be building fine: haveno-dex/monero #6

Yes, my PR also built - originally. I did not see any error when jberman approved.

selsta if you have powers could you retrigger the buildbots for 8076?

might be some weird github bug triggered by me closing the wrong pr before it completed the tests

<selsta> "woodser: can you revert https..." <- I confirm my issue is resolved by reverting this PR

opened an issue for exporting/importing outputs breaking the wallet since #8179: monero-project/monero #8484

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): Snipa22/node-cryptonote-util #7

going to move over to this 8484 issue^^

rbrunner: you have to force push the restart CI

Would be better to simply retrigger the builds

luigi1111 has powers for sure. Could you retrigger the builds for monero-project/monero #8076

in any case the pr is fine. my pr built with no issues

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 ...

yeah that's why i suggest to simply retrigger. it's a matter of clicking one button

always better avoid a force push after a big pr has been reviewed if it's not strictly necessary

🙂

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.

i did something

Thanks, but it looks to me like it ran into the same problem as the first attempt:

ErCiccione opened a second PR for #8076, #8482, and deleted it shortly afterwards: monero-project/monero #8482

But now this seems to confuse CI somehow on the original PR 8076, as I believe to see in the error messages

No idea however how to rectify this if true ...

(ErCiccione simply was in the wrong repo when opening, they intended to open a Haveno PR.)

Seems to me luigi1112 needs to apply some more powerful magic :)

:shrug:

don't see a way to fix this apart from closing and reopening a new PR

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?

I don't know what happens when merging, but I was only talking about CI on that PR.

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?

.merges

moneromooo: could you take a look over this PR? It is well tested already, just would like another code review: monero-project/monero #8465

rbrunner: it will conflict with monero-project/monero #8427

I see. So first merge that one, then I solve the conflicts, and then the way might be clear?

yes, plus I will test your PR on my node now

All clear. I will keep an ear on the ground :)

stagenet forked to v15 without issues, v16 fork in 16h

Can someone explain in simple terms, what determines generation of a "key image" for a transaction?

And if 2 same "key images" were to be found in lmdb, would that indicate a double spend?

.merge+ 8299 8483

Added

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()`

if two identical key images were found in lmdb, that would probably be a critical bug

So, Input's one-time addr. = sub-addr at an index, in an account? And what is 'ko'?

ps: not a hardcore math guy, bt will try to get this. Thanks.

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.