40 sats \ 4 replies \ @tptrevethan OP 1 Feb \ parent \ on: Mercury layer AMA bitcoin
I will say it is definitely 'not' custodial, IF the server is honest. I recognise that in the world of bitcoin the word 'non-custodial' has a specific meaning - so that why we usually use 'proactively non-custodial' - if the server has been proactive (i.e. honest in the past) it has no ability to steal in the present.
It is certainly non-custodial from a legal/regulatory perspective.
But we are very explicit about the trust model. Regarding SGX, this is layered below that fundamental trust. There are many protocols that rely entirely on SGX (i.e. it is the only line of defence) - this is risky IMO: we know it can be compromised (with difficulty).
We are using it as an additional layer to secure our deployed service, like how any company (e.g. Liquid) uses HSMs.
if the server has been proactive.. it has no ability to steal in the present.
Is this accurate? can you not push updates to the code that runs on SGX once it's deployed?
reply
By being 'proactive' I mean that the present owner cannot be stolen from if the server deleted the (all) previous owners keys (in the past).
Even if we updated the code (in the present), there is no way to get old key shares (from the past).
This does not protect against a 'proactive' theft/collusion, where the operator and a previous owner conspire to steal from you (a new owner). This requires trust.
However, the blinded nature of the server make this collusion more difficult.
reply
reply
The principle (in theory) of SGX remote attestation is that you can verify that a specific value (e.g. a cryptographic key) has been produced in an enclave running a specified code. The attestation that this code is running in the enclave is called a 'quote' and is signed with a key unique to that CPU. You can then use Intel's attestation service to verify its a genuine enclave.
There are lots of caveats to this though, and you must trust intel (and also there are privacy issues using intel's service).
reply