00:50:14 no, although my idea here https://github.com/monero-project/research-lab/issues/69 is similar; you'd want to store full copies of recent blocks I imagine 03:00:26 curious how that is different / better than the existing pruning / striping approach? 03:15:22 With the current method you only get down to 1/3rd of the full chain, but my light node can go much further and can even be ~O(1) instead of O(n). 03:16:08 Of course you make a lot of sacrifices and can no longer act as a full node that serves the network with data on request 03:17:09 But if the difference is between having a light node and no node at all, as it would be for most users, then it's a step up for network security. 03:17:46 Or rather, between a light node and using a remote node 06:20:34 the problem with requesting the rest on the fly is that you need to get old TXOs to make a transaction 06:21:01 even if you request a thousand TXOs from a node, and use some of them in your tx, your real TXO is going to stick out like a sore thumb 06:21:07 since it isn't in that retrieved set 06:21:17 so you *need* to store the txoset 06:21:49 arguably we could cut the txoset down to a random 1/4 (rolling, based on the current distribution selection algo) and you can use that to build txs 06:22:03 but that would just cut down storage requirements, not bandwidth 06:22:09 and frankly bandwidth is cheap, storage is not 06:22:17 sorry other way around 06:22:21 storage is cheap, bandwidth is not 11:44:11 it's cheaper in bandwidth than a full node which downloads signatures and range proofs for every transaction; a light node only needs the prunable Merkle roots, supposedly like an SPV node in bitcoin 11:44:48 of course, if you want to verify blocks there is no way around downloading the entire chain 11:50:01 branch not root* 12:52:39 right, for me this gets to the persistent question - what is the purpose of the monero core software? To (A) create, secure, and maintain the monero network? Or to (B) provide user access to the monero network? 12:52:47 imo, you can't have B without A, so A is the primary 13:06:28 yeah that's true 13:06:53 but we haven't really pulled wallet2 out into a proper wallet lib that can do anything except connect to a remote node 13:07:05 I think there would have to be a LOT of refactoring for that to be feasible 13:07:20 (where a wallet can be a first class citizen on the network, I mean) 13:15:47 You don't really want that. The node is on the network. The wallet is a view/manipulator for the node. 13:16:06 Or you end up merging the two, and you've got lots more attack surface. 13:26:41 Actually, thinking about a process running both a node and a wallet tickles my curiosity... 13:52:00 Hello all 13:52:05 More security model stuff today 13:52:54 Zcoin released a new version of their Lelantus preprint that I just saw; they overhauled its security model, which may be of interest 13:54:26 Looks like they didn't revise the IACR version, but here is the version to which I'm referring: https://zcoin.io/papers/lelantusv2.pdf 16:24:33 im not versed enough regarding libs etc.... but in general, i think if there are any further light wallets efforts made, it should be a standalone thing, like a sidecar. 16:29:13 kinda like how electrum is a separate thing 22:04:10 OK, so I think the linkable anonymity proof in CLSAG won't require a reversion to the underlying hardness assumption 22:04:34 I was stuck on part of the proof that the reviewers wanted changed, and I think it works out better than expected!