06:42:53 https://monerointegrations.com/ 06:51:14 I'm inspired to do another Breaking Monero episode on unlock times 06:56:00 Someone can use unlock_time when sending funds to others and better track the spending of these real outputs in theory 06:56:12 Obviously this would be a detectable attack 06:57:00 But imagine a dust poisoned output attack with an unlock time 09:33:06 I hope more wallets will make outputs easier to manage in the future 09:33:55 and such an attack would be easily foiled by the wallet highlighting you got a small input with unlock time and letting you freeze it for example 13:48:30 Hi, saw that sgp_ pinged from the earlier meeting 13:48:40 Huge thanks for the support on BP+ 13:49:14 And yes, the new version of Lelantus does require that addresses be public on chain, even for their confidential transaction type 13:49:46 It removes the self-spend requirement and improves the security model, but would require either trivial address linking or single-use addresses (like is typically recommended for transparent assets) 13:50:43 Neither Arcturus nor Triptych have this particular limitation; they support the current Monero-style separation of amount commitments from one-time addresses 13:52:37 And I suppose there is no way to enforce those single-use addresses? 13:53:11 Well, there's no way to enforce them in Monero either =p 13:53:22 Other than to make it some kind of consensus rule 13:54:06 Sure, but they technically lead to a burn if re-used in Monero 13:54:23 Yes, but that's a wallet thing 13:54:43 You could do the same in Lelantus, presumably, if you wanted to 13:54:52 I don't know if this is being done in any implementations 13:55:11 Er no, I spoke too soon 13:55:16 You'd have a key image reuse in Monero 13:55:19 scratch that, d'oh 13:55:50 You could still enforce in Lelantus by a consensus rule 13:58:01 Anyway, just thought I'd confirm what sgp_ had said earlier 13:58:33 I had heard the term "shielded address" used at some point to describe the new Lelantus addressing structure, but it's not the same as, say, Zcash 14:20:56 If we are able to enforce it in Lelantus through consensus rule, what is the downside? 14:21:06 ^ sarang 14:22:05 Sender and receiver would need to communicate to provide fresh addresses for each transaction 14:22:54 dEBRUYNE I'm guessing there is also the downside of checking the entire chain for addresses every time, just like with a potential fix for monero's burn bug. 14:23:29 sarang: Ah I see, that would be inconvenient 14:23:51 Yeah, the Monero addressing construction supports non-interactive one-time addressing 14:23:54 Lelantus does not 14:24:17 If you post a Lelantus address somewhere and receive multiple transactions addressed to it, they are immediately linked in the clear 14:24:57 Fortunately, you can get the same logarithmic scaling in Arcturus or Triptych while still supporting Monero-type addressing 14:26:01 Seems either of those are more worthwhile to pursue then 14:36:37 It would be nice to do an updated size/time analysis against the updated Lelantus construction 14:37:00 It changes the transaction structure and adds some new verification requirements 14:37:27 Addresses are also longer, but I don't know if this is really a big deal in practice (maybe for QR codes?) 14:47:17 Oh, and very preliminary tests on BP+ show a nice speed improvement, which folks might be interested to know 14:48:07 so speed and size? nice 14:48:13 indeed 14:48:33 Speed benefits are highly dependent on number of outputs and batch structure though 14:48:59 However, under no test conditions did I find that BP+ is slower 14:49:05 At worst it's marginally faster 14:49:12 At best it's several percent faster 14:49:35 But again, these are very preliminary results 15:24:22 oh i see the convo about bp+ was here 15:25:31 sarang: how much (relatively speaking) tinkering needs to be done to implement bp+? 15:25:47 and will it require both maths and code audits? 15:27:51 It should receive a code audit, most definitely 15:29:04 and is the pretence that transaction size improvements are in the region of ~6-8% correct? 15:29:43 As well as both prover and verifier time improvements 15:30:45 so ~6-8% is a correct estimate? 15:37:44 For the most common transaction types (1-2 and 2-2) the improvement is 6.6% and 4.9%, respectively 15:37:59 It's a decrease of 96 bytes per transaction, regardless of input/output structure 15:38:07 That's the size improvement, to be clear 15:38:44 The time improvement does depend heavily on batching and structure, but in no cases is statistically worse 15:39:02 (there's a lot of variance in test timing, so these are mean and median results over many test runs) 15:39:36 thanks sarang, that's solid info. 15:39:41 np 15:40:08 Once I have the code completed, you'll be able to run the performance tests on any machine you like, of course 15:40:55 FWIW I've initially seen verification improvement between 1% and 8% or so, across different test types and parameters 15:41:07 Proving times are much better overall, and I haven't worked on optimizing that yet 15:41:50 There's still quite a bit to do, of course 15:47:33 there are always things to do; life would be boring otherwise 15:47:56 Heh sure 15:48:14 I mean in terms of documentation, optimization, tests, and other things that will hopefully make auditing much easier 15:49:11 I've already included some optimizations that are extremely useful, but need careful documentation 15:50:50 To your earlier question, stuff like function signatures are the same (up to naming!) as for BP 15:51:09 So I would expect a smooth transition if it's decided to deploy this 15:53:28 Looking back, it's pretty impressive to see how much better tx size and time have gotten over the years 15:53:53 Used to be what, something like 13 kB for a 1/2-2 transaction? 15:53:58 and super slow 15:54:13 If BP+ is deployed, a 1-2 tx will be 1.3 kB 15:54:39 and a 2-2 will be 1.8 kB 15:55:00 that's like a tenth of what it used to be... 15:55:20 I should re-run the old verification numbers at some point and see the overall cumulative improvement too 15:56:17 so basically you are saying you are a transaction size barber? 15:58:05 lol 15:58:07 Not just me! 15:58:12 Lots of great work by a lot of people 15:58:40 We also get better formal security guarantees from some of these new constructions (e.g. CLSAG, BP, BP+) 16:00:54 Plus it's fascinating to see so much ongoing and new research by so many groups 16:01:35 Omniring, Lelantus, RingCT 3.0, some MW work, stuff from Zcash, etc. 16:52:05 Tbh, I don't see a comparison to Lelantus as super useful if we're not going to use it because of the one time address issue 17:02:08 So where do things stand for solutions like Zec with full-txo anonymity set and no trusted setups? still pie-in-the-sky? 17:04:11 sgp_: more of a curiosity than a practical metric in this case 17:04:55 Inge-: ECC (the company behind Zcash) has a recursive proving technique they've worked into an instantiation they call Halo 2 17:05:00 It's in a weird place, TBH 17:05:27 The code is being developed on GitHub, but their commit messages and PRs are basically empty, and the commenting and documentation seem basically nonexistent 17:05:57 sounds typically corporate 17:06:45 I thought ECC was turning everything over to zcash foundation 17:06:55 this doesn't sound like it 17:08:23 This is odd, since the initial Zcash work had extensive development and implementation discussion on GitHub 17:08:40 However, they've also significantly changed the Halo 2 licensing 17:08:55 I wonder if this new development model wasn't a very intentional internal decision 17:09:24 Anyway, to answer the question... it could be that Halo 2 ends up providing useful efficient transactions for Zcash without trust requirements, but frankly they aren't giving enough details to know 17:10:05 sarang: I seem to remember you commenting on Halo 2 quite a few months ago, basically saying the same thing ... 17:10:08 recursion still has to have a starting point. 17:10:12 Some community experts asked for details on their forums, but were not given any practical details by ECC researchers 17:10:21 Inge-: yeah, nothing has changed 17:10:37 And Halo 2 is the only horse in the race currently? 17:10:41 You can see their repo, but all the commits and PRs seem suspiciously devoid of any useful information or detail :/ 17:10:47 Inge-: for Zcash? Who knows 17:11:00 Like I said, ECC seems not to be doing forward-looking design stuff openly anymore AFAICT 17:11:03 no I mean in general, things that COULD be a future candidate for Monero 17:11:07 Oh ok 17:11:19 more than "forever increasing ring sizes" 17:11:52 Inge-: ideally, an accumulator-style transaction protocol requiring general trustless proving systems 17:12:03 Right now, no implementations provide this in a way that's practical 17:12:18 not impossible, just impossibly high resource costs? 17:12:25 Halo 2 is not some magic silver bullet... it's a way to do recursive proving, but that doesn't automatically make everything Fast And Small Forever 17:12:51 You need a construction that can actually use this technique, and even then, there are other practical considerations that right now ECC is refusing to discuss 17:13:00 Perhaps they will at some point, and I hope so 17:13:07 Inge-: right 17:13:17 One thing has changed. I've stopped asking about it as ZK proofs or ZK-SNARKS. PROGRESS! 17:14:33 eh 17:14:36 *heh 17:14:56 Yeah, ZERO KNOWLEDGE is not a magic wand that gives you anonymity 17:15:27 It's a useful property of many constructions that can be used as building blocks for transaction protocols that could give useful anonymity (as part of This Balanced Breakfast, as they say) 17:17:14 Arcturus, Triptych, Lelantus, Omniring, RCT3... they all use zk proofs 17:17:34 It's very, very unfortunate that "zero knowledge" has been wielded as a marketing term 17:17:39 I don't think that's helpful for users 17:20:01 I think I’d say in a protocol that zero knowledge is like ketchup. The main course is usually the information theoretical part and the sides being the cryptography 17:20:46 In an argument protocol* 17:20:55 Heh 17:21:36 My point is that an overlying security model might deal with anonymity 17:21:57 and perhaps having a zk proving system makes it straightforward to establish a security proof for that 17:22:09 But maybe in a particular security model, witness indistinguishability suffices 17:22:46 But it's not like plugging in a zk proving system into some random overlying construction magically makes it "anonymous" 17:23:12 So statements like "we use zk proofs" don't inherently have any practical meaning 17:24:10 What if I give the protocol a cool name :) 17:24:36 Well, that's another story entirely =p 17:24:36 Yeah it would be interesting to see what protocols are using zk but don’t actually need it 17:25:01 e.g. we never built an extractor for MLSAG/CLSAG that would be needed for zk 17:25:10 But you can still establish anonymity definitions without it 17:25:41 And you can flip that script... you could easily take a zk proving system and build a terrible transaction protocol with awful anonymity guarantees... 17:25:57 so easily in fact, that ... 17:26:39 Note that I say this as someone who renamed Triptych-2 to Arcturus... 17:26:55 Naming does matter 17:26:57 without a doubt 17:27:34 Triptych-2? missed a chance to call it Hextych 17:27:42 lol 17:28:07 I considered "Polyptych" 17:28:18 but realized nobody would ever spell it correctly without looking it u 17:28:19 *up 17:28:21 including me 17:28:40 I jokingly recommended Triptyzk 17:28:44 Just to include zk 17:28:53 -____- 17:28:59 lol 17:29:26 It could have been useful to remove this absurd use of "ring signatures" vs "zk proofs" as a proxy for anonymity set size 17:29:39 I mean, that's how initial implementations' transaction protocols worked, sure 17:29:50 Yeah that's on the ECC for abusive marketing 17:29:53 but I think it can easily become almost misleading if not explained properly 17:30:20 ECC has been misleading at every oppty 17:30:31 I made some fun charts last night https://twitter.com/JEhrenhofer/status/1332552672185098240?s=19 17:30:43 Including a cumulative one haha 17:31:03 I am still extremely interested to know how much Quesnelle-style pool interaction analysis still applies to Zcash 17:31:16 ^ yes, but no one has bothered 17:31:23 I've requested (on Zcash forums, etc.) that someone with access to this kind of analysis tooling examine it 17:31:29 but AFAIK nobody has done so publicly 17:31:46 I think that's a _much_ better metric for the practical safety of their pool approach 17:31:54 "value of the pool" is not useful IMO for individuals 17:32:23 Much like how in Monero, individuals may need to consider repeat poison transactions, network threats, etc. 17:32:30 The whole ecosystem is complex 17:32:58 and reducing security to something like a signature scheme or proving system is useful to a point, and then not useful 17:33:18 FWIW I did try to get some Zcash tooling updated to do this analysis, but it just didn't work 17:33:40 sgp: you decided 0/0 is 100% ? 17:35:34 hyc: FWIW I don't agree that ECC researchers have been misleading... I think they have generally tried to be accurate and correct in their work 17:36:33 That is not to say that they have been transparent about their work, which is different, and likely depends on leadership decisions 17:36:47 *transparent about _all_ their work 17:37:09 I personally would love to dive into the new Halo 2 stuff, but there's nothing out there except code without useful documentation or commit messages 17:37:12 that may be true, but ECC marketing messages prob aren't dictated by their researchers 17:37:21 and "the code is the comments" isn't useful, either in Monero (hint hint) or in Zcash 17:37:36 Maybe, but I don't want to throw researchers under the bus here 17:37:39 that isn't fair 17:37:46 they chose wher eto be employed. 17:37:50 it is 100% fair. 17:37:58 Eh, not really a research discussion at least 17:38:04 ok 17:38:17 I ought not to have deviated to that 17:38:39 I'll classify Halo 2 as "interesting if true in practice" 17:38:46 which has yet to be seen :) 17:39:57 The most interesting possibility about recursive verification might be how it could apply to transaction verification 17:40:09 Their early tests IIRC were only for block verification, which seems inherently recursive 17:41:11 There's other related work being done on things like curve choice and other implementation specifics that I'm very curious about too 17:44:40 Unfortunately, any code they release under their new license (as I understand it) is restricted for a period of like a year 17:44:53 but then appears to be open 17:45:45 Is this common in the FOSS world? 17:49:18 it is becoming common in corporate environments 17:49:40 the rationale is "we need to monetize our work for at least <1 year> before giving it away to everyone" 17:49:55 Hmm, I can see the benefits for the authors, I guess 17:50:03 Sounds like a patent, no? 17:50:17 mebbe, but less than the 17yr patent term 17:50:21 right right 17:50:24 but the same motivation? 17:50:30 I guess yes 17:50:35 I mean, I have no desire to release code under such a license... 17:51:03 a patent without all the lawyers and registration fees 17:51:16 or, a trade secret with a fuse. 17:51:30 I worry that this will also incentivize those who also build the underlying math not to publish their work 17:52:01 yeah it's troubling. but if they keep it to 1 year, I guess it's livable. 17:52:05 Since you can't copyright/patent math 17:52:10 but you can copyright the implementation 17:52:32 One thing that's nice about cryptography is that preprints are typically the way to communicate research quickly 17:53:05 but if the trend is to lock down implementations for a period, and the implementers want to prevent people from doing separate implementations in the meantime from the math, this slows down the openness of the preprint process 17:53:12 makes sense to me. analogous to alpha/beta software releases 17:53:19 Maybe this isn't the case, who knows 17:53:23 ah. yeah 17:53:25 Certainly feels like a big change though 17:54:12 But who knows... if the end effect is to encourage research because of a short period of being the sole benefactor from it, maybe that outweighs these (possibly nonexistent!) risks 17:54:27 Kinda like how patents are supposed to work 17:54:30 it's the same curse of profit motive 17:54:47 Zcash is an interesting petri dish for this stuff, since they have a lot of capital involved 17:55:25 it's a shitty model for research. need to get things like Xerox PARC back. 17:55:28 I disagree with many of their business decisions, but there's a lot of research going on related to that eosystem 17:55:35 *ecosystem 17:55:49 and TBH having a variety of funding models seems like a good way to determine the best ones 17:55:58 At least, overall... certainly not individually 17:56:21 e.g. BP+ was done under a new-to-the-Monero-community funding model 17:56:30 Maybe it works more broadly, and maybe not 17:56:34 meh. when you involve VC funding, you're on the wrong path. 17:57:19 Well, doing BP+ under the MAGIC umbrella seems more akin to how ZF operates 17:57:25 Albeit with different funding sources 17:57:32 they will always prioritize quarterly profits over anything else. 17:58:30 ZF is a promising change from ECC, yes. 17:58:40 FWIW ECC's owners (I don't know who these are) are apparently "donating" (I don't know what this means legally) some kind of control to a nonprofit: https://electriccoin.co/blog/eccs-owners-to-donate-ecc/ 17:58:46 So the VC model no longer seems to apply 17:59:11 Having a nonprofit at least ensures that the use of funds is restricted based on purpose 17:59:28 Seems like a good move 17:59:34 agreed 18:00:07 it's not a guarantee. there are plenty of nonprofit CEOs still milking their orgs. 18:00:17 but it's a step in the right direction 18:00:59 I think it's a very interesting experiment to apply this kind of nonprofit model to Monero-related research 18:01:06 Granted, the funding model is very different 18:01:23 but at least the nature of projects and the accountability seem quite similar between ZF and, say, MAGIC 18:01:54 licensing vs not licensing software has interesting market structure implications; if you can't profit from gating access to a service, the driving thought process behind making it must be different; the people who _actually want the service to exist_ must fund its creation instead of those who want to sell it to the users; investment in the service must be directly related to the _consequences of it being 18:01:54 used_ rather than the ability of the service to generate sales; basically, it peels away one layer of complexity in the market process, which would seem to make it inherently more efficient 18:03:08 What do you think the implication is for something like Zcash, where the network itself generates the revenue funding the organizations doing development? 18:03:44 more efficient in terms of providing the means for consumers to meet their ends, not necessarily making it easier for service makers to figure out how to make services that are worthwile 18:03:45 I don't know enough about economics to have a solid grasp over whether/how the incentives appreciably change in this case 18:08:16 there is at least one clear effect; the organizations will be greatly disincentivized to do anything that could reduce exchange rates with fiat 18:08:43 Would that increase overall liquidity, which seems beneficial? 18:09:04 in the extreme case, it could even mean compromising on privacy features in order to comply with increasingly onerous regulatory requirements 18:09:41 Well, their approach seems to be maintaing the pool approach, which seems to work for them so far... 18:09:47 at least in terms of exchange support 18:10:02 As stated before, AFAIK there's no up-to-date research on whether pools are used safely 18:10:53 On a topic actually related to Monero research, I saw some questions about the tradeoffs of BP+ deployment 18:11:12 It is a size and time benefit, but would require an audit, and additional code for a new transaction format 18:11:16 Any thoughts on this? 18:12:15 is it impossible to translate old proofs into the new proof style (spitballing)? 18:12:21 I think most people have reservations about sensitive code being touched for a relatively marginal (evidently, this is a bit subjective) change 18:12:24 ^ sarang 18:12:49 I think the new transaction format changes can be mitigated by, for instance, implementing it along side Triptych 18:12:54 UkoeHB__: this is not possible 18:13:52 what would be the point of such a translation? 18:14:25 FWIW transaction format changes have been quite smooth in the past. 18:14:26 As a quick reminder, BP+ reduces typical transactions by 5-7% (a fixed 96 byte reduction per transaction) 18:14:41 hmm I was thinking you could deprecate the old code, but that doesn't work since you always need compatibility 18:14:43 and reduces verification time by maybe 1-8% based on initial tests 18:15:09 Proving time is also much faster, but this is less important in practice 18:16:15 BP+ proofs are a drop-in replacement for BP proofs 18:16:57 and retain the same compatibility with other constructions currently under R&D here and elsewhere (e.g. RCT3, Lelantus, Triptych, Arcturus) 18:17:17 since those constructions simply require range proofs as a black-box construction 18:17:29 (Omniring includes its own range proofs) 18:18:26 it seems worthwhile to me; it may depend on the PR size and complexity to evaluate if it is worthwhile 18:19:16 you don't need to translate the proofs. you know what is being proved, you just need to generate a new proof in the new system. 18:19:53 We already don't verify old Borromean-style range proofs without a flag 18:20:02 This could be done for older BPs as well, if desired 18:27:23 Anyway, for each BP prove/verify function there's a corresponding BP+ prove/verify function 18:27:31 I've tried to keep it fairly modular there 18:27:55 The rest of a deployment is updating the transaction format, consensus rules, etc. 18:33:58 8% here, 8% there... pretty soon monero will be making your processor run faster 18:37:50 Monero makes my computer faster? 18:37:53 Already does. Makes your CPU switch to performance mode after running for a bit. 18:38:14 (not actually tested) 18:39:26 Can we patent this process and sell it to Microsoft 20:00:24 Monero makes computers faster * 20:00:29 *) In participating universes