00:00:03 how expensive would it be to check that all pub keys in extra field are actually pub keys and not random data? 00:04:42 Easy if we change them to be 1/8th of their actual value. 00:24:31 UkoeHB_: the seed has to be unique per signature 00:24:42 But that's doable 00:26:21 If the keys are uniformly distributed from random secret keys, it is not possible 00:26:41 Or are you asking about subgroup testing 00:26:53 based on how complex the code is it amazes me how fast creating a transaction is, barely 1 seconds 00:27:03 There's a probabilistic way to do batch testing for subgroup membership 00:27:11 But it's statistical 00:29:19 well group elements have a limited range, so if there is a pub key outside that range then someone must have made a random value, which is useful info to analyst 00:29:29 idk if it's worth the expense to test 00:32:43 Any key that decodes to a curve point in the G subgroup is equally likely to be random as to be a key generated correctly 00:33:23 Any key that does not belong to the subgroup was not generated correctly 06:42:20 I mean a random 32 byte scalar, rather than random point. Unlikely and probably not worth code up 07:26:33 figured something cool out, please take a look! response to sgp_ here https://github.com/monero-project/research-lab/issues/58 13:03:57 UkoeHB_: that went well above my head haha 18:25:54 I responded to UkoeHB_ on github. You can _usuall_ infer the real spend with just the viewkey, the major exception being when someone uses your output in their ring to send you XMR 18:27:05 the probability is somewhat low, but could happen. So you can give some reasonable account balance estimate right now, without any changes to the chain protocol 18:30:49 Btw viewspent wouldn't be part of the protocol, as everything related to the extra field is unverified. It would require non-trivial code changes though, I think 18:31:30 it is part of a protocol - the wallet has to do something different 18:31:31 And that's a good point vtnerd 18:31:58 not part of consensus protocol, yes. just something extra for the wallet todo 18:32:01 By protocol I mean the minimum rules to get a transaction admitted to the block chain 18:33:12 is there a specific use case for this? 18:33:59 I think it could be interesting to try the technique I proposed, to see accuracy of it, etc. At the least its a stop-gap if someone wanted that behavior sooner without changing wallet2 and derivatives 18:34:35 I imagine the current view only wallet, or even the 'highly probable' version you just mentioned, would be adequate in a high stakes corporate environment 18:34:52 While view wallets are required for those environments for fund security 18:35:10 inadequate* 18:35:27 yeah, an exchange would want accuracy 18:36:45 I was thinking about light-wallet frontends. they currently require the spend-key to determine account balance. You should be able to do a view-key only frontend that does a "good enough" job for an individual to monitor the wallet from phone 18:36:51 then spend only on some other device 18:37:24 Since monero adoption is still fairly nascent, a probabilistic view wallet would not have many drawbacks, and would improve the situation greatly. I wonder though if it would hamper long term adoption. It has a psychological effect too, since lack of certainty often weighs disproportionately on people's minds. 18:38:24 Are you suggesting a "you might have that much monero, or not" mode ? 18:38:39 Sorry if I've got the wrong end of it, it just sounds htat way :D 18:38:52 me or UkoeHB_ ? 18:39:04 Good question. 18:39:06 'You probably have that much monero' mode 18:39:23 UkoeHB_ wanted a mode that determined the true account balance without the spend-secret-key 18:39:52 the initial proposal required changes to how a wallet sends txes for it to work 18:39:54 Ah, OK. Sounds good then, ignore me. 18:40:19 I pointed out, that you get a _really_ close balance without any changes 18:40:31 Yeah IIRC I had a patch for that but it was rejected because it required "honesty" from the wallet owner wrt the auditors. 18:40:33 with the unfortunate caveat. 18:40:51 By relying on getting change back ? 18:41:13 yup. its usually the giveaway to the real spend 18:41:16 (ie, sweep_all gets hidden) 18:41:28 moneromooo: I may have solved that with a new type of proof, that a key image does NOT correspond with an owned output. Very nice for audits :) 18:41:47 Research Issue #58 18:42:07 I think the uncertainty kills it. People will rely on it and complain when it's wrong. 18:42:53 And if it's uncertain, it's pointless, isn't it. The main use people want is to ensure they can see when their money is stolen. 18:43:03 Which relying on change does not help. 18:43:36 Says a lot about crypto btw, if the main use is "seeing when my money gets stolen"... 18:44:34 hmm. yeah, if any of this dependent on sender behavior, then they "hide the steal". I love that phrase lol 18:44:45 viewspent may also not work for verifying stolen funds, since a thief may edit out the curve point 18:46:07 although, if you are watching someone steal your XMR, its already too late lol 18:46:11 KoH wa 18:46:22 Typo. Only way to know for sure is with the key image 18:48:26 this is unfortunate, because the ability to view an account balance with just the viewkey on a phone to a light-wallet-server is kind of nice. But the false impression under adversarial cases ... :/ 18:50:06 or maybe if the UI said (in fine print) : "*Account balance shown might not be real" like one of those drug ads 18:50:09 then we're covered 18:50:51 The basic problem is view keys are not part of the consensus protocol. An alternate wallet may use single-key one time addresses, and ignore the view/spend concepts 18:51:08 So no kind of solution that doesn't involve the consensus protocol will solve it 18:51:56 Fine print! Of course! Time to update the roadmap 18:54:57 The idea of a point-in-time "account snapshot" using key images and proofs-of-non-spend could be useful 18:55:16 Where the improvement is not leaking unspent information 18:59:24 I think the problems with current view-only are, in order of importance: a) unable to view entire balance, b) unable to cooperate with audit without leaking unspent info, c) unable to know when theft has occurred. (a) is partially solved by probabilistic view balance, and fully solved by viewspent keys. (b) is solved by proofs of unspent, assuming person being audited has spend key and auditor has view key. 18:59:24 (c) is unsolvable without consensus changes. 19:00:16 Although auditor knowledge of view key is still problematic, since they can keep that key forever 19:00:34 At least in the immediate audit they don't learn more than necessary 19:04:29 Don't see a way around auditor knowing view key, since they must be able to know all the owned outputs. 19:08:53 The traditional use case for audits has been presented as the "club treasurer" problem 19:09:25 Where Alice is the treasurer for her club, and wants to show the members the balance is as expected 19:10:43 So there's not much of a threat model, and a point-in-time balance test might be sufficient 19:11:09 Members can use the view key to see incoming funds, and can request that Alice provide a point-in-time proof as needed to check the balance 19:11:36 Makes sense 19:12:08 and it doesn't involve changes to transaction structure etc. 19:12:24 Alice runs the point-in-time tool, and the members verify it with their own tools 19:12:57 While more robust handling of balance would be nice, I think it'd be a marginal benefit (at best) for a big cost in terms of development and chain bloat 19:14:18 Anything optional and sender-only seems to be useful more as a view-only convenience, not an absolutely-to-be-trusted-under-all-use-cases application 19:14:32 and then you have to weigh the practical convenience against the development cost and bloat 19:17:48 Maybe a good discussion is to identify the use cases for transaction/wallet proofs and assertions that are "must haves" 19:18:12 And see how well the existing options handle those cases, or could be adjusted to do so 19:18:49 Right now we have InProofs and OutProofs and ReserveProofs and SpendProofs 19:19:08 InProofs and OutProofs are being updated but would retain their same functionality 19:19:30 i dunno about the whole thing. if we're really trying to be like cash, how does this concept fit in? 19:19:31 I think it'd useful, but it'd have to be always segregated from the balance, like "likely balance if no corner case happened, and exchange key images for certainty". 19:20:07 Let's set aside the sophisticated adversary for a moment. It seems like an improved view only wallet would be very beneficial to the ecosystem, and would go a long way toward making Monero user friendly. There are now two options on the table: probabilistic view that depends on change output heuristics, and viewspent keys that show an exact balance. I expect high volume wallets would not be able to rely on 19:20:07 the probabilistic view, while viewspent keys certainly lost the chain. Both entail development costs 19:20:07 Because if not, you'll get tons of people complaining monero's buggy, even if they had to click on a "I understand it might not be right" button. 19:20:25 i think the viewkey functionality was just a side effect of how the monero system works. they went "oh, the way we designed it allows us to do this" kind of thing 19:20:32 UkoeHB_: for what specific use cases? 19:20:47 I don't want to fall into the "surely it would be handy" trap 19:20:55 because we can't make good cost-benefit analysis from that 19:21:00 For anyone using a view only wallet 19:21:08 OK, for what use cases 19:21:09 but I don't fully understand the viewkey/spendkey. But from what I sorta understand, its not like monero could use a single viewspend key to do what it needs to do 19:21:48 if you show someone your wallet full of cash they can take it 19:22:02 You can have the view key derived from the public spend key (giving a truncted address). 19:22:16 View only wallets are helpful when your spend keys are not easily or safely accessible. 19:22:29 OK, what are the trust requirements? 19:22:40 Any solution that can be reasonably gamed needs to be only a convenience feature 19:23:21 and we'd need to specify interactive (like Alice providing a point-in-time proof set) or non-interactive (only needs the chain data) 19:24:45 Trust requirements? 19:25:49 You could imagine use cases where you intend any view functionality to be used by you for convenience, so you can trust yourself to not mess with your own transactions and screw it up 19:26:10 But there could be other cases where you don't trust the prover/keyholder to do this 19:27:15 gingeropolous: current view only just shows all the outputs you received, not if you spent any of them. viewspent shows which are spent directly (assuming honest person or unsophisticated thief spent them). Probabilistic view estimates balance based on outputs you receive from tx where a previous owned output is referenced (probably spent, and the one you received is the change). 19:28:34 Unsophisticated thief who manages to steal coins from a cold wallet ? :) 19:28:52 Or just a thief who doesn't care 19:29:08 what is the currency parallel here? not that existing things should restrict future things.... 19:29:36 I like the club treasurer model because it's an example of a partial trust. The club members don't trust Alice enough to let her simply have the wallet with no oversight, but they might trust her enough to provide monthly point-in-time proofs to assure that everything is ok 19:29:51 And that model has reasonable solutions 19:30:06 Financial analysts know a lot about company finances, but can't spend any of the money. And in fact the records may be fake or incomplete 19:30:31 yeah but thats not the money doing that. thats some institution 19:31:04 sarang I'll have to think about that carefully for a bit 19:32:15 gingeropolous: the blockchain is just a ledger, a cash metaphor breaks down under too much scrutiny 19:32:45 Including something that's optional and can be gamed by a dishonest party might work in the case where you trust yourself, but that probably incurs a big cost for the entire ecosystem and wouldn't address more stringent trust models anyway 19:33:05 yeah thats more true of a transparent ledger. monero's ledger is more a history of mathematical proof that everyones playing the same game 19:33:07 Off-chain stuff is point-in-time and interactive, but can be made hard to game and does not incur ecosystem-wide costs 19:33:25 If you don't need any of the point-in-time proof stuff, you don't ever need to care about it 19:34:40 I'm curious about wallets in open ledger coins (everything except monero). What is the prevalence of spend-authority wallets vs non-spend authority wallets/balance checkers? 19:35:00 you don't need wallets to do it. 19:35:07 Any explorer could do it 19:35:40 Oh, but you mean with multiple derived addresses 19:38:41 for the club treasurer model, it would be cool to do something where you can send someone an output that is effectively a fake transaction 19:38:56 maybe thats what you were talking about 19:39:07 ? 19:39:20 point-in-time proof set 19:39:30 I meant that when the members only have the view key, they don't have full insight into Alice's spending 19:39:44 but they can request/require point-in-time proofs to account for the balance 19:39:54 and presumably fire Alice if anything shady happened 19:40:28 like, i could imagine a new type of transaction, where it is formed in much the same way, except the output that is created isn't spendable, and it doesn't actually nullify the outputs it used as inputs 19:40:41 so the only way to create that new output thats worth 20 XMR is if you had the 20 XMR to create it 19:41:00 The MLSAG asserts that one of the input ring members was used as the signer 19:41:00 so you can send that tx to someone, and they can reasonobly conclude that indeed you have 20 XMR 19:41:12 You can always generate an "output to nowhere" 19:41:41 of course, one could spam the chain with these things 19:41:46 but they would cost the same tx fee 19:41:53 or an output addressed properly but with bad commitment data, for example 19:41:58 (this would not be spendable) 19:42:07 but at that point your wallet detects this and says no-good 19:42:16 well thats just wallet and consensus rules 19:42:24 Isn't everything? =p 19:42:36 indeed! Blue skies baby! 19:43:14 "Any explorer could do it" smh 19:43:22 ? 19:43:29 Look at an address balance? 19:43:39 smh = so many hamsters 19:43:54 yeah lol, the fungibility maximalist in me shakes his head 19:44:08 oh 19:44:17 I thought you weren't sure about that claim 19:45:11 would your position change for viewspent with Triptych, since the extra scalars are there? 19:45:45 I thought the key image format mechanism could allow for the same functionality, but it doesn't appear so 19:45:53 Triptych et al. use nonlinear key images 19:46:04 thats my favorite kind 19:46:19 You can still store up to 64 bytes of arbitrary data per input proof, to be clear 19:46:47 But the linking tag format for output private key `x` is `J := x*U`, where `U` is a globally-fixed group element 19:46:52 sigh 19:46:53 typo 19:47:00 `J := (1/x)*U` 19:47:36 FWIW Omniring can support the existing tag format 19:47:49 but it isn't clear to use that format with multisignatures 19:48:36 ah so next gen of protocol may not even support viewspent; does it still support current view capabilities? 19:48:58 The proof system doesn't care how you derived your output keys 19:49:07 Just like how MLSAG/CLSAG don't care 19:50:08 Everything's a commitment, and some things are commitments to zero :D 19:51:27 However, I was thinking about if/how the hiding could be safely done in CLSAG 19:51:43 where all round scalars are random except for the scalar at the signing index 19:52:17 So you could generate all but the signing scalar via PRNG, and hide the data in one of those 19:52:34 and have a rule about where it's hidden (e.g. the index after the signing index) 19:52:58 provided the scalars are still independent and uniformly distributed, adversaries can't detect which is hiding the data 19:53:22 and if you know which output is yours, you know where to look in the ring 20:00:03 makes sense 20:00:32 we could do that right now with MLSAG scalars 20:01:14 of course they are pruned which is problematic 20:09:39 I think we need to differentiate two main uses of the view key 20:10:04 One is the MyMonero wallet scanning type, where we want the LEAST info revealed to optimize efficiency 20:10:32 Another is the audit functionality, where presumably it would be great to have the same view as the spend key holder 20:13:01 to optimize efficiency <- if you mean scanning time, both viewspent and probabilistic would involve insignificant time compared to actually finding owned outputs in the first place (basic view key function) 20:17:14 UkoeHB_: I took an ever bigger step back into the reasons why you would want to hand over a view key in the first place 20:19:19 in the first case, I want as many barriers to preventing someone from figuring out which outputs are actually spent as possible 20:19:30 in the second case, I would want to be 100% sure it can't be gamed 20:37:02 I'm going to switch the conversation to something more timely 20:37:25 If the intent is to have CLSAG code reviewed, there needs to be a scope specified for this 20:37:28 ^ moneromooo etc. 20:39:22 what do you need help on when defining scope? 20:39:42 At a high level, we need to tell the auditor what to review 20:40:04 At one level, there's "we ripped out X and directly replaced it with Y", which is true for some functionality 20:40:35 Ideally this would assert that the CLSAG implementation is _at least_ as secure as the MLSAG functionality was (but that was never externally reviewed) 20:40:58 Or it could be extended out somewhat to other parts of the tx protocol, but then the "stopping point" becomes less well-defined 20:41:06 and eventually it's the whole damn codebase =p 20:41:35 Separately, the math is reviewed... and the CLSAG code is checked against that as well 20:41:57 I await news from suraeNoether on some further updates to the paper we've been working on to really ramp up the security model 20:42:09 (and none of which presently change the sign/verify algorithms) 20:43:22 If it's.... name escapes me.... they already reviewed MLSAG, so it's easy. Review the patch. And apparently Tim Ruffing (IIRC ?) was willing to review the made side (though not sure how this differs from what he did in the first place). 20:43:22 Right now there are 3 commits that relate to this, from older to newer: 20:43:42 ? 20:44:03 There was an audit group that reviewed a secp256k1-based implementation of MLSAG, is that what you mean? 20:44:13 AFAIK that was _not_ any review of the Monero implementation 20:44:14 Unlikely. 20:44:52 I'm talking about the people who went to review a load of things then came back to say "it was more htan we expceted, can we get some more money" ? 20:45:08 They were hired for bulletproofs but pulled all the other stuff in. 20:45:35 Not X41. 20:46:05 quarkslab 20:46:07 Quarkslib\ 20:46:24 I didn't realize they asked for more money 20:47:00 If it ends up being "review the patch", then that's a nicely defined scope 20:47:02 Maybe I'm confusing with another ? 20:47:54 they went beyond scope. that was them 20:48:14 I'll need to review their report, but I don't believe it extended to a complete review of MLSAG 20:48:40 I didn't think so either 20:48:58 Well, part of it anyway. Still, whether they did or not does not really change the point. 20:49:45 And we'd need to list obvious caveats: "yes, we know this isn't constant time" 20:49:54 "yes, we know this is not a prime-order curve" 20:50:42 Looks like total patch for the 3 relevant commits is ~1800 lines 20:50:57 Main functions to compare to the math are only ~200-300 20:52:09 what's the next realistic scope cutoff? best guess 20:53:24 One extension could be to the way commitment offsets are used to form the input rings to MLSAG/CLSAG 20:53:45 and the balance assertion via commitment sums 20:54:16 It's one of those "how much time and money ought to be spent" 20:54:41 Presumably, reviewing the 3-commit patch would assert that CLSAG is at least as solid an implementation as existed before 20:54:43 might tie in nicely with bulletproofs, since those take as inputs the commitments 20:54:57 Our initial bulletproofs deployment was heavily reviewed 20:55:17 (but note that it has been updated in the meantime) 20:57:06 What would 1-2 broader scope audits look like for the cost of 3 just on clsag? 20:57:23 (narrow clsag) 20:57:45 Right now I know of only audit group that indicated availability and interest: Teserakt 20:58:01 I'm sure there will be more when we ask, no? 20:58:06 OSTIF did 20:58:26 ostif asked kudelski, quarkslab, etc? 20:58:31 they all said no interest? 20:58:32 FWIW the complexity of MLSAG -> CLSAG is far less than that of Borromean -> Bulletproofs 20:58:57 There was a lack of confidence in the expertise needed to review the math/proofs 20:58:58 I wonder if broadening the scope will get them interested 20:59:07 ah 20:59:37 There would be _some_ benefit to having a group review only the code, but having one group that understands both deeply has its advantages 20:59:42 why could they find people for bulletproofs but not clsag? is it a different type of complexity? 20:59:42 and Teserakt is well qualified 20:59:49 They weren't reviewing the math 20:59:58 only the implementation's match to the paper 21:00:14 how important is the math review? 21:00:19 Very 21:00:22 It's new math 21:00:23 Wait, I just realized I confused things with my comment above about Tim reviewing math. That was BPs. 21:00:34 You're thinking of Benedikt? 21:00:39 and bulletproofs wasn't because it was old math, or that everyone else in the world already reviewed it? 21:00:39 I might, 21:00:42 Who reviewed our prototype? 21:00:48 Benedikt was the author of the BP paper 21:00:55 Yes, I am. Thanks. 21:01:03 sgp_: Bulletproofs had its math/proofs heavily scrutinized already 21:01:09 got it 21:01:13 CLSAG has not received that level of scrutiny 21:01:23 I would not advocate deploying without a proof review 21:01:29 how realistic is it to get published in another paper? 21:01:34 I happen to be confident in the math, but I am naturally biased 21:01:42 Tough 21:01:57 There's waaaaay more new work than spaces/eyes available for peer review 21:02:20 It's a losing battle to wait and hope for inclusion in proceedings, and there's no guarantee of the quality of review 21:02:26 (plus it'd be anonymous) 21:02:26 I would think "this is going to be deployed in an open-source, billion dollar project" would help a bit, but academia is weird 21:02:36 I'd rather have a known entity (JP) review it 21:02:42 Academia is busy 21:02:53 I'm moreso getting at both 21:03:03 And you get no credit for reviewing a paper outside of a journal/proceedings 21:03:23 I certainly plan to submit CLSAG to PoPETS, no doubt 21:03:35 But it often takes several submissions with different deadlines 21:03:54 Political... pets ? 21:04:01 perhaps 21:04:08 Proceedings of... 21:04:12 * moneromooo goes lookup 21:04:18 https://petsymposium.org/index.php 21:04:28 I knoew it, it's about pets. 21:04:33 pet symposium is a dumb name 21:04:49 police pets 21:05:08 I feel... all fuzzy inside knowing such a thing exists ^_^ 21:05:16 FWIW, the CLSAG security model is already better than that of MLSAG 21:05:28 But we're trying to improve it even more to handle some cases that LSAG/MSAG did not 21:06:06 by better security model, does that essentially mean you feel more confident in the math of clsag than mlsag already before review? 21:06:23 Yes, assuming our proofs are correct 21:07:07 did Teserakt give a rough estimate for the narrow scope review? 21:07:24 So far, informally it'd be the patch changes 21:07:29 TBD more specifically 21:07:44 Cost ~7200 USD for code, and another ~7200 for math/proofs 21:08:13 we should split off the math/proofs and compare other providers for the code portion (including varying scopes) 21:08:23 Just to be clear, the fact that we're changing the security model doesn't mean there are exploitable problems with LSAG/MLSAG 21:08:37 only that the proofs couldn't guarantee the non-existence of certain edge cases 21:08:56 "lack of proof of non-existence" != "existence" 21:09:03 got it 21:10:02 Hiring someone else for code review would certainly involve billable hours just to get familiar with the paper 21:10:14 which is built in to the Teserakt stuff already (same people doing both) 21:10:18 could you recruit other crypto researchers to do reviews, as standin for academia which may be inaccessible? 21:10:32 If you know people with time and interest, go for it 21:10:44 We'll have the preprint updated on IACR as soon as the updates are done 21:10:45 I'd still like to see what it looks like to compare firms for the code reviews of narrow and medium scopes 21:10:52 all the people I know are already working on it :p 21:11:14 "Get peer review" is one of those things that is always harder than it sounds, even when it sounds hard 21:11:51 I can ask Derek at OSTIF if any of the other firms would be interested in code-only reviews, given the new timeline (or lack thereof) 21:12:03 yes, I think that would be great 21:12:06 it sounded like the security proofs are pretty novel, would that inspire peer review? 21:12:14 The proofs techniques aren't novel 21:12:24 the security model is different than other LRS definitions, though 21:12:41 and have Teserakt clearly specify quotes for (math), (math + narrow), (math + medium) 21:12:51 Depends what those scopes mean specifically 21:13:00 Math is a defined scope 21:13:13 yeah of course, I mostly defer to your and moo's judgement on the code scopes 21:13:14 but "narrow" and "medium" require a "these commits / these files / these functions" listing 21:13:57 "medium" to me means "what's the next reasonable 1 thing that could be audited by extension" 21:14:29 Oof 21:14:37 I'd like to know what moneromooo thinks of that question 21:14:48 you only get to pick one, choose wisely :p 21:14:56 I can think of conceptual scopes, but it isn't clear what tentacles that extends into the recesses of the codebase 21:15:15 sounds like moo can help define that 21:15:39 If we can get a nice limiting scope for commitment offsets and balance assertion, that'd be my pick 21:15:49 since that's the crux of the transaction model 21:16:36 UkoeHB_: this is where something like ZtM could come in handy, as the closest thing to a written spec 21:16:39 How to define the scope between math and code ? 21:16:46 now we're getting somewhere 21:16:48 moneromooo: no, just what code to review 21:16:59 The patch seem like a good target. 21:17:04 They'd check that the CLSAG_Sign/Verify functions do the Right Thing 21:17:09 As in "it does not introduce any flaw". 21:17:24 Right, that's a narrow scope 21:17:31 sgp_ asked about the "next biggest useful scope" 21:17:32 As in "we did not find any flaw it introduces" :) 21:18:01 Well, given it pulls things which pull things... that'd be the whole protocol really. 21:18:12 that was my worry 21:18:25 And given we might switch to omniring/triptych/rct3/lelantus, it seems not worth it at this point. 21:18:30 At least the patch would show "no less secure than however secure it was before" 21:18:48 can we say "treat this as a black box and lob this off?" throwing out ideas, not dictating 21:18:51 OmniTripLantus3 21:18:53 I can do a CLSAG writeup of how it would be implemented if that would help getting reviewed. At this point I should be doing CCS since my work is getting way off ZtM2 scope 21:19:03 UkoeHB_: that's what the paper is for 21:19:07 we already have that 21:19:29 It would be useful if more of the RCT protocol were in scope 21:20:28 However, I'm sure Teserakt would find ZtM useful to help them understand how MLSAG/CLSAG fit in to the tx protocol (basically a drop-in replacement) 21:21:02 if there's no good way to define a medium scope, then it's probably best to not do one 21:21:03 if it's drop in then not much is actually changing 21:21:06 Anyway, most of this is a moo point until the paper gets the thumbs-up 21:21:14 UkoeHB_: it's still like 1800 lines 21:21:29 There are underlying crypto functions that were custom-written to speed things up 21:21:51 well in terms of how the transaction protocol fits together 21:21:52 and integration code 21:22:01 Yes, there's basically no change to how the tx protocol works 21:22:09 Hence the idea of narrow scope 21:22:15 that's what I meant 21:22:20 gotcha 21:22:32 but it's still a non-trivial change in code, even if it's a small change in the math 21:22:42 The old math didn't have formal security definitions that we liked 21:23:02 So the non-triviality in math exists mainly because of the security model change 21:24:03 The handling of linkability and non-frameability was super limited, for example, and had strong assumptions 21:24:54 Well at least we have some agreement on a scope, which is good 21:25:19 moneromooo: when it comes time to send the list to the auditors, should they review the 3 commits in your crash branch? 21:25:32 Or is there a PR for changes 21:26:02 I plan to send them any commit/PR lists, the CLSAG preprint, and ZtM as a reference for MLSAG and the overall tx protocol 21:26:56 Let me know and I'll rebase first. 21:27:03 OK, will let you know 21:27:15 UkoeHB_: what version of ZtM is most appropriate for this use case? 21:27:22 Assume that it would get sent in a week-ish 21:27:30 And I'll make a branch just for it. 21:27:35 great 21:28:03 I hope it still works ^_^ 21:28:03 moneromooo: did that silly extra-data-in-hash issue get fixed too? 21:28:07 heh 21:28:15 What is the silly extra-data-in-hash issue ? 21:28:45 I pointed out a few lines in the sign/verify routines where space in hash input was allocated and zeroed, but never used 21:28:53 It was along with a note about serialization that you'd already addressed 21:28:58 Ah, a few days ago ? I've got that here, yes. 21:29:04 great 21:29:25 That was the only change I noticed (and it wasn't security related obviously, just a waste of spacetime( 21:31:41 Probably the latest draft, since rcttypefull has been deprecated 21:32:09 Just missing bulletproof really 21:32:39 And that's most definitely out of scope 21:32:56 I'll ping you again before I send it, to confirm the right draft 21:34:22 Sounds good 21:35:06 thanks UkoeHB_ 21:35:11 ZtM wins again 22:21:25 🥳 22:43:01 did a brief analysis of txtangle, assuming 1% of current tx volume is converted, is 230 participant tx per day, for about 9 per hour, so 15-30mins per txtangle, at around 0.05-0.10 USD per output to be financially viable 22:43:41 coinjoin is at 4% volume but that's an open ledger, and bitcoin is easier to implement 22:47:24 Plz define txtange 22:47:43 join protocol 22:47:45 and why 1% would be expected 22:48:07 just an approximation based on coinjoin adoption 22:49:00 How is txtangle != joinmocoinjoin 22:49:04 expected adoption is lower since monero is already not an open ledger 22:49:08 its a better name 22:49:24 and coinjoin means bitcoin] 22:49:27 OK so, "txtangle" == "input joining" or whatever generic term we wish to use 22:49:39 * sarang likes terms to be defined 22:49:46 sry :p 22:50:53 Whenever I see an undefined term that sounds cool, my subconscious assumes it's a marketing thing and automatically recoils =p 22:51:00 Unless I came up with the term, in which case I am proud of it :D 22:51:26 Also, "tangle" means something else depending on what projects you know of :/ 22:52:26 whatever! it's mine now! 22:53:01 I am cool with reclaiming that word 22:53:03 it's a cool word 22:53:37 I mean, I only chose the term "Triptych" because I got sick of saying "the new LRS construction proposed in issue #XYZ"... 22:53:57 and you only get media attention with a badass name 22:54:27 i figured koejoin was way too much ego ;p 22:54:59 You can call it whatever you want! But you need at least 51% of nodes to agree on the name 22:55:20 I was told during my math training that you can't name something after yourself; someone else needs to 22:55:36 shit need to work on my outreach 23:47:14