If a Lightning node needs its keys to be hot to sign transactions & channel updates, and if that node is running on a VM by a 3rd party LSP provider...

How exactly is that node's key NOT in memory in that server? (aka your keys are accessible to the provider)

Enlighten me pls!

Reply to this note

Please Login to reply.

Discussion

Well, that's exactly what's happening with LN nodes and why many run these nodes at home on their hardware.

#[2]

They can easily just take your admin.macaroon, just a sitting duck, huge risk if the provider knows what they're doing.

Right on!

So why is everyone okay shilling “NON CUSTODIALLY HOST YOUR LN NODE ON OUR INFRA” when they technically have access to the keys?

Don’t even think about the top level provider like GCP and AWS. I’m thinking if LSP providers selling this faux “non custodial” feature

Not your machine/server = not your node = not your key

Agree

Tried a method wherein the box would instantiate and then lock itself down but it still requires a degree of trust that that’s actually what’s taking place.

I though all Lightning wallets were custodial.

Unless you self host.

SGX / Secure Enclaves?

Ofc you must trust that you are running in one; not sure if that’s verifiable from within the enclave

Using a hosted provider at all (even "bare" AWS) does place some trust in the rule of law and your counterparties, we've never suggested that ours is a trustless enterprise, but know some other folks have been less transparent about that sort of thing.

Yeah for sure. My issue is not at all w hosting nodes. I think that’s wonderful and necessary. My concern is more w those that use marketing tactics to suggest something that is factually untrue.

My node runs on AWS. I get your point but uptime is also important for me as a routing node operator.

Pis at home cannot be scalable routing nodes. It's just the reality.

Oh I fully agree. Not saying otherwise. PIs are NOT for Lightning nodes imo 🤷‍♀️