<p​reland:monero.social> I’ve kinda had this on my mind for the last couple days—

<p​reland:monero.social> Is it possible to create a blockchain (or *any* reasonably decentralized/trustless system) that doesn’t continuously increase in size as time goes on?

<p​reland:monero.social> Ie ignoring any system changes other than those for verification, can the size of a blockchain remain constant relative to time while still being secure?

<s​nowman:tetaneutral.net> You invented gold

<n​eromonero1024:monero.social> it's almost possible with zk proofs

<n​eromonero1024:monero.social> check the mina protocol... the caveat being, there has to be some node in the network that holds the full data

<n​eromonero1024:monero.social> for monero's use, however, it might be kinda difficult to implement... it breaks some crucial functionality like restoring wallet from seed (afaik)

<t​rasherdk:monero.social> Single user blockchain 🙂

<h​ardhatter:monero.social> I mean you could have a period based system where each unit of the the currency among a finite number of units is owned by a wallet.

<h​ardhatter:monero.social> The current state of the system proves which wallets those units are in.

<h​ardhatter:monero.social> The next period uses the current state and the requests for transactions to update the system to the next period then throws out the last period

<h​ardhatter:monero.social> Consensus has to be a achieved before the state of the next period is valid to become the state of the new current period. Which guarantees the new state was correctly transformed from the last state (well if we assume the consensus didn’t miscalculate the transformation). So now we can throw out the state of the old period.

<h​ardhatter:monero.social> This obviously has draw backs including not being able to prove validity of historical transactions. It only proves that you currently own what you have. But anyway this is just meant to be an example

<b​lacksdontmatter3:nope.chat> media.discordapp.net/attachments/12…&format=webp&width=1072&height=1078

<b​lacksdontmatter3:nope.chat> matrix.monero.social/_matrix/media/…/nope.chat/bbGOTZWHzgpZGwNRiISmQkMx

<b​lacksdontmatter3:nope.chat> matrix.monero.social/_matrix/media/…/nope.chat/RjQzgKNijDrQXoPowhotsShX

<t​rasherdk:monero.social> hardhatter: Ah, you mean like a pull request, awaiting review?

<h​ardhatter:monero.social> Pretty much. But also this is just slightly different from monero’s protocol being changed to periodically reset the blockchain to the most recent state of every unspent output after some period of blocks. Where we throw out the previous block periods

<h​ardhatter:monero.social> This wouldn’t work with fcmps presumably unless we do fcmps in a way where it only uses a block period instead of the every historical period

<t​rasherdk:monero.social> So, when I open my GUI wallet, that hasn't been synced for a while, 3 weeks I think, how would I get caught up? How many snapshots would I have to download?

<h​ardhatter:monero.social> You would just sync it starting from either the beginning of the current block period or from where you were last synced if that’s already in the same block period

<h​ardhatter:monero.social> But you wouldn’t be able to retrieve the history of transactions from previous block periods

Seems like #monero-research-lounge topics?

<h​ardhatter:monero.social> I rather go to monero off topic then. Since I’m not participating in implementing anything in monero codebase yet, I rather not clutter their conversations that’s probably irrelevant to what they’re working on

<h​ardhatter:monero.social> Plus, iirc kayaba said on monerotopia he wouldn’t support something akin to this, but I’ll let him speak for himself. And if that’s the case my guess is the other devs considered this already and decided against it

<h​ardhatter:monero.social> But you wouldn’t be able to retrieve the history of transactions from previous block periods or validate transactions from previous periods them without storing those previous periods

<h​ardhatter:monero.social> But you wouldn’t be able to retrieve the history of transactions from previous block periods or validate transactions from previous without storing those previous periods

<h​ardhatter:monero.social> But you wouldn’t be able to retrieve the history of transactions from previous block periods or validate transactions from previous periods without storing those previous periods

<t​rasherdk:monero.social> Well, it's not really a blockchain you describe. It's more like an account based system with a ledger.

<h​ardhatter:monero.social> I mean the part where I later said this could be done just by resetting the blockchain periodically is still a blockchain. The first part that I wrote was just an example for what preland asked

<p​reland:monero.social> What I was thinking of was basically that the entire database would only be records of individual outputs. That way, the database increases as output count does, but not directly as time goes on

<h​ardhatter:monero.social> Yea you could do that. But it wouldn’t be something that you could do without completely changing how monero is implemented.

<h​ardhatter:monero.social> The blockchain resetting thing I mentioned is something that could be more easily transitioned to that still caps the blockchain size. I’m not saying we should or shouldn’t transition to that but yea it’s easier.

<s​trawberry:monero.social> Monero doesn't have a finite number of units though

<h​ardhatter:monero.social> I know didn’t say monero did. But in the case implementing blockchain resetting in monero, the last block of the period used for the reset would have a finite number of unspent outputs for the next period to start from

<s​trawberry:monero.social> By blockchain resetting do you mean pruning spent outputs on some interval? how?

<s​yntheticbird:monero.social> plowsof, lionelnassi is back

<s​yntheticbird:monero.social> kill him

<s​yntheticbird:monero.social> thx

<system> file fcg9.png too big to download (2889097 > allowed size: 1000000)

<n​yx:nyx.1337.cx> fcg9.png

<h​ardhatter:monero.social> Pruning individual spent outputs most likely won’t be practical especially if the addresses with unspent outputs and their amounts are not known by scanning the block chain without view keys.

<h​ardhatter:monero.social> You’d probably have to figure out a way to pair the unspent outputs of each transaction with an address that can be automatically used at the end of each block period to reinitialize the next period’s blockchain with those outputs at their paired addresses.

<h​ardhatter:monero.social> An unideal alternative would be having everyone holding monero participate in the reinitialization to figure out how many unspent outputs there are and where they should be reinitialized in the next blockchain. But that’s impractical since people who don’t participate will lose their xmr.

<h​ardhatter:monero.social> Anyway the constraints to the solution introducing this functionality are largely dependent on the existing design of monero’s protocol and how much we’re willing to change that to accommodate this.

<s​trawberry:monero.social> I understand it's not practical, which is why I asked what you meant if not pruning spent outputs

<s​trawberry:monero.social> Surely you don't mean storing the owner of every individual piconero? I suppose that would result in a hard cap on space if there was no tail emission, but would also be horrifically impractical

<h​ardhatter:monero.social> I mean I didn’t point out it’s impractical to insult your intelligence, I was just acknowledging that aswell to then follow up with an abstract suggestion for how you might approach coming up with a solution

<h​ardhatter:monero.social> Not every piconero but possibly every unspent output, unless some mass consolidation event occurs prior to the reinitialization to minimize the needed outputs to reinitialize total amount of xmr in each address with a unspent output

<h​ardhatter:monero.social> Not every piconero but possibly every unspent output, unless some mass consolidation event occurs prior to the reinitialization to minimize the needed outputs to reinitialize total amount of xmr in each address with a unspent output, which may also allow negligible amounts in wallets to be excluded for practicality.

<h​ardhatter:monero.social> But on the other hand there was enough computational resources to distribute those existing outputs into individual addresses in the first place so it’s likely practical enough to do it again if it came down to that.

<s​yntheticbird:monero.social> ain't no wat pewdiepie joined the chat

<n​yx:nyx.1337.cx> don't tell him about the bridge bot lest we have another incident

<p​reland:monero.social> This is kinda my thinking