00:02:42 hmmm 00:02:45 test 00:02:46 s/test/monerobux meant to say s/test/monerobux meant to say s/test/monerobux meant to say 00:02:46 Isthmus meant to say: monerobux meant to say s 00:02:54 s/s/s/test/monerobux meant to say test/monerobux meant to say test/monerobux meant to say 00:02:57 test 00:02:58 s/s/s/test/monerobux meant to say test/monerobux meant to say test/monerobux meant to say 00:03:50 @UkoeHB_ your github issue is a 3 course meal 00:03:57 Haven't finished it yet, but so far so good 02:06:00 is there anything a bunch of GPUs would be useful for regarding monero development? 02:07:14 seems unlikely. GPUs are optimized for 16bit floating point math 02:07:31 using them for anything else is pretty weak 02:07:55 well i didn't know if there's some math or stats or AI or something 02:08:17 AI accelerators on the market now are accelerating 8bit math 02:08:45 I guess a GPU can do that stuff, but precision is wasted 02:09:02 yeah, but free infrastructure. except for me swearing at them. 12:18:13 knaccc I think my main objection to change address for Janus mitigation is scope creep. It requires 'baking in' the change address designation, effectively increasing the number of types of basic addresses: normal addresses, subaddresses, and now change addresses (integrated addresses don't really count, since it's just appending the ID to other addresses). My feeling is 8 bytes per tx is not too much a 12:18:13 price to pay to prevent the design scope from increasing. The 48+8 Janus mitigation does not affect what kinds of choices an implementer can make, it's just an extra step during tx construction, and an extra step during scanning. 12:19:09 i'm not sure why you're classifying change addresses as a different kind of address. It's just a normal subaddress that you should never tell people about 12:19:50 i'm always concerned about bloat on the non-pruneable part of txs 12:19:59 and this 8 extra bytes would be non-pruneable 12:21:12 i haven't done the math recently, but i'd expect 8 bytes means an approx. 5% increase in the non-pruneable part of the tx 12:21:35 It's a new classification since it's not interchangeable with other subaddresses 12:21:47 what do you mean by "interchangeable" 12:22:23 You can't alter which subaddresses receive change for 2-out tx 12:24:04 right, i guess what this fundamentally comes down to is that you've got a gut feel that it could be worth preserving the ability to segregate funds between subaddresses inside the same account, and i'm of the opinion that we've already decided that there should be no segregation because each account has a shared balance and we've already decided the wallet will spend funds out of any available 12:24:06 subaddress 12:24:34 And it puts a burden on implementers to segregate change subaddresses from normal subaddresses, disallowing them from normal use 12:25:52 my response to that is as follows: 12:26:00 let's say you have an account 12:26:25 it's already the case that when you send funds, you don't choose which outputs from which subaddresses will be spent 12:26:36 and the funds could be spent out of multiple subaddresses within that account 12:26:38 which means: 12:27:32 1. the user is already expecting there to be no segregation within accounts 12:28:09 2. there is no natural consistent place to put the change. if funds were spent out of subaddresses 3 and 4, does the change go in subaddress 3? or 4? or 0? 12:28:22 so i'm saying we can bring consistency to this 12:28:27 change always goes into -1 12:28:47 i'm not sure how that could be considered a burden. it's a really simple rule 12:29:06 Ah, but to be clear: the account model is not 'baked in'. You'd more or less be canonizing the account model while creating a new classification of address. 12:30:14 i'll take a second to dwell on what you just said, so i'm fully absorbing its significance 12:30:56 So you'd be moving from 'can do what you want' to 'this is how it must be'. Hence a burden on implementers to constrain how they may use subaddresses 12:32:23 how strictly does monero follow RFC 8032 for things like point addition or private key generation. 12:32:31 I mean this: https://tools.ietf.org/html/rfc8032#page-11 12:32:50 maybefbi monero uses the exact same ed25519 stuff every other ed25519 lib does 12:33:21 It would be changing the design environment for implementers in the name of 8 bytes per tx 12:33:56 knaccc: which language has the best ed25519 library in my opinion for implementing things like blsag or other things mentioned in monero-zero-to-hero PDF? 12:34:02 *in your opinion 12:34:22 UkoeHB_ it's gonna take me a while to ponder what you said fully.it does occur to me that for the first time in monero's history, the inclusion of a schnorr48 would be an acknowledgement that subaddresses exist at all, at the consensus/tx format level 12:36:02 maybefbi if you're just playing with math, python maybe easiest. if you're building an app, choose whatever language the rest of your app is best coded in 12:36:19 The same could be said for how one-time addresses are constructed. Technically they don't need a tx pub key, but by moving the tx pub key to tx_supplement we are canonizing how addresses are constructed. Why do it? Since tx pub keys are non-optional. Likewise, being subaddress compatible is non-optional 12:36:31 knaccc: i tried to use golang's ed25519 to follow along monero-zero-to-hero but it doesnt have the right primitives. it uses things like extended homogeneous coordinates with cached coordinates and projected coordinates etc 12:37:21 You could try Rust and the dalek library 12:37:34 let me try dalek. THanks UkoeHB_ 12:37:36 maybefbi javascript might be the easiest way to get started. take a look at https://github.com/knaccc/subaddress-js 12:38:06 i tried https://pkg.go.dev/golang.org/x/crypto⊙v0/ed25519/internal/edwards25519?tab=doc but it is too opiniated and just for doing sign-verify as per RFC8032 12:38:25 it can add field elements, but not group elements 12:38:52 maybefbi yeah some ed25519 libs only implement signing stuff and don't give you eveything you need. javascript 'elliptic' gives you everything you need 12:39:01 oh 12:39:01 take a look at https://github.com/knaccc/subaddress-js/blob/master/index.js 12:39:05 You could also try making your own primitives implementation based on the modular arithmetic, idk how much work that would be tho 12:39:25 i dont want to make a mistake. just want to understand the math high level 12:40:22 iirc sarang has a python library as well for crypto. Not at the computer atm 12:40:28 So a few options :) 12:40:58 sarang is sarangs' github username? 12:41:08 @SarangNoether 12:41:25 ah ok 12:41:26 thanks 12:41:30 will follow that lead too 12:43:59 Good luck and lmk if you have any questions/ find any errors :p 12:44:11 thanks a lot. 12:51:26 UkoeHB_ let's say that some wallet software wanted to go down a different path to our current account/subaddress model. So, instead of having no segregation between outputs between subaddresses within an account, they wanted to have each subaddress effectively behave as a separate wallet. So each subaddress would be segregated, and an outgoing tx must use outputs only out of a single subaddress, 12:51:28 and change must be returned to that subaddress. If we did have the extra 8 bytes, it would be straightforward, and they would be janus-protected. If we didn't have the extra 8 bytes, they'd have to segregate such that each segregated unit had two subaddresses: one for incoming funds, and one for change. And the change subaddress would not be shared, and they'd present things to the user as if 12:51:30 there was only one address, even though technically change was going to a different incoming address. Or to put it another way, effectively they'd be creating an account for each user in their wallet, and would not have to reinvent anything. I'm struggling, in practical terms, to think of any kind of real world examples where leaving out the extra 8 bytes will tie the wallet software's hands. 12:51:32 Perhaps you can think of some examples that I've not noticed yet 12:53:24 to put the question more simply: can you think of any situations where the account/subaddress model could not be applicable? 12:58:18 as another thought, i think there might be a fundamental difference in each of our sensitivites about whether an extra non-pruneable 8 bytes on a 2-out tx is a significant burden on tx size or not. I'm of the opinion that those bytes are very precious, and that we should not add extra bytes unless we absolutely have to. we should get others to weigh in on that narrow point 13:00:30 for example, in a marketplace where subaddress index corresponds 1:1 with product ID/payment order 13:01:04 that is probably true 13:01:20 can you flesh out what the obstable would be, i'm not sure i understand the example 13:01:27 osbtacle* 13:01:35 lol obstacle 13:07:09 well anyone generating subaddresses for a vendor would have to: A) work around the change addresses while assigning subaddresses to new product/order IDs (possibly even skipping IDs, which could be confusing to users), and B) to spend money received to those subaddresses figure out how to properly direct change. I'd even expect some implementers to not understand the Janus mitigation, and end up 13:07:09 distributing change addresses publicly (perhaps not a threat to this example, but more generally implementers would be required to _understand_ the Janus mitigation on some level). 13:08:07 Are we at least agreed on: "You'd more or less be canonizing the account model while creating a new classification of address.", "It would be changing the design environment for implementers", and "implementers would be required to _understand_ the Janus mitigation on some level"? 13:09:19 i still don't quite understand your scenario 13:09:24 "anyone generating subaddresses for a vendor" 13:09:27 what does that mean 13:10:14 are you talking about someone providing wallets to vendors, so vendors don't have to have their own wallets? 13:10:36 and in that scenario, wouldn't they assign an account per vendor, and then allow the vendor to have one or multiple subaddresses? 13:10:45 i'm not sure why the account/subaddress model would not be suitable 13:12:21 I mean someone making a wallet useable by vendors 13:12:51 or integrated with some kind of marketplace for vendor useage 13:12:53 ok, so what would be a reason that that wallet software could not use the account/subaddress model 13:13:41 Rather than any thinking about specific reasons, Im trying to point out that the implementation framework is changing 13:14:05 I don't have an objection to the account model, but _Im not an implementer_ 13:14:14 so my opinion on it doesn't really matter 13:14:36 i'm effectively saying that the account/subaddress model is so universally applicable, that there is no harm in tying ourselves to it 13:15:45 and that no one should ever feel the need to reinvent the wheel there 13:16:43 and so i see an extra 8 bytes as an insurance policy for the account/subaddress model turning out not to be universally applicable 13:17:11 ok, so long as we are agreed on the core question, then it will be clear for others what they need to evaluate 13:17:49 i do sympathize with the abstract principle you're putting forth 13:18:19 i'm predisposed to a much more concrete rather than abstract way of evaluating things i guess 13:19:20 and i also take into consideration that if the 8 byte insurance policy needs to be invoked, it can be invoked either by having it in place now, or by simply introducing it in the future 13:19:51 and a future introduction could be done without consensus changes, since it could just be added to txextra if wallets ever decide that it was a mistake to not include it 13:20:48 also on a related topic, apparently the average output count is 2.2, and that extra 0.2 refers to tx with >2 outputs; 0.2*48 = 9.6 bytes (additional Schnorr signatures per output), and 0.2*32 = 6.4 bytes (additional tx pub keys per output assuming no additional tx pub keys currently, let's assume for argument it's around 1/2 so 3.2 bytes average increase from mandating 1tx pub key per output for >2 outs) 13:21:28 so about 13 bytes average increase above the 2-out consideration 13:21:54 interesting 13:33:56 If I may dumb things down with an analogy, imagine that Monero is a software for letting an author write books. It allows the author to have a hierarchy of books, chapters, and pages, and that's it. Some authors come along and say "hey, I can't write a book without sub-chapters; how hard can it be to add? please add this feature." Monero says "no, believe it or not, the extensibility isn't worth the 13:33:56 technical debt and loss of the current clarity/simplicity, in our opinion." Well, that's the actual story of the open source BookStack web app, and book/chapter/page is mostly analogous to our wallet/account/subaddress. And that opinion is what it appears you're trying to converge on. Hopefully this parallel triggered a light bulb for someone 13:35:41 Hm if I understand it right, the question is whether to mandate sub-chapters or not. 13:35:49 Maybe not a perfect analogy 13:37:03 i do get the gist. it's the perpetual question of whether we need to offer future flexibility, and flexibility generally often comes with a cost 13:37:14 not mandate. allow. the point is they have a rigid structure. i say "they" but it's a single maintainer, so much easier to reach "consensus." 13:41:37 here is another way to go about things: instead of saying "do we really need those 8 bytes", maybe we should be asking whether we need to add not only those 8 bytes but more 13:42:01 is 16 bytes the limit for reducing the challenge hash? e.g. could we go down to 8 bytes for the Schnorr? sarang ? 13:42:01 so the 8 bytes are there to prove that we were the ones that sent the transaction that is returning change to us 13:42:27 maybe we should take this opportunity to not only prove we sent the tx, but also to indicate to ourselves which outputs were spent 13:42:40 and thus solve the "view-only balance is wrong" issue 13:43:03 (although not solving the "funds were stolen but the view-ony wallet couldn't tell" issue 13:43:45 UkoeHB_ i'm fairly sure we need to stick to 128 bits for the hash 13:44:06 because that can be brute forced without spamming txs 13:44:29 you'd just need an extra 1 byte to encode the index 13:45:34 maybe we need 1 byte per input spent in a tx, to indicate the spent output, and encrypt that with the private view key 13:46:02 the only objection is that people might rely on the view-only wallet to know if their funds have been stolen 13:46:15 but i think it's worth the byte to make view-only wallets more useful 13:52:13 hm it seems like to brute force 8-byte challenge you'd have to test on the order of 1e17-1e18 scalar-mult-keys (or scalar-mult-base), since all you could do is figure out all the possible tx private keys and then test them against a selected base for the listed tx pub key; it wouldn't be enough to find a collision for the hash 13:52:51 i guess if there are 17 real inputs being spent, we could encode more compactly. we look at the number of inputs, go to the next power of 2 and decide how many bits required to encode the real index of each input in the ring, and use only as many bits as required per ring. then pad to the next byte boundary 13:53:45 yeah the scalarmult does mean the hash could be less than 128 bits i guess 13:54:05 i wonder how many bits that scalarmult buys us 13:57:26 i think it allows us to maybe reduce it at most from 128 bits to 110 bits, so only 16 bytes to 14 bytes roughly 13:57:49 based on? 13:57:50 based on a 0.25ms scalarmult compute time 13:57:58 and a 2ghz processor with one core 13:58:14 these are very rough and wildly inaccurate approximations 13:58:21 i just assume one instruction per cycle 13:59:04 so log_2 of (.25e-3)*2e9 is 18.9 bits 13:59:23 that's with the assumption though that one hash is one cycle, and that's not true 14:05:41 I think we could reduce the change tag to 6 bytes, which is 2.8e14 domain space (280 trillion) 14:06:39 even with 1mill outputs the chance is 1 in 280million to guess 14:08:31 what would be the objection to simply adding the change tag to the txextra if some future wallet implementation has some unforeseen reason to need it? 14:09:20 if could put it in some future encrypted memo space that might be introduced into the future, to not affect tx uniformity 14:09:28 that wallet would be implementing it selfishly, and it would become difficult to get other wallets to update 14:09:46 but i don't think that's possible 14:10:05 because the change tag is only useful when a wallet sends funds outbound 14:10:35 it doesn't matter if there is only one running instance of that alternative wallet in the world 14:10:47 it doesn't need any other wallets to use the change tag 14:11:03 it's only useful for the wallet to put on its own txs if it finds it useful 14:12:36 so the only argument against making the change tag optional is tx uniformity 14:14:37 well other wallets would now have to start adding the tag to be compatible with the unorthodox wallet, which may cause some drama/etc 14:14:53 not adding, reading the tag 14:15:26 and that other wallet would have a harder time reading orthodox wallets if they are using the change address for some other purpose 14:16:36 "well other wallets would now have to start adding the tag to be compatible with the unorthodox wallet" < that's not true 14:17:05 I meant reading 14:17:23 we already know how to put extra txextra tags that wallets ignore 14:17:31 you just ignore unknown txextra tags 14:19:16 right, but if someone transferred their keys to another wallet it wouldn't be able to read the change tags (unless updated) 14:20:48 but if someone was using a wallet that threw away the account/subaddress model, they wouldn't expect things to make sense when restoring with a standard wallet 14:23:09 well it would certainly make even less sense 14:23:24 i guess i'll take back some of my last sentence 14:23:41 i can see your point that it would make more sense if change tags were universally adopted 14:26:13 yeah i think then we're back to "i can't imagine a scenario where accounts/subaddresses aren't universally applicable, and if we do realize a shortcoming, we can always introduce change tags when we understand how they can be useful" 14:27:01 so the point of the insurance would be if we don't think the tx format will be evolving such that we can easily add change tags in later 14:27:48 if we assume that things like triptych or other future changes are inevitable, then adding change tags when we understand a real world application for them sounds very easy 14:28:33 there may be some centralization objections there, i.e. relying on the core team to permit/enable innovations 14:28:59 yes 14:29:16 although not in this case, i'd argue 14:29:31 because all of this could be implemented in txextra instead 14:29:56 and the marketplace could decide whether they wanted to use wallets with view tags and change tags and schnorr48s etc 14:30:23 there is a broader point here, that you've identified 14:31:20 which is, if a wallet e.g. doesn't support addresses that start with a 4 or an 8, can that really be called "monero"? 14:31:29 there is no reason that wallets need to use base58 addresses 14:31:37 they could use base64 14:32:17 i think the reality is that we're going to have to always look for consensus on what "monero compatible" really means 14:32:39 and that'll bleed into all sorts of things that aren't anything to do with the tx format or consensus protocol 15:57:14 just for completeness: the proposal is currently that, given m=Hs(a || account index || subddress index), change is sent to subaddress index -1. As an alternative, if we deemed it valuable to preserve subaddress balance segregation within accounts, we could make it so that for every subaddress m there is a change address m_change=Hs("change" || a || account index || subddress index). 15:58:28 and wallets would simply consider change to be part of the corresponding subaddress balance 18:35:52 updated proposal part 2, hopefully it captures all the salient points 19:53:40 UkoeHB_ thanks for all the hard work in writing this stuff up. couple of quick things: 19:53:45 "Implementation complexity will rise as implementers will be required to comprehend the Janus attack on some level" 19:54:08 It'd be useful i think to make clear that you're talking about people writing their own Monero wallets, rather than implementers in the sense of people using a monero wallet 20:00:26 and secondly, "Note: @knaccc argues change addresses could be used initially, then we could switch to change tags if they seem more reliable/better." -> i do agree with what you noted about " I am concerned about technical debt from change tags" 20:01:29 so if it came across that way, i withdraw the argument that it is a simple win-win where you can not have change tags now, and introduce them in the future 20:05:45 so really my argument is that we've already gone down the path of introducing the concept that users should not expect there to be output segregation between subaddresses belonging to the same account, and have told users that having multiple accounts within a wallet is the correct way to segregate balances. therefore i see the no-change-tag-required option as a natural followon from that 20:05:47 approach, and we can add change tags later if we later discover that it provides any compelling additional flexibility 20:07:11 and of course i welcome anyone to suggest compelling possibilities that I have not currently have had the imagination to consider 20:17:13 you're totally right that people writing wallets will need to know what a janus attack is 20:17:38 but then, if they're writing a monero wallet, and they don't know what a janus attack is, then they're also ignoring the schorr48 20:17:52 and they'll also ignore the change tag 21:04:56 if i had misinterpreted you and you really did mean implementers in the sense of people using the monero wallet, then i'd advocate for dropping the ability of users to direct change to particular subaddresses 21:05:07 (although allow direction of change to different accounts) 21:07:33 There is a possibility of wanting to segregate within accounts even further. I also have a vague idea there could be utility to controlling which specific address gets change outputs, e.g. some kind of key management scheme where a bunch of outputs must go to the same exact address. Just spitballing, since imo the current system isn't constrained enough for adding change outputs to be a neutral change 21:08:49 Well there may be people forking the core wallet to implement their own address related schemes 21:09:47 And a new implementation would have to take into account 48-byte and change tag since they are stuck in the tx structure 21:10:10 Possible that Janus could be mitigated through tx uniformity. Make all txes the same size (set at some reasonable limit), and could include in that tx proofs/tags/whatever or dummy padding for smaller txes 21:10:27 So it basically forces all possible implementers to deal with it 21:10:32 By having change tag 21:11:58 thinking along the lines of how mixnets defeat traffic analysis attacks with uniform packet length/format 21:12:02 derbleak: I think that would entail way bigger tx, like 20x bigger 21:12:18 yes, it would be *very* space inefficient 21:12:41 but a huge gain in privacy, iiuc or it actually works 21:12:43 And here knaccc and I are squabbling over 6 bytes :p 21:12:52 may be not worth the tradeoff 21:12:54 right 21:12:57 :) 21:13:23 but the concept may apply in the future, or when space per tx is not a huge concern 21:13:49 currently agree, the chain would bloat to becoming unusable atm 21:15:21 I suppose if unexpectedly petabyte thumb drives become commonplace then we could go wild with memory consumption 21:16:10 * derbleak pulls out their exabyte thumb drive 21:16:16 :p 21:17:22 could potentially archive the uniform tx separately, with a witness chain similar to segwit, but then we are talking *huge* architectural changes 21:18:18 anyway, tangent over, just wanted to put it out there 21:21:59 btw despite the implementation pain, there is a certain sense of correctness to the idea that shared secrets with strangers should happen using asymmetric means, and shared secrets with yourself should be achieved via symmetric means 21:22:09 and that therefore you shouldn't be diffie helmanning with yourself 21:22:13 for the change outputs 21:25:41 i agree though that simplicity trumps the notion i just described 21:32:34 knaccc: so smth like a HKDF for self-secrets, DH for shared w/ others? 21:34:27 derbleak yeah, so specifically in this case, an output is Hs(rA||i)G+B when sending to others, but Hs(private view key || txpubkey || i) for change to yourself 21:35:16 Hs(rA||i)G+B vs Hs(a||R||i) 21:35:44 Hs(rA||i)G+B vs Hs(a||R||i)G+B 21:41:38 or even skip the mult with G and make an output A'+R+iG+B for change outputs, where A' is a secret known only to the person with the private view key, calculated as A'=Hs("my secret ec point"||a)G 21:44:42 actually that doesn't work unless you remember your choice of random r 21:47:36 heh we really need to get lots of people to weigh in with opinions and considerations we may have missed, or we're gonna go crazy :) 21:48:03 i think we'll probably come to a consensus pretty quickly once the discussion is opened up 21:48:59 will definitely keep thinking about Janus, and re-read the discussion up until now 21:49:29 hopefully nothing too moronic flows through my keyboard :p 21:52:05 my mind can be changed on this incredibly rapidly through some potential use cases that would be hindered by -1 subaddresses 21:52:58 -1 mod p, or negative index? 21:53:04 * derbleak new to the discussion 21:55:19 as in the subaddress 0003FFFF for the -1 subaddress in the fourth account in a wallet 21:55:53 oops i meant 00000003FFFFFFFF 21:56:49 ah, so -1 in the normal sense :) 21:57:17 yeah, and actually i really meant 03000000FFFFFFFF since it's supposed to be two little endian uint32s 21:57:20 why not just invalidate xxxxxxxxFFFFFFFF? 21:57:41 i don't understand 21:57:47 to achieve what? 21:58:07 o, thought that was causing the Janus issue, or contributed to it 21:58:12 no 21:58:18 then nvm 22:40:01 option 4 for mitigation sounds the most compatible (tags + schnorr-48) 22:40:31 agree w/ knaccc about not including integrated address stuff in any new tx schemes