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.

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?

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

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.

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.

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.

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?

Hi, this sounds great but you're probably 1 of 10 users of this relay and that's just not worth the effort. Besides, I'd say relay-browsing apps should just implement these filters on the client - with wot/reactions/etc as filters, that's much more versatile then me trying to cater to every possible filtering/UX need at the relay level.

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.

Not to be rude, but how do you know it's bad? And bad compared to what? Is there a source that is not bad? I maintained stats for myself to see the real picture, and some people think the real picture is different, but they never cite the source. I 100% support passing the torch to someone, but don't hope the new maintainer will give you much "better" data.

So do you want to work on stats, or the whole package - the relay, the nostr.band site with search, profile stats, trending etc?

Tell me more on why blockchain is needed? To set policies for how to get the keys out? Why would you want the keys out?