Well, that was a fun IRCCloud outage

<Isthmus> Argh, IRCcloud still down

<Isthmus> When was "hard fork 2"?

<Isthmus> (referenced in a comment in the code)

<Isthmus> Is that v0.9.4 from height 1009827?

test

Clearly I spoke too soon about the IRCCloud outage...

At least they said they will look into having backup network infra.

I didn't get a chance to review my action items during the meeting due to network issues, but here they are

With sgp_, getting a blog post up about auditability (I'm finding it tricky to present the risks/tradeoffs clearly)

Finalizing encrypted timelock stuff (currently in progress)

Getting CLSAG out (pending suraeNoether)

And doing a review of the interesting new BLAKE3 tree-based hash function

The blog post is pretty important, probably overdue

The current version separates risks/tradeoffs by transparency vs. non-transparency

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

audibility at the wallet/transaction level, or at the network/supply level?

Supply auditing

Make it clear that a transparent ledger is not immune from bugs that could affect users, nor are non-transparent ledgers

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?)

IMO a hardness break is _extremely_ unlikely, and such a thing would probably affect general DL-based security (including Bitcoin keys)

I've come to dislike the hiding vs. binding discussion, because I think it too narrowly focuses the problem

Better, I think, to discuss in terms of practical risk

Transparency has a whole set of practical risks

Hardness breaks do too, but are balanced by being considered exceptionally unlikely

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

*user

e.g. Zcash says (correctly) that transparent migrations avoid supply inflation in particular pools, but honest users can still lose funds

or e.g. Bitcoin's inflation bug

or e.g. Monero's detectable key image bug

Undetectable inflation is another class of risk

But I'm having a hard time clearly delineating and differentiating these risk types

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

and that choosing a transparent asset does not guarantee safety of funds in all cases

i dont think a supply audit is about guaranteeing safety specifically is it?

it's about perfect knowledge of supply that is network symmetric (known to all nodes)

I think there's some relationship

Suppose you discover an inflation problem in a transparent asset; what happens next?

If you roll back, users can get screwed

so it becomes a verifiable characteristic of the asset in question, as apposed to a presumed characterstic

If you don't roll back, your supply has changed

And if anything, there could be a subset of risks that are "detectable but not yet detected"

Any ideas for the best way to present all this?

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

One of the keys to me is that, while it is a tradeoff, we view it as absolutely worth it for fungibility/privacy

Right; it's up to users to decide what their priorities are, and how that influences their choices

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

If people prefer the guarantee of eventually-detectable supply guarantees, then choose Bitcoin or something similar

Are you going to share about the difference between cryptographic bugs/issues and implementation bugs/issues?

as long as they understand the tradeoffs

And would absolutely love to see info/thoughts about turnstiles in there too as that affects any L2 implementation on Bitcoin like Liquid

You mean the difference between breaks in the cryptography itself, versus implementations?

yes

Like hardness assumption breaks? Yes

IMO that should not be the overriding concern

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

If someone can break DL, everyone is screwed

yeah

Including Bitcoin

Thats why I want to be sure it's clear that imp breaks are MUCH more likely

Your supply is guaranteed, but such an adversary can probably nab all funds by recovering keys

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"

The initial blag post draft tried to make it clear that implementation risks are way higher

Thats a common thread I see as a followup to auditability concerns

Sweet

I wouldn't call it complex... the code gets pretty hairy, but that's more a development thing

The math is pretty straightforward compared to something like Zcash

exactly :)

It's a middle point on the sliding scale

intentionally

Will be an incredibly important post, as auditability seems to be a huge sticking point for many people moving from bitcoin to Monero.

Well, and that's an entirely different tradeoff having to do with centralized trust

For sure

i.e. no trusted setup means you don't get full-anonymity-set transaction inputs

I'd love to take a look at the blog post draft if you don't mind/want another set of eyes on it

Or I should say, you don't get it with practical efficiency that's useable

^

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 ;-)

I don't like that comparison

Because

Current draft: gist.github.com/SarangNoether/6af1d93359a5279fb24d06655f13014f

fort3hlulz:

With Monero you DO have full transparency of emission-time supply

it was sort of a joke

oh sorry haha

this stuff gets me riled up

My current draft is a fork of sgp_'s version, which is a fork of my earlier version

it's not easy

It's blag posts all the way down =p

but, can i ask, doesn't MW include a supply audit at the cut through?

(if thats the correct terminology)

How so? They rely on balance through Pedersen commitment differences too

isn't their whole scheme based on a recurring supply audit?

AFAIK a Pedersen DL break would imply inflation

hang on, i will try and find a link that explains it

If something claims otherwise with detail, I'd like to read it

as i definitely can't

sarang sgp_ great work on that

Couldn't have said it any better, and a great quick read on the actual facts behind the choices involved

A+++ and easy for non-technical readers to grasp as well, I think

Now post it so I can share it broadly ;)

That version doesn't separate the discussion by risk type

and that's what I'd like to try next before posting anything

I think it could clarify the different tradeoffs even better

Tradeoffs of auditability/fungibility/privacy?

Or different implementations?

Tradeoffs in security/privacy/etc. and risk of inflation or fund loss

Which are not always neatly delineated by project/asset type

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

You can have detectable inflation flaws in transparent or non-transparent projects, for example (and we have real-world examples of this)

sarang: maybe start with an outline rather than a full rewrite?

So it's not like using Bitcoin magically makes you immune from all risks

yeah

comparing outlines is probably more useful than comparing completed blog posts

good point

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

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)

And I don't like how this point is sometimes glossed over in their discussions of supply soundness

It would be a huge deal in practice for users

I'd also like to add links with some supporting details

supporting links would be good

Hey suraeNoether. I know you are completing CSLAG, but I was just wondering if you got a chance to push the changes you have.

sgp_ and others... new draft: gist.github.com/SarangNoether/89a08ab5f9bd09350e653fb9b2e4e99b

Consider it still incomplete

Hopefully this provides more clarity about different types of risks and benefits

I removed the title's specific reference to Monero, since this question is more broadly applicable

Cool, will review

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)

Make a couple of minor edits for typos and clarity just now

Earlier versions are available via the revisions tab

On a similar note, this certainly qualifies as misleading twitter.com/least_nathan/status/1217528240664743936?s=19

Yep

That's why I specifically noted it in the post

It's technically correct, to a point

I noted "eventual supply consistency" to mean that a particular pool's supply can't be inflated through the migration

but that you risk getting your funds frozen

That might be the "various tradeoffs"

Oh yeah, he notes the possible harm to users in the next tweet

Although: it's tricky because the supply _within_ a shielded pool could absolutely suffer inflation in case of a soundness flaw

It's only the transitions that can catch this

Heh, which is noted here: twitter.com/least_nathan/status/1217826806121648128

Hmm, but I don't see how this can possibly be correct: twitter.com/least_nathan/status/1217829034807189505

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

I asked for clarification

I asked in a zcash dev chat as well

I think Nathan is mistaken here

But if not, I can somehow note this in the post

Regarding this, it'd probably be possible to modify the Monero protocol to do a similar kind of transparent migration: twitter.com/least_nathan/status/1217827459397144576

(but I think it's a really bad and dangerous idea to do so)

Any comments or suggestions on the new blag post, aside from checking on the transparent migration stuff?

reading now

+1 for using shenanigans in the post

Much better, and love all the source links now

nice job guys

Thanks

Any ETA on publishing?

I'd like additional feedback

Then I can do a site MR

sarang: added a few sentences back from the original gist.github.com/SamsungGalaxyPlayer/2e79e11a897a640e11da1394f60cf828

thoughts?

In the case of a direct cryptographic break on Pedersen commitments, no.

That sentence is a bit odd

in any remaining funds (including those of honest users) would be permanently frozen.

would be... that's a grammatical mistake

oh yeah, I copied it over incorrectly, give me a sec

sarang: I removed the one sentence

Any word on the Zcash migration question?

I haven't heard back on the dev chat

nope

I don't want to post without confirming that

sarang: confirming what, the requirement that t-addresses are necessary?

But I don't see how they can confirm value pools in a verifiably countable way without transparency

Yes

I think it's likely he is making that statement with some carefully-worded technicality and that your statements are also correct

but it's good to check

Yeah, and perhaps best to provide the Zcash team with the draft in advance, as a professional courtesy

I'd certainly appreciate it

let me message Nathan

I'm not suggesting asking for their approval, only a chance to correct any factual mistakes

sarang: can you please check my minor edits and re-approve? Then I'll send over

any remaining funds (including those of honest users) would be permanently frozen.

s/would be/being

Otherwise send it over and ask if they have any comments

Hopefully they appreciate it since it applies to them as well

I don't hear as much talk about Zcash commitments relating to supply compared to Monero

Their use of commitments is slightly different for efficiency reasons

But the same ideas apply

suraeNoether: you on IRC today?

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

Heck, you could do that in Monero too if you really, really wanted to (but let's not...)

why hasn't bitcoin implemented stealth addresses? they are pretty straightforward and just require 32 bytes per transaction (or is that too much lol)

an extra 32 bytes on every output, which are usually not even 32 bytes in size, would indeed be a lot

as would the ECDH computation required to receive things

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

sorry, i'm exaggerating, it's about 25 hours i think (400MM outputs total times a quarter second)

but syncing bitcoin currently takes only a few hours on a fast PC

wow didn't realize it was that substantial

there are ways to make it much faster but then you're into weird bikesheddy design territory

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

then wallets can skip the ecdh step for 1023/1024 of all outputs

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

and you'll never get a standard out of that because the whole thing is too ugly

doesn't really engender optimism about scaling both bitcoin and monero, albeit beating a dead horse there

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)

but things are getting better

multiple times a year there are new crypto breakthroughs which make the situation better. bulletproofs were huge

Or rather, not huge :D

is there an estimate of the upper limit to scaling improvements? is it just equivalent to Visa's servers?

as evidenced by snarks, which allow constant-time verificatino of arbitrarily complex statements, there appears to be no limit

though plausibly we would always need a trusted setup to achieve that

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

yep, and starks have had similar specs for a while

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

oh wait these let you -prove- in polylog time?

no no

prove is n log n

it's just that in recursion the verifier needs to be encoded as a circuit so need to be reasonably small

and they claim to have small enough verifiers to make recursion efficient

Has that been tested with any proofs-of-concept?

they have specs online

not sure if they have code, but i think they do

Link for the lazy?

Ah, I have seen the paper

starks have polylog verifiers

and admit efficient recursion

hm

then not sure why the stark ppl haven't made the same claims as these guys

i guess this depends on how big the constraint system encoding a verifier in stark arithmetization is

i mean, the stark ppl have made the same claims as you have here :)

i'd have to check the "related work" section to see a detailed comparison

must've missed it in their paper then

my understanding was that since starks don't use r1cs there's a hidden cost in their arithmetization

and even though asymptotically they get 'efficiency' in practice the cost is high

i don't see how anything that uses r1cs could have sublinear verification

because the verifier needs to read the whole r1cs circuit

but yes, i believe starks have high costs at setup time when converting a program to arithmetic form

that's done once at the beginning

they put this cost in the indexer

in marlin at least

and i think you can do even better by leveraging structure in the predicates

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

yeah i'm sure

this is also true of starks

but i don't know much detail about any of these schemes

too much to read

I think the way they got that structural improvement was through LDEs, which is different to starks

but would wait for the writeup

before getting too excited

the other upper bound in pairing based snarks is the 2adicity

Groth etc. (i.e. all the most efficient constructions) suffer from this

in practice it means you can only get a maximum sized predicate

at 80 bit security for recursion this is at 2^32 constraints in r1cs

but the good news is this isn't an issue in these newer types of snarks that don't use ECC