jberman: Isn't it the case that if an attacker somehow knew that a target user was using the reference wallet, the vulnerability, in your original formulation, would still be a concern?

if an attacker knows a transaction came from the reference wallet then it should still be a concern yes

Is there some kind of backlog/list of issues, that need to be tackled? Or how can I contribute/learn the best as a new member?

<ellpepe[m]> "Is there some kind of backlog/..." <- You may look at github.com/monero-project/monero/labels

labels are not really used in that repo. Better take a look at the open issues ellpepe[m]

indeed many labels seem quite old and obsolete (but I didn't check all of them)

yeah they are not used. They might well be still the default ones of when a repo is created

Could somebody from here review monero-project/monero-site #1831?

<ErCiccione> "Could somebody from here..." <- it is intended to be a blog post ?

yep. selsta already left his approval. I'm reviewing as we speak

moneromooo: luigi1111w : I have now submitted the document and supporting materials to HackerOne, encrypted with your respective PGP keys. The text itself is 11 pages. With images, tables, and code appendices, it is 28 pages. Thank you for reviewing it!

> * <@moneromooo:libera.chat> feels DoSed

Lol. Feel free to take your time with it :)

<Rucknium[m]> "moneromooo: luigi1111w : I..." <- thanks for dedicating all this time into it :) cheers

Is generate_from_keys and open_wallet in monero_wallet_rpc an expensive operation if done only with viewkeys? I have lots of view keys and I want to make integrated addresses and then look with get_bulk_payments if the money was received. Is going through wallet rpc even the right approach in my case? it seems like I would have to go through all the viewkeys sequentially in repeated intervals. instead of just looking for incoming

payments to any of the view keys.

The tx scan will be expensive either way.

If you can do with subaddresses/accounts instead, do that, scales in O(N) rather then O(NM) (with N being number of outputs, M being number of view keys)

That said, generate_from_keys and open_wallet aren't super expensive, but I'd expect something on the order of 1 second.

open_wallet may take more if it's got to load a massive wallet cache too.

If the bot is still borked, someone please repaste the above on a paste site and paste the url for spirobel[m].

(someone from matrix :P)

Is there a reason why monero isn't publish docker containers along with the cli releases? (or perhaps I've not looked in the right place)

<spirobel[m]> "Is generate_from_keys and..." <- okay i read this monerodocs.org/public-address/integrated-address and the linked to reddit thread. it says to create an integrated address no private key is necessary and monitoring incoming funds to integrated addresses is essentially free: reddit.com/r/Monero/comments/9aevri…ay_integrated_addresses_are/e4vf47p i was just wondering how to actually

achieve this. I am going to do more digging by myself, but I would be glad if someone can give me some hints 😀🙃😆❤️

Subaddresses are better than integrated addresses at first approximation.

<spirobel[m]> "okay i read this https://..." <- There are recurring discussions about deprecating and suppressing integrated addresses.

Last one = monero-project/monero #7889

Using subaddresses is generally preferred.

Subaddresses are indeed really quite easy to use.

janitha: there is a docker file in the repo, but it needs someone to maintain it, and AFAIK nobody volunteered for that.

> <@hoverhalver:monero.social> There are recurring discussions about deprecating and suppressing integrated addresses.... (full message at libera.ems.host/_matrix/media/r0/do…648d3684cd909a7cf366990a686316c35c8)

(even though maybe its still not solving my issue because i guess payment processors would still deal with only a single view key)

* view key/wallet)

my monerod is spamming console with this

021-09-16 16:18:56.613 E Exception at [portable_storage::load_from_binary], what=duplicate key: support_flags

2021-09-16 16:18:58.608 E duplicate key: support_flags

Do you have the whole stack trace ? At first approximation, it's probably ignorable unless something isn't catching and dropping the connection.

hang on, yeah stack traces are in logfile

eh, no useful symbol info tho

It still keeps up, right ?

seems so

Then it's just someone hacking the source and fucking up. Can be ignored.

ok

still, it's a continuous stream of errors. one of the peers I'm connected to is causing this?

Somewhere upstack, you'll have a connection_context object, it prints the IP:port when logged.

Attaching gdb and breaking in... hmm... maybe "catch throw" will work, though that might give many false positives.

Maybe not, looks like only duplicate keys in your log. gdb should see the stack a bit better.

pigeons: pigeons : The IRC --> Matrix bridge seems to be broken for #monero-dev and another channel (can't remember which exactly) Could you try to fix it? Or someone else?

I thought it was a network wide bridge, not a monero one.

Must be, there are a few [m] people in #townforge and I've not added any matrix bot.

moneromooo: You can directly join an IRC channel from Matrix with "!join #monero-research-lab" command to the appservice . Somehow that is different from the corresponding Matrix room. So what I see now in my Matrix client are two #monero-dev channels: the native Matrix one and the IRC one. I can see your messages in the IRC one but not the Matrix native one.

test

IRC -> Matrix test message

hyc: had this too the past weeks

can be ignored

IRC bridge in here should be fixed, in theory.

I see selsta messages now after the change.

Seth: Thank you!

moneromooo can you add a comment to this report pointing to the PR that fixed the issue?

or TheCharlatan

I guess this one? monero-project/monero #6745

Yes.