<b​inarybaron:matrix.org> Can someone clarify this further. I still have trouble grasping exactly what this means.

<b​inarybaron:matrix.org> I have constructed a transaction with 3 outputs. In wallet2 `PendingTransaction.tx_key` has value and `PendingTransaction.additional_tx_keys` has three entries.

<b​inarybaron:matrix.org> When I construct a transaction with two outputs, `tx_key` has a value and `additional_tx_keys` is empty.

<b​inarybaron:matrix.org> Suppose I want to construct a transfer proof for one of the outputs for the transaction with three outputs (output a which is a primary address, output b which is a subaddress and output c which is change (also a subaddress))? Which of the keys should I use ?

<b​inarybaron:matrix.org> Can someone clarify this further. I still have trouble grasping exactly what this means.

<b​inarybaron:matrix.org> I have constructed a transaction with 3 outputs. In wallet2 `PendingTransaction.tx_key` has value and `PendingTransaction.additional_tx_keys` has three entries. Why do we have four tx keys now ? Is `tx_key` also present in `additional_tx_keys` ?

<b​inarybaron:matrix.org> When I construct a transaction with two outputs, `tx_key` has a value and `additional_tx_keys` is empty.

<b​inarybaron:matrix.org> Suppose I want to construct a transfer proof for one of the outputs for the transaction with three outputs (output a which is a primary address, output b which is a subaddress and output c which is change (also a subaddress))? Which of the keys should I use ?

<j​effro256:monero.social> If you look at the transaction extra, you will see 4 pubkeys contained in the transaction: one "main" pubkey in `tx_extra_pub_key`, and three "additional" pubkeys in `tx_extra_additional_pub_keys`. The private keys in the `pending_tx` correspond to these public keys. The reason that there's 4 keys for a 3-out transaction is because A) we always include a "main" txpubkey, and B) if<clipped message>

<j​effro256:monero.social> a >2-out tx contains a subaddress as a destination, then each output needs its own additional pubkey b/c of math reasons

<b​inarybaron:matrix.org> So if I want to prove to construct a transfer proof for a specific output, which tx_key should I use ? The one in `tx_extra_additional_pub_keys`?

<k​ayabanerve:matrix.org> binarybaron: May I recommend reading wallet/src/send/tx_keys.rs of monero-oxide?

<b​inarybaron:matrix.org> Thank you for taking the time to respond ❤️

<k​ayabanerve:matrix.org> It has an explicit conditional defined, `need_additional_keys`, which you should be able to trace well

<j​effro256:monero.social> To make a transfer proof, use the main tx key if to a main address, or its corresponding additional tx key if to a subaddress

<b​inarybaron:matrix.org> I will. I am looking forward to the day where I can move over to monero-oxide

<k​ayabanerve:matrix.org> What's your current blocker?

<b​inarybaron:matrix.org> manpower, too little time, wanting to maintain compatability with wallet2 wallet files, wanting to support hardware wallets in the future, missing storage layer for wallets

<k​ayabanerve:matrix.org> Uhhhh I think someone did connect oxide to a hardware wallet

<k​ayabanerve:matrix.org> Also, we have an epee lib on a PR

<k​ayabanerve:matrix.org> You'd have to define the wallet2 types but you could load such wallet files

<k​ayabanerve:matrix.org> Rest of the problems are yours though :p

<b​oog900:monero.social> we also have a rust cryptonight for that wallet file

<b​inarybaron:matrix.org> if you know anyone who would be interested in helping out with the migration, please let me know. We'd be open to funding their work with parts of our last ccs.

<b​inarybaron:matrix.org> We are going to do it eventually though... Choosing wallet2 FFI might have been the wrong decision. I know you told me so... 😄

<k​ayabanerve:matrix.org> boog900: you're shilling cuprate in a monero room? How dare you. It doesn't even have monero in its name

<k​ayabanerve:matrix.org> /s :p

<k​ayabanerve:matrix.org> I enjoy being correct and proven correct a year later, but I prefer to be listened to from the start

<k​ayabanerve:matrix.org> :p

<k​ayabanerve:matrix.org> Tbf, very diff lib a year ago w.r.t. reliability and review

<m​ayhem69:matrix.org> How about we rename Cuprate, Monero++ lol

<m​ayhem69:matrix.org> only with your approval Kayaba

<b​inarybaron:matrix.org> You cannot possibly comprehend how much pain has flown into the FFI and build system alone lol... Would have been easier to spend that time building on top of monero-oxide

<b​inarybaron:matrix.org> So if all outputs are to suabaddresses then the main tx_key has no validity for any transfer proof for that transaction ?

<e​inliterflasche2:matrix.org> We easily spend 200 hours getting our bindings to build correctly ಥ╭╮ಥ

<b​oog900:monero.social> I did want to rename to ReXmr (Rust enhanced XMR) with our logo being a T-rex but others didn't like it :( Too late now

<e​inliterflasche2:matrix.org> We easily spent 200 hours getting our bindings to build correctly ಥ╭╮ಥ

<b​oog900:monero.social> I remember the issues we had with our cryptonight bindings, having a Rust impl is so much easier to work with.

<k​ayabanerve:matrix.org> I can because I removed the C libs from monero-oxide due to being frustrated with building them and the FFI lol

<k​ayabanerve:matrix.org> mayhem69: I'm not involved with Cuprate

<k​ayabanerve:matrix.org> boog900: That sounds hilarious

<k​ayabanerve:matrix.org> I still like Monero 2: Electric Boogaloo

<m​ayhem69:matrix.org> I know but you are great at naming things :)

<m​ayhem69:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/NFrFiJyDmLyKKlXBcEQjXQRl

<m​ayhem69:matrix.org> Not to get you guys too side tracked but in an alternate future

<e​inliterflasche2:matrix.org> Do you have a link or something?

<k​ayabanerve:matrix.org> einliterflasche2: no, just whispers and a vibe

<k​ayabanerve:matrix.org> /s I'll ask

<b​oog900:monero.social> github.com/KeystoneHQ/keystone3-firmware this one?

<b​oog900:monero.social> They need to update tho they are using `monero-serai`

<k​ayabanerve:matrix.org> No, that's old news, this is recent and not yet published

<e​inliterflasche2:matrix.org> Anyone has an answer to this one?

<j​effro256:monero.social> Basically

<j​effro256:monero.social> wtf that's awesome, I didn't know that we almost had rusty dinos

<e​inliterflasche2:matrix.org> Is it guaranteed that the additional_tx_keys in wallet2::pending_tx are ordered such that they map exactly to the tx_destination_entries? Meaning that the first output that goes to a subaddress has it's transfer key at position 0 in the addition_tx_keys vector

<j​effro256:monero.social> Yes AFAIK

<e​inliterflasche2:matrix.org> If theres 3 outputs (1 base address, 1 subaddress and one change, also subaddress) then the additional_tx_key vector will be 2 long

<e​inliterflasche2:matrix.org> If theres 3 outputs (1 base address, 1 subaddress and one change, also subaddress) then the additional\_tx\_key vector will be 2 long, correct?

<e​inliterflasche2:matrix.org> And thank you so much for your help <3

Controlling the exact outputs used for a transaction - it seems the only solution for this with wallet-rpc / cli is to `freeze` all key images then `thaw` the ki's you wish to be spent, a d transfer as normal. `sweep_all` from a subaddress index is done also but there is no control over the amount being sent. Would this be a valid request for the

reference wallet?

<b​inarybaron:matrix.org> We are calling wallet2 directly (like Feather Wallet does it)

<i​nterestingband:matrix.org> hahahahahahaha

<j​effro256:monero.social> No, the reference transaction creation functions either create 0 additional tx keys or N, where N is the number of outputs in a transaction. In a 16-out tx, if even only 1 of them is a subaddress, it will include 16 additional tx pubkeys in extra

<j​effro256:monero.social> Except that it never creates them in a 2-out tx because it can be skipped

<j​effro256:monero.social> More generally, if you had 16 outputs, 1 being someone's else subaddress, and 15 change outputs, you wouldn't need any additional tx pubkeys. I can't remember if the reference wallet checks that condition though

<v​tnerd:monero.social> Does carrot drop the main pubkey when multiple outputs? I recall that it no longer uses it in that situation

<j​effro256:monero.social> Yes

<j​effro256:monero.social> It uses N "additional" in a >2-out tx, 1 in a 2-out tx, but doesn't include the "main" in a >2-out tx