10:11:39 UkoeHB_ if i understand correctly, the view tag concept is essentially that one scalarmultbase can be saved per output scanned, 255 out of 256 times? 10:11:58 that's very cool 10:15:43 i like everything in your issue #6456, with just the exception that the janus mitigation requires knowledge of the private view key. i think making the janus mitigation work with view-only wallets should be a design goal 10:46:45 s/knowledge of the private view key/knowledge of the private spend key 10:46:45 knaccc meant to say: i like everything in your issue #6456, with just the exception that the janus mitigation requires knowledge of the private spend key. i think making the janus mitigation work with view-only wallets should be a design goal 10:59:07 also, for the record, i'd be in favor of eliminating encrypted payment ids 11:00:21 and thus i'd be in favor of leaving them in txextra and not putting them into the new tx_supplement, and then hopefully they will be used less and less until not used at all 11:10:58 Ah I see a question. The 48-byte method seems to require using a secret subaddress for change outputs. However, in the future I imagine needing to do audits will be fairly widespread. Based on the framework I laid out in ZtM2 ch8 (section 8.2), the only way to do an audit is for the auditor to know the auditee's addresses and subaddresses. Note the framework includes InProofs, which require addresses 11:41:29 A solution might be a spend-wallet/view-wallet hierarchy, where the view wallet has access to the chain, and then talks to the spend wallet for importing key images (to identify change outputs). The view wallet would need to send info to the spend wallet to get key images, so it could just send the information to perform Janus tests too, a point in favor of Janus base key method. However, a view wallet 11:41:29 would only talk to a spend wallet periodically, so its set of key images would always be older than new outputs being discovered. In that case, with 48-byte proofs you could do a Janus test sooner on non-change outputs, a Janus test on change outputs up to the block height with known key images, and then leave the remainder change outputs as 'tentative change outputs' pending a refresh with the spend 11:41:29 wallet. 11:42:17 Im not sure if we want to base the design choice on that complex of a setup though 11:49:30 Hm although the auditor has to learn addresses and subaddresses.. while the point of Janus is to prevent that! 11:50:49 But an auditor would be able to use the secret change address to Janus attack subaddresses hidden from the audit 11:58:15 Regarding the change subaddress assumption.. what if someone doesn't want all their change outputs to go to the same address? It seems to have some privacy implications for advanced users. 11:59:00 One big point against Janus base key method is TxTangle wouldn't be compatible 12:10:57 i should catch up on TxTangle, i don't know what that is 12:11:13 good points above 12:11:51 so either we accept that an auditor (or anyone with knowledge of the private view key) is able to janus attack a wallet 12:12:40 or we add a janus schnorr proof on both of the 2 outs in a 2-out tx 12:13:17 it's worth pointing out that the auditor can't gain anything from janus attacking the wallet, since all a janus attack achieves is proving that subaddresses belong to the same wallet 12:13:19 anyone who knows the private view key can calculate all subaddresses, so it isn't a concern 12:13:50 he could uncover hidden subaddresses from the same private keys 12:13:57 right 12:14:13 ok so great, the auditor issue isn't a concern, right? 12:14:37 auditor doesnt need to know the private view key, which is the point of the audit framework 12:14:50 so there is a small window 12:14:59 i should read up on your auditor framework stuff 12:15:10 txtangle is in there as well, ch11 12:15:22 what is the advantage of not simplifinh things by just giving the auditor the private view key? 12:15:40 they don't learn about future outputs you might receive 12:15:52 and don't learn key images, so can't know when current unspent outputs are spent 12:18:12 ok so without the auditing framework, the other way to achieve the same outcome would be to simply get the auditee to switch to a new wallet/new private view key at the point where they want to cut off the auditor from seeing future transactions, until some point at which they wish to have further txs audited and where they will provide the auditor with the more recent private view key 12:19:07 yes that would work, although they would have to update all contacts with new addresses, and transfer all funds over from all subaddresses 12:19:13 so the auditing framework is for when you only want to restrict recent transactions from an auditor until the next audit 12:20:19 right, it also means if the auditor gets compromised then your view key/key images are not compromised 12:20:24 minimizes risk 12:20:31 interesting, ok 12:20:51 i'll take a read of it in z2m2 12:24:36 btw i still marvel at z2m all the time. incredbile piece of work 12:24:48 thanks :) 12:38:23 I think these are the main tradeoffs to consider: 12:38:23 1. Janus base key: +32 bytes on average, requires private spend key, not compatible with TxTangle 12:38:23 2. 48-byte Schnorr (w/ change out assumption): +48 bytes on average, view-only compatible, change assumption is not super clean/robust given design goal of view-only compatibility 12:38:23 3. 48-byte Schnorr (w/o change out assumption): +96 bytes on average, view-only compatible, no concern about change outputs 12:38:23 notes: 48-byte Schnorr is TxTangle compatible; no compromises are made on scanning time for any solution 12:39:33 UkoeHB_ can you be specific about the change assumption not being clean/robust given design goal of view-only compatibility? 12:39:53 is that only with reference to the auditing framework? 12:40:28 there is the auditing scenario, and also that maybe people don't want to always use the same change address 12:42:14 given that balances received to any subaddress in an account are generally supposed to be in a single pool, i'm struggling to see a scenario where it'd be useful to send change to a particular subaddress within an account 12:44:02 it feels too far away from the basic protocol, requiring users to use specific addresses for specific scenarios 12:44:39 a scoping problem, if you will 12:47:50 i think i get the gist of what you mean. i see this more as just the tiniest of changes, where the change subaddress will be set to subaddress index -1 instead of subaddress index 0 12:48:26 i'm assuming that 0 is the default change subaddress if none is specially given 12:48:36 i'm not sure if that assumption is correct for the monero wallet 12:49:04 i also can't think of any use cases we'd want to preserve when it comes to directing change to particular subaddresses rather than to particular accounts 12:50:26 if when an outgoing tx is made, if outputs received to any subaddress in an account can be spent, i don't see any advantage to directing change to any particular subaddress within the account 12:53:32 and given that we're not showing balances per-subaddress in most wallets, i don't see how it's useful to send change to a particular subaddress 12:54:30 I see what you mean, that seems a reasonable assumption. The risk with change outputs all going to the same place is when you spend them they can create heuristically significant ring loops on-chain. However, if subaddress accounts are considered separate behavioral units then that situation isn't affected by the change subaddress designation. 12:54:58 right, *if* 12:55:21 but we decided not to consider subaddresses within accounts as separate behavioral units 12:55:32 I mean the account itself as a unit 12:55:53 ok i'd better clarify something just in case it wasn't clear: 12:56:09 i didn't mean that an entire wallet would have all change sent to a particular change address 12:56:27 i meant that for each account, there would be a change subaddress of index -1 12:56:37 so you still have account segregation 12:56:41 Yeah I noticed that after what you said 10mins ago :p 12:56:56 ah ok cool :) 12:58:02 btw with the auditor framework, i guess the advantage is that you prevent the auditor from seeing future txs, but the disadvantage is that the auditee could decide to not declare 10% of the incoming txs to the auditor, and siphon off those funds to a personal account, and the auditor would be none the wiser? 12:58:06 so making a change assumption and implementing Janus would require widespread consensus about the account model 12:58:31 right, yes wallets would have to agree 12:58:34 otherwise wallets wouldn't be interchangeable for users since Janus might get flagged in different ways 12:59:01 although I think spend enabled wallets should try to use key images to identify change outs just in case 12:59:14 yeah if wallets for some reasons wanted to work in a different way, they could ignore the janus stuff and do things however they wanted, and it woulnd't affect anyone else 12:59:48 with the audit framework you make an inproof on all on-chain outputs 13:00:34 so none can slip through the cracks 13:01:26 oh, so you can't just neglect to tell the auditor about certain inbound txs? 13:01:31 right 13:01:38 ok thanks, i'll read it again, i didn't realize that 13:01:48 from a maintainability standpoint then, change assumption would be the most expensive 13:03:59 Updated main tradeoffs to consider: 13:03:59 1. Janus base key: +32 bytes on average, requires private spend key, not compatible with TxTangle 13:03:59 2. 48-byte Schnorr (w/ change out assumption): +48 bytes on average, view-only compatible, change assumption entails code maintainability costs and extra logic for identifying change outputs 13:03:59 3. 48-byte Schnorr (w/o change out assumption): +96 bytes on average, view-only compatible, no concern about change outputs 13:03:59 notes: 48-byte Schnorr is TxTangle compatible; no compromises are made on scanning time for any solution 13:06:50 "and extra logic for identifying change outputs" <- other than just ensuring that the subaddress lookup table is generated from -1 onwards rather than from 0 onwards, what logic are you referring to? 13:08:01 well logic for spend wallets vs view-only if necessary, or logic to deal with new subaddress account schemes that might crop up 13:09:24 the other solutions, once implemented, would never need to be touched again, but the change out assumption _may_ need to get touched again 13:09:51 what would be different with spend vs view-only? 13:10:04 a spend wallet can use key images to identify change outs 13:11:00 I guess it's 'possibly* extra logic' not guaranteed lol 13:11:48 to be explicit: i think you're saying that if you know a change output was an output you spent yourself, you can trust it as not being a janus attack 13:12:00 right 13:12:05 and that that test should happen regardless of whether there is a 48-byte schnorr or not 13:12:14 i agree, i like the double check 13:12:36 although i can imagine that is annoying for the wallet implementers 13:12:43 it's the way Janus base key method would use to identify change outs 13:12:54 since that must be spend key enabled 13:12:57 anyway 13:12:58 since the schnorr can be checked immediately, and the key image check is something that is delayed to when key images are available for view-only wallets 13:13:46 right, it seems like a question that has no perfect/ideal answer 13:14:25 hence, the risk of maintenance and logic costs 13:14:44 can you be explicit abotu what you mean about maintenance? 13:18:17 for example, let's say a spend wallet was implemented and used key images to identify change outs since that is most simple (or seems that way to the implementer), then they want to make it view-only capable and now have to make all new logic around identifying change outs 13:18:54 ok i see what you mean 13:19:11 or a new kind of subaddress account scheme appears, and old wallets have to add logic to harmonize with tx made with that new scheme 13:19:37 ooh new subaddress schemes, you're talking :) 13:19:47 now* you're talking :) 13:20:07 the wallet ecosystem is fairly simple right now, but if Monero adoption expands too much who knows what people will do with it 13:23:38 another point against Janus base method: multisig groups can't perform Janus tests on change outs until they have computed key images for spent outs, which may be problematic for subcoalitions who did not originally make the relevant tx, since they need to collaborate with an M-size group to construct key images 13:25:28 s/perform Janus tests on/identify 13:25:28 UkoeHB_ meant to say: another point against Janus base method: multisig groups can't identify change outs until they have computed key images for spent outs, which may be problematic for subcoalitions who did not originally make the relevant tx, since they need to collaborate with an M-size group to construct key images 13:29:37 ooh interesting point 14:52:36 knaccc: I updated intro part 2, and proposal part 2, would you mind taking a look? anything I should add/change? 14:59:23 In your new issue? 14:59:34 yes 15:03:01 Im on the fence about which solution is best. Janus base has limitation but is small and I invented so Im biased, +48 it bugs me the idea of loose ends we can't completely tie down, and +96 might be too big. 16:59:55 UkoeHB_ nice, thanks for writing it up 16:59:59 couple of quick things: 17:00:05 1. "Although, with the 48-byte Schnorr proof method there is a niche case where if both recipients are normal addresses then a 2-out tx with 1 tx pub key can work" <- it only works if the normal address recipient does not also use subaddresses, and the sender cannot know whether this is the case 17:01:49 2. Am I correct in saying that the janus base key would require 2 txpubkeys on a 2-out tx, meaning that for the vast majority of txs (which are 2-out with one change output) the storage comparison is +64 bytes for janus base key vs +48 bytes for schnorr, since the janus base key method requires that extra txpubkey? 17:04:29 3. that since the janus base key method requires a txpubkey per output on a 2-out tx, there are 2 variable base scalarmults for janus base key scanning s 1 variable base scalarmult required for schnorr48? so schnorr48 is twice as quick for scanning? 17:07:43 s/s 1/vs 1 17:07:43 knaccc meant to say: 3. that since the janus base key method requires a txpubkey per output on a 2-out tx, there are 2 variable base scalarmults for janus base key scanning vs 1 variable base scalarmult required for schnorr48? so schnorr48 is twice as quick for scanning? 17:14:06 1. two normal non-change addresses would work if you used two Schnorr proofs, one for each shared secret using the same tx pub key 17:14:06 2. with Janus base key you can also make the change out assumption, in which case only one tx pub key is necessary (constructed based on the non-change output's address) 17:14:06 3. yes if you don't make the change out assumption, Janus base key method would affect scan times 17:16:45 edited to clarify about the niche case a little 17:20:05 1. ah sorry, i only now understood the point you were making 17:21:42 and 2/3: ah, ok i get it, thanks 17:28:38 the reason i had view-wallet compatibility as a primary goal was that if i were designing a system, i'd use a view-wallet for notifying me of all incoming funds and for then notifying people of successful receipt 17:29:11 and so i wouldn't want to have to have a full-wallet to monitor incoming transactions in order to be janus-proof 17:30:31 that's a fair objective 18:15:21 not sure if this is insane or not: you can brute force random values of alpha until the first byte of the challenge is the same as the byte that you'd otherwise have to store separately in the tx :) 18:18:20 so a 1-byte saving per output, in exchange for an extra quarter second to generate the transaction :) 18:18:45 idk about the security implications 18:19:08 120-bit security vs 128-bit 18:19:17 why not just make the challenge hash smaller 18:20:01 hah excellent point 18:20:09 yeah it's a silly idea 18:20:16 going a little too far. 18:34:40 ok I think we could do it in 80 bytes lol, a 48 byte Schnorr proof for non-change output, then 32 bytes to encode the tx private key for the change output 18:59:13 actually it would have to be 32 bytes to encode the tx author's view key, since the details around how tx pub keys are currently constructed for 2-outs precludes the tx private key being useful for this purpose (ztm2 pg 40 footnote 16) 19:00:57 it also means the 96+ version wouldn't work, i.e. 1 tx pub key but 2 schnorr proofs 19:01:47 basically you'd encode the view key with the view key, so no information leak 19:17:37 oh I wonder.. maybe you'd only need to record 16 bytes of the view key, so 64 bytes; sarang what do you think? 19:20:50 Sorry, have not been following conversation lately due to other work 19:20:51 What's up 19:22:05 so, we want a way to identify an owned output is a change output, in the name of optimizing potential Janus solutions 19:22:22 roger 19:22:50 one possibility I just thought of, would be to add an encoded scalar in chain data, e.g. the private view key Diffie-Hellman encoded with a value produced by the private view key 19:23:41 could you Diffie-Hellman just the first 16 bytes without risk? 19:25:06 Can you write out a pseudoformula for exactly what you mean, for clarity? 19:25:18 on it 19:32:39 https://www.irccloud.com/pastebin/G9Xx3fMJ/ 19:33:04 H_16 is a hash function that outputs 16 bytes, which we would also use for the 48-byte Schnorr proof 19:34:43 we could alternatively key prefix with the one-time address of the change output if they were enforced to be unique like key images (they aren't currently as Isthmus pointed out) 19:35:06 that may be more compatible with how scanning works 19:35:14 OK, so the use of a truncated hash does decrease the collision resistance 19:37:15 However, I don't think that's a problem in this case 19:37:44 Since effectively an adversary would need second-preimage resistance on another private key 19:38:09 Ah, not even that 19:38:14 Standard preimage resistance 19:40:36 interesting idea. i'm still not really sure why setting the change index to -1 is so important to avoid 19:41:11 it just seems so simple to tell wallets to send change to subaddress -1 instead of subaddress 0 19:41:31 idk it bugs me somehow 19:41:47 anyway Ill present the different ideas and let people decide 19:42:53 using a designated change address doesn't bug me, just making it part of the basic consensus does 19:43:14 it can't be part of consensus 19:43:22 consensus can't detect if the correct change subaddress was used 19:43:57 well whatever the right word is, basic requirements for universal compatibility 19:44:31 even then, failure to send change to -1 only affects janus-protection of the wallet of the person that decides to use that non-standard wallet 19:46:14 * sarang returns to coding Triptych batching 19:46:25 hah 19:47:46 Here's a question related to batching for ya 19:48:02 Imagine you have a 2-input transaction, which is very common 19:48:31 Right now, you pick separate rings for each input and build a separate MLSAG (or CLSAG, same deal) signature on each 19:48:51 Triptych still requires a signature per input 19:49:03 But imagine that we've chosen to use 64-rings or something 19:49:21 and that you decide to use the _same_ ring for both signatures 19:49:31 Meaning both true spends are within that common ring 19:49:59 This lets you get all sorts of speedups in verification, but at the cost of changing the ring distribution somewhat 19:50:09 How good or bad is this, based on the ring size? 19:50:19 sounds perfectly fine to me 19:50:32 You can already use cross-ring correlations to try to identify spends 19:50:41 e.g. if both spends come from the same very old block 19:50:48 does it also save on having to create pseudo-outs when there are multiple inputs? 19:51:06 But it changes two separate 1-of-N signatures to effectively a 2-of-N 19:51:25 i don't see how the cross-ring correlation issue is any different whether you have 2 rings or one 19:51:26 knaccc: you still use pseudo-outs, just like you do with CLSAG 19:51:47 Arcturus (the modification to Triptych) lets you get rid of them 19:52:06 I also think the use of a common ring is not a problem in practice 19:52:20 I don't see any problems with it 19:52:30 And if binning were used, it becomes helpful 19:52:44 Since outputs from the same block/txn are likely to appear in the same bin 19:53:00 if you were going to use two inputs each with a seperate 32-ring, i'd say that's pretty much exactly equivalent to using one 65-ring with two outputs in that ring being spent 19:53:14 so you can use exactly the same distribution 19:53:43 just select the inputs based on what you'd do for two rings, but put those selections into a 64-ring 19:54:17 Note that Triptych works perfectly fine if you don't do this (except verification takes a hit) 19:54:32 You could do the same thing for MLSAG/CLSAG, but wouldn't see any verification benefit 19:54:43 verification time is the main thing we care about 19:55:11 The trick is that Triptych verification reduces to a single multiscalar multiplication, so any group element reuse lets you amortize it among anything in a batch 19:55:18 MLSAG/CLSAG don't have this property 19:55:54 Right now I'm coding such a modification to Triptych in order to get real numbers on it 19:56:07 This will provide better real-world data to augment the plots I showed at the last meeting 19:56:24 i assume the reason that CLSAG is being released is because Triptych is a long way away? 19:56:53 as opposed to just jumping straight to Tryiptych? 19:57:49 There are still research and engineering questions to be worked out for Triptych 19:57:55 CLSAG is effectively ready to go now 19:58:02 and provides a substantial size and time benefit 19:58:12 what is the assumed Triptych timeline? 19:58:19 the rough guestimate 19:58:39 I do not have one 19:58:49 ok fair enough 19:58:49 The math hasn't been peer-reviewed 19:58:59 The questions surrounding multisig engineering are still open 19:59:50 FWIW the preprint is now submitted for review, but that'll be a while 19:59:55 The deadline hasn't hit yet 20:00:03 Peer review is a very lengthy process 20:00:08 and it can't happen in parallel 20:00:17 makes sense 20:00:26 Anyway, just thought I'd toss out that ring question, since it's an interesting one 20:01:44 as far as heuristics/analysis go, you can already assume all ring members are part of the same ring, so actually doing it changes nothing 20:02:12 Yeah, I think my underlying question was really about how/if the distribution sampling changes, depending on how you do the selection 20:02:15 btw is surae doing ok? not seen him around here lately 20:02:46 Surae sait that he'd be only occasionally available in channels 20:02:51 s/sait/said 20:02:51 sarang meant to say: Surae said that he'd be only occasionally available in channels 20:03:01 so he can concentrate? 20:03:15 He's not currently under any community funding, but I know he's still been doing some research 20:03:23 (I don't want to speak for him, of course) 20:03:33 as long as he's healthy 20:03:57 how come he didn't put in further CCS funding requests? 20:04:13 He wanted to be able to devote time to personal and family matters 20:04:35 And I'm sure the general upheaval caused by the health pandemic did not help 20:04:46 ouch, i hope he's ok 20:05:25 If you like, I can reach out via separate channels and see if he has anything he'd like me to pass on to this channel 20:06:44 it'd be nice to know he's ok 20:06:50 updated with the change_tag idea; I initially thought the proposal was going to be good-to-go from the getgo, but here we are lol 20:07:14 Such is research 20:07:34 the secret is to propose things so complicated that no one can bikeshed it :) 20:07:44 https://en.wikipedia.org/wiki/Hofstadter%27s_law 20:07:45 [WIKIPEDIA] Hofstadter's law | "Hofstadter's law is a self-referential adage, coined by Douglas Hofstadter in his book Gödel, Escher, Bach: An Eternal Golden Braid (1979) to describe the widely experienced difficulty of accurately estimating the time it will take to complete tasks of substantial complexity:Hofstadter's Law: It always..." 20:12:49 I think there is a long road ahead before the issue gets resolved.. 20:15:04 for the record, my vote is currently on the 48-byte Schnorr + 16-byte change_tag Janus mitigation; based on the limitations of the Janus base key method, sadly I must admit it looks like it will die 20:15:30 Maybe the fact that projects like Bulletproofs have basically no downsides makes it more challenging to accept that other aspects of the protocol's design absolutely do 20:19:29 would there be a reason not to go down to 8 bytes for the change_tag? it's a 2e19 domain space 20:21:02 Well, let's consider the conditions under which an adversary beats it 20:22:37 when a change_tag is included that passes validation, but in fact the user did not make the tx and the tx author did not know the private view key 20:23:39 And this occurs provided the adversary produces `y` such that `H(private_key,other_data) = y` 20:23:59 where the adversary does not know `private_key` 20:24:19 hah yeah they'd have to flood the network with transactions like crazy to get lucky 20:24:41 right, so if H() is uniform then they must guess 20:25:25 These are effectively similar conditions to how amounts are encoded 20:25:42 but with a different risk model 20:28:03 what do you think knaccc? tastier and tastier 20:28:21 what do i think about the change tag? 20:28:32 8 bytes! 20:28:55 i can't see why it could possibly be worth any bytes when it's so easy to set the subaddress to -1 instead of 0 20:29:14 perhaps you'll find a way of explaining your reluctance about that that i'll eventually understand :) 20:29:28 let me sleep on it lol 20:46:00 here is another consideration: if you wanted to dice up an output (take a large amount output and split it up into 10 smaller outputs, so that outgoing txs aren't waiting on one another to fully confirm), then you'd have to have a change tag for every single output in a transaction 20:48:04 so the cost is now an extra 8*num_outputs per tx, rather than just 8 bytes per tx 20:48:21 for tx with >2 outs there would be one tx pub key per output, and a separate 48-byte Schnorr for each; the change tag vs change subaddress is only relevant for 2-outs 20:48:44 oh right, good point 20:48:59 ok so then it's 2*8=16 bytes extra for a 2-out tx 20:49:20 wait 2*8? how? 20:50:15 actually never mind. i was thinking that if you were simply splitting an output into two, with both outputs essentially being change outputs back to yourself, then you'd need a change tag for each 20:50:46 but i just realised that as long as you saw that one of the two outputs had a valid change tag, you can assume the tx was created by you, so you could also trust the other of the 2 change outputs 20:51:09 yeah that would work 20:51:26 although the logic would be: first check the Schnorr proof, then if it fails check the change_tag 20:52:24 oh lol good point, you could decide to always use a schnorr proof to apply to one ouf the 2 outputs, and a change_tag to apply to the other of the two :) 20:52:44 right, that's how tx are made now anyway afaik 20:52:50 yeah 21:58:18 another insane idea: if the private keys or all txpubkeys in a tx are determinstically created from a single source of randomness r, and if r was created deterministically as a hash of (private view key || lexicographically sorted key images declared in the transaction), then you could know when you were the one that created the transaction 21:59:07 so now you can trust the change output if your recreation of the deterministic txpubkey matches 21:59:47 s/or all/of all 21:59:48 knaccc meant to say: another insane idea: if the private keys of all txpubkeys in a tx are determinstically created from a single source of randomness r, and if r was created deterministically as a hash of (private view key || lexicographically sorted key images declared in the transaction), then you could know when you were the one that created the transaction 22:02:21 the problem is tx pub keys are made weird sometimes with change outputs 22:02:31 so knowing the tx private key isnt enough 22:04:01 good point 22:04:26 but then that means you can't do the test on your change output txpubkey, but you can do the test on the other txpubkeys 22:04:29 and that's enough 22:04:40 that works in all situations 22:05:29 as long as a single txpubkey can be shown to have been created with knowledge of the private view key, that proves you sent the tx 22:05:47 oh wait i'm talking all sorts of nonsense 22:06:33 yeah this doesn't work if the non-change outputs are destined for subaddresses 22:06:57 because you'd need to know the destinations of those outputs, and that's not possible to know when receiving change 22:09:17 yup 22:10:14 oooh no it actually does work i think 22:10:30 so in a 2-out tx, the txpubkey R=sD 22:10:38 change is Q = Hs(x*R)*G + Y 22:11:12 so if x = Hs("change" || private view key || maybe key images here too) 22:11:24 then you can check the change was created with knowledge of the private view key 22:12:15 oh no i'm talking nonsense again 22:12:29 x is the private view key in that algebra 22:12:35 nvm :) 22:37:58 ok more insanity: 22:39:02 change output is Q = Hs("change_output" || private view key || R)*G + Y 22:40:42 and that means you can use the new view tag to check whether to attempt to then multiply with G to check the output 22:41:38 so the shared secret for change outputs is Hs("change_output" || private view key || txpubkey) instead of Hs(private view key * txpubkey) 22:42:42 and that change output is ultra fast to calculate since there is no variable base scalarmult 22:43:42 it does mean that when the view tag matches, you're now doing two scalarmultbases (one for the regular shared secret and one for the change output shared secret) to detect an incoming output 22:44:09 but thanks to the view tag, that's only in a small number of cases 22:45:44 hmmm 22:46:47 seems reasonable 22:46:59 and obviously you'd probably want to concatenate in the output index too 22:49:24 I like it! will update the issue again 22:50:12 it would also let us deprecate a bunch of complex logic in construct_tx_with_tx_key() and its friends 22:50:12 lolll i'm surprised this isn't making your eyes bleed, or that it isn't causing mooo to chime in with threats of physical violence :) 22:50:56 what logic are you talking about deprecating? 22:52:38 https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf pg40 footnote 16 22:54:29 although.. that kind of fundamental change would probably affect LOTS of code 22:54:54 yeah that's why i was surprised you didn't immediately hate it :) 22:55:13 i guess it depends on how the code is written 22:55:14 it had to percolate a bit 22:59:23 adding an extra entry to the subaddress table for -1 and then using that subaddress change sounds 2 orders of magnitude easier than messing with the shared secret derivation 22:59:55 s/subaddress change/subaddress for change 22:59:55 knaccc meant to say: adding an extra entry to the subaddress table for -1 and then using that subaddress for change sounds 2 orders of magnitude easier than messing with the shared secret derivation