13:58:34 Can someone clarify this further. I still have trouble grasping exactly what this means. 13:58:35 I have constructed a transaction with 3 outputs. In wallet2 `PendingTransaction.tx_key` has value and `PendingTransaction.additional_tx_keys` has three entries. 13:58:37 When I construct a transaction with two outputs, `tx_key` has a value and `additional_tx_keys` is empty. 13:58:39 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 ? 13:59:31 Can someone clarify this further. I still have trouble grasping exactly what this means. 13:59:31 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` ? 13:59:33 When I construct a transaction with two outputs, `tx_key` has a value and `additional_tx_keys` is empty. 13:59:35 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 ? 14:07:45 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 14:07:45 a >2-out tx contains a subaddress as a destination, then each output needs its own additional pubkey b/c of math reasons 14:09:43 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`? 14:09:47 binarybaron: May I recommend reading wallet/src/send/tx_keys.rs of monero-oxide? 14:09:53 Thank you for taking the time to respond ❤️ 14:10:09 It has an explicit conditional defined, `need_additional_keys`, which you should be able to trace well 14:10:29 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 14:11:23 I will. I am looking forward to the day where I can move over to monero-oxide 14:11:42 What's your current blocker? 14:12:42 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 14:13:17 Uhhhh I think someone did connect oxide to a hardware wallet 14:13:34 Also, we have an epee lib on a PR 14:13:59 You'd have to define the wallet2 types but you could load such wallet files 14:14:17 Rest of the problems are yours though :p 14:14:39 we also have a rust cryptonight for that wallet file 14:15:06 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. 14:15:07 We are going to do it eventually though... Choosing wallet2 FFI might have been the wrong decision. I know you told me so... 😄 14:15:17 boog900: you're shilling cuprate in a monero room? How dare you. It doesn't even have monero in its name 14:15:17 /s :p 14:15:43 I enjoy being correct and proven correct a year later, but I prefer to be listened to from the start 14:15:45 :p 14:16:16 Tbf, very diff lib a year ago w.r.t. reliability and review 14:16:21 How about we rename Cuprate, Monero++ lol 14:16:42 only with your approval Kayaba 14:16:55 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 14:17:45 So if all outputs are to suabaddresses then the main tx_key has no validity for any transfer proof for that transaction ? 14:18:51 We easily spend 200 hours getting our bindings to build correctly ಥ╭╮ಥ 14:19:01 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 14:19:07 We easily spent 200 hours getting our bindings to build correctly ಥ╭╮ಥ 14:20:11 I remember the issues we had with our cryptonight bindings, having a Rust impl is so much easier to work with. 14:20:46 I can because I removed the C libs from monero-oxide due to being frustrated with building them and the FFI lol 14:20:47 mayhem69: I'm not involved with Cuprate 14:21:05 boog900: That sounds hilarious 14:21:11 I still like Monero 2: Electric Boogaloo 14:24:10 I know but you are great at naming things :) 14:25:53 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/NFrFiJyDmLyKKlXBcEQjXQRl 14:25:55 Not to get you guys too side tracked but in an alternate future 14:26:15 Do you have a link or something? 14:27:39 einliterflasche2: no, just whispers and a vibe 14:27:45 /s I'll ask 14:33:09 https://github.com/KeystoneHQ/keystone3-firmware this one? 14:34:33 They need to update tho they are using `monero-serai` 14:36:54 No, that's old news, this is recent and not yet published 14:40:59 Anyone has an answer to this one? 14:42:24 Basically 14:45:00 wtf that's awesome, I didn't know that we almost had rusty dinos 15:10:30 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 15:29:12 Yes AFAIK 15:32:58 If theres 3 outputs (1 base address, 1 subaddress and one change, also subaddress) then the additional_tx_key vector will be 2 long 15:33:02 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? 15:34:17 And thank you so much for your help <3 15:35:50 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 15:35:50 reference wallet? 15:47:41 We are calling wallet2 directly (like Feather Wallet does it) 17:02:42 hahahahahahaha 17:05:05 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 17:05:37 Except that it never creates them in a 2-out tx because it can be skipped 17:06:29 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 17:38:19 Does carrot drop the main pubkey when multiple outputs? I recall that it no longer uses it in that situation 17:38:39 Yes 17:39:19 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