<c​haserene:matrix.org> there is a way, via recursive zero-knowledge proofs (and using a virtual machine for your blockchain that can be proved in such a way). what it does is whenever there is a state transition (block N -> block N+1), you can create a small, constant-sized proof. this small piece of data mathematically proves that this transition AND all previous transitions have not violated the block<clipped message>

<c​haserene:matrix.org> chain's rules. with a setup like this, you can take the proof at a given block height (even the most recent one), plus the state of the chain at that height (this would be the larger chunk of the data), and verify that that state is correct. this way you could full-sync a chain to the tip by downloading just those from the peers, no need for the history of the re-execution of it. <clipped message>

<c​haserene:matrix.org> the implementation is much more complex and AFAIK relies on cryptographic hardness assumptions that are less tried-and-tested than what Monero relies on. there is a live network called Mina that implemented it and is exploring how to make it more practical.

<c​haserene:matrix.org> *or the re-execution of it

<k​ayabanerve:matrix.org> jeffro256 Rucknium Following up on monero-project/monero #9023, if my work doesn't over-select yet always selects per the decoy, I'm fine, right?

<k​ayabanerve:matrix.org> And then regarding over-selection, as needed for privacy, I am fine if when I select 99 decoys per gamma, I always select `[0. . 15]` as the ones to use? If one errors, I'd move to use `[16]`?

<u​ntraceable:monero.social> matrix.monero.social/_matrix/media/…ero.social/BrcJAsSkjbtgbQjezXfKroeS

<u​ntraceable:monero.social> between blocks 3102598 and 3102606 were over 400kb in size (largest Monero blocks ever) and all contained just 5 to 6 146-input transactions paying about 0.0081 XMR per tx. Total of ~0.025 XMR ($3.66) in fees per block.

<u​ntraceable:monero.social> matrix.monero.social/_matrix/media/…ero.social/hIkGymnXRGMbUhSVanbuypHS

Someone wanted their consolidation to go through quickly

<m​onerobull:matrix.org> grafik.png

<m​onerobull:matrix.org> could binance withdrawals have something to do with this

<j​effro256:monero.social> Yes if you select exactly as many decoys as you will use to sign (even taking into account unlock times etc), then yeah you don't have to worry about this effect

<j​effro256:monero.social> Also yes: if you're going to over select, then you should try adding in the original selected order

<j​effro256:monero.social> That's what the code does in that PR: it overselects but retains the original picking order

<r​ucknium:monero.social> AFAIK, selecting the exact number of decoys will fail some of the time because you will select a locked output sometimes. `monerod` doesn't give the wallet info about locked outputs in the first selection step. So how does the Rust implementation of the Monero wallet do it?

<j​effro256:monero.social> You *could* select the exact amount of outputs if you downloaded information about lockedness at the same time as the output distribution, but AFAIK the daemon doesn't have an RPC endpoint for that. You could also do that while refreshing though

<r​ucknium:monero.social> Cache it in the wallet? Yes, but your restore height would have to be set to the block height of the first RingCT tx to be sure you didn't miss any locked outputs.

<j​effro256:monero.social> Or if you assume that the chain won't reorg 6 years deep, you could include a small static data file that lists non standard lock times in the past

<j​effro256:monero.social> Kinda like the checkpoints file

<a​leenor:matrix.org> oh, thank you for that. yeah I was gonna ask while reading it if this isn't what Mina is doing, but you answer it at the end

<a​leenor:matrix.org> that seems pretty damn cool, if there are no major downsides. do you know of any?

<r​ucknium:monero.social> aleenor: AFAIK, Mina has an interesting trick, but nodes would still have to keep most of the tx data like output public keys and amounts, assuming safe, realistic use. Without it, wallets have to store that data themselves. A corrupted local wallet file would lose its coins forever. No way to recover with a seed phrase. And wallets would have to stay connected to the internet to <clipped message

<r​ucknium:monero.social> receive coins. Isn't that correct? Nodes could probably delete some signature data like Monero's pruned blockchain mode.

<s​yntheticbird:monero.social> Couldn't a middle ground exist where a zk proof is generated every 300GB state. That would let a reasonable amount of time for people to sync, get their inputs, backup their local wallet file and be prepared for the next state. Tho I assume generating a recursive zk proof over 300GB of data might be expensive for consumer-grade hardware.

<m​onerobull:matrix.org> >corrupted local wallet file would lose its coins forever

<m​onerobull:matrix.org> this just doesnt fly

<m​onerobull:matrix.org> chainsize is not an issue and every proposed "fix" so far has terrible trade-offs

<m​onerobull:matrix.org> thorchain migrated tokens from one network to the other with 3 years notice

<m​onerobull:matrix.org> and yet i know a guy that lost 11 million USD when the day came

<m​onerobull:matrix.org> as well as countless others who "left crypto during the bearmarket"

<m​onerobull:matrix.org> forcing people to move coins or else loose them in order to save a few hundred GB of data in times where storage is mega cheap is not something you should do

<e​ndor00:matrix.org> Is there a way to see if any outputs from the first version of Monero (before the v2 hardfork) are still unspent (or if we can establish a method to check how many transactions they show up in, or if they have been upgraded to a newer output type after the fork)

<e​ndor00:matrix.org> For example, transactions with a ring size of 1 are known spends, right? So those can already be crossed out

<e​ndor00:matrix.org> And building from there, we might be able to get to a point where we can say something like: "We are 99.995% sure that all v1 outputs have been spent, and we consider that a reasonably acceptable risk"

<e​ndor00:matrix.org> And maybe even estimate the Monero value of the "unsure" outputs, to get an idea of the potential impact/damage

<e​ndor00:matrix.org> (And also see if any outputs from that time have definitely not been spent, ever)

<r​ucknium:monero.social> Probably the Dulmage-Mendelsohn decomposition is best for this: moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=39

<r​ucknium:monero.social> And for the 🦀s, this implementation is written in Rust!

<r​ucknium:monero.social> But the amount of data that could be deleted is probably small.

<e​ndor00:matrix.org> If I'm reading page 19 correctly (of the published paper), there are ~18.8M pre-ringct rings, of which ~12.2M have 0 mixins, i.e. ring size 1, so they are known spends

<b​oog900:monero.social> v1 outputs have to be spent in rings with outputs that all have the same amount.

<b​oog900:monero.social> So you could count the number of v1 outputs with a certain amount and then count the amount of tx inputs with rings of that amount, then to get the amount of unspent outputs with that amount you would just get the difference between the 2. Then just repeat with all different output amounts to get the total value of all unspent v1 outputs.

<e​ndor00:matrix.org> The secons biggest contributor is ring size 3 (2 mixins) with 1.779M/2.941M (60%) traced outputs, according to the paper

<e​ndor00:matrix.org> Then there's ring size 4 and size 2

<e​ndor00:matrix.org> Overall, the paper claims ~86.9% traced outputs

<e​ndor00:matrix.org> Now, I don't know how many GB worth of data that actually corresponds to, but it still sounds like a significant amount

<e​ndor00:matrix.org> So if we actually verified that "all outputs from blocks 1-N have been generated and spent before that block", then, theoretically, we could move the genesis block to N?

<e​ndor00:matrix.org> Where N is the first block where we see an output that we're not sure that it has been spent

<e​ndor00:matrix.org> (Or something along those lines, anyway)