02:27:31 <jeffro256[m]> 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 
06:43:34 <chch3003[m]> Hello! I just learned that Kovri has not been implemented in Monero ?! https://www.getmonero.org/fr/resources/moneropedia/kovri.html Why is that?
06:46:52 <geonic> because we have Tor & I2P https://github.com/monero-project/monero/blob/master/docs/ANONYMITY_NETWORKS.md
06:48:03 <chch3003[m]> i2p-zero right? I see. Thank you
06:49:55 <chch3003[m]> Can you run both I2P and Tor?
07:30:26 <geonic> i think it's recommended that you pick one. vtnerd would know best
10:21:20 <kayabanerve[m]> What are the rules on change addresses?
10:23:51 <kayabanerve[m]> 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.
10:23:55 <kayabanerve[m]> https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_format_utils.cpp#L1062 This is the exact error being hit.
10:24:59 <sech1> seems like a bug
10:25:16 <sech1> additional_derivations will have size 1 in this case, and output_index for the 2nd output will be also 1
10:25:34 <kayabanerve[m]> I'm not sure. I think it's an attempt at normalization.
10:26:01 <kayabanerve[m]> 99% of TXs have a change output to (0, 0)
10:26:33 <sech1> additional_derivations should have the same size as the number of outputs
10:26:43 <sech1> so maybe the problems is in the tx creation code
10:26:47 <kayabanerve[m]> There shouldn't be TXs on the net which hit this accordingly
10:27:00 <kayabanerve[m]> sech1: Shoudn't there always be TX_PUBLIC_KEY?
10:27:08 <sech1> yes
10:27:16 <kayabanerve[m]> And ADDITIONAL_PUBLIC_KEY (or whatever they're called) should therefore always have n-1
10:27:55 <kayabanerve[m]> This code is erroring because a 2-out TX has 2 keys.
10:28:33 <sech1> this assert is not needed
10:28:47 <kayabanerve[m]> 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.
10:28:54 <sech1> a tx can have 16 outputs and only one of them using additional pub key
10:29:01 <kayabanerve[m]> It isn't, and yet it's here, and I have to deal with it.
10:29:10 <kayabanerve[m]> So I'm curious what rules are here, even if it shouldn't be
10:29:37 <kayabanerve[m]> Or more specifically, akil27 who found this. I'm just the one trying to get someone who already knows about this to confirm/deny
10:29:42 <sech1> as it is now, a tx must have either empty ADDITIONAL_PUBLIC_KEY array or exactly the number of outputs in this array
10:29:52 <kayabanerve[m]> ... oh
10:30:06 <kayabanerve[m]> TIL
10:30:22 <kayabanerve[m]> ... won't that generate 3 keys if sending to two subaddresses in a 2-out TX?
10:31:01 <sech1> no, you just make a copy of the derivation in one of the slots
10:31:46 <sech1> I think
10:32:16 <kayabanerve[m]> 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
13:10:17 <UkoeHB> kayabanerve[m]: when the additional keys are present the tx pubkey is also redundantly present, it’s a long-standing issue
13:10:49 <kayabanerve[m]> Is there a fingerprinting issue if we just set the TX pubkey to a random point?
13:11:44 <kayabanerve[m]> 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?
13:13:02 <UkoeHB> Probably a fingerprinting issue yes
13:13:16 <UkoeHB> I don’t remember off the top of my head
13:16:33 <kayabanerve[m]> https://github.com/monero-project/monero/blob/ab63fbc549b2534ce63726ba6ed2fdee29ca9a14/src/device/device_default.cpp#325
13:16:56 <kayabanerve[m]> Looks like the additional should only be used for subaddress outputs.
13:20:58 <kayabanerve[m]> (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)
13:21:51 <kayabanerve[m]> 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.
13:43:09 <shalit[m]> 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?
13:51:30 <rbrunner> shalit[m]: You may have a look at this "recruiting devs" text I wrote, about a particular and particularly big project within Monero
13:51:31 <rbrunner> https://github.com/seraphis-migration/wallet3/issues/40
13:55:35 <rbrunner> 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
13:55:36 <rbrunner> https://github.com/monero-project/meta/issues/783
13:58:14 <shalit[m]> rbrunner: Wow, sounds really interesting, how can I join this meeting?
13:59:41 <ghostway[m]> Join "No Wallet Left Behind"!
14:03:00 <rbrunner> Yeah, the place where we conspire to conquer the world using Monero and Seraphis is this: https://matrix.to/#/#no-wallet-left-behind:monero.social
14:03:38 <rbrunner> We also have a wiki: https://github.com/seraphis-migration/strategy/wiki
16:08:30 <jtgrassie> kayabanerve[m]: wrt additional pub keys: https://github.com/monero-project/monero/blob/50aa0e8b7f11680be3954c176f2daa9ccf77b7dd/src/cryptonote_core/cryptonote_tx_utils.cpp#L399
16:10:31 <jtgrassie> (as to when they are needed)
17:30:20 <Disciiple[m]> Is this a general monero room or just for development?
17:30:37 <Disciiple[m]> Nvm
18:08:37 <UkoeHB> kayabanerve[m]: looks like the main tx pubkey is not a duplicate of the any 'additional' tx pubkeys
18:09:01 <UkoeHB> of any*
18:13:21 <UkoeHB> 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)
20:57:10 <soakermonero[m]> helo everyone. good to be here and thanks.
20:59:01 <soakermonero[m]> 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.
21:00:11 <plowsof11> is this a -dev question or #monero-gui:monero.social / #monero-support:monero.social ? 
21:02:54 <soakermonero[m]> thanks more of support , now i see that channel thanks and sorry