<p>In Ark, all virtual tx outputs (vtxos) are actually outputs on the leaf txs of a binary tree of transactions. The reason for this is two-fold: so that a single person exiting doesn't have to broadcast all the vtxo outputs for all vtxos in the Ark tx and so that in the case of mass exit, the process smoothens out and there is more time for everyone to exit slowly.</p>
<p>You could think of the vtxo tree of a tree of transactions that each have one input and two outputs and like that they form a tree structure. Think of these transactions as transactions that are already pre-specified upfront. They can either be pre-signed or pre-specified using introspection opcodes. This means that all these transactions are valid Bitcoin transactions and could all in theory be confirmed. However, they don't carry any fee and no one has an incentive to broadcast them to the network.</p>
<p>Such a tree might look like this:
<a href="https://i.sstatic.net/La3VJ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/La3VJ.png" alt="enter image description here" /></a></p>
<p>In this tree, there are 4 leaves, A, B, C and D; they are actual valid transaction outputs and we will call them &quot;vtxos&quot;. Virtual because they are not confirmed yet, but can be confirmed if they would be mined.</p>
<p>Now, for the vtxo A to be confirmed, let's say because its owner wants to spend the money on-chain, all the transactions going from the on-chain output (the top-most &quot;cov&quot;) towards the leaf A have to be confirmed on the chain.</p>
<p><a href="https://i.sstatic.net/SeCZe.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/SeCZe.png" alt="enter image description here" /></a></p>
<p>Because this is a binary tree, the number of nodes in a branch is <code>log2(n)</code> where <code>n</code> is the number of leaves, plus one for the leaf itself. So that means <code>log2(4) + 1</code> is 3 transactions to be confirmed.</p>

CC BY-SA 4.0
2023-09-29T15:45:08.867Z
How can these txs be broadcasted if they have no fees? maybe CPFP?
altafan
CC BY-SA 4.0
2023-09-29T16:21:01.580Z
Yeah that is something still in the design phase. CPFP is definitely the most obvious option. Even though the nature of the timelocks makes it non-trivial. Probably a (ephemeral) fee anchor output would be required if we use pre-signed txs or OP_CTV.
Steven Roose
CC BY-SA 4.0
2023-10-02T18:07:36.050Z
Does one person paying out their vtxo necessitate that other users participating in that batch also go on-chain?
Murch
CC BY-SA 4.0
2023-10-03T12:55:25.410Z
Let's say A and B want to unilaterally exit the ark at the same time, they would try to broadcast the same chain of txs, wouldn't they? How would this be handled?
altafan
CC BY-SA 4.0
2023-10-04T16:35:17.483Z
> Let's say A and B want to unilaterally exit the ark at the same time, they would try to broadcast the same chain of txs, wouldn't they? How would this be handled?
--
@altafan I would say that if B waits for A to broadcast, then B will only need to broadcast one transaction
bordalix
CC BY-SA 4.0
2023-10-06T17:32:24.333Z
@Murch, no, as per design that is never required. All exits can be done independently, the only effect would be that others might already have part of their branch broadcast/confirmed if they try to, so they will have to pay less fees.
Steven Roose
CC BY-SA 4.0
2023-10-06T17:34:02.687Z
@altafan they are exactly the same txs. So that would be handled normally. Like when two channel partners try to broadcast the exact same tx at the same time. In Ark, only part of the txs would overlap, but there would not be a conflict.
In constructions with a more flexible covenant, like TXHASH, the tx chain might actually be malleable and if one of the nodes goes in first, the other user might have to re-broadcast the leftover part of his branch with updated prevouts.
Steven Roose
CC BY-SA 4.0
2023-09-29T15:08:18.103Z
2023-09-29T15:08:18.103Z
Steven Roose
<p>It's been told <a href="https://bitcoin.stackexchange.com/a/119822/145037">here</a> that the cost of a unilateral exit depends on the number of leaves of the shared vtxo tree, which determines the number of transactions one has to broadcast to complete the process.</p>
<p>Why does the unilateral exit require multiple transactions to be broadcasted?</p>

<ark>
How does the unilateral exit process in Ark work?
altafan
# How does the unilateral exit process in Ark work?

(Asked by: username_0 on 2023-09-29)

It's been told [here](https://bitcoin.stackexchange.com/a/119822/145037) that the cost of a unilateral exit depends on the number of leaves of the shared vtxo tree, which determines the number of transactions one has to broadcast to complete the process.

Why does the unilateral exit require multiple transactions to be broadcasted?

**Tags:** ark


---

## 1 answers

### Answer by username_1 on 2023-09-29. Score: 3

In Ark, all virtual tx outputs (vtxos) are actually outputs on the leaf txs of a binary tree of transactions. The reason for this is two-fold: so that a single person exiting doesn't have to broadcast all the vtxo outputs for all vtxos in the Ark tx and so that in the case of mass exit, the process smoothens out and there is more time for everyone to exit slowly.

You could think of the vtxo tree of a tree of transactions that each have one input and two outputs and like that they form a tree structure. Think of these transactions as transactions that are already pre-specified upfront. They can either be pre-signed or pre-specified using introspection opcodes. This means that all these transactions are valid Bitcoin transactions and could all in theory be confirmed. However, they don't carry any fee and no one has an incentive to broadcast them to the network.

Such a tree might look like this:
[![enter image description here](https://i.sstatic.net/La3VJ.png)](https://i.sstatic.net/La3VJ.png)

In this tree, there are 4 leaves, A, B, C and D; they are actual valid transaction outputs and we will call them "vtxos". Virtual because they are not confirmed yet, but can be confirmed if they would be mined.

Now, for the vtxo A to be confirmed, let's say because its owner wants to spend the money on-chain, all the transactions going from the on-chain output (the top-most "cov") towards the leaf A have to be confirmed on the chain.

[![enter image description here](https://i.sstatic.net/SeCZe.png)](https://i.sstatic.net/SeCZe.png)

Because this is a binary tree, the number of nodes in a branch is `log2(n)` where `n` is the number of leaves, plus one for the leaf itself. So that means `log2(4) + 1` is 3 transactions to be confirmed.

> **Comments:**
> **username_0**: How can these txs be broadcasted if they have no fees? maybe CPFP?  
> **username_1**: Yeah that is something still in the design phase. CPFP is definitely the most obvious option. Even though the nature of the timelocks makes it non-trivial. Probably a (ephemeral) fee anchor output would be required if we use pre-signed txs or OP_CTV.  
> **username_2**: Does one person paying out their vtxo necessitate that other users participating in that batch also go on-chain?  
> **username_0**: Let's say A and B want to unilaterally exit the ark at the same time, they would try to broadcast the same chain of txs, wouldn't they? How would this be handled?  
> **username_3**: > Let's say A and B want to unilaterally exit the ark at the same time, they would try to broadcast the same chain of txs, wouldn't they? How would this be handled? -- @username_0 I would say that if B waits for A to broadcast, then B will only need to broadcast one transaction  
> **username_1**: @username_2, no, as per design that is never required. All exits can be done independently, the only effect would be that others might already have part of their branch broadcast/confirmed if they try to, so they will have to pay less fees.  
> **username_1**: @username_0 they are exactly the same txs. So that would be handled normally. Like when two channel partners try to broadcast the exact same tx at the same time. In Ark, only part of the txs would overlap, but there would not be a conflict. In constructions with a more flexible covenant, like TXHASH, the tx chain might actually be malleable and if one of the nodes goes in first, the other user might have to re-broadcast the leftover part of his branch with updated prevouts.  

---

