Nostr Web Client

>Is it possible for the owner to pull the keys out or can only AWS or Intel do that?

AWS themselves cannot pull the mint keys out. Only a human or bot holding a private key the sig of which has been designated in the enclave code can. Basically the enclave will only allow to happen what its runtime code allows to happen, and any change to the runtime code will result in an attestation fail. So you can be sure the code is what it is.

> If the owner can pull them out and the mint self-destructs, how is this different to what is possible today? With "self-destruct", I assume you mean the mint is no longer available for any operation, including melt.

The mint doesn't actually have to self destruct. It will only do so if its code says it has to self-destruct if the keys are exported. But if it's possible for a human being to know the mint keys then attested query returns from the database of the mint in the enclave are no longer of value at best, and misleading at worst, so what's the point of it being in the enclave?

But also the owner of the AWS enclave can also just delete the enclave anytime, so whether it does or does not self destruct on a given event is besides the point, it can vanish anytime regardless. And this doesn't touch upon the lightning reserve backing the mint, which is another story.

>Or Is this only about resisting inflation, but not rugpulls?

Neither, it's actually about insurance. In other words, the value for this isn't in making things un-ruggable, it totally doesn't achieve this. The reason I started researching this is related to the topic of mint insurance, which is closer to what I'm working on in a particular B2B space.

As a mint insurer you will only insure a mint the liabilities of which you are sure of. If the mint operator rugs then you as the insurer can recreate the mint and database (this comes down to the smart contract and how it interacts with the AWS enclave) and make whole the token holders.

So a prospective mint operator who wants his or her mint to be insured must spin up an enclaved mint as per the mint insurer's spec. (It can be on the operator's own AWS infra, that's fine, but it has to be one for which the keys are birthed inside). If the owner pulls the keys then the mint can live on, but this will terminate the insurance coverage since the insurer can no longer be sure of the mint's liabilities. So it's actually the insurance coverage that self destructs in my case, not the mint.

Reply to this note

Please Login to reply.

Discussion

brugeman 3mo ago 💬 2

Sounds like you're trying to solve the 'what if operator terminates the enclave' with a blockchain? I had a different vision for this, involving custom key stores (also in enclave) - enclave uploads it's keys to keystores (I have 2 now) and if it restarts it can pull those from the keystores (if attestation matches). This can be extended arbitrarily to enclave making a 'backup' of itself - launching a backup process in another enclave instance which will be allowed to pull keys from keystores if the master goes down, etc. This implies that we'd have many operators running compatible app servers in enclaves, all open without kyc paid in bitcoin. That's roughly where I'm going with 'enclaved' server.

Garbage nsec 3mo ago

That architecture is really nice for signing. But for Cashu mints, since putting a mint in a Nitro enclave can't prevent rugging then doing so has to be useful for something else in order to bother (and pay) to do it, and that something else for me is mint insurance. And the smart contract facilitates the business end of the insurance side.

Although maybe there's some other benefit to putting a mint in a cloud enclave that exists despite the fact that token holders can still be rugged, I just haven't been able to think of it.

brugeman 3mo ago 💬 2

How can they still be rugged if mint and it's LN backend are both in the enclave and keys never leave and enclave termination is solved by backups?

Garbage nsec 3mo ago

There are some critical ways in which backups won't help in a Cashu context. The backup can actually be the source of the rug, since the only way a Cashu mint can function is by being a single, authoritative entity. (Double spend and all that.) That means a backup CANNOT be restored unless that specific backup is to take over as the single, authoritative entity, and this leads to all sorts of problems that in the end can only be solved if all backups are under centralised control.

And even if this was solvable, a backup is a snapshot in time, and even if backups are frequent the rug event can easily happen in the shortest of missing time-gaps.

More minor, mint is on an ICANN URL first, and the operator is going to be in control that URL, so there's that.

And other things. For example a vulnerability is discovered and you need to update the code of the mint, or the node, or both, you cannot leave them online in the vulnerable state, they must be shut off. In that case the backups all share this vulnerability, so they are of no use. You need a stable and discoverable source for the new code's hash that has been publicly vetted and which the orchestrator enclave can use to fan out to the fleet, and a smart contract on blockchain can provide that much better than a signed nostr event or something else.

brugeman 3mo ago 💬 2

I would separate rug pull risk from service failure risk. Cashu is custodial without unilateral exit so with or without enclave, if mint goes down, funds are inaccessible. To me it looks like rug pull risks are minimized with enclaves - we could get a lot of independent mints all running verified code, which sounds quite awesome. The rest are reliability questions: backup might be sync real time, coordinator can live in another enclave, dns record can be controlled by the current master, updates don't require a blockchain - just a set of signatures by pre-declared maintainers (that's my current approach). Not that it's a proven set of solutions, or that I am against the blockchain, but I think more experiments are needed to figure out the actual problems and solutions.

Garbage nsec 3mo ago

The biggest issue with Cashu is that even with cloud enclaves (of any kind) there is no escape from central control, and central control means the central controller can rug the token holders. Cashu basically mandates central control no matter where deployed.

If you look at all the ways to build trust in mints that don't rely on cloud enclaves, some are pretty innovative and will get you to the same level of "good enough" as with cloud enclaves. So the only reason to add enclaves if if you can make the leap from "good enough" to "100% sure", otherwise it's just adding cost and latency.

With what you're suggesting I think it maybe could work with Fedimint, but I'm still quite skeptical vis a vis Cashu.

brugeman 3mo ago 💬 2

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.

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.