-
m-relay
<anilwang:matrix.org> Sorry I'm a bit late to the discussion. I see several issues with the proof of sacrifice (1) counterfeiting, (2) simulated sacrifice, (3) what determines the value of an item?, (4) in the real world, an item has no value if it is destroyed. So it can't work. What proof of sacrifice is trying to simulate is proof of work, so why not simply have proof of actual work. Two possible "p<clipped message>
-
m-relay
<anilwang:matrix.org> roof of actual work" schemes would be "renting out your disk space/RAM memory" for XMR and "renting out your CPU time" for XMR. With distributed and cloud computing, this is very possible and can even work in a mesh environment. The key difficulty of this approach is that it's peer two peer so faces the same issues atomic swaps face, namely matching of needs. If I need 100 XMR, an<clipped message>
-
m-relay
<anilwang:matrix.org> y my only offers require a day to produce 14 XMR, 29 XMR, 5 XMR, 35 XMR, etc, I have to piece together all these offers to come up with the 100 XMR. A better approach would be to have a "liquidity pool" of "actual work". This liquidity pool not only allows for a matching of needs, it also adds anonymity to the trades so liquidity proof of actual work (POAW) providers and XMR provi<clipped message>
-
m-relay
<anilwang:matrix.org> ders don't need to directly communicate with each other. There are several issues that need to be resolved (e.g. reliability of storage, uptime, etc) but there has been several decades of research and practise on this topic, so there are known workarounds. Torrents are an imperfect implementation of this. You want your torrents hosting distributed, so you "pay" by hosting other to<clipped message>
-
m-relay
<anilwang:matrix.org> rrents that want to be distributed. Torrents struggle because "torrent liquidity providers" tend to be "leaches" that give only the amount that's needed to "pay" for the torrent they want to download. Decoupling these the "storage provider" from the "storage downloader" through conversion to XMR liquidity pools may solve this issue.
-
m-relay
<preland:matrix.org> I actually want to implement this sort of thing in a separate idea
-
m-relay
<preland:matrix.org> Effectively, the concept (which I call “grapebox”) would be to have a host devote a certain amount of storage space, bandwidth, and compute power (cpu,gpu,etc.) to a “GrapeBox”, which is effectively a *very* special VM.
-
m-relay
<preland:matrix.org> Everything on the GrapeBox is encrypted or obfuscated, such that the GrapeBox host cannot know what is running or stored on the machine, or what it is doing networking-wise. All connections into and out of the GrapeBox are routed directly through I2P.
-
m-relay
<preland:matrix.org> In addition, the host *cannot know for certain how many guests are in a GrapeBox*. As extra protection for both guests and hosts, each GrapeBox guest is also hosted on at least 2 other GrapeBox instances (this prevents an attacker from determining that a guest is on a host by removing the host)
-
m-relay
<preland:matrix.org> There is…. A lottt of things that would have to be figured out (all executed instructions would have to also be encrypted *during execution*, so there would have to be something to deal with that; there are also a metric ton of side-channel attacks that would need to be mitigated with this.) But the end result would be an end-user being able to trustlessly setup a remote server,<clipped message>
-
m-relay
<preland:matrix.org> and a host can trustlessly host guests.
-
m-relay
<preland:matrix.org> (If you are wondering about concerns like the host dropping, I do have some ways to address that)
-
m-relay
<syntheticbird:monero.social> Long story short its impossible
-
m-relay
<syntheticbird:monero.social> zero knowledge instruction execution is impossible, state of the art is arithmetic operations without loop and it take approximately 16000 times more space
-
m-relay
<syntheticbird:monero.social> and also It's fucking complex, prone to error of implementation
-
m-relay
<syntheticbird:monero.social> What you wish is impossible to develop even in under a decade. All you can do is obfuscation and that would kill performance to a point its not viable anymore
-
m-relay
<syntheticbird:monero.social> The closest protection you have right now is *Confidential Computing* on new server x86 cpus. AMD-SEV encrypt the memory an host is unable to read the live memory or disk. It's supported by QEMU. Tho it is a hardware based security and literally no one in this room have a new generation EPYC cpu to even test this
-
m-relay
<syntheticbird:monero.social> OH FUCK IT HE IS ON MATRIX.ORG
-
m-relay
-
m-relay
<someoneelse495495:matrix.org> ^
-
m-relay
<preland:matrix.org> Man I love matrix
-
m-relay
<preland:matrix.org> But yeah I’m aware of those limitations already
-
m-relay
<xfedex:matrix.org> confidential computing / TEE is not a solution
-
m-relay
<xfedex:matrix.org> it requires trust on hardware producers
-
m-relay
<syntheticbird:monero.social> Yes, that is why I said: *Tho it is a hardware based security*
-
m-relay
<preland:matrix.org> Yeah
-
m-relay
<preland:matrix.org> My idea would be some sort of “contextless computing” setup, where the host is given instructions to execute, but they make no sense without the context that the guest has