Was posted here before I think, but figured it wouldn't hurt to post again

May inspire some ideas

Thanks for sharing that :) Pretty cool stuff they're doing

My biggest concern is distinguishability of transactions causing some issues, and the whole Chainlink/oracle portion

But cool to see their idea come to fruition on a Monero-chain

Interesting application of CLSAG, for sure

We mentioned exchange rates in the original version of the preprint

Haven was the project that had contacted me about that aspect of CLSAG math

I'll have to take a look at the code they link to see if that's what they have finished implementing, or if it's something else

fort3hlulz: if they're using the CLSAG-based exchange method invented in the original preprint, what non-uniformity are they introducing?

It's still visible if a transaction is merely XHV, or if it's an exchange transaction

The whole point of our construction is that amounts are still hidden during the exchange

so wouldn't you end up with two "pools" of anonymity/TX type?

Yes for sure

Amounts are hidden, but the transactions still stand out as exchange TXs

It's not clear to me if this is in fact the method they are using

No, not necessarily

One method, the one we built in CLSAG, uses two separate commitments within each output

and whether or not a transaction actually "moves value" is hidden

That should be the new code

It's worth noting that this part of the preprint remains entirely unreviewed; we removed it from later drafts in order to focus the preprint on the basic security model

But again, not clear if this is the method they're using

The current CLSAG audit won't be reviewing that application

explorer.stagenet.havenprotocol.org if you want to view the transactions

The stagenet is the current place where exchanges are happening

ok

It's blocked on my work network so I can't dig into it right now lol

I'll take a look at the code and see if I can determine what method they decided to use

I'm just speculating here based on some questions their team had on how the CLSAG math/code worked

sweet, obviously no pressure but I'm always curious for your thoughts :)

On the CLSAG-exchange method? I'm a coauthor on its preprint, so I think it's pretty nifty =p

yeah :D

But AFAIK nobody has/had yet implemented it outside of proof-of-concept stuff

If it's the method they used, I hope they seek external review

I had advised this when they asked, since the method could be flawed

We listed it as a side application, but did not study it in detail

Looks like they do have CLSAG functions in the code

and they look to be essentially unchanged from the Monero code that's currently under review

Along with some extra functionality to handle confidential multiple asset types

Hmm, separate range proofs though, if I'm reading it correctly

If they can establish a common range requirement, they could aggregate those and save a ton of space

probably at the expense of a bit more complex logic

I wonder if/how they adjust the fee structure to account for this

sarang: Would it be worthwhile to spin this part into a new paper that can be reviewed separately?

It certainly could

A full treatment would require a new security model, which would itself be interesting

Since now you have an added goal of ensuring proper soundness of value across the asset commitments

There's always the question of how to set the exchange rate, which this project appears to be doing via some kind of pricing oracle

That rate can't inherently be handled by the cryptography; it has to come from somewhere, whether fixed in the protocol or via an external source (and that would be outside the security model)

Yes, it basically does not solve the oracle problem

they are pulling pricing from feeds.chain.link

In what way?

Is that a single-source point of failure?

exchange rates

not sure how they call it a "decentralized" oracle service

No, I mean suppose that service were compromised

Is it the only source of rate data?

it seems so

I see

I further wonder how the network verifies the rates of previous transactions were correct

Does the oracle need to be available for historical data forever?

"We plan to add additional decentralized pricing oracles in the future"

Or do verifiers assume that accepted transactions used a valid oracle?

I know very little about the use of price oracles in practice

I have so many questions

it is a single point of failure

I mean for past transactions

Suppose in a year, I want to spin up a Haven node

My client needs to verify transactions

It sees that transactions have an exchange rate

How does it know whether or not that rate was valid at that time?

Does it need to query the oracle for historical data?

Or does it assume that the transaction is deep enough into the chain that it "must be" correct?

To be fair, Monero clients make assumptions relating to old range proofs (they aren't checked by default, but _absolutely_ can be on request)

If you need historical data and the oracle doesn't do this for whatever reason, then you have to trust the chain alone and can't verify externally

Maybe this is considered an acceptable risk; I dunno

o_0

looks very hacky

Looks like it pulls historical price data directly from them: github.com/haven-protocol-org/haven…note_core/blockchain.cpp.patch#L696

That seems very risky

depending on their trust model

Also looks to ignore this unless a "full mode" is enabled: github.com/haven-protocol-org/haven…note_core/blockchain.cpp.patch#L711

Which isn't necessarily a big risk on its own

This is basically what Monero does for pre-bulletproofs range verification

it doesn't verify historical price darta

*data

?

it just assumes it was correct at the time

Did I misread?

"why would a miner lie to us"

oh wait you're correct

sorry I'm reading backlog down

so then it's still SPF

My understanding is that "full mode" uses the historical oracle

Historical Oracle would be a great band name

lol

yeah

or a Dr. Seuss book

will fund

Anyway, dEBRUYNE asked if it's worth writing a paper that elaborates the exchange idea that suraeNoether and RandomRun and I included in our early CLSAG drafts... the reason we didn't do that already is because it assumes some kind of exchange data that we assumed would not be acceptable for the Monero use case

I am certainly interested from an academic perspective

Any results of the CLSAG audit should _not_ be taken to mean any kind of review of this exchange idea, which is not in the most recent preprint version and is not being audited in any way

We don't make any claims about the security of the exchange idea

It could be safe; it could also be very flawed

It'd make a cool separate preprint :)

I have an idea for a security model that I suspect would be easy to build into security proofs with Triptych

more complex for CLSAG (which doesn't share the same properties that Triptych does as a zkp system)

Can't the exchange rate be something like... Alice says <= x, Bob, says >= y, the protocol accepts any compatible constraint and uses (x+y)/2 ? No need for oracle then, it's by mutual agreement.

(It does require x and y to be public, but a public rate oracle is also public)

Protocol can do whatever it wants... but Alice and Bob could collude and build whatever they like, which seems like a bad idea

Why would it be a bad idea ?

I *assume* this is about an exchange protocol. We *want* Alice and Bob to collude, no ?

decentralized oracles don't seem to solve the problem of decentralized prices to me. They seem to simply change the trust from one person to another, which in many cases seems unnecessary to me, or isn't really an improvement. But "decentralized" prices are sexy I guess

the way I think about decentralised oracles is that I'd maybe trust them if it was like 50+ academic institutions / non-profits around the world

but most of the decentralised oracle experiments are based on "we'll pay you not to lie" which seems more like "we'll pay you not to lie unless a better offer comes along"

It feels similar to the idea of "trusted setup"

where you rely on some level of non-collusion

and honesty

yes

which might be fine for coffee-grade transactions, I dunno

All comes down to your trust/risk model

is the TL; DR; that haven stablecoin is a pipe dream?

IMO it's all relative to your risk model

If you're cool with their idea of a price oracle, it may be suitable for you

If you are not, then it may not be

Same with things relating to trusted setups... if you're willing to offload that risk, it may be ok for you

Same with things relating to supply auditing

etc.

All designs imply risk

"enter Sarang Noether" sounds so badass

I had also hypothesized that coinbase spend-age distribution patterns would differ from non-coinbase

Also worth noting that there's no a priori expectation (AFAIK) that suggests the spend distributions _should_ be gamme distributions

they just happen to agree

s/gamme/gamma

good bot

Has anyone investigated the verification hit for doing a coinbase-only ring check during sync?

sgp_: your comments here still valid? wownero/wownero #101

The current selection algorithm no longer selects coinbase outputs "too often" relative to other outputs as it used to

The selection algorithm takes block density into account

It was addressed after some observations that the Miller method was non-optimal as originally presented

Well, "too often" imo = "one or more"

?

I only mean in terms of block density

You can probably ignore the comment on 12/27

What is a coinbase-only ring check ?

A hypothetical consensus rule that a ring may contain either (a) only coinbase outputs; or (b) only non-coinbase outputs

wowario[m]: the more elegant consensus rule is simply "rings can either be all-coinbase or all-no-coinbase"

I've expressed my concern previously about this

When spending from a wallet, if spending coinbase, select all coinbase for that ring. If not spending coinbase, then don't select any coinbase for that ring

The consensus rule enforces this wallet behavior

If coinbase-only rings will stick out anyway, perhaps their ring size could be made higher

The marginal benefit of this is unknown

AFAIK the extent of plausible deniability has not been formally tested

scoobybejesus: I've definitely thought about this, but it's tough when most pool hashrate doesn't care and makes info public anyways

Such a test could be made to have negligible extra runtime, if we change the db to store an extra byte per output.

It used to be so visible you'd need ringsize 45 to protect the real input with at least 1 non-discernable decoy 99% of the time

It currently stores 2 keys and 2 64 bit values, so... 80 bytes, for comparison.

We could also cheat and store height on 63 bits. No extra size, but some juggling in various places.

adding 1 byte would be awkward, breaking data alignment in the DB

Haven.. how in the world would an exchange rate develop if the amount of coins you receive is pegged to the exchange rate?! It's circular...

hyc the view tag idea would add 1 byte per tx monero-project/research-lab #73 does that seem like a problem?

not really a problem per se

but if current data values are 80 bytes, and keys are 8 or 32 bytes, then all data is currently perfectly 8-byte aligned, which helps performance

adding 1 byte to data will in fact add 2 bytes, because LMDB always keeps all records at least 2-byte aligned

Transactions are variable size already in the db. The per output tx is not.

ah yeah 1 byte per output

0_0

quite like the sound of zk-WIP

The improvement in size is intriguing, if it still retains the desired security properties

seems like a relatively marginal improvement? 2.5 KN -> 2.4 KB

s/KN/KB

What's QuisQuis?

It's an idea that came out of UCL (and possible collaborators) for a privacy-preserving account-based ledger

Meiklejohn et al., IIRC

Yep, UCL _and_ collaborators

also table 2 suggests this bulletproofs+ trades some verification time for faster prover time, which ideally I'd rather have the other way

I need to examine batch verification in greater detail

Single proof vs. batch proof is an important detail

is agg size batching?

I use the term "aggregation" to refer to generating a single proof demonstrating range on multiple commitments

and "batching" to refer to verification of multiple indendent proofs at the same time in a way that combines the computational complexity of common generators

They are not the same thing

Aggregation has size benefits

Batching has time benefits

It'd be interesting to see if that new method can do aggregation without power of 2.

Doesn't appear so

That's surprisingly subtle and tricky

it sounds like they shave off 96 bytes per proof; the initial claim is a bit misleading

I have at least one method, but it doesn't work as well as you'd like

also, our 2-out range proof is 736 bytes, which isn't listed on their table so I'm not sure how direct the size comparison is

Since dEBRUYNE posted to r/Monero: the usual disclaimer that preprint neither require nor expect any formal peer review

32x8 is 800 bytes, and our 4-out range proof is 800 bytes so maybe that's appropriate to look at

Anyone can submit a preprint; preprint server editors perform minimal editorial review that does not examine accuracy of results

(this seems to be an ongoing issue with "reporting" of technical material)

so at 4-out tx (according to their numbers): 12% size reduction from 800->704 bytes, and 0.8% verification increase for a single proof 4.51 -> 4.55 ms

although maybe the 64x series is more accurate.. anyway Ill stop typing :p

Post on r/Monero: reddit.com/r/Monero/comments/hbl0li…_shorter_proofs_for_privacyenhanced

I'm getting pretty sick and tired of terrible reporting on preprints

so I'll probably continue to increase my disclaimers on them whenever I see them

when you see "preprint", think "PDF that someone uploaded"

lol

"Google Drive for PDFs only"

-____-

Good preprint servers do a cursory editorial review, but only for apparent relevance

IACR does this

as does arXiv

but if you see "a study shows..." there's a _very_ good chance it's a preprint

and therefore shitty reporting

I have increasingly little patience for this poor reporting

"preprint" means neither "accurate" or "inaccurate"

why can't they just watermark the preprint with something like, I don't know "preprint"

would this matter in practice?

I've seen medical preprint archives have specific disclaimers and warnings for reports that appear to go unheeded

"a study" means absolutely nothing, apparently

Preprint archvies are a double-edged sword

They're of huge value to experts

and (IMO) huge risk to non-experts

Heck, even experts fall into the trap of assuming preprint results are correct without external verification

It's an easy trap to fall into

to be honest, I think it's a shit-show, but it seems a "thing". Instapost-research

well, presumably the reputational damage from publishing invalid results is enough to motivate some diligence in the authors

To be clear, I think having preprint archives is a benefit to research

If all research had to wait for peer review to be posted anywhere, there would be a large body of work that never sees the light of day

and not for specific lack of quality

"Just get accepted to a journal/conference" is highly nontrivial, and could take months or years

I _love_ that I can see up-to-date work as it's done

but you have to take it with a large spoonful of salt

no, I totally understand the benefit, but just wonder about how it weighs up against the negatives.

but it's frustrating to see reporting that does not appreciate the spectrum of the review process

like it's essentially just a message board for research. Which is great. But it is being read as a message board for knowledge.

Which is troublesome

This is not the fault of the preprint archives

Their acceptance criteria are easy to find

this is the fault of poor reporting

which is also easy to find

"Knows how to operate an FTP client"

It's come to the point where if I see a news article about "a study" without a direct link to the paper or preprint, I assume it's full of shit and ignore it

There is nothing more annoying these days then a reference without a source hyperlink.

addicted to the semantic web

Yeah, surely the internet has advanced to the point where a hyperlink is possible