Nostr Web Client

I think the difference btw "we are 100% sure this mint runs this code" vs "we don't really know what it's doing but some checks make it look fine" is significant.

Garbage nsec 3mo ago

In terms of rugging it's the same I think. In fact it could be worse, the operator could use a cloud enclave to instil trust in the token holders (look you can attest the code) and then wait some time and rug the holders all the same. And every rug is 100% of the value of all your tokens gone, it doesn't matter how trustworthy things looked the split second before the rug.

But I think there are some benefits to enclaves, the biggest benefit being that a mint insurer can be 100% sure of the mint's outstanding assets. That's impossible without enclaves.

Reply to this note

Please Login to reply.

Discussion

brugeman 3mo ago 💬 2

It's not a rug, funds aren't stolen, but destroyed - enclave is terminated and keys are lost, a very different set of incentives to do this.

Garbage nsec 3mo ago

Tricky thing in Cashu is that a service failure and a rug are indistinguishable. And stealing funds and destroying funds are also indistinguishable acts. Destroying the mint is how you steal the funds.

brugeman 3mo ago 💬 2

My point is the motivation for taking your funds for myself is obvious, while taking them to no-one's benefit - not so obvious.

Garbage nsec 3mo ago

How do you mean taking them to no-one's benefit?

brugeman 3mo ago 💬 2

I mean if keys can't be extracted and operator just kills the enclave then keys are gone and LN node's channels are force closed and node's sats are gone with the keys and operator gets no benefit from the shutdown. Or am I missing something?

Garbage nsec 3mo ago

Ah right, my understanding is that even if the node were birthed in the enclave the bitcoin would return to on-chain in case of force close. If the node is destroyed before a force close event can be sent, and also no backup was obtained (a problematic setup in itself), then I think any of the destroyed node's past outside peers can still initiate the force close and the bitcoin is still released on-chain. And the malicious operator would be behind one of those peers. I have to defer to a lighting dev on this, but the gist of my understanding is that the operator in this scenario is always going to have *some* way to access the bitcoin on-chain if the node is destroyed. Who here would be good to ask this I wonder?

brugeman 3mo ago 💬 1

Channel peers could try to broadcast old channel state, but there are watchtowers for that, and you can just code it to use reputable LSP. My wallet uses phoenixd, I'm pretty sure Asinq won't try to benefit from my channel if the enclave terminates.

Garbage nsec 3mo ago

I'm pretty hazy on the lighting node stuff, but hardcoding a trusted LSP makes sense. That's similar to another situation we gamed out where the on-chain keys are also generated in the enclave, what we called full autopilot.

The thing for me though is that even for full autopilot it just returns to the update/recovery vector. With a mint and node essentially running together in there on autopilot you'll need updates and emergency recovery flows. The Cashu mint codebases are not yet mature, to say nothing of all the layers of logic to govern the interplay between the mint, the node, the LSP, ensuring no solvency rules are broken, etc. Things will break.

Trying to handle risk mitigation for updates with just signatures from a hardcoded set of approvers for seems not worth it to me. If every updated enclave image represents a potential rug pull, and updates are inevitable and frequent, then in that scenario the only thing standing between the token holders and a rug pull is their trust in the human approvers on that list, i.e the guardians. But for me that just becomes Fedimint, since it seems to be pretty much the same class of distributed risk. And if all the enclave does in terms of mitigating the rug pull risk is to convert Cashu mints to Fedimint mints then seems you may as well just go with a Fedimint mint in the first place.

And on top of that there's the UX issues. For example there is a critical vulnerability discovered, mint has to come offline, soon you have an updated image to push, but of the four hardcoded approvers one is on vacation, another is mad at you, another has a very careful personality and takes days to review these kinds of patches. Just the kind of people stuff that always seems to happen. Even if your n of x is 2 of 4 it’s still a headache. And all this time token holders are trying to transact and getting timeouts. And who updates the list of approvers? And under what rules? It all gets very messy when trying to scale beyond the hobby level.

But coming back to the main thing, even if your maintainers are all super eager, to me it still becomes just a very expensive Fedimint in terms of reliance on trust in a few people. Maybe I'm just not seeing some opportunities here, but as of how it looks to me now the value of enclaves can't be about just rug-proofing Cashu mints, neither the kind of rugging that doesn't profit the rugger (negligence, just being psycho), neither the kind that does profit them (collusion, some clever hack, obfuscating malicious update code that the reviewers miss, etc.). It seems that outcome is always going to be possible. So the value has to be about something else.

Good discussion though.