13:31:12 <dEBRUYNE> https://twitter.com/HavenXHV/status/1273272339938107394
13:31:22 <dEBRUYNE> Was posted here before I think, but figured it wouldn't hurt to post again
13:31:25 <dEBRUYNE> May inspire some ideas
13:35:56 <fort3hlulz> Thanks for sharing that :) Pretty cool stuff they're doing
13:36:14 <fort3hlulz> My biggest concern is distinguishability of transactions causing some issues, and the whole Chainlink/oracle portion
13:36:26 <fort3hlulz> But cool to see their idea come to fruition on a Monero-chain
14:03:42 <sarang> Interesting application of CLSAG, for sure
14:03:51 <sarang> We mentioned exchange rates in the original version of the preprint
14:04:23 <sarang> Haven was the project that had contacted me about that aspect of CLSAG math
14:05:23 <sarang> 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
14:18:12 <sarang> fort3hlulz: if they're using the CLSAG-based exchange method invented in the original preprint, what non-uniformity are they introducing?
14:18:47 <fort3hlulz> It's still visible if a transaction is merely XHV, or if it's an exchange transaction
14:18:58 <sarang> The whole point of our construction is that amounts are still hidden during the exchange
14:19:01 <fort3hlulz> so wouldn't you end up with two "pools" of anonymity/TX type?
14:19:03 <fort3hlulz> Yes for sure
14:19:25 <fort3hlulz> Amounts are hidden, but the transactions still stand out as exchange TXs
14:19:27 <sarang> It's not clear to me if this is in fact the method they are using
14:19:32 <sarang> No, not necessarily
14:19:48 <sarang> One method, the one we built in CLSAG, uses two separate commitments within each output
14:20:08 <sarang> and whether or not a transaction actually "moves value" is hidden
14:20:28 <fort3hlulz> https://github.com/haven-protocol-org/haven-offshore
14:20:31 <fort3hlulz> That should be the new code
14:20:41 <sarang> 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
14:20:53 <sarang> But again, not clear if this is the method they're using
14:21:19 <sarang> The current CLSAG audit won't be reviewing that application
14:23:08 <fort3hlulz> https://explorer.stagenet.havenprotocol.org/ if you want to view the transactions
14:23:21 <fort3hlulz> The stagenet is the current place where exchanges are happening
14:23:36 <sarang> ok
14:23:39 <fort3hlulz> It's blocked on my work network so I can't dig into it right now lol
14:23:55 <sarang> I'll take a look at the code and see if I can determine what method they decided to use
14:24:15 <sarang> I'm just speculating here based on some questions their team had on how the CLSAG math/code worked
14:24:33 <fort3hlulz> sweet, obviously no pressure but I'm always curious for your thoughts :)
14:24:54 <sarang> On the CLSAG-exchange method? I'm a coauthor on its preprint, so I think it's pretty nifty =p
14:25:20 <fort3hlulz> yeah :D
14:25:30 <sarang> But AFAIK nobody has/had yet implemented it outside of proof-of-concept stuff
14:25:49 <sarang> If it's the method they used, I hope they seek external review
14:26:20 <sarang> I had advised this when they asked, since the method could be flawed
14:26:35 <sarang> We listed it as a side application, but did not study it in detail
14:34:45 <sarang> Looks like they do have CLSAG functions in the code
14:35:04 <sarang> and they look to be essentially unchanged from the Monero code that's currently under review
14:35:17 <sarang> Along with some extra functionality to handle confidential multiple asset types
14:35:57 <sarang> Hmm, separate range proofs though, if I'm reading it correctly
14:36:16 <sarang> If they can establish a common range requirement, they could aggregate those and save a ton of space
14:36:35 <sarang> probably at the expense of a bit more complex logic
14:36:45 <sarang> I wonder if/how they adjust the fee structure to account for this
14:42:42 <dEBRUYNE> sarang: Would it be worthwhile to spin this part into a new paper that can be reviewed separately?
14:43:34 <sarang> It certainly could
14:43:47 <sarang> A full treatment would require a new security model, which would itself be interesting
14:44:22 <sarang> Since now you have an added goal of ensuring proper soundness of value across the asset commitments
14:45:08 <sarang> 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
14:45:39 <sarang> 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)
15:41:03 <dEBRUYNE> Yes, it basically does not solve the oracle problem
16:03:04 <wowario[m]> they are pulling pricing from https://feeds.chain.link
16:03:45 <sarang> In what way?
16:03:56 <sarang> Is that a single-source point of failure?
16:04:11 <wowario[m]> exchange rates
16:04:52 <wowario[m]> not sure how they call it a "decentralized" oracle service
16:05:27 <sarang> No, I mean suppose that service were compromised
16:05:34 <sarang> Is it the only source of rate data?
16:05:38 <wowario[m]> https://oracle.havenprotocol.org
16:05:52 <wowario[m]> it seems so
16:06:18 <sarang> I see
16:06:47 <sarang> I further wonder how the network verifies the rates of previous transactions were correct
16:06:58 <sarang> Does the oracle need to be available for historical data forever?
16:06:58 <wowario[m]> https://medium.com/@havencurrency/haven-launching-xusd-on-july-20th-856b04c62065
16:07:06 <wowario[m]> "We plan to add additional decentralized pricing oracles in the future"
16:07:14 <sarang> Or do verifiers assume that accepted transactions used a valid oracle?
16:07:43 <sarang> I know very little about the use of price oracles in practice
16:08:29 <sarang> I have so many questions
16:08:34 <wowario[m]> it is a single point of failure
16:08:44 <sarang> I mean for past transactions
16:08:52 <sarang> Suppose in a year, I want to spin up a Haven node
16:08:58 <sarang> My client needs to verify transactions
16:09:04 <sarang> It sees that transactions have an exchange rate
16:09:18 <sarang> How does it know whether or not that rate was valid at that time?
16:09:26 <sarang> Does it need to query the oracle for historical data?
16:09:40 <sarang> Or does it assume that the transaction is deep enough into the chain that it "must be" correct?
16:10:19 <sarang> To be fair, Monero clients make assumptions relating to old range proofs (they aren't checked by default, but _absolutely_ can be on request)
16:10:49 <sarang> 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
16:11:04 <sarang> Maybe this is considered an acceptable risk; I dunno
16:13:59 <wowario[m]> https://github.com/haven-protocol-org/haven-offshore/blob/32d8d21b52866c7b766832bcaae2ea64d73c518b/patches/src/cryptonote_core/blockchain.cpp.patch#L683
16:14:58 <sarang> o_0
16:15:06 <wowario[m]> looks very hacky
16:15:31 <sarang> Looks like it pulls historical price data directly from them: https://github.com/haven-protocol-org/haven-offshore/blob/32d8d21b52866c7b766832bcaae2ea64d73c518b/patches/src/cryptonote_core/blockchain.cpp.patch#L696
16:15:36 <sarang> That seems very risky
16:15:41 <sarang> depending on their trust model
16:16:15 <sarang> Also looks to ignore this unless a "full mode" is enabled: https://github.com/haven-protocol-org/haven-offshore/blob/32d8d21b52866c7b766832bcaae2ea64d73c518b/patches/src/cryptonote_core/blockchain.cpp.patch#L711
16:16:35 <sarang> Which isn't necessarily a big risk on its own
16:16:52 <sarang> This is basically what Monero does for pre-bulletproofs range verification
16:17:12 <fluffypony> it doesn't verify historical price darta
16:17:13 <fluffypony> *data
16:17:17 <sarang> ?
16:17:19 <fluffypony> it just assumes it was correct at the time
16:17:21 <sarang> Did I misread?
16:17:25 <fluffypony> "why would a miner lie to us"
16:17:35 <fluffypony> oh wait you're correct
16:17:40 <fluffypony> sorry I'm reading backlog down
16:17:55 <fluffypony> so then it's still SPF
16:17:55 <sarang> My understanding is that "full mode" uses the historical oracle
16:18:03 <sarang> Historical Oracle would be a great band name
16:18:41 * sarang goes to start a band
16:18:58 <fluffypony> lol
16:18:59 <fluffypony> yeah
16:19:00 <fluffypony> or a Dr. Seuss book
16:19:06 * fluffypony goes to write a book
16:20:34 <sarang> will fund
16:22:12 <sarang> 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
16:22:24 <sarang> I am certainly interested from an academic perspective
16:23:09 <sarang> 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
16:23:20 <sarang> We don't make any claims about the security of the exchange idea
16:23:30 <sarang> It could be safe; it could also be very flawed
16:27:16 <sarang> It'd make a cool separate preprint :)
16:27:42 <sarang> I have an idea for a security model that I suspect would be easy to build into security proofs with Triptych
16:28:04 <sarang> more complex for CLSAG (which doesn't share the same properties that Triptych does as a zkp system)
16:29:14 <moneromooo> 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.
16:30:39 <moneromooo> (It does require x and y to be public, but a public rate oracle is also public)
16:30:45 <sarang> Protocol can do whatever it wants... but Alice and Bob could collude and build whatever they like, which seems like a bad idea
16:31:06 <moneromooo> Why would it be a bad idea ?
16:31:50 <moneromooo> I *assume* this is about an exchange protocol. We *want* Alice and Bob to collude, no ?
16:33:03 <sgp_> 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
16:40:10 <fluffypony> 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
16:40:45 <fluffypony> 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"
16:41:58 <sarang> It feels similar to the idea of "trusted setup"
16:42:06 <sarang> where you rely on some level of non-collusion
16:42:09 <sarang> and honesty
16:42:58 <fluffypony> yes
16:42:59 <fluffypony> which might be fine for coffee-grade transactions, I dunno
16:43:38 <sarang> All comes down to your trust/risk model
17:40:35 <Inge-> is the TL; DR; that haven stablecoin is a pipe dream?
17:41:12 <sarang> IMO it's all relative to your risk model
17:41:21 <sarang> If you're cool with their idea of a price oracle, it may be suitable for you
17:41:25 <sarang> If you are not, then it may not be
17:42:02 <sarang> Same with things relating to trusted setups... if you're willing to offload that risk, it may be ok for you
17:42:13 <sarang> Same with things relating to supply auditing
17:42:14 <sarang> etc.
17:42:20 <sarang> All designs imply risk
17:44:23 <sgp_> https://twitter.com/JEhrenhofer/status/1273672780660293632
17:46:30 <sarang> "enter Sarang Noether" sounds so badass
17:49:07 <sarang> I had also hypothesized that coinbase spend-age distribution patterns would differ from non-coinbase
17:50:13 <sarang> Also worth noting that there's no a priori expectation (AFAIK) that suggests the spend distributions _should_ be gamme distributions
17:50:19 <sarang> they just happen to agree
17:50:27 <sarang> s/gamme/gamma
17:50:27 <monerobux> sarang meant to say: Also worth noting that there's no a priori expectation (AFAIK) that suggests the spend distributions _should_ be gamma distributions
17:50:30 <sarang> good bot
17:55:23 <sarang> Has anyone investigated the verification hit for doing a coinbase-only ring check during sync?
17:56:13 <wowario[m]> sgp_:  your comments here still valid? https://github.com/wownero/wownero/issues/101
17:57:15 <sarang> The current selection algorithm no longer selects coinbase outputs "too often" relative to other outputs as it used to
17:57:28 <sarang> The selection algorithm takes block density into account
17:58:26 <sarang> It was addressed after some observations that the Miller method was non-optimal as originally presented
18:00:45 <sgp_> Well, "too often" imo = "one or more"
18:01:13 <sarang> ?
18:01:23 <sarang> I only mean in terms of block density
18:01:26 <sgp_> You can probably ignore the comment on 12/27
18:01:50 <moneromooo> What is a coinbase-only ring check ?
18:02:21 <sarang> A hypothetical consensus rule that a ring may contain either (a) only coinbase outputs; or (b) only non-coinbase outputs
18:02:23 <sgp_> wowario[m]: the more elegant consensus rule is simply "rings can either be all-coinbase or all-no-coinbase"
18:02:39 <sarang> I've expressed my concern previously about this
18:03:17 <sgp_> 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
18:03:36 <sgp_> The consensus rule enforces this wallet behavior
18:08:26 <scoobybejesus> If coinbase-only rings will stick out anyway, perhaps their ring size could be made higher
18:09:43 <sarang> The marginal benefit of this is unknown
18:10:16 <sarang> AFAIK the extent of plausible deniability has not been formally tested
18:13:04 <sgp_> scoobybejesus: I've definitely thought about this, but it's tough when most pool hashrate doesn't care and makes info public anyways
18:14:21 <moneromooo> Such a test could be made to have negligible extra runtime, if we change the db to store an extra byte per output.
18:14:48 <sgp_> 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
18:15:07 <moneromooo> It currently stores 2 keys and 2 64 bit values, so... 80 bytes, for comparison.
18:15:31 <moneromooo> We could also cheat and store height on 63 bits. No extra size, but some juggling in various places.
18:16:52 <hyc> adding 1 byte would be awkward, breaking data alignment in the DB
18:18:30 <UkoeHB_> 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...
18:24:14 <UkoeHB_> hyc the view tag idea would add 1 byte per tx https://github.com/monero-project/research-lab/issues/73 does that seem like a problem?
18:25:40 <hyc> not really a problem per se
18:26:07 <hyc> 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
18:26:31 <hyc> adding 1 byte to data will in fact add 2 bytes, because LMDB always keeps all records at least 2-byte aligned
18:27:18 <moneromooo> Transactions are variable size already in the db. The per output tx is not.
18:27:44 <UkoeHB_> ah yeah 1 byte per output
18:56:12 <sarang> https://eprint.iacr.org/2020/735
18:56:14 <sarang> 0_0
18:56:18 * sarang reads on...
19:08:50 <midipoet> quite like the sound of zk-WIP
19:09:54 <sarang> The improvement in size is intriguing, if it still retains the desired security properties
19:12:10 <sgp_> seems like a relatively marginal improvement? 2.5 KN -> 2.4 KB
19:12:20 <sgp_> s/KN/KB
19:12:20 <monerobux> sgp_ meant to say: seems like a relatively marginal improvement? 2.5 KB -> 2.4 KB
19:13:09 <sgp_> What's QuisQuis?
19:13:44 <sarang> It's an idea that came out of UCL (and possible collaborators) for a privacy-preserving account-based ledger
19:13:54 <sarang> Meiklejohn et al., IIRC
19:14:25 <sarang> https://eprint.iacr.org/2018/990
19:15:14 <sarang> Yep, UCL _and_ collaborators
19:17:16 <sgp_> also table 2 suggests this bulletproofs+ trades some verification time for faster prover time, which ideally I'd rather have the other way
19:18:52 <sarang> I need to examine batch verification in greater detail
19:19:02 <sarang> Single proof vs. batch proof is an important detail
19:20:33 <sgp_> is agg size batching?
19:21:04 <sarang> I use the term "aggregation" to refer to generating a single proof demonstrating range on multiple commitments
19:21:31 <sarang> 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
19:21:40 <sarang> They are not the same thing
19:21:56 <sarang> Aggregation has size benefits
19:21:59 <sarang> Batching has time benefits
19:22:12 <moneromooo> It'd be interesting to see if that new method can do aggregation without power of 2.
19:22:23 <sarang> Doesn't appear so
19:22:33 <sarang> That's surprisingly subtle and tricky
19:22:39 <UkoeHB_> it sounds like they shave off 96 bytes per proof; the initial claim is a bit misleading
19:22:40 <sarang> I have at least one method, but it doesn't work as well as you'd like
19:25:32 <UkoeHB_> 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
19:27:24 <sarang> Since dEBRUYNE posted to r/Monero: the usual disclaimer that preprint neither require nor expect any formal peer review
19:27:27 <UkoeHB_> 32x8 is 800 bytes, and our 4-out range proof is 800 bytes so maybe that's appropriate to look at
19:28:11 <sarang> Anyone can submit a preprint; preprint server editors perform minimal editorial review that does not examine accuracy of results
19:28:43 <sarang> (this seems to be an ongoing issue with "reporting" of technical material)
19:30:13 <UkoeHB_> 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
19:31:26 <UkoeHB_> although maybe the 64x series is more accurate.. anyway Ill stop typing :p
19:32:52 <sarang> Post on r/Monero: https://www.reddit.com/r/Monero/comments/hbl0li/bulletproofs_shorter_proofs_for_privacyenhanced/
19:32:52 <monerobux> [REDDIT] 'Bulletproofs+: Shorter Proofs for Privacy-Enhanced Distributed Ledger' (https://eprint.iacr.org/2020/735) to r/Monero | 5 points (100.0%) | 2 comments | Posted by dEBRUYNE_1 | Created at 2020-06-18 - 19:19:40
19:33:03 <sarang> I'm getting pretty sick and tired of terrible reporting on preprints
19:33:18 <sarang> so I'll probably continue to increase my disclaimers on them whenever I see them
19:33:34 <sarang> when you see "preprint", think "PDF that someone uploaded"
19:34:50 <sgp_> lol
19:34:58 <sgp_> "Google Drive for PDFs only"
19:35:19 <sarang> -____-
19:35:36 <sarang> Good preprint servers do a cursory editorial review, but only for apparent relevance
19:35:40 <sarang> IACR does this
19:35:45 <sarang> as does arXiv
19:36:00 <sarang> but if you see "a study shows..." there's a _very_ good chance it's a preprint
19:36:04 <sarang> and therefore shitty reporting
19:36:19 <sarang> I have increasingly little patience for this poor reporting
19:36:47 <sarang> "preprint" means neither "accurate" or "inaccurate"
19:38:15 <midipoet> why can't they just watermark the preprint with something like, I don't know "preprint"
19:39:06 <sarang> would this matter in practice?
19:39:31 <sarang> I've seen medical preprint archives have specific disclaimers and warnings for reports that appear to go unheeded
19:39:39 <sarang> "a study" means absolutely nothing, apparently
19:39:55 <sarang> Preprint archvies are a double-edged sword
19:40:01 <sarang> They're of huge value to experts
19:40:11 <sarang> and (IMO) huge risk to non-experts
19:40:45 <sarang> Heck, even experts fall into the trap of assuming preprint results are correct without external verification
19:40:50 <sarang> It's an easy trap to fall into
19:41:40 <midipoet> to be honest, I think it's a shit-show, but it seems a "thing". Instapost-research
19:41:58 <hyc> well, presumably the reputational damage from publishing invalid results is enough to motivate some diligence in the authors
19:42:03 <sarang> To be clear, I think having preprint archives is a benefit to research
19:42:24 <sarang> 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
19:42:30 <sarang> and not for specific lack of quality
19:42:54 <sarang> "Just get accepted to a journal/conference" is highly nontrivial, and could take months or years
19:43:07 <sarang> I _love_ that I can see up-to-date work as it's done
19:43:17 <sarang> but you have to take it with a large spoonful of salt
19:43:46 <midipoet> no, I totally understand the benefit, but just wonder about how it weighs up against the negatives.
19:43:55 <sarang> but it's frustrating to see reporting that does not appreciate the spectrum of the review process
19:44:23 <midipoet> like it's essentially just a message board for research. Which is great. But it is being read as a message board for knowledge.
19:44:32 <midipoet> Which is troublesome
19:45:15 <sarang> This is not the fault of the preprint archives
19:45:31 <sarang> Their acceptance criteria are easy to find
19:45:43 <sarang> this is the fault of poor reporting
19:45:46 <sarang> which is also easy to find
19:45:49 <moneromooo> "Knows how to operate an FTP client"
19:47:55 <sarang> 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
19:49:35 <midipoet> There is nothing more annoying these days then a reference without a source hyperlink.
19:50:00 <midipoet> addicted to the semantic web
19:50:47 <sarang> Yeah, surely the internet has advanced to the point where a hyperlink is possible