<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

<s​pirobel:kernal.eu> we should never recommend TEE even for small amounts.

<s​yntheticbird:monero.social> very controversial

<s​yntheticbird:monero.social> but an opinion is an opinion

<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

<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

<k​ayabanerve:matrix.org> The time locked VDF solutions, IMO, are only insecure with trust anyways.

<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.

<s​pirobel:kernal.eu> this tricknology should not be white washed. it is not worth it

<k​ayabanerve:matrix.org> TEE solutions, whether Intel, AMD, or open, shift trust to an explicit entity and the idealized security of hardware.

<k​ayabanerve:matrix.org> Though now that I think of it, I'm unsure TEEs have access to clocks...

<s​yntheticbird:monero.social> They have

<s​yntheticbird:monero.social> nvm they don't. they only have access to execution time

<k​ayabanerve:matrix.org> Yes, you'd need to measure time with cumulative PoW or some signature (like an Ethereum commit)

<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

<r​brunner7:monero.social> Did I really read *SGX* somewhere in the backlog? That thing that soon will be gone? hardenedvault.net/blog/2022-01-15-sgx-deprecated

<r​brunner7:monero.social> Oh, wow, talking about soon - that's an article from 2022 already

<c​ountbleck:matrix.org> It'll still be there in servers IIRC

<c​ountbleck:matrix.org> It'll still be there in servers IIRC (oh, the article says that)

<r​brunner7:monero.social> Xeon only now: intel.com/content/www/us/en/archite…re-guard-extensions-processors.html

<r​brunner7:monero.social> Yeah, sure, servers, can we put something out that only runs on server processors? I have my doubts.

<c​ountbleck:matrix.org> I'd guess not

<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 :)

<s​yntheticbird:monero.social> SEV is absolutely not the same

<s​yntheticbird:monero.social> SGX is a secure enclave

<s​yntheticbird:monero.social> SEV is using the PSP for encrypting VM guest memory and keeping it tamper free from the hypervisor

<s​yntheticbird:monero.social> the two have completely different applications

<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 ...

<s​yntheticbird:monero.social> there are none

<s​yntheticbird:monero.social> because unlike Intel, AMD isn't arrogant enough to market something as uncertain as a security enclave