If there’s a way to unilaterally exit but we don’t provide it, and we don’t even store the state to provide it later, then we are to blame if stackers lose funds. If you lose funds using a custodial wallet, it’s not our fault.

> Yeah that was my point above.

Ah, mhh, but for me these are two different points:

1. Unilateral exit if the wallet is only ever funded via lightning
2. How lightning is implemented to stay trustodial

Why is it blocking? I count 16 custodial "wallets" in the list (though I may be off by a couple in either direction because thinking about these gives me headaches)

----

Re: edit

> Or did Spark find a way to "decentralize a lightning node"?

Yeah that was my point above.

optimism

afaik the LN interface is as custodial as npubcash, i.e. you have no cryptographic / on-chain recourse when the LN channel fucks up?

So far, I have to agree. Before I went on vacation, I was looking into exactly this: how to get the presigned tx for unilateral exit when I fund my wallet via lightning, not on-chain.

Afaik, the only thing I get when I pay a lightning invoice is a 

 property ("leaves transfer after lightning payment was sent") might be related, but I haven't looked further into it.

edit: Btw, I even wonder how Spark can stay trustodial via lightning. The sats must be going into some channel right? Isn't just one entity (not many) running the lightning node? Or did Spark find a way to "decentralize a lightning node"?

Lots Of Riders Without Their Weapons

siggy47

> afaik the LN interface is as custodial as npubcash, i.e. you have no cryptographic / on-chain recourse when the LN channel fucks up?

So far, I have to agree. Before I went on vacation, I was looking into exactly this: how to get the presigned tx for unilateral exit when I fund my wallet via lightning, not on-chain.

Afaik, the only thing I get when I pay a lightning invoice is a [`LightningSendRequest`](https://github.com/buildonspark/spark/blob/f7ec21b7008c620851d4bf0cc3e13fbd2f2861d8/sdks/js/packages/spark-sdk/src/graphql/objects/LightningSendRequest.ts#L12-L48). The `transfer` property ("leaves transfer after lightning payment was sent") might be related, but I haven't looked further into it.

This is currently blocking [adding Spark to SN](https://github.com/stackernews/stacker.news/pull/2575).

---

edit: Btw, I even wonder how Spark can stay trustodial via lightning. The sats must be going into some channel right? Isn't just one entity (not many) running the lightning node? Or did Spark find a way to "decentralize a lightning node"?