Ark explainer

Pool transaction

The ASP places one (or more) input(s) to its pool transaction to supply funds to the shared UTXO, connectors output, change output, and transaction fees.

Shared output (aka Shared UTXO)

The shared UTXO is locked by 2 taproot leaves:

• A multisig n-of-n, where n is the number of participants in the transaction.
• The other leaf, ASP in 1 month, allows the ASP to spend it alone after 1 month.

In order to be trustless, before signing the pool transaction Alice needs a way to unilaterally get their funds back. To achieve this, the ASP builds and signs a binary tree of transactions and shares them with each participant.

Each leaf on this tree represents a VTXO:

In the example above, Alice can broadcast anytime tx1 => tx2 => tx4 to receive their funds back.
For comparison, Bob will need to broadcast tx1 => tx2 => tx5.

Notes:

• Since tx1:1 => tx2:1 => tx4 (the VTXO) have no fees, Alice will need to add an extra transaction to pay for all the fees (see CPFP).
• The number of transactions on this branches will be equal to log2(n) + 1, where n = number of participants

For clarity, VTXOs will be represented like this:

Example

Alice wants to send sats to Charlie via Bob, which means she will send sats to Bob but only if she is sure Bob will send them to Charlie

1. Bob prepares payment to Charlie (B => C)
   • adds Bob's UTXO as input
   • adds Charlie address as output
   • adds extra output (aka connector), with minimum value possible
   • doesn't sign it, shows transaction to Alice
2. Alice prepares payment to Bob (A => B)
   • adds Alice's UTXO as input
   • adds connector output from B => C as input
   • signs (commiting all inputs with SIGHASH_ALL) and sends to Bob
3. Bob broadcasts
   • signs and broadcasts B => C
   • broadcasts A => B

Payment of A => B is anchored to payment B => C

Onboarding

Alice now wants to enter the Ark, so he must use a process called lifting, which is an atomic two-way peg mechanism that doesn't require trust. Lifting lets users lift their onchain UTXOs off the chain for a 1:1 VTXO. Users can unilaterally redeem a VTXO for an onchain UTXO without asking for ASP cooperation.

1. Alice creates a Funding transaction:
   • adds any segwit output as an input (must be segwit)
   • adds output locked by (Alice + ASP) or (ASP in 1 month)
   • sends it to ASP, not signed
2. Alice receives a signed Redeem transaction from the ASP:
   • spends Funding transaction (1) via Alice + ASP
   • has output locked to (Alice + ASP) or (Alice in 24h)
3. Alice signs and broadcasts Funding transaction (1)
   • Is now safe for Alice to broadcast his funding transaction because now she can leave anytime with Redeem transaction (2) spending Alice in 24h, i.e. Alice will be able to get her funds back in 24 hours.
4. ASP (with Alice) prepares next Pool transaction
5. Alice creates a Forfeit transaction:
   • spends from Redeem transaction (2) via Alice + ASP
   • adds connector output from Pool transaction (4) as input
   • signs (commits all inputs with SIGHASH_ALL) and sends it to the ASP
6. ASP broadcasts Pool transaction (4)
7. Alice has now a VTXO
   • A VTXO is very similar to a Redeem transaction
8. After 1 month ASP spends Funding transaction (1) via ASP in 1 month

So far, Alice polluted onchain by funding an address, and the ASP by claiming funds from that address.

Further steps from here will be footprint minimal.

Adversarial scenarios

• Alice broadcasts Funding transaction (1) but ASP never responds:
  Alice broadcasts Redeem transaction (2) and get his funds back in 24 hours
  
  
• Alice broadcasts Redeem transaction (2) after Pool transaction (3):
  ASP broadcasts Forfeit transaction (5) and claims Alice's funds
  
  
• ASP doesn't wait for confirmation of Funding transaction (1) before broadcasting Pool transaction (4):
  Alice will double spend his original UTXO, making the funding transaction invalid and them spending the VTXO, thus stealing the ASP
  
  

1. Alice asks Bob for an address (address B)
2. Alice informs ASP she wants to pay 0.01 BTC to address B
3. ASP prepares new transaction (Pool Tx 2) and show it to Alice:
4. Alice looks at the locking script for this new UTXO and sees Bob's public key on it
5. Alice understands that when Pool Tx 2 confirms, Bob will have 0.01 BTC on Ark
6. Alice proceeds by signing a PSBT that sends her VTXO to the ASP, on the condition that Pool Tx 2 is confirmed. We will call this the forfeit transaction:
7. ASP cannot cheat, if he wants to receive from Alice he needs to send it to Bob, which means Alice is paying Bob atomically.

"Only if Pool Tx 2 is confirmed"

This condition is not possible to implement today using Bitcoin script, but we can implement it using anchored transactions:

• Pool Tx 1 will have additional outputs, called connectors
• This connectors have no financial value (minimum dust limit)
• Connectors are singlesig spendable by the ASP (ASP)
• Alice will use one of this connectors as input to the new transaction
• Alice will sign her VTXO with SIGHASH_ALL to commit to all inputs
• The ASP will sign the connector input

This way, the transaction where Alice gives her VTXO to the ASP is only valid if Pool Tx 2 is confirmed.

Adversarial scenarios

• Alice doesn't sign the Forfeit transaction
  The ASP doesn't include Bob's VTXO on the next pool transaction
  
  
• ASP never broadcasts the next Pool transaction
  ASP forfeit transaction becomes invalid, which means Alice still has full control of her VTXO
  
  

Collaborative exit

1. Alice generates new onchain address A
2. Alice informs ASP she wants to pay 0.01 BTC onchain to address A
3. ASP (with help of Alice) prepares new transaction (Pool Tx 3) and show it to Alice:
4. Alice sees extra output paying 0.01 BTC to her address
5. Alice understands that when Pool Tx 3 confirms, she will have 0.01 BTC onchain
6. Alice proceeds by sending her VTXO to the ASP, on the condition that Pool Tx 3 is confirmed:
7. ASP cannot cheat, if he wants to receive the VTXO from Alice he needs to send it onchain to Alice, which means Alice is exiting the Ark atomically.

Unilateral exit

Alice can leave the Ark anytime by redeeming hers VTXO for an onchain UTXO.

The cost of this broadcast depends on several factors:

• How many transactions are on Alice's branch?
• How much is mempool fees (sats/vbyte) at the moment?
• Did anyone leaved already, making some of Alice's transactions already confirmed?

Adversarial scenarios

• Alice doesn't sign the Forfeit transaction
  The ASP doesn't include Alice's UTXO on the next pool transaction
  
  
• ASP never broadcasts the next Pool transaction
  ASP forfeit transaction becomes invalid, which means Alice still has full control of her VTXO
  
  

1. Let's say Alice wants to send to Bob
2. Alice gets the ASP to sign a new Shortcut transaction with the following script: (Bob + ASP) or (Alice + ASP) or (Alice in 1 month) (i.e. adding the Bob + ASP condition). We ensure the new Shortcut transaction becomes valid before the old Redeem transaction with timelocks.
3. Now Alice foregoes her claim on the old Redeem transaction by signing an unconditional Forfeit transaction, thus allowing ASP to simply claim the money if Redeem transaction ever gets published.
4. Alice now sends Shortcut transaction to Bob, who can claim the payment by swapping with the ASP. If Bob isn't responsive, Alice can perform the swap instead, or attempt to repeat the same steps with another recipient.

1. Let's say Alice wants to send to Bob
2. Alice gets the ASP to sign a new Shortcut transaction with locking script: (Bob + ASP) or (Bob in 24h)
3. Alice doesn't need to sign a Forfeit transaction
4. The Ark tree will look something like this: