Maybe the tx validation context could be split into two parts: tx block relative information and absolute information. Ring input members would fall into absolute informaton whereas coinbase height and reward would fall into tx block relative

Hello! I just learned that Kovri has not been implemented in Monero ?! getmonero.org/fr/resources/moneropedia/kovri.html Why is that?

because we have Tor & I2P github.com/monero-project/monero/bl…b/master/docs/ANONYMITY_NETWORKS.md

i2p-zero right? I see. Thank you

Can you run both I2P and Tor?

i think it's recommended that you pick one. vtnerd would know best

What are the rules on change addresses?

For a two-out TX, monero-wallet-rpc errors when trying to scan the second output if there's an additional public key. It sounds like having a two-out TX to two subaddresses (either no change or subaddress change) isn't supported accordingly.

github.com/monero-project/monero/bl…c/cryptonote_format_utils.cpp#L1062 This is the exact error being hit.

seems like a bug

additional_derivations will have size 1 in this case, and output_index for the 2nd output will be also 1

I'm not sure. I think it's an attempt at normalization.

99% of TXs have a change output to (0, 0)

additional_derivations should have the same size as the number of outputs

so maybe the problems is in the tx creation code

There shouldn't be TXs on the net which hit this accordingly

sech1: Shoudn't there always be TX_PUBLIC_KEY?

yes

And ADDITIONAL_PUBLIC_KEY (or whatever they're called) should therefore always have n-1

This code is erroring because a 2-out TX has 2 keys.

this assert is not needed

I think that's stupid as hell, as it doesn't allow TXs without change. I'd understand if this is an attempt at normalization. Don't reveal you're sending to a subaddress, for a standard 2-out TX, by changing the change derivation formula from 8rA to 8Ra.

a tx can have 16 outputs and only one of them using additional pub key

It isn't, and yet it's here, and I have to deal with it.

So I'm curious what rules are here, even if it shouldn't be

Or more specifically, akil27 who found this. I'm just the one trying to get someone who already knows about this to confirm/deny

as it is now, a tx must have either empty ADDITIONAL_PUBLIC_KEY array or exactly the number of outputs in this array

... oh

TIL

... won't that generate 3 keys if sending to two subaddresses in a 2-out TX?

no, you just make a copy of the derivation in one of the slots

I think

Except if you need the derivations to have the same length, then it'll have the base key and n additionals. That causes n+1

kayabanerve[m]: when the additional keys are present the tx pubkey is also redundantly present, it’s a long-standing issue

Is there a fingerprinting issue if we just set the TX pubkey to a random point?

As in, if the TX pubkey supposed to be equal to additional[0]/is the TX pub key usable by the person receiving output 0?

Probably a fingerprinting issue yes

I don’t remember off the top of my head

Looks like the additional should only be used for subaddress outputs.

(so a recipient who uses a standard address dest will naturally scan the additional pub key, yet if they code in an extra debug statement, they'll realize it wasn't wallet2 which created the TX)

As long as all keys are unique, and the additional pub keys line up with the outputs, it should only be fingerprintable to recipients though, AFAICT. Not saying that's acceptable, just looking for corrections in my understanding of the behavior/implications.

Hi, I have experience with cpp and other languages mostly in the field of OS's and embedded systems and I would like to contribute to the monero project. What are the current projects that I can start contribute to?

shalit[m]: You may have a look at this "recruiting devs" text I wrote, about a particular and particularly big project within Monero

We have a workgroup for that, and on the next weekly meeting coming Monday I propose to talk about something like "embedded systems" and Monero, hardware wallets

rbrunner: Wow, sounds really interesting, how can I join this meeting?

Join "No Wallet Left Behind"!

Yeah, the place where we conspire to conquer the world using Monero and Seraphis is this: matrix.to/#/#no-wallet-left-behind:monero.social

We also have a wiki: github.com/seraphis-migration/strategy/wiki

kayabanerve[m]: wrt additional pub keys: github.com/monero-project/monero/bl…e_core/cryptonote_tx_utils.cpp#L399

(as to when they are needed)

Is this a general monero room or just for development?

Nvm

kayabanerve[m]: looks like the main tx pubkey is not a duplicate of the any 'additional' tx pubkeys

of any*

although it seems the normal tx construction method always uses the main tx pubkey for change outputs... which I was not aware of (this spaghetti is really frustrating)

helo everyone. good to be here and thanks.

i have a wallet support question which i couldnt solve , and i wonder of there is any other way to crosscheck it. or do it again.

is this a -dev question or #monero-gui:monero.social / #monero-support:monero.social ?

thanks more of support , now i see that channel thanks and sorry