18:38:38 A bit overworked? Need a break and a good laugh - if you don't know it already: https://minaprotocol.com/ 18:38:40 https://masked.medium.com/the-coda-protocol-bbcb4b212b13 18:38:58 https://dev.to/librehash/mina-protocol-debunked-303c 21:24:40 rbrunner: the mina claims, and the 'debunking' article are both misleading. It is conceivable that you could make a blockchain proof saying 'this merkle root X represents a set of enotes assembled by a series of blocks with N cumulative difficulty', then make a tx with a proof that says 'the enotes spent by this tx are members of the set of enotes represented by merkle root X (and they haven't been spent before 21:24:41 [although this piece seems like it would be hard to add here])', then someone with the blockchain proof could validate the tx proof and be confident the tx spends enotes from the ledger. So basically validators don't need copies of every block or even the entire set of enotes in the ledger, they just need to monitor the miner network and maintain an up-to-date blockchain proof. It's not clear to me how advantageous that 21:24:41 would be though. You still need nodes that store all the enotes in the ledger so people can make membership proofs... 21:44:02 One thing that might be nice is if you could 'roll up' tx proofs into an existing blockchain proof that says all state-changes have been validated. So basically a block 'consumes' tx proofs to issue an updated blockchain proof + state changes that are valid according to the updated blockchain proof. Then tx proofs could be discarded without losing anything, a pretty significant space savings. Plus, synching a node from 21:44:02 scratch would be way cheaper because you'd just need to check the enote set and key images against the one blockchain proof. (maybe this is really what Mina and so on are trying to achieve; according to Mina you can at least hypothetically roll a blockchain proof across blocks so only one is needed at any given state of the chain). 21:51:41 the person behind this "librehash" account also made up nonsensical claim about monero in the past 21:54:14 Yeah I guess that would be a major scalability improvement, basically make the 'tx validation cost' a fixed cost for active miners who have to construct an updated blockchain proof. I do wonder how reorgs would be handled if the chain of block ids is not maintained. If there is a reorg, how do you figure out the point of divergence for purposes of balance recovery? 21:56:13 I suppose some tricks in the enote database would be enough. 23:52:33 Just a follow up on ZCash attack https://blockchair.com/zcash/charts/median-block-size The latest version is a maintenace attack that has been going for 6 days. The graph is best viewed on a 1 or 6 month scale 23:55:05 I find it interesting to follow this to get some insights as to how to further harden Monero 23:55:50 ArticMine: is this the first example of a fairly dedicated and impactful spam attack? 23:56:50 What is interesting here is that there has been no respite. So I am interested to see how long the attacker can keep this up 23:57:50 So it is different from the previous versions.