<a​tori_0xbdc3ab4e:matrix.org> Well in that case there might be some savings to be made if the decoy output is dropped in that situation.

<n​ihilist:nowhere.moe> btw some of you guys wanted a lemmy instance over tor : lemmy.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion

<n​ihilist:nowhere.moe> btw i know some of you guys wanted a lemmy instance over tor : lemmy.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion

<3​21bob321:monero.social> lemmy see

<p​reland:monero.social> Food for thought: Would it be possible for an external viewer to, without possessing any blockchain information themselves, verify that the Monero blockchain is working “up to spec”?

<p​reland:monero.social> Motivation: I am trying to see how viable a “dual chain” PoC would be, where you could “send” Monero between the two chains by burning on one and minting on the other. In order for it to work safely, each chain would have to be able to semi-trivially check that the other chain is operating properly.

<s​yntheticbird:monero.social> you really need to define what operating properly means

<s​yntheticbird:monero.social> if you don't know how, start to define what you consider to be operating anormaly

<s​pirobel:kernal.eu> been thinking about that too. you have to verify randomx with risc0 for example to convince yourself that the work was done. Solana can verify groth16 as part of the svm now

<s​pirobel:kernal.eu> another solution would be to fork it and just make the monero transactions available to the vm as part of a global data structure x.com/spirobel/status/1825480495494537699 "thought:

<s​pirobel:kernal.eu> scale solana to a size where it becomes feasible to run nodes at home 1-10k tps

<s​pirobel:kernal.eu> have the validators cross post transactions on demand

<s​pirobel:kernal.eu> validators of one minisolana act as oracles in the programs of another." similar to this. just let the block leader be the oracle that gives the monero transactions to the vm when evaluating the transactions

<s​pirobel:kernal.eu> another solution would be to fork it and just make the monero transactions available to the vm as part of a global data structure x.com/spirobel/status/1825480495494537699 "

<s​pirobel:kernal.eu> scale solana to a size where it becomes feasible to run nodes at home 1-10k tps

<s​pirobel:kernal.eu> have the validators cross post transactions on demand

<s​pirobel:kernal.eu> validators of one minisolana act as oracles in the programs of another." similar to this. just let the block leader be the oracle that gives the monero transactions to the vm when evaluating the transactions

<s​pirobel:kernal.eu> another solution would be to fork it and just make the monero transactions available to the vm as part of the sysvar global data structure that is available to all programs x.com/spirobel/status/1825480495494537699 "

<s​pirobel:kernal.eu> scale solana to a size where it becomes feasible to run nodes at home 1-10k tps

<s​pirobel:kernal.eu> have the validators cross post transactions on demand

<s​pirobel:kernal.eu> validators of one minisolana act as oracles in the programs of another." similar to this. just let the block leader be the oracle that gives the monero transactions to the vm when evaluating the transactions

<s​pirobel:kernal.eu> another solution would be to fork it and just make the monero transactions available to the vm as part of the sysvars data structure that is available to all programs x.com/spirobel/status/1825480495494537699 "

<s​pirobel:kernal.eu> scale solana to a size where it becomes feasible to run nodes at home 1-10k tps

<s​pirobel:kernal.eu> have the validators cross post transactions on demand

<s​pirobel:kernal.eu> validators of one minisolana act as oracles in the programs of another." similar to this. just let the block leader be the oracle that gives the monero transactions to the vm when evaluating the transactions

<p​reland:monero.social> I left it intentionally vague, as there are probably many ways the blockchain could be “improper”

<p​reland:monero.social> Basically what it really would mean in my context is that the two chains are operating under the same rules, a very non-exhaustive list would be block rewards, block times/difficulty scaling, the scaling of the size, ensuring that there isn’t unaccounted for supply, etc.

<p​reland:monero.social> If they aren’t playing by the same rules, then the chains would simply not interact with each other

<p​reland:monero.social> This is pretty similar to my thinking

<p​reland:monero.social> The solution to blockchain inscalability isn’t an L2; it’s an *L0*

<p​reland:monero.social> Have local consensus in the form of individual blockchains, and then have a universal consensus among all the blockchains so they don’t completely isolate from each other

<s​pirobel:kernal.eu> main thing to verify is that the proof of work was done and that the consensus rules were respected. essentially what the daemon code does.

<s​pirobel:kernal.eu> i saw it more from a DEX experience standpoint as an alternative to thorchain, atomic swaps etc

<s​pirobel:kernal.eu> solana dex experience is simply better than anything else

<p​reland:monero.social> As in the Monero daemon? If so, could it reasonably do so without syncing to the blockchain?

<p​reland:monero.social> Hmm

<n​eromonero1024:monero.social> are we talking about blockchain scalability in terms of size?

<p​reland:monero.social> Yeah my idea wouldn’t be a DEX at all

<p​reland:monero.social> The point of it would be to ensure that 1 XMR on chain#3785 is equivalent in every way to 1 XMR on chain#72932

<p​reland:monero.social> Partially yes, though bandwidth and transaction volume does become a concern given a large enough user base

<s​pirobel:kernal.eu> yes you would bake the monero daemon into the solana validator code. Or you would have to find a way to verify the consensus rules and pow with a zk proof in risc0 and do this just as a part of a solana on chain program not as a separate network

<n​eromonero1024:monero.social> local, individual chains is a no-go imo... it already kinda exists today

<n​eromonero1024:monero.social> for example, Monero, Zephyr, and Salvium. all of them use rx/0 as pow

<n​eromonero1024:monero.social> but 1 XMR =/= 1 ZEPH =/= 1 SAL

<p​reland:monero.social> The reason for that is that there are other factors that make them incompatible

<p​reland:monero.social> If you could trade the currencies 1:1 with *zero trade offs, and with no change in pricing,* then that would be what I’m describing in essence

<s​pirobel:kernal.eu> partially agree. but if i had to choose between some half baked dex mini project and a solana fork that makes xmr transaction data available to the smart contracts, i would pick the latter. It will be better maintained and in general have more eyes on it / higher quality code, because the ecosystem is so large and quickly evolving. I also think smaller slower solana is an under ex<clipped message>

<s​pirobel:kernal.eu> plored design space. More people should take a look at it.

<n​eromonero1024:monero.social> my node and your node agrees on the rules

<n​eromonero1024:monero.social> 1 xmr on my node is accepted and treated as valid by your node

<n​eromonero1024:monero.social> both are essentially "local" chains that agree on the rules

<n​eromonero1024:monero.social> what's the point of having different chains if there's no other factors? why not just use the original chain instead?

<n​eromonero1024:monero.social> essentially, we're back to the current system

<p​reland:monero.social> This is what I’ve been thinking of in essence, albeit it requires a lot of assumptions to be able to be made:

<p​reland:monero.social> Whenever a Monero blockchain becomes too large (by a combination of multiple factors) it will “split” into two blockchains, with nodes being split between them based on a “distance” function that uses the ping times of the nodes relative to the others. Conversely, if a blockchain gets too small, it can “merge” into another blockchain.

<p​reland:monero.social> In-chain transactions occur as usual. The only very noticeable change to each chains is the addition of a “mint” and “burn” function, which is only used when cross-chain transactions occur.

<p​reland:monero.social> Cross-chain transactions will involve burning a given amount on the sending chain and minting a given amount on the recipient chain.

<p​reland:monero.social> Each node in a Monero blockchain will be randomly assigned a certain number of blockchains to “check”, to ensure they are still “canonical”. The blockchains to check will be switched around continuously. If a given blockchain fails enough checks, the blockchain will be “isolated” and unable to transact with the other chains until it comes back into compliance.

<p​reland:monero.social> Tons of simplification and assumptions are made with this concept ofc.

<s​trawberry:monero.social> Automatic splitting seems complicated, think about how this would work in the simple case with 2 chains first

<n​eromonero1024:monero.social> here's how the current monero nodes work:

<n​eromonero1024:monero.social> * it stores all the inputs and outputs since the genesis block

<n​eromonero1024:monero.social> * you create a tx with inputs you own, create proofs, and send it to the node

<n​eromonero1024:monero.social> * the node verifies that the proof is valid and announces it to the network

<n​eromonero1024:monero.social> in order to verify that the tx is valid, you need to know the entire history of the chain

<n​eromonero1024:monero.social> so, without having the entire history, separate chains have no way to know if the coin you're trying to "burn and mint" is valid or not

<s​trawberry:monero.social> You want to be able to verify that coins on the other chain have been burnt, but how do you do that without syncing with the sending chain?

<n​eromonero1024:monero.social> this, as well

<n​eromonero1024:monero.social> if we're concerned about blockchain size, IMO, there are several ways we can go:

<n​eromonero1024:monero.social> * incorporate powerful compression algo (doesn't solve the actual issue but a good band-aid)

<n​eromonero1024:monero.social> * more pruned nodes w/o `--sync-pruned-blocks` (if I understand correctly, this will increase the initial block sync time but better help the network health... again, a band-aid solution that requires community collaboration)

<n​eromonero1024:monero.social> * some sort of zk blockchain like mina protocol (shoutout to hardhatter for bringing it to my attention) that dramatically shortens the blockchain size to < 1 MB

<s​trawberry:monero.social> Why without --sync-pruned-blocks?

<s​pirobel:kernal.eu> realistically there is also no way to get the different projects to verify the consensus rules of the other chains. that is why projects like thorchain etc use multisig and run their own chain

<s​pirobel:kernal.eu> zk proofs solve some of that

<s​pirobel:kernal.eu> (in case the other chain supports smart contracts that can verify them)

<p​reland:monero.social> This is my main issue that I’ve kinda realized:

<p​reland:monero.social> In more traditional fields, transactions are broadcast more locally, and storage as such is localized as well. In other words, when you use a debit card, that transaction doesn’t have to propagate throughout the entire network in order to become legitimate.

<p​reland:monero.social> Imagine if every single Visa transaction had to go through a centralized server. Even if you assume that they don’t all have to go to that server immediately (analogous to how a node isn’t simultaneously connected to every other node in existence) they will all have to go through it *eventually*, and that would kill it, regardless of how beefy the server is or how much bandwid<clipped message>

<p​reland:monero.social> th you give it (at least by our current technology).

<p​reland:monero.social> Now replace that server with every single node in a universal blockchain system, and you get the same problem.

<n​eromonero1024:monero.social> getmonero.dev/interacting/monerod.html#performance

<n​eromonero1024:monero.social> you download blocks that others pruned instead of pruning them yourself

<n​eromonero1024:monero.social> saves sync time + some computation

<n​eromonero1024:monero.social> however, afaik, those pruned data are still important and whenever needed, will be further probed from the network

<n​eromonero1024:monero.social> now, the pruning process is selecting part of the prune-able data randomly and "delete" them

<n​eromonero1024:monero.social> if you're downloading the block already pruned, the overall randomness of the pruned nodes of the network decreases

<n​eromonero1024:monero.social> if everyone pruned the blocks themselves, the overall randomness distribution would be more smooth, thus increasing the data availability in case those pruned data is needed

<s​pirobel:kernal.eu> another avenue would be layer two protocols that span 2 chains. like the colored coins concept as implemented in counter party. But let the client validate monero and bch / btc transactions and rely on the security guarantees of this consensus and tx ordering to issue coins on a layer above that has no rule enforcement at the node level, but only at the client level

<s​pirobel:kernal.eu> study colored coins, counterpary, ordinals etc

<s​trawberry:monero.social> what do colored coins have to do with this

<n​eromonero1024:monero.social> in visa, there's a central database

<n​eromonero1024:monero.social> through various database tech and techniques, it's split and copied to multiple servers across the globe... as a whole, it acts as if it's a single database

<n​eromonero1024:monero.social> whenever you're making a tx, you're interacting with this central entity

<n​eromonero1024:monero.social> the database verifies if the tx is valid and if valid, processes it

<n​eromonero1024:monero.social> basically, every single visa transaction goes through the "central" server where underneath, it's a web of servers

<n​eromonero1024:monero.social> in some situations, your visa tx has to wait some time before it's verified

<n​eromonero1024:monero.social> that's the latency that results from the "central" server entity gradually processing millions of queued tx

<n​eromonero1024:monero.social> (sorry if I'm somehow repeating what you've already said, preland )

<p​reland:monero.social> No you’re good

<p​reland:monero.social> It kinda works that way

<p​reland:monero.social> The main difference is this though:

<p​reland:monero.social> A transaction made in a given region doesn’t have to go to the same server as in another region. So there isn’t a truly “centralized” system in that sense.

<p​reland:monero.social> Transactions can occur cross-region though, as the servers trust each other to be behaving properly

<p​reland:monero.social> My thinking is this:

<p​reland:monero.social> Replace the regional servers with regional blockchains

<p​reland:monero.social> Replace the trust between the servers with some sort of a proving system between blockchains

<n​eromonero1024:monero.social> okay, smart contracts, in this sense, could be a solution

<n​eromonero1024:monero.social> but to enforce a smart contract, there has to be validators, right? the validators supposedly will host copies of all the blockchains it supports

<n​eromonero1024:monero.social> assuming the sum total chain size gets big enough, the number of validators will decrease proportionally

<n​eromonero1024:monero.social> while a handful of validators can make it work, the power of validation then gets concentrated to a small number of people (basically, catastrophic for decentralization)

<n​eromonero1024:monero.social> unless I'm totally misunderstanding the nature of smart contracts (sorry, I didn't look into them deeply)

<p​reland:monero.social> (And by regional I don’t mean by physical region if you are asking: it would be purely determined by the ping times between nodes, in a perfect world at least)

<s​trawberry:monero.social> This seems analogous to trustless sidechains

<p​reland:monero.social> It is in a way

<p​reland:monero.social> Although everything would be a sidechain

<p​reland:monero.social> (And most sidechain research that I’ve seen with Monero has been to advance some sort of L2 tech; not what I’m thinking)

<o​frnxmr:monero.social> Except for p2pool

<n​eromonero1024:monero.social> you see, the Visa servers "trust" each other because it's a "trusted" setup

<n​eromonero1024:monero.social> why should the American blockchain trust the Chinese (or North Korean) blockchain w/o verifying? as far as the American blockchain is concerned, those are adversary chains that have their best interest in lying

<n​eromonero1024:monero.social> again, the verification requires having the copy of the other blockchains

<n​eromonero1024:monero.social> (unless there's some trustless setup possible through cryptography magic)

<s​yntheticbird:monero.social> I actually like cryptography magic

<i​ty:itycodes.org> Crypto magic is the best thing ever

<i​ty:itycodes.org> I swear that I am not biased at all

<b​asses:matrix.org> 🧙

<n​eromonero1024:monero.social> matrix.monero.social/_matrix/media/…ero.social/TzJleHJAXBTExxLxxhttFUZk

<p​reland:monero.social> 1. This is why I said it wasn’t necessarily split by physical boundaries. It would ideally be split algorithmically. Otherwise you could get a scenario where countries run their own chains, and then start artificially censoring each other. Not good.

<p​reland:monero.social> 2. The only reason verification in my case would necessitate not copying the blockchain is that it’s soooooo damn big. We can’t have dedicated nodes to validate them (else then those nodes could become compromised) so they’d have to be determined randomly, and switched often. This is impossible with a blockchain in the range of hundreds of gigs. Either local networks would b<clipped message>

<p​reland:monero.social> lock the usage of it, or the nodes would be destroying their ssds on a weekly basis.

<p​reland:monero.social> However, if the blockchain could be reduced in size, *and then guaranteed to not grow over time*, then this wouldn’t need to be avoided.

<n​eromonero1024:monero.social> i also agree that size is the limiting factor of blockchain scalability

<n​eromonero1024:monero.social> then, zk proof based blockchain is one of the best ways forward

<n​eromonero1024:monero.social> minaprotocol.com/blog/kimchi-the-latest-update-to-minas-proof-system

<n​eromonero1024:monero.social> hell, we even have god-tier compression algorithms that don't get used (** FUCK YOU MICROSOFT**)

<n​eromonero1024:monero.social> youtu.be/RFWJM8JMXBs

<n​eromonero1024:monero.social> i also agree that size is the limiting factor of blockchain scalability

<n​eromonero1024:monero.social> then, zk proof based blockchain is one of the best ways forward

<n​eromonero1024:monero.social> minaprotocol.com/blog/kimchi-the-latest-update-to-minas-proof-system

<n​eromonero1024:monero.social> hell, we even have god-tier compression algorithms that don't get used ( ** FUCK YOU MICROSOFT** )

<n​eromonero1024:monero.social> youtu.be/RFWJM8JMXBs

<n​eromonero1024:monero.social> i also agree that size is the limiting factor of blockchain scalability

<n​eromonero1024:monero.social> then, zk proof based blockchain is one of the best ways forward

<n​eromonero1024:monero.social> minaprotocol.com/blog/kimchi-the-latest-update-to-minas-proof-system

<n​eromonero1024:monero.social> hell, we even have god-tier compression algorithms that don't get used (**FUCK YOU MICROSOFT**)

<n​eromonero1024:monero.social> youtu.be/RFWJM8JMXBs

<n​eromonero1024:monero.social> monero-project/research-lab #110

<n​eromonero1024:monero.social> bounties.monero.social/posts/95/3-0…nc-a-monero-full-node-in-an-instant

<n​eromonero1024:monero.social> hahahahaha.... we already have proposals and bounties for zk proof based blockchain

<n​eromonero1024:monero.social> but not enough traction :(

<h​ardhatter:monero.social> The zk route is more practical imo. The compression route requires more computational power. And getting unfathomable compression ratios by today’s standard, as I’ve said before, is possible but imo still not worth going that route since it’s still gonna cost you more computational power. And idk how quickly you guys are gonna figure out a reasonably computationally efficien<clipped message>

<h​ardhatter:monero.social> t recursively repeatable compression algorithm that allows memory retrieval in the compressed form, let alone having an algorithm of that kind at all.