Clarify how unilateral exit works

[basantagoswami]

In all the places in docs.spark.money that I looked, it is mentioned that a user can unilaterally exit by broadcasting their exit transaction.

From https://docs.spark.money/learn/withdrawals#unilateral-exit

Unilateral Exit
If the SE is unavailable or uncooperative, the user can perform a unilateral exit using the pre-signed exit transactions created during the deposit and transfer processes.

1. Broadcasting Branch Transaction: The user broadcasts the branch transaction that was signed during the deposit process.
2. Waiting for Confirmation: Once the branch transaction is confirmed, the user waits for the relative timelock to expire.
3. Broadcasting Exit Transaction: After the timelock expires, the user broadcasts the exit transaction that was signed during the deposit or most recent transfer.
4. Confirmation: Once confirmed, the funds are available in the user’s Bitcoin address.

Reading it, I get the impression that user needs to broadcast only two transaction to unilaterally exit, but reading the code, it seems like the user might have to broadcast up to 50 (!) txns to exit because it's not a exit transaction but rather a chain of transactions leading up to the exit transaction

The more hands the statechain has changed, the worse it gets

Is that correct?

If so, then a user using Spark doesn't have much of a exit guarantee and must rely on the operators to collaboratively exit. The system, thus is not any better than a completely custodial system for most of the users.

[bitcoinuser]

The system, thus is not any better than a completely custodial system for most of the users.

I think the idea is: as the federation can't steal so it does have the incentive for the operators to allow collaboratively exit.

[basantagoswami]

I don't think the incentive works here. If most users can't unilaterally exit, and the Spark entity has nothing to lose from not allowing collaborative withdrawals, then the incentive is to keep them stuck in that system forever to make money via fees. Also a system like that can slowly become one where users have to KYC or do some other kind of compliance to keep using it. Only the users have something to lose in this system from not collaborating with the SE

As of now, all the wallets built on Spark that I have come across don't even show anything to the user about their cost of exiting the system to onchain

Another thing is, the Spark Service Providers are supposed to be anyone who's willing to participate to provide swaps etc to the end users. But if they are swapping Spark txn leaves for lightning payments on behalf of the users, they also have the same issue as the end users. They have these leaves that they can't exit to onchain easily with. That means incentives force the SSPs to be "friends" of the SE or the SE itself or one of the operators in the SE

Overall, almost all the good things about Spark (at least The ones that are highlighted repeatedly by their marketing materials) disappear completely if there is no way for the exit txn chain depth to be refreshed somehow

[bitcoinuser]

I don't think the incentive works here. If most users can't unilaterally exit, and the Spark entity has nothing to lose from not allowing collaborative withdrawals, then the incentive is to keep them stuck in that system forever to make money via fees. Also a system like that can slowly become one where users have to KYC or do some other kind of compliance to keep using it. Only the users have something to lose in this system from not collaborating with the SE

Spark:

1- Can't steal.
2- If they do not allow collaborative withdraws, has a reputation risk or even legal risk.
3- Yes, they can require KYC, but custodial services too, and custodial services can steal.
4- Spark at least can have unilateral exit for not small amounts.

So I see this model much better than custodial.