00:40:46 <sarang> Well, that was a fun IRCCloud outage
06:00:27 <MRL-discord> <Isthmus> Argh, IRCcloud still down
06:00:44 <MRL-discord> <Isthmus> When was "hard fork 2"?
06:00:52 <MRL-discord> <Isthmus> (referenced in a comment in the code)
06:08:47 <MRL-discord> <Isthmus> Is that v0.9.4 from height 1009827?
14:47:22 <sarang> test
14:47:32 <sarang> Clearly I spoke too soon about the IRCCloud outage...
14:49:25 <selsta> At least they said they will look into having backup network infra.
15:03:53 <sarang> I didn't get a chance to review my action items during the meeting due to network issues, but here they are
15:04:17 <sarang> With sgp_, getting a blog post up about auditability (I'm finding it tricky to present the risks/tradeoffs clearly)
15:04:29 <sarang> Finalizing encrypted timelock stuff (currently in progress)
15:04:40 <sarang> Getting CLSAG out (pending suraeNoether)
15:04:58 <sarang> And doing a review of the interesting new BLAKE3 tree-based hash function
15:08:56 <sgp_> The blog post is pretty important, probably overdue
15:12:32 <sarang> The current version separates risks/tradeoffs by transparency vs. non-transparency
15:13:10 <sarang> I'm thinking through whether it would be more clear to separate them by class of exploit/flaw: breaks of cryptographic hardness assumptions, detectable inflation flaws, non-detectable inflation flaws
15:13:13 <midipoet> audibility at the wallet/transaction level, or at the network/supply level?
15:13:24 <sarang> Supply auditing
15:14:22 <sarang> Make it clear that a transparent ledger is not immune from bugs that could affect users, nor are non-transparent ledgers
15:14:54 <midipoet> there was a really good discussion on reddit about 18 months ago about this. perfectly blinding/hiding vs perfectly binding (is that the correct terminology?)
15:14:57 <sarang> IMO a hardness break is _extremely_ unlikely, and such a thing would probably affect general DL-based security (including Bitcoin keys)
15:15:17 <sarang> I've come to dislike the hiding vs. binding discussion, because I think it too narrowly focuses the problem
15:15:31 <sarang> Better, I think, to discuss in terms of practical risk
15:15:39 <sarang> Transparency has a whole set of practical risks
15:15:54 <sarang> Hardness breaks do too, but are balanced by being considered exceptionally unlikely
15:16:21 <sarang> Detectable flaws are way more likely... while they could be "rolled back" in some sense to avoid supply problems, you could still get screwed over as a uer
15:16:23 <sarang> *user
15:17:02 <sarang> e.g. Zcash says (correctly) that transparent migrations avoid supply inflation in particular pools, but honest users can still lose funds
15:17:12 <sarang> or e.g. Bitcoin's inflation bug
15:17:27 <sarang> or e.g. Monero's detectable key image bug
15:17:44 <sarang> Undetectable inflation is another class of risk
15:18:14 <sarang> But I'm having a hard time clearly delineating and differentiating these risk types
15:19:12 <sarang> I think a good takeaway message is that there are risks and tradeoffs with the design choices of _any_ project, and how you prioritize those risks can/should influence your choices
15:19:36 <sarang> and that choosing a transparent asset does not guarantee safety of funds in all cases
15:19:57 * sarang is done now
15:23:04 <midipoet> i dont think a supply audit is about guaranteeing safety specifically is it?
15:23:37 <midipoet> it's about perfect knowledge of supply that is network symmetric (known to all nodes)
15:24:13 <sarang> I think there's some relationship
15:24:30 <sarang> Suppose you discover an inflation problem in a transparent asset; what happens next?
15:24:39 <sarang> If you roll back, users can get screwed
15:24:44 <midipoet> so it becomes a verifiable characteristic of the asset in question, as apposed to a presumed characterstic
15:24:48 <sarang> If you don't roll back, your supply has changed
15:26:05 <sarang> And if anything, there could be a subset of risks that are "detectable but not yet detected"
15:26:56 <sarang> Any ideas for the best way to present all this?
15:27:36 <sarang> I think the post should make it clear that there absolutely are risks/tradeoffs with hidden amounts when it comes to supply; but it's not like transparent amounts suddenly removes all risk from the equation
15:35:47 <fort3hlulz> One of the keys to me is that, while it is a tradeoff, we view it as absolutely worth it for fungibility/privacy
15:36:16 <sarang> Right; it's up to users to decide what their priorities are, and how that influences their choices
15:36:18 <fort3hlulz> Transparency allows you to detect some inflation issues before you could in Monero, but just like you're saying -- what happens next? If you don't roll back, your golden cap is gone regardless of transparency
15:36:44 <sarang> If people prefer the guarantee of eventually-detectable supply guarantees, then choose Bitcoin or something similar
15:36:47 <fort3hlulz> Are you going to share about the difference between cryptographic bugs/issues and implementation bugs/issues?
15:36:51 <sarang> as long as they understand the tradeoffs
15:37:14 <fort3hlulz> And would absolutely love to see info/thoughts about turnstiles in there too as that affects any L2 implementation on Bitcoin like Liquid
15:37:20 <sarang> You mean the difference between breaks in the cryptography itself, versus implementations?
15:37:24 <fort3hlulz> yes
15:37:28 <sarang> Like hardness assumption breaks? Yes
15:37:39 <sarang> IMO that should not be the overriding concern
15:37:53 <fort3hlulz> Just to make it clear that the much more likely issue is implementation breaks, which is why audits/more eyes on the code is key
15:37:54 <sarang> If someone can break DL, everyone is screwed
15:37:57 <fort3hlulz> yeah
15:38:02 <sarang> Including Bitcoin
15:38:09 <fort3hlulz> Thats why I want to be sure it's clear that imp breaks are MUCH more likely
15:38:18 <sarang> Your supply is guaranteed, but such an adversary can probably nab all funds by recovering keys
15:38:53 <fort3hlulz> Also (and this may be way too much info for a blog post) would like to see info in there about the cryptography being used in Monero being too "cutting edge" or "complex"
15:39:04 <sarang> The initial blag post draft tried to make it clear that implementation risks are way higher
15:39:10 <fort3hlulz> Thats a common thread I see as a followup to auditability concerns
15:39:13 <fort3hlulz> Sweet
15:39:32 <sarang> I wouldn't call it complex... the code gets pretty hairy, but that's more a development thing
15:39:41 <sarang> The math is pretty straightforward compared to something like Zcash
15:39:53 <fort3hlulz> exactly :)
15:40:00 <fort3hlulz> It's a middle point on the sliding scale
15:40:05 <fort3hlulz> intentionally
15:40:11 <fort3hlulz> Will be an incredibly important post, as auditability seems to be a huge sticking point for many people moving from bitcoin to Monero.
15:40:20 <sarang> Well, and that's an entirely different tradeoff having to do with centralized trust
15:40:35 <fort3hlulz> For sure
15:40:35 <sarang> i.e. no trusted setup means you don't get full-anonymity-set transaction inputs
15:41:04 <fort3hlulz> I'd love to take a look at the blog post draft if you don't mind/want another set of eyes on it
15:41:04 <sarang> Or I should say, you don't get it with practical efficiency that's useable
15:41:10 <fort3hlulz> ^
15:41:28 <midipoet> i wonder if there is an analogy to fiat currencies. in fiat, we cannot effectively verify the supply, or guard against hidden inflation, as it's layered behind the complexities of governments, monetary policy, and all the baggage that goes with it. in fungible cryptocurrency, supply verifiability is layered behind the complexities of zero-knowledge schemes, complex math, and that other baggage ;-)
15:41:48 <fort3hlulz> I don't like that comparison
15:41:49 <fort3hlulz> Because
15:41:50 <sarang> Current draft: https://gist.github.com/SarangNoether/6af1d93359a5279fb24d06655f13014f
15:41:59 <midipoet> fort3hlulz:
15:42:01 <fort3hlulz> With Monero you DO have full transparency of emission-time supply
15:42:03 <midipoet> it was sort of a joke
15:42:11 <fort3hlulz> oh sorry haha
15:42:27 <fort3hlulz> this stuff gets me riled up
15:42:35 <sarang> My current draft is a fork of sgp_'s version, which is a fork of my earlier version
15:42:37 <midipoet> it's not easy
15:42:39 <sarang> It's blag posts all the way down =p
15:43:04 <midipoet> but, can i ask, doesn't MW include a supply audit at the cut through?
15:43:11 <midipoet> (if thats the correct terminology)
15:43:29 <sarang> How so? They rely on balance through Pedersen commitment differences too
15:43:29 <midipoet> isn't their whole scheme based on a recurring supply audit?
15:44:02 <sarang> AFAIK a Pedersen DL break would imply inflation
15:44:13 <midipoet> hang on, i will try and find a link that explains it
15:44:16 <sarang> If something claims otherwise with detail, I'd like to read it
15:44:22 <midipoet> as i definitely can't
15:45:10 <fort3hlulz> sarang sgp_ great work on that
15:45:22 <midipoet> https://tlu.tarilabs.com/protocols/grin-protocol-overview/MainReport.html#cut-through
15:45:26 <fort3hlulz> Couldn't have said it any better, and a great quick read on the actual facts behind the choices involved
15:45:38 <fort3hlulz> A+++ and easy for non-technical readers to grasp as well, I think
15:45:53 <fort3hlulz> Now post it so I can share it broadly ;)
15:46:33 <sarang> That version doesn't separate the discussion by risk type
15:46:43 <sarang> and that's what I'd like to try next before posting anything
15:46:53 <sarang> I think it could clarify the different tradeoffs even better
15:47:06 <fort3hlulz> Tradeoffs of auditability/fungibility/privacy?
15:47:10 <fort3hlulz> Or different implementations?
15:47:31 <sarang> Tradeoffs in security/privacy/etc. and risk of inflation or fund loss
15:47:43 <sarang> Which are not always neatly delineated by project/asset type
15:48:08 <sgp_> I think the current version is good, but sarang is interested in a rewrite organized a different way. I'm partially interested in seeing what this could look like
15:48:09 <sarang> You can have detectable inflation flaws in transparent or non-transparent projects, for example (and we have real-world examples of this)
15:48:21 <sgp_> sarang: maybe start with an outline rather than a full rewrite?
15:48:31 <sarang> So it's not like using Bitcoin magically makes you immune from all risks
15:48:33 <sarang> yeah
15:48:47 <sgp_> comparing outlines is probably more useful than comparing completed blog posts
15:49:01 <sarang> good point
15:50:04 <fort3hlulz> I, personally, think the current version is quite good -- only things I could see added is a note about the complexity a lack of fungibility/privacy adds to a users required steps (CJ, coin control, etc), and maybe something about what "happens next" in the event of an inflation bug in Bitcoin et al
15:51:17 <sarang> Yeah; Zcash is another good example, because they've said what would happen in the event a transparent migration fails the supply check (remaining funds get locked forever)
15:51:39 <sarang> And I don't like how this point is sometimes glossed over in their discussions of supply soundness
15:51:52 <sarang> It would be a huge deal in practice for users
15:55:24 <sarang> I'd also like to add links with some supporting details
15:55:47 <sgp_> supporting links would be good
16:36:55 <atoc> Hey suraeNoether. I know you are completing CSLAG, but I was just wondering if you got a chance to push the changes you have.
16:45:03 <sarang> sgp_ and others... new draft: https://gist.github.com/SarangNoether/89a08ab5f9bd09350e653fb9b2e4e99b
16:45:14 <sarang> Consider it still incomplete
16:46:34 <sarang> Hopefully this provides more clarity about different types of risks and benefits
16:47:16 <sarang> I removed the title's specific reference to Monero, since this question is more broadly applicable
16:57:28 <sgp_> Cool, will review
16:58:09 <sgp_> Though I think some reference to Monero in the title is desired for people looking for answers to questions about Monero (in addition to other things)
17:00:43 <sarang> Make a couple of minor edits for typos and clarity just now
17:01:01 <sarang> Earlier versions are available via the revisions tab
17:02:35 <sgp_> On a similar note, this certainly qualifies as misleading https://twitter.com/least_nathan/status/1217528240664743936?s=19
17:02:50 <sarang> Yep
17:02:56 <sarang> That's why I specifically noted it in the post
17:03:06 <sarang> It's technically correct, to a point
17:03:23 <sarang> I noted "eventual supply consistency" to mean that a particular pool's supply can't be inflated through the migration
17:03:31 <sarang> but that you risk getting your funds frozen
17:03:52 <sarang> That might be the "various tradeoffs"
17:04:10 <sarang> Oh yeah, he notes the possible harm to users in the next tweet
17:04:49 <sarang> Although: it's tricky because the supply _within_ a shielded pool could absolutely suffer inflation in case of a soundness flaw
17:04:58 <sarang> It's only the transitions that can catch this
17:05:24 <sarang> Heh, which is noted here: https://twitter.com/least_nathan/status/1217826806121648128
17:06:12 <sarang> Hmm, but I don't see how this can possibly be correct: https://twitter.com/least_nathan/status/1217829034807189505
17:08:00 <sarang> I think the necessity of so many tweets on the topic highlights how it's subtle and tricky to properly inform people of the risks/tradeoffs
17:08:03 <sgp_> I asked for clarification
17:08:24 <sarang> I asked in a zcash dev chat as well
17:08:35 <sarang> I think Nathan is mistaken here
17:08:53 <sarang> But if not, I can somehow note this in the post
17:12:06 <sarang> Regarding this, it'd probably be possible to modify the Monero protocol to do a similar kind of transparent migration: https://twitter.com/least_nathan/status/1217827459397144576
17:12:14 <sarang> (but I think it's a really bad and dangerous idea to do so)
17:15:50 <sarang> Any comments or suggestions on the new blag post, aside from checking on the transparent migration stuff?
17:39:35 <fort3hlulz> reading now
17:40:21 <fort3hlulz> +1 for using shenanigans in the post
17:42:26 <fort3hlulz> Much better, and love all the source links now
17:42:31 <fort3hlulz> nice job guys
17:45:27 <sarang> Thanks
17:50:36 <fort3hlulz> Any ETA on publishing?
17:51:37 <sarang> I'd like additional feedback
17:51:46 <sarang> Then I can do a site MR
17:54:32 <sgp_> sarang: added a few sentences back from the original https://gist.github.com/SamsungGalaxyPlayer/2e79e11a897a640e11da1394f60cf828
17:54:34 <sgp_> thoughts?
17:57:45 <sarang> In the case of a direct cryptographic break on Pedersen commitments, no.
17:57:53 <sarang> That sentence is a bit odd
17:59:21 <sarang> in any remaining funds (including those of honest users) would be permanently frozen.
17:59:37 <sarang> would be... that's a grammatical mistake
18:08:06 <sgp_> oh yeah, I copied it over incorrectly, give me a sec
18:08:45 <sgp_> sarang: I removed the one sentence
18:09:53 <sarang> Any word on the Zcash migration question?
18:10:02 <sarang> I haven't heard back on the dev chat
18:10:14 <sgp_> nope
18:12:09 <sarang> I don't want to post without confirming that
18:12:32 <sgp_> sarang: confirming what, the requirement that t-addresses are necessary?
18:12:46 <sarang> But I don't see how they can confirm value pools in a verifiably countable way without transparency
18:13:00 <sarang> Yes
18:13:23 <sgp_> I think it's likely he is making that statement with some carefully-worded technicality and that your statements are also correct
18:13:27 <sgp_> but it's good to check
18:14:00 <sarang> Yeah, and perhaps best to provide the Zcash team with the draft in advance, as a professional courtesy
18:14:09 <sarang> I'd certainly appreciate it
18:14:35 <sgp_> let me message Nathan
18:15:04 <sarang> I'm not suggesting asking for their approval, only a chance to correct any factual mistakes
18:16:04 <sgp_> sarang: can you please check my minor edits and re-approve? Then I'll send over
18:17:25 <sarang> any remaining funds (including those of honest users) would be permanently frozen.
18:17:37 <sarang> s/would be/being
18:17:58 <sarang> Otherwise send it over and ask if they have any comments
18:18:15 <sarang> Hopefully they appreciate it since it applies to them as well
18:18:42 <sarang> I don't hear as much talk about Zcash commitments relating to supply compared to Monero
18:19:44 <sarang> Their use of commitments is slightly different for efficiency reasons
18:19:50 <sarang> But the same ideas apply
19:13:44 <sarang> suraeNoether: you on IRC today?
19:51:33 <sarang> Looks like Zcash _could_ retire transparent addresses and still do a transparent migration by revealing amounts in single transactions without relying on separate addresses, FWIW
19:51:53 <sarang> Heck, you could do that in Monero too if you really, really wanted to (but let's not...)
19:57:45 <koe> why hasn't bitcoin implemented stealth addresses? they are pretty straightforward and just require 32 bytes per transaction (or is that too much lol)
20:00:58 <andytoshi> an extra 32 bytes on every output, which are usually not even 32 bytes in size, would indeed be a lot
20:01:05 <andytoshi> as would the ECDH computation required to receive things
20:02:01 <andytoshi> there are like 5000 outputs per block, if wallets had to do a 50us ECDH computation on each one that's 250ms ... or an extra 42 hours to scan the chain
20:02:29 <andytoshi> sorry, i'm exaggerating, it's about 25 hours i think (400MM outputs total times a quarter second)
20:02:42 <andytoshi> but syncing bitcoin currently takes only a few hours on a fast PC
20:07:18 <koe> wow didn't realize it was that substantial
20:09:41 <andytoshi> there are ways to make it much faster but then you're into weird bikesheddy design territory
20:10:47 <andytoshi> e.g. requiring users to grind their keys so that you can cheaply do an hmac on them, for which the first ten bits have to be zero
20:10:59 <andytoshi> then wallets can skip the ecdh step for 1023/1024 of all outputs
20:11:37 <andytoshi> but now you've got another hmac key to keep private, there's a question of how many bits to grind, a tradeoff between verification speed and generation speed, a choice of hmac, a choice of what to put into the hmac, etc etc
20:11:45 <andytoshi> and you'll never get a standard out of that because the whole thing is too ugly
20:13:10 <koe> doesn't really engender optimism about scaling both bitcoin and monero, albeit beating a dead horse there
20:21:40 <andytoshi> sure, the existing crypto has scaling which is not good enough for bitcoin (and puts a high cost on monero users, who are selected for being willing to bear it)
20:21:43 <andytoshi> but things are getting better
20:22:01 <andytoshi> multiple times a year there are new crypto breakthroughs which make the situation better. bulletproofs were huge
20:22:57 <sarang> Or rather, not huge :D
20:23:07 * sarang will show himself out
20:24:29 <koe> is there an estimate of the upper limit to scaling improvements? is it just equivalent to Visa's servers?
20:25:23 <andytoshi> as evidenced by snarks, which allow constant-time verificatino of arbitrarily complex statements, there appears to be no limit
20:25:38 <andytoshi> though plausibly we would always need a trusted setup to achieve that
20:43:25 <ellithiosa[m]> andytoshi: you can get snark constructions that improve on this limitation. fractal/marlin are two recent results that bypass this and get reasonable proof sizes (~100kB) although constant-size is replaced by polylog afaik
20:46:42 <andytoshi> yep, and starks have had similar specs for a while
20:49:02 <ellithiosa[m]> main difference i think was the linearity in the verifier in starks, the polylog in these newer constructions means that you can do recursion (reasonably?) efficiently
20:49:28 <andytoshi> oh wait these let you -prove- in polylog time?
20:49:43 <ellithiosa[m]> no no
20:49:53 <ellithiosa[m]> prove is n log n
20:50:13 <ellithiosa[m]> it's just that in recursion the verifier needs to be encoded as a circuit so need to be reasonably small
20:50:55 <ellithiosa[m]> and they claim to have small enough verifiers to make recursion efficient
20:51:34 <sarang> Has that been tested with any proofs-of-concept?
20:51:53 <ellithiosa[m]> they have specs online
20:52:03 <ellithiosa[m]> not sure if they have code, but i think they do
20:52:09 <sarang> Link for the lazy?
20:52:49 <ellithiosa[m]> https://eprint.iacr.org/2019/1047.pdf
20:53:03 <sarang> Ah, I have seen the paper
20:53:06 <ellithiosa[m]> https://eprint.iacr.org/2019/1076.pdf
20:53:15 <andytoshi> starks have polylog verifiers
20:53:18 <andytoshi> and admit efficient recursion
20:53:36 <ellithiosa[m]> hm
20:53:56 <ellithiosa[m]> then not sure why the stark ppl haven't made the same claims as these guys
20:54:43 <ellithiosa[m]> i guess this depends on how big the constraint system encoding a verifier in stark arithmetization is
20:56:52 <andytoshi> i mean, the stark ppl have made the same claims as you have here :)
20:56:59 <andytoshi> i'd have to check the "related work" section to see a detailed comparison
20:57:53 <ellithiosa[m]> must've missed it in their paper then
20:58:40 <ellithiosa[m]> my understanding was that since starks don't use r1cs there's a hidden cost in their arithmetization
20:59:29 <ellithiosa[m]> and even though asymptotically they get 'efficiency' in practice the cost is high
21:00:16 <andytoshi> i don't see how anything that uses r1cs could have sublinear verification
21:00:25 <andytoshi> because the verifier needs to read the whole r1cs circuit
21:00:56 <andytoshi> but yes, i believe starks have high costs at setup time when converting a program to arithmetic form
21:01:01 <ellithiosa[m]> that's done once at the beginning
21:01:48 <ellithiosa[m]> they put this cost in the indexer
21:02:11 <ellithiosa[m]> in marlin at least
21:04:17 <ellithiosa[m]> and i think you can do even better by leveraging structure in the predicates
21:05:26 <ellithiosa[m]> i think that there's some work showing that if you have a structured predicate (e.g. N transaction verifications) then you can do much better. haven't seen any rigorous writeup though
21:09:30 <andytoshi> yeah i'm sure
21:09:33 <andytoshi> this is also true of starks
21:09:47 <andytoshi> but i don't know much detail about any of these schemes
21:09:49 <andytoshi> too much to read
21:10:09 <ellithiosa[m]> I think the way they got that structural improvement was through LDEs, which is different to starks
21:10:17 <ellithiosa[m]> but would wait for the writeup
21:10:23 <ellithiosa[m]> before getting too excited
21:10:47 <ellithiosa[m]> the other upper bound in pairing based snarks is the 2adicity
21:11:01 <ellithiosa[m]> Groth etc. (i.e. all the most efficient constructions) suffer from this
21:11:14 <ellithiosa[m]> in practice it means you can only get a maximum sized predicate
21:11:32 <ellithiosa[m]> at 80 bit security for recursion this is at 2^32 constraints in r1cs
21:11:59 <ellithiosa[m]> but the good news is this isn't an issue in these newer types of snarks that don't use ECC