This post describes a bond which improves the economic security of one-time, out-of-round assignments of Ark VTXOs. These assignments are intended to enable instant opening of small-value just-in-time Lightning channels with inbound liquidity for the user. The bond works by making equivocation in the VTXO assignment provable on-chain using 

. Each assignment is authorized by a signature over the BIP-341 sighash of the assignment transaction, so conflicting authorization signatures provide exactly the evidence needed for an equivocation proof. Using 

 to prove equivocation in an off-chain protocol may also be useful beyond this application.

For end users, receiving initial Lightning payments is a significant impediment to onboarding into the ecosystem. For LSPs, onboarding requires pricing the risk of channel abandonment into JIT channel support, increasing fees and capital requirements. Ark servers can instead preallocate small-value VTXOs in their transaction trees which they can assign out-of-round (OOR) to open channels just-in-time. This enables instant channel opening without additional on-chain cost for the Ark server, and abandoned channels are automatically swept with the rest of the tree!

I propose that Ark servers post an on-chain “equivocation bond” which can be slashed by providing an “equivocation proof”. The Ark server preallocates VTXOs 

 must be assignable by producing a signature with the respective key 

 which fully commits to the spending transaction. Every key 

 is chosen unilaterally by the Ark server, but must be globally unique and single-use to prevent spurious bond slashing. To assign a preallocated VTXO to Alice, Alice and the Ark server agree on an assignment transaction funding a Lightning channel between them. The Ark server signs the assignment transaction with key 

. If the Ark server signs a conflicting assignment transaction assigning the same VTXO to a JIT channel with Bob, this produces a signature with 

lightning

> This post describes a bond which improves the economic security of one-time, out-of-round assignments of Ark VTXOs. These assignments are intended to enable instant opening of small-value just-in-time Lightning channels with inbound liquidity for the user. The bond works by making equivocation in the VTXO assignment provable on-chain using `OP_CHECKSIGFROMSTACK`. Each assignment is authorized by a signature over the BIP-341 sighash of the assignment transaction, so conflicting authorization signatures provide exactly the evidence needed for an equivocation proof. Using `OP_CHECKSIGFROMSTACK` to prove equivocation in an off-chain protocol may also be useful beyond this application.

> For end users, receiving initial Lightning payments is a significant impediment to onboarding into the ecosystem. For LSPs, onboarding requires pricing the risk of channel abandonment into JIT channel support, increasing fees and capital requirements. Ark servers can instead preallocate small-value VTXOs in their transaction trees which they can assign out-of-round (OOR) to open channels just-in-time. This enables instant channel opening without additional on-chain cost for the Ark server, and abandoned channels are automatically swept with the rest of the tree!

## Solution (Using CSFS)

> I propose that Ark servers post an on-chain “equivocation bond” which can be slashed by providing an “equivocation proof”. The Ark server preallocates VTXOs `V_0`, `V_1`, …, `V_n` to use in this scheme. Each VTXO `V_0`, `V_1`, …, `V_n` must be assignable by producing a signature with the respective key `K_0`, `K_1`, …, `K_n`. Every VTXO spending path for `V_i` must require a signature with `K_i` which fully commits to the spending transaction. Every key `K_i` in `K_0`, `K_1`, …, `K_n` is chosen unilaterally by the Ark server, but must be globally unique and single-use to prevent spurious bond slashing. To assign a preallocated VTXO to Alice, Alice and the Ark server agree on an assignment transaction funding a Lightning channel between them. The Ark server signs the assignment transaction with key `K_i`, producing a signature over a message `M_a`. If the Ark server signs a conflicting assignment transaction assigning the same VTXO to a JIT channel with Bob, this produces a signature with `K_i` over a second message `M_b`.