40 sats \ 5 replies \ @TonyGiorgio 1 Feb \ on: Mercury layer AMA bitcoin
How far are you willing to go calling mercury a non custodial solution? We just have to trust:
  1. Intel SGX
  2. Mercury to not push bad updates to the SGX
  3. Mercury not colluding with other actors
Is that accurate? Does that still fit your definition of non custodial?
write
preview
40 sats \ 4 replies \ @tptrevethan OP 1 Feb
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.
reply
0 sats \ 3 replies \ @TonyGiorgio 1 Feb
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
10 sats \ 2 replies \ @tptrevethan OP 1 Feb
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
0 sats \ 1 reply \ @joda 1 Feb
I'm sure it's outside the scope of this project, but is it possible to "prove" a particular version of a software is being run (if you know)?
reply
10 sats \ 0 replies \ @tptrevethan OP 2 Feb
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