00:00:22 <m-relay> <j​berman:monero.social> I can look into this / identify where the issue may be. Unfortunate I spent some time on implementing grouping proofs per tx, but is what it is
17:08:49 <m-relay> <s​pirobel:kernal.eu> we should never recommend TEE even for small amounts.
17:11:31 <m-relay> <s​yntheticbird:monero.social> very controversial
17:12:10 <m-relay> <s​yntheticbird:monero.social> but an opinion is an opinion
17:13:39 <m-relay> <s​pirobel:kernal.eu> it is fundamentally anti freedom technology that 1. normalizes the idea that our computers are just "appliances" that we dont fully control even though we bought them. 2. it is used by extractive industries for "Digital Rights Management" 3. it blurs the lines between real privacy technology and this garbage
17:15:49 <m-relay> <s​yntheticbird:monero.social> I agree the use of SGX is fundamentally incompatible with monero's philosophy and values, however third-party projects are always free of these constraints
17:16:00 <m-relay> <k​ayabanerve:matrix.org> The time locked VDF solutions, IMO, are only insecure with trust anyways.
17:17:07 <m-relay> <k​ayabanerve:matrix.org> The premise is extracting a private key can only happen after a certain moment in time because of bounds on computational power. That means the minimum bound for lifetime is the time for the most powerful computer in the planet, known or secret, to solve the puzzle.
17:18:24 <m-relay> <s​pirobel:kernal.eu> this tricknology should not be white washed. it is not worth it
17:18:28 <m-relay> <k​ayabanerve:matrix.org> TEE solutions, whether Intel, AMD, or open, shift trust to an explicit entity and the idealized security of hardware.
17:19:07 <m-relay> <k​ayabanerve:matrix.org> Though now that I think of it, I'm unsure TEEs have access to clocks...
17:19:47 <m-relay> <s​yntheticbird:monero.social> They have
17:25:11 <m-relay> <s​yntheticbird:monero.social> nvm they don't. they only have access to execution time
17:29:14 <m-relay> <k​ayabanerve:matrix.org> Yes, you'd need to measure time with cumulative PoW or some signature (like an Ethereum commit)
17:40:55 <m-relay> <k​ayabanerve:matrix.org> None of these solutions are great and basically every single one requires deferring some degree of trust. The one with a horrible UX defers a degree of trust on the adversary's ability to perform a sequential computation
17:57:57 <m-relay> <r​brunner7:monero.social> Did I really read *SGX* somewhere in the backlog? That thing that soon will be gone? https://hardenedvault.net/blog/2022-01-15-sgx-deprecated/
17:58:25 <m-relay> <r​brunner7:monero.social> Oh, wow, talking about soon - that's an article from 2022 already
18:01:20 <m-relay> <c​ountbleck:matrix.org> It'll still be there in servers IIRC
18:01:56 <m-relay> <c​ountbleck:matrix.org> It'll still be there in servers IIRC (oh, the article says that)
18:02:00 <m-relay> <r​brunner7:monero.social> Xeon only now: https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions-processors.html
18:02:28 <m-relay> <r​brunner7:monero.social> Yeah, sure, servers, can we put something out that only runs on server processors? I have my doubts.
18:04:36 <m-relay> <c​ountbleck:matrix.org> I'd guess not
18:06:43 <m-relay> <r​brunner7:monero.social> And then, Intel: has SGX, AMD: seems to have another thing called SEV; ARM: no idea, really. Good luck supporting that all :)
19:21:36 <m-relay> <s​yntheticbird:monero.social> SEV is absolutely not the same
19:21:46 <m-relay> <s​yntheticbird:monero.social> SGX is a secure enclave
19:21:56 <m-relay> <s​yntheticbird:monero.social> SEV is using the PSP for encrypting VM guest memory and keeping it tamper free from the hypervisor
19:22:21 <m-relay> <s​yntheticbird:monero.social> the two have completely different applications
19:43:57 <m-relay> <r​brunner7:monero.social> So what is the closest thing to SGX over in AMD land? I tried to google, but got only more confused ...
19:45:02 <m-relay> <s​yntheticbird:monero.social> there are none
19:45:35 <m-relay> <s​yntheticbird:monero.social> because unlike Intel, AMD isn't arrogant enough to market something as uncertain as a security enclave