Withdrawals to L1
There are two ways to exit Spark to L1 - either by using an SSP or by unilaterally exiting.
Using an SSP
Steps-by-Step Process
Cooperative exits via an SSP offer the most cost-effective and efficient way to withdraw funds from Spark. In this process, the SSP performs an atomic swap, exchanging on-chain funds for the user’s leaves in Spark. When a user initiates a withdrawal, they collaborate with the SSP to craft a transaction (let’s call it N) for use on L1. Although not immediately published, this transaction spends from the SSP’s UTXO on L1 and creates three outputs: change returned to the SSP, funds transferred to the user, and a dust output serving as a connector.
The user now transfers ownership of the leaf to a combination of User+SSP. The user and SSP craft a transaction that spends from the dust connector and the leaf.
At this point, the SSP can safely put their swap transaction N on-chain. The user now has their funds on-chain.
Once the on-chain transaction has been included in a block, the SSP and user both sign off on sending the Spark leaf/leaves to be owned solely by the SSP.
If the SSP never sends the on-chain transaction, the user can put their branch on-chain and claim the second-to-last redemption transaction (because the SSP cannot claim the most recent one if they have not published the connector transaction).
If the user refuses to update the leaf to give control of it solely to the SSP, then the SSP can still claim the funds by putting the branch on-chain, since the SSP has published the connector transaction.
Unilateral Exit
The user can unilaterally exit Spark at any time by broadcasting the exit transaction for their leaf or leaves. In cases where the leaf is the child of a branch, the branch transaction will need to be broadcast first.
Any user who has previously held the leaf could attempt to publish an old state. The current user will always have a signed transaction with the lowest timelock. If the current user is not online, the individual SOs can optionally serve as watchtowers on behalf of the current user and publish the latest transaction state if the previous owner attempts to be malicious and broadcast an invalid state. The SO’s can do this since each leaf (unless it’s the root of a tree) has one or many parent transactions that need to be broadcast before the leaf and to trigger the leaf’s time bomb. Depending on the configuration of the tree, this attack can be costly for the attacker, who may need to CPFP each branch node. Further, any party can act as a watchtower, not solely the SOs. Contrary to Lightning, the exit transaction is not toxic in itself - i.e. an old commitment transaction in Lightning can be punished - so the lowest exit transaction can be concurrently broadcast by any number of entities. Any additional party serving as a watchtower measurably adds to security for the end-user.