no, although my idea here monero-project/research-lab #69 is similar; you'd want to store full copies of recent blocks I imagine

curious how that is different / better than the existing pruning / striping approach?

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

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

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.

Or rather, between a light node and using a remote node

the problem with requesting the rest on the fly is that you need to get old TXOs to make a transaction

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

since it isn't in that retrieved set

so you *need* to store the txoset

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

but that would just cut down storage requirements, not bandwidth

and frankly bandwidth is cheap, storage is not

sorry other way around

storage is cheap, bandwidth is not

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

of course, if you want to verify blocks there is no way around downloading the entire chain

branch not root*

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?

imo, you can't have B without A, so A is the primary

yeah that's true

but we haven't really pulled wallet2 out into a proper wallet lib that can do anything except connect to a remote node

I think there would have to be a LOT of refactoring for that to be feasible

(where a wallet can be a first class citizen on the network, I mean)

You don't really want that. The node is on the network. The wallet is a view/manipulator for the node.

Or you end up merging the two, and you've got lots more attack surface.

Actually, thinking about a process running both a node and a wallet tickles my curiosity...

Hello all

More security model stuff today

Zcoin released a new version of their Lelantus preprint that I just saw; they overhauled its security model, which may be of interest

Looks like they didn't revise the IACR version, but here is the version to which I'm referring: zcoin.io/papers/lelantusv2.pdf

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.

kinda like how electrum is a separate thing

OK, so I think the linkable anonymity proof in CLSAG won't require a reversion to the underlying hardness assumption

I was stuck on part of the proof that the reviewers wanted changed, and I think it works out better than expected!