00:21:30 Has the monero research lab looked into PIR in some capacity? 00:22:24 I have been thinking about and researching PIR for over 9 months now and at my company we have a roadmap to attempt an implementation for 3 other blockchain systems and are deciding on a fourth 00:22:51 We are deciding between Monero and Zcash based on the funding available and have been following both projects for a few years now 00:23:48 Based on my experience in the Monero community, there is a higher chance and much better accountability around open-ended research projects that are funded by the Monero Community Funding System. 00:24:20 Currently Zcash's funding situation for project has been sketchy for years and it's not only gotten worst with the events of the past weekend. 01:01:17 lol. anybody who even gives zcash a 2nd thought isn't thinking clearly. 01:07:29 The tech is really good, especially halo 2. 01:07:43 I just don't think they care about security and privacy like Sarah says 01:08:22 mikerah[m]: I am not sure the value of PIR. If the goal is to reduce bandwidth for a wallet-centric node, it can't be easily done... because you have to download every single output anyway in order to scan for owned outputs. 01:08:46 Plus such a node may want to download all key images to check for double spends 01:09:24 Why couldn't the node do both? I.e. download all key images for double spends and enable Monero light clients to fetch the outputs that they own? 01:10:03 you have to compute a Diffie-Hellman exchange on every on-chain output to identify owned outputs 01:10:24 they can't be obtained remotely with any trivial approach 01:11:38 here is my attempt to sketch out a Monero light node: https://github.com/monero-project/research-lab/issues/69 01:18:00 unless I am misunderstanding something about what you want to accomplish... 01:29:39 "The tech is really good" "don't think they care about security and privacy" - these two statements are irreconcilable. the tech isn't as good as they say it is. 01:30:04 they would have to care a lot more about privacy for it to actually be that good. 01:30:59 when they launched in 2016 everyone was saying "the tech is really good" about zk-snarks too. it was a lie back then too. 01:31:46 the tech is pretty fancy at least 01:31:50 "fool me once, shame on you" 01:33:53 @hyc: What are your practical qualms about zk-snarks? Do you simply disagree with its instantiation in Zcash or are you skeptical of zk-snarks in general? 01:34:18 the trusted setup has always been a threat hanging over it, of course 01:34:50 but as a practical matter, it was unusable. Joe Average couldn't run it. exchanges couldn't afford the CPU resources to support Zaddrs 01:36:01 Halo and Halo 2 have improved upon the state of the art in recursive composition systems without trusted setups. The main goal was indeed to provide better privacy and security. However, the team's other actions surround it (namely pre-anouncing Orchard and claiming that it can be finished by June 2021) is an example of not really caring about both of those things 01:36:01 considering that it's a new system that hasn't even been peer-reviewed yet! 01:36:45 is that so different from when they launched with zk-snarks? over-promise, under-deliver 01:36:53 launch with poorly understood tech 01:37:11 But in general, there are applications that use zk-snarks that are usable. The main reasonable it's hard to run Zcash is based on their protocol and the circuits needed in a SNARK to implement it. 01:37:47 that's just a lame excuse. the system they launched couldn't deliver what they promised. 01:37:53 that's the bottom line. 01:38:38 the poor quality coding is just ... icing on the top 01:39:18 I'm what I'm thinking is highly dependent on where PIR is used. I'm thinking that light nodes would use PIR to request those outputs and then find some way to do a local decryption. But as you say, since that local decryption is already being done, what's the point of PIR? 01:40:13 the problem is they have to get _all the outputs_ 01:40:23 that's unavoidable, yes 01:41:13 there are no shortcuts. if there was a way to accelerate identifying which outputs are of interest to you, then that means there's a way to trace all outputs. 01:41:39 If I recall correctly, Zerocash and Zerocoin were accepted at highly regarded cryptography conferences/journals and the initial Zk-snarks scheme they used was peer-reviewed as well. So, the academic community understood the tech well. It's main the OSS communities that didn't and still don't 01:42:23 Zerocoin was accepted and *abandoned* by the zerocash team, to develop the zerocash protocol. zerocoin isn't worthy of any further mention. 01:42:40 I only mentioned for completeness 01:42:45 * I only mentioned it for completeness 01:43:58 as for the OSS communities not understanding it - the zerocash paper was written in 2014 and they claimed it to already have production-ready code. 01:44:12 http://zerocoin.org/talks_and_press 01:44:24 "In Zerocash, transactions are less than 1 kB and take under 6 ms to verify — orders of magnitude >more efficient than the less-anonymous Zerocoin " 01:44:41 yet it still took them until 2016 to launch, with much worse real world performance 01:44:53 are you telling me the OSS community had to reimplement it from scratch? 01:45:05 why did it take 2 years if they already had such a good existing implementation? 01:45:30 or maybe, just maybe, the stuff the academics had peer-reviewed didn't actually work as well as they claimed? 01:46:29 Calling the ECC the OSS community is wrong. They were the ones that implemented the new stuff not open source devs. A lot of the early OSS devs left because they were being ignored. 01:47:07 ok. 01:47:16 This is way more common than you would think. The incentives of academia, especially in CS, is to publish a lot and have code that does the basics in terms of benchmarking and then never open source the code. 01:47:24 either way, that whole "ecosystem" is garbage 01:47:57 Have you seen: https://github.com/arkworks-rs 01:48:25 yes that's common in academia, and it's a crime. research that's unreproducible. what kind of peer-review is that 01:49:29 Anyway, UkoeHB__ Do you have any other resources on what the current light node infra is in Monero? I would like to take a deeper look 01:49:36 hm, a collection of primitives? is anyone using it for production work? 01:51:08 you're going to have to tweak your terminology. light node doesn't make a lot of sense, I think you mean light wallet? 01:52:27 I use light node and light client interchangably. Light wallet is different. Light wallets depend on a light node to provide a storage and bandwidth efficient interface to a full node (or sets of full nodes) 01:53:06 ok 01:53:13 there isn't really a "light node" per se, although there are pruned nodes, which can function as nodes for light wallets 01:53:30 chops blockchain size on disk from 90 GB to 30 GB or so 01:54:47 btw pruning was a misnomer, it's actually sharding. "pruned" nodes discard 7/8 of the chain data 01:55:01 Don't think so. The folks that I know who are using zk-snarks in production simply write their own libraries or fork the zcash libraries 01:55:30 By sharding, do you mean DB sharding? 01:55:46 it's not implemented in the DB engine 01:55:50 but it is sharding 01:56:04 across a random set of 8 nodes you will get the complete blockchain 01:56:44 each of those "pruned" nodes carries a disjoint 1/8th slice of the whole 01:59:47 Is there a mechanism by which they decide which 1/8 to keep? 02:00:07 when you enable pruning it randomly selects which slice 02:00:48 there is no coordination across the network. we just rely on the PRNGs to give a uniform distribution across the network 02:08:51 I think since users have to download all the outputs anyway there isn't much interest in a 'light node' which only validates headers 02:11:13 So for Monero's usecase, finding a way to efficiently download and verify which outputs a light wallet owns is more important than enabling light wallets to query full nodes privately? 02:11:40 It would be nice to have a set of open research/implementation questions that Monero has. 02:11:46 I'd say yes 02:12:09 there is https://github.com/monero-project/research-lab/issues 02:12:11 what do you mean "query full nodes privately" ? 03:08:07 So, think of a blockchain like bitcoin or ethereum that are transparent. Private queries in that case means that full nodes will not be able to tell what blocks you are interested in. All they would do is simply answer your query using some PIR protocol 03:08:53 In the case of monero, everything is hidden by default. So, privately in this context is a bit murky as UkoeHB__ has said 18:03:03 Look on the bright side. At least you don't need to obsess over signs of life from FUK now.