# [DRAFT] Spark leaves
*There are probably some errors in this post. Feel free to leave a comment on anything that is incorrect!*
### Spark intro

Spark is a statechain protocol. This means that it locks a UTXO that is spendable by a 2/2 [in Spark specifically, it is a 1+(2/2)] multisig. One key is held by a user. The other key is held by the statechain entity, which requires 2/2 signers in a FROST scheme to produce a valid signature for this keyshare. To immediately spend the funds in the multisig, both key holders need to sign a transaction.

The purpose of moving your funds onto Spark is to send bitcoin around offchain. Users do this by transferring ownership of one of the signing keys in the multisig. During the transfer, the statechain entity tweaks their respective keyshare value so that only the current owner, plus the statechain entity, can produce a valid signature to move the funds. The statechain entity is expected to delete the keyshare it held with a previous owner. This means that only current owners can spend the UTXO, immediately, with the statechain entity. Every owner, previous and current, of the UTXO can broadcast a unilateral exit path. Using decrementing timelocks, the current owner's exit path expires before previous owners which sees them be the first person to spend transactions related to the exit path before anyone else.

### Leaves

To avoid having to solely spend fixed denominations, Spark splits UTXOs into leaves.

A Spark leaf is an output that is created by constructing pre-signed transactions with the statechain entity that spends a parent UTXO and creates new outputs. Let’s say we want to create two leaves. First, we construct a transaction that uses the original UTXO as the input and creates two leaves as the outputs. But, we don’t broadcast it. The outputs are now leaves that you can send, individually, on Spark. This is done entirely offchain.

The newly created, now separate outputs have their own unilateral exit paths. When the leaves are created, you work with the statechain entity to pre-sign the respective unilateral exit paths. Additionally, the statechain entity deletes their keyshare for the branch UTXOs, meaning that users can only spend leafs with the statechain entity.

To unilaterally spend the funds, you broadcast the entire exit path. For each of these two, newly created leaves the path would be:

Txn0, the onchain, deposit transaction is spent to create a root, offchain UTXO, Txn1. This is then spent to create two new outputs that connect the newly created leaves to Txn1. When you unilaterally exit with a leaf, for example, you broadcast the entire exit path, thus spending, for example, Txn0, Txn1, and now Txn2, which creates a new output on bitcoin whose path is derived from Txn0.


Building on the example above, when Bob sends Alice a leaf, Bob transfers ownership of the leaf to Alice. The Statechain tweaks the keyshare values for the keys that can spend the leaf and deletes the keyshare they held with Bob. Then Alice and the Statechain entity pre-sign a new exit transaction with a lower timelock. This transfer of ownership is effectively replacing the unilateral exit transaction with a new one that has a lower timelock.

To leave the statechain, Alice similarly broadcasts the entire unilateral exit path associated with her newly received leaf. On Bitcoin, she spends Txn0, Txn1…, and now Txn3 to create Txn4, onchain. But, no other users are required to come onchain because this exit path is specifically associated with the leaf that was spent in Tx4. Other paths that additionally spend Txn0, Txn1..., and so on, build on the spent transactions that are included in their path and then spend any pre-signed, unspent outputs to ultimately unilaterally exit with their leaf.

### Possible issues

The above is a simple explination of creating Spark leaves.

An issue with this is when a transaction is buried in a Spark tree. Let’s say your leaf is 99 branches away from the original output within a tree. You would have to broadcast 99 individual transactions, starting from the original root UTXO, to claim your funds onchain. To ensure users don't get buried in a tree, Spark implements a max depth for leaves that can be created. This means that leaves can only be branched so far away from a parent UTXO. Additionally, users do not have to split their own leaves. They can atomic swap with a service provider to receiver newly generated leaves instead of having to split their own.

Another issue is that every leaf within the tree has its own, valid unilateral exit path that is pre-signed by a previous owner and the statechain entity. If the tree of ownership has a dozen of previous owners, you trust them all to not broadcast their unilateral exit path. Let’s say the owner of the previously spent Tx3 decides to publish their pre-signed unilateral exit path maliciously. The owner of the output created by Tx12 must then publish their exit transaction to ensure they retain their funds. Owners of other unspent leaves in the branch must also publish their unilateral exit transactions onchain. If none of the owners of unspent leaves, derived from Tx3, publish their unilateral exit transaction, then all leaves created after Tx3 are effectively double-spent. If one of them publishes their unilateral exit transaction, then all other leaves are safe.

To help mitigate this risk, Spark Operators participating in the Statechain Entity additionally act as watch towers that can broadcast current owner's unilateral exit transactions to prevent cheating from previous owners. Still, this forces current owners onchain.

### Summary

Spark enables users to split the denominations of UTXOs offchain, while ensuring every new virtual output has their own unilateral exit path. However, each leaf should be worth an economically, spendable UTXO on bitcoin. This is because operators can go offline in Spark, and previous leaf owners in a branch can publish their unilateral exit transaction, forcing current owners onchain.