<p>Good question. There are different options that are being considered that each have their own set of trade-offs. Let me dig into the main options.</p>
<p>The first and most obvious solution is to use the exact same construction as is used for the vTXO output: <strong>a transaction tree, built using a covenant, so that each leaf output is a connector</strong> and each connector is used for a single forfeit transaction.</p>
<p>Similarly such a pre-specified transaction tree can also created without a covenant, but to be entirely pre-signed by the service provider. Because no one else in the protocol cares whether this transaction tree can be broken down but the service provider, this is safe. Similarly each leaf in the tree would be a connector for a single forfeit transaction.</p>
<p>When using a tree of N items, that means that to use a single connector, the service provider would have to broadcast and finance <code>log2(N)</code> transactions. This is unfortunate and can be optimized. An alternative solution is to use <strong>a single series or chain of N subsequent transactions, each of which create a single connector output</strong>. In the previous solutions, we asked each user participating in the round to sign a single forfeit transaction using a single connector input; in this solution we will ask them to sign N different forfeit transactions using each of the N connectors that were created in this chain. This means that the service provider can always unlock a working connector for any forfeit transaction by broadcasting just a single transaction. The trade-off is that users have to do a little bit more work to sign many different transactions.</p>

CC BY-SA 4.0
2023-10-22T14:02:36.603Z
2023-10-24T11:07:28.743Z
2023-10-24T11:07:28.743Z
Steven Roose
<p>According to <a href="https://www.arkpill.me/deep-dive" rel="nofollow noreferrer">https://www.arkpill.me/deep-dive</a>, pool transactions contain 2 main outputs related to the protocol:</p>
<ol>
<li>The vTXOs output</li>
<li>The connectors output</li>
</ol>
<p>I understand that vTXOs output is a partially signed bitcoin transaction (psbt) binary tree where 1 leaf = 1 vTXO.</p>
<p>Is it the same format for connectors (binary tree)? Or is it a single (virtual) psbt splitting the connectors output into X dust outputs?</p>

<ark>
How are the connectors batched in Ark pool transactions?
Louis Singer
# How are the connectors batched in Ark pool transactions?

(Asked by: username_0 on 2023-10-17)

According to <https://www.arkpill.me/deep-dive>, pool transactions contain 2 main outputs related to the protocol:

1. The vTXOs output
2. The connectors output

I understand that vTXOs output is a partially signed bitcoin transaction (psbt) binary tree where 1 leaf = 1 vTXO.

Is it the same format for connectors (binary tree)? Or is it a single (virtual) psbt splitting the connectors output into X dust outputs?

**Tags:** ark


---

## 1 answers

### Answer by username_1 on 2023-10-22. Score: 1 | Accepted answer

Good question. There are different options that are being considered that each have their own set of trade-offs. Let me dig into the main options.

The first and most obvious solution is to use the exact same construction as is used for the vTXO output: **a transaction tree, built using a covenant, so that each leaf output is a connector** and each connector is used for a single forfeit transaction.

Similarly such a pre-specified transaction tree can also created without a covenant, but to be entirely pre-signed by the service provider. Because no one else in the protocol cares whether this transaction tree can be broken down but the service provider, this is safe. Similarly each leaf in the tree would be a connector for a single forfeit transaction.

When using a tree of N items, that means that to use a single connector, the service provider would have to broadcast and finance `log2(N)` transactions. This is unfortunate and can be optimized. An alternative solution is to use **a single series or chain of N subsequent transactions, each of which create a single connector output**. In the previous solutions, we asked each user participating in the round to sign a single forfeit transaction using a single connector input; in this solution we will ask them to sign N different forfeit transactions using each of the N connectors that were created in this chain. This means that the service provider can always unlock a working connector for any forfeit transaction by broadcasting just a single transaction. The trade-off is that users have to do a little bit more work to sign many different transactions.


---

