<r​adim34:matrix.org> Yeah I figured :)

<r​adim34:matrix.org> I obviously don't expect to trigger a massive protocol change here, just want to understand if the option to convert a monero txs batch (i.e. block) into a succinct proof of computation was ever considered and your thoughts about it.

<r​ucknium:monero.social> radim34: You mean a system like Mina's? My and monerobull 's comments on Mina-like systems: libera.monerologs.net/monero-research-lab/20240311#c345412-c345437

<m​onerobull:matrix.org> That you even remember stuff like this is crazy

<m​onerobull:matrix.org> That convo was over a year ago!

<r​adim34:matrix.org> Rucknium: It is similar in a sense of using snark proofs to shrink the block (even the entire chain), yet Mina does not support private txs natively and they are indeed public.

<r​adim34:matrix.org> My suggestion is much simpler than Mina - instead of Monero blocks being just a batched txs (each several kbs), it will be a relatively small proof of a program execution, that claims "this is block n, it verified some txs, and this is their output".

<r​adim34:matrix.org> The nodes then verify the proof (the new block) and do not have to verify the actual txs...in fact, they dont even have to know whats ringCT or bulletproofs, they just have to agree that the verified program is correct. Fork rules and other concensus related parts can remain the same.

<r​ucknium:monero.social> radim34: Something like these? monero-project/research-lab #110 monero-project/research-lab #111

<r​ucknium:monero.social> Still, AFAIK your idea means that a user will lose their coins if their local wallet file(s) are corrupted/lost, unless they pull data from "archive nodes". And then you still need some archive nodes to keep all the data. And you need to call the archive nodes if you want to sync a wallet that has been offline, e.g. a wallet on a mobile device that is not constantly connected to a node. Correct?

<r​adim34:matrix.org> Yes! This is great :) Is the author in this chat?

<r​ucknium:monero.social> Yes. kayabanerve

<k​ayabanerve:matrix.org> There's a lot of better, more recent commentary I could make on IVC/RCG schemes but I'll instead point to my call for a moratorium on EC cryptography and just namedrop LatticeFold.

<k​ayabanerve:matrix.org> monero-project/research-lab #116 for the existing issue on a generic SC design, which Aztec appears to be pioneering a production version of (not that they got the idea from me)

<r​adim34:matrix.org> IIUC the property you're referring too is purely a design choice of Minas creators (weird choice if you ask me but whatever). In this suggestion the state grows as usual, but the txs can be discarded, we only need a proof of their execution.

<r​ucknium:monero.social> AFAIK, a wallet needs the actual tx data, not just the ZK proof that it happened.

<r​adim34:matrix.org> Well that blew my mind abit...Can you please explain/refer as to why an xmr wallet needs its txs history and not its priv keys?

<r​adim34:matrix.org> *assuming the txs output are publicly available as part of the state

<r​ucknium:monero.social> So your proposal is to keep the transactions' outputs in the "reduced" blockchain? I guess that could work. Generally, when wallets are being stored from seed words, they need to know which of their tx outputs have already been spent, but I suppose the wallets can figure that out by trying to spend an output and the node rejecting it as already spent (if not a more elegant solutio<clipped message

<r​ucknium:monero.social> n). Still, keeping all those outputs would still get you a large blockchain.

<r​adim34:matrix.org> Yes. I agree the state will grow the same, but the chain will be much "slimmer" since blocks will be able to contain more txs (logarithmic in #txs)

<r​ucknium:monero.social> But linear in the number of transaction outputs, right? If the effect very different from Monero nodes' pruning option that already exists?

<j​effro256:monero.social> Wallets also need the "ephemeral transaction pubkeys" (not output pairs) to scan the blockchain. Monero uses stealth addresses, so before determining if an output belongs to them or not, they need to perform ECDH against these "ephemeral transaction pubkeys"

<j​effro256:monero.social> That's an additional 32 bytes per output (technically 16 per output in a 2-out since it's shared)

<j​effro256:monero.social> There's also view tags to keep for wallets if you want scanning to be fast

<r​ucknium:monero.social> Thank you, jeffro. I'm out of my depth on this one 😄

<j​effro256:monero.social> And Carrot introduces 16-byte "anchor" fields which are used to Mitigate Janus attacks, and if Jamtis is rolled out, this field is used as an encrypted UUID field for the address

<j​effro256:monero.social> One could definitely argue that those should be pruned from the L1, but you need to store it somewhere if you like having money

<j​effro256:monero.social> In the Monero codebase, basically everything in a "pruned" transaction is what is needed for wallets to sync their balances. The "prunable" part *doesn't* matter to wallets

<r​ucknium:monero.social> jeffro256: While you're here, I wanted to ask if you had an opinion about the adoption curve I should assume for the 10 block lock decoy selection fix. I am just at the point in the OSPEAD data update where I have to decide. Not decide for all time, but this run, at least.

<r​ucknium:monero.social> Last time, this was the assumption:

<r​ucknium:monero.social> > It was assumed that adoption followed a straight linear trend, starting at zero percent in April 2023 and ending at 75 percent in October 2024, the end of the dataset.

<r​ucknium:monero.social> rucknium.github.io/OSPEAD/CCS-miles…EAD-docs/_book/transformed-age.html

<j​effro256:monero.social> That seems somewhat slow to me, but I've never looked at the data

<r​ucknium:monero.social> Seems slow to me, too. Probably quick uptake for early adopters in the beginning, then slower uptake after that. Maybe I will use a logistic curve. That's more complex than linear, but maybe more realistic.

<j​effro256:monero.social> On the other hand, a lot of the volume is driven by large automated services like exchanges who spend very very recent outputs. But enterprises also tend to not update core software unless something's broken

<j​effro256:monero.social> But yeah a logistics curve feels correct here

<r​afaelkinder:matrix.org> Maybe dumb question, but what is the reason for matching interpolation to adoption?

<r​ucknium:monero.social> 8trmns: Did you read my link?

<r​afaelkinder:matrix.org> No I'll check it out, I'm just learning and following along here thanks.

<r​ucknium:monero.social> Wait. Logistic is used in technology adoption models, but it's slow-fast-slow. And I just said we have many fast early adopters probably in the beginning. I'll figure out something.

<r​ucknium:monero.social> When Exodus wallet updated their Monero fees, it looked like most Exodus users updated in a few weeks. But that's a specific case and does not cover services, as you said.

<j​effro256:monero.social> Yeah sorry I was thinking of exponential decay, not logistic

<r​adim34:matrix.org> Pruned nodes still relay on full nodes for data availability. But the main gimmick here is that the blocks are smaller or contain more txs for the same size. Blocks cannot grow too much - long propagation time through the network causes soft forks and losing hash power.

<r​ucknium:monero.social> I'm not sure that your proposal would reduce block propagation time. If nodes do not have all the txs in a mined block in their txpool, then they have to run a verification of the ZK proof on the whole block (I'm not sure how long that would take). With proofs separated into each tx like now, individual proofs can be verified as they arrive in the txpool and then any few missing t<clipped message

<r​ucknium:monero.social> xs can be verified when the fluffy block arrives.

<r​adim34:matrix.org> Verifying proofs is pretty fast (talking about stark, which is my specialty :)). Also note that verifying state transition do no require storage access! It claims - "here is a valid transition from Sn to Sn+1 and this is the delta".

<r​adim34:matrix.org> That optimization sounds super interesting and never heard of it. Yet I assume they still have to somewhat rerun them all to see it make are valid as a sequence ( e.g. avoid double spend).

<r​ucknium:monero.social> radim34: Fluffy blocks are just Monero's version of a compact block protocol, which is common on most UTXO-based blockchains AFAIK. You don't really need to check any "sequences" longer than 1 because you cannot spend a Monero output that has been created in the same block. (In fact, you cannot spend an output created in any of the previous 9 blocks.) Just check that the key image<clipped message

<r​ucknium:monero.social> s are distinct for the current block and all previous blocks, which is a database lookup operation, not a cryptographic one.

<r​ucknium:monero.social> jeffro256: What do you think about: Use exponential probability distribution to model adoption. Let the mean of the distribution be 6 months. Then, downscale it so that at the end of the 24 month period (we are 2 years into adoption now) adoption is about 80%?

<r​ucknium:monero.social> In R it would be

<r​ucknium:monero.social> ```R

<r​ucknium:monero.social> adoption.time <- seq(0, 24, by = 0.01)

<r​ucknium:monero.social> plot(adoption.time, 0.80 * pexp(adoption.time, rate = 1/6), type = "l",

<r​ucknium:monero.social> ylim = c(0, 1), ylab = "Adoption share", xlab = "Months")

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> radim34: I don't intend to try to shoot you down, but that is my feedback.

<r​ucknium:monero.social> Happy to be proven wrong :)

<r​adim34:matrix.org> I did not know that. So it wont improve the block propagation time, but at least the requested missing transactions time is saved - thats also something:)

<r​adim34:matrix.org> On the contrary - this is great!

<j​effro256:monero.social> I wonder though.... If we assume *mean* is six months, then we are activating hard forks wayyy too fast by doing them in a 6-month gap

<r​ucknium:monero.social> A hard fork will encourage users to update a lot more than a normal version release. And last hard fork, tx volume roughly halved: bitinfocharts.com/comparison/monero-transactions.html#3y

<r​ucknium:monero.social> Last hard fork was 2022-08-14

<r​ucknium:monero.social> And as you know, many wallets were not ready for the upgrade in time: github.com/Rucknium/misc-research/t…-transactions-with-nonstandard-fees