<p>In Ark there is a process called lifting. When a user lift funds they take an onchain <code>utxo</code> (unspent transaction output) and getting an ark <code>vtxo</code> (virtual transaction output) in return.</p>
<p>To explain lifting it is crucial to understand what a <code>vtxo</code> is.</p>
<p>First of all, a <code>vtxo</code> is a specific type of bitcoin-transaction. We call it virtual because the transaction is supposed to never go on chain.</p>
<p>In Ark, a <code>vtxo</code> has a very specific design. The design allows the owner to spend the coins in the <code>vtxo</code>-unilaterally. However, there is some kind of an expiry date. After 4 weeks the <code>vtxo</code> expires and the Ark Service Provider is allowed to grab the funds.</p>
<p>Now we understand what a <code>vtxo</code> is. Creating a lifting protocol isn't that hard. Together, the user and ASP can create a virtual transaction that has a <code>vtxo</code> as an output. They also create a lifting transaction that can only be used to fund the virtual transaction.</p>
<p>At this point the transactions are created but aren't funded yet. The user has seen the transactions and knows that unilateral exit path exist. The user can safely sign and broadcast the transaction. The user has lifted their funds and has a <code>vtxo</code> that can be used.</p>
<p>However, it is not exactly like a <code>vtxo</code> yet. The ASP will only allow the user to spend the <code>vtxo</code> once the on-chain lifting transaction is confirmed. The ASP doesn't want to be the victim of a double-spend attack.</p>
<p>The double-spend attack is also exactly why the pool transaction must be fully funded by the ASP. If users would fund the pool transactions directly. An evil user could double-spend and prevent the pool-transaction from making it on chain.</p>

CC BY-SA 4.0
2023-10-04T16:02:18.700Z
so lifting transactions are the pool transactions ? and they need to be signed by the users joining the Ark?
Louis Singer
CC BY-SA 4.0
2023-10-04T19:01:45.693Z
No, they are two different kind of transactions.
Both go on chain though
Erik
CC BY-SA 4.0
2023-10-10T16:44:34.653Z
To summarize, you can lift your own on-chain utxo directly into a vtxo and then you can use this vtxo just like any other vtxo that was the result of an Ark round: you can spend it in an Ark round in return for other vtxos
Steven Roose
CC BY-SA 4.0
2023-10-13T14:27:35.470Z
> The ASP will only allow the user to spend the vtxo once the on-chain lifting transaction is confirmed.



How is this enforced?
altafan
CC BY-SA 4.0
2023-10-13T15:14:28.190Z
Spending a vtxo is like an atomic swap between an old and a new vtxo. 

The ASP can just decide to not provide the new vtxo
Erik
CC BY-SA 4.0
2023-10-16T12:06:49.473Z
AFAIU, the lifting tx cannot be broadcasted before the pool tx where the vtxo is created because the pool tx's connector output is used as input of the lifting one. 

Therefore, the pool tx must be broadcasted first in this scenario. And once a pool tx is broadcasted, vtxos are created and can be redeemed at any time, so how could the ASP enforce what you said? Did I misunderstand something?
altafan
CC BY-SA 4.0
2023-10-16T13:06:09.357Z
The order you described isn't correct.

The pool tx and vtxo's are created first. Then, the pool transaction  is broadcasted.
Erik
CC BY-SA 4.0
2023-10-04T13:17:55.327Z
2023-10-04T13:17:55.327Z
Erik
<p>This is the definition of a pool transaction taken from <a href="https://arkpill.me/deep-dive" rel="nofollow noreferrer">https://arkpill.me/deep-dive</a>:</p>
<blockquote>
<p>Pool transactions are created by Ark service providers perpetually every 5 seconds, which are effectively blinded, footprint-minimal, rapid coinjoin rounds.</p>
<p>ASP funds the coinjoin with their own on-chain funds in exchange for vTXOs redemptions. Therefore, the coinjoin transaction that hits on-chain has only one or a few inputs provided by the ASP.</p>
<p>The pool transaction has three outputs: vTXOs output, connectors output, and ASP change. Service providers place vTXOs for the intended recipients to claim (under the vTXOs output) and connectors for senders to connect (under the connectors output) in their pools.</p>
</blockquote>
<p>The doc says that all inputs of a pool tx are owned by the ASP. When Alice joins the ark by onboarding/lifting, how does this actually work if her on-chain funds are not used as inputs of the pool tx?</p>
<p>The most obvious explanation to me (I'm pretty sure it's not the right one though) is that Alice sent her funds to the ASP in a prior tx, but how could she be sure that the ASP will create the vtxos for her in the pool tx?</p>

<ark>
Clarification on Ark pool transaction inputs
altafan
# Clarification on Ark pool transaction inputs

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

This is the definition of a pool transaction taken from <https://arkpill.me/deep-dive>:

> Pool transactions are created by Ark service providers perpetually every 5 seconds, which are effectively blinded, footprint-minimal, rapid coinjoin rounds.
>
> ASP funds the coinjoin with their own on-chain funds in exchange for vTXOs redemptions. Therefore, the coinjoin transaction that hits on-chain has only one or a few inputs provided by the ASP.
>
> The pool transaction has three outputs: vTXOs output, connectors output, and ASP change. Service providers place vTXOs for the intended recipients to claim (under the vTXOs output) and connectors for senders to connect (under the connectors output) in their pools.

The doc says that all inputs of a pool tx are owned by the ASP. When Alice joins the ark by onboarding/lifting, how does this actually work if her on-chain funds are not used as inputs of the pool tx?

The most obvious explanation to me (I'm pretty sure it's not the right one though) is that Alice sent her funds to the ASP in a prior tx, but how could she be sure that the ASP will create the vtxos for her in the pool tx?

**Tags:** ark


---

## 1 answers

### Answer by username_1 on 2023-10-04. Score: 4

In Ark there is a process called lifting. When a user lift funds they take an onchain `utxo` (unspent transaction output) and getting an ark `vtxo` (virtual transaction output) in return.

To explain lifting it is crucial to understand what a `vtxo` is.

First of all, a `vtxo` is a specific type of bitcoin-transaction. We call it virtual because the transaction is supposed to never go on chain.

In Ark, a `vtxo` has a very specific design. The design allows the owner to spend the coins in the `vtxo`-unilaterally. However, there is some kind of an expiry date. After 4 weeks the `vtxo` expires and the Ark Service Provider is allowed to grab the funds.

Now we understand what a `vtxo` is. Creating a lifting protocol isn't that hard. Together, the user and ASP can create a virtual transaction that has a `vtxo` as an output. They also create a lifting transaction that can only be used to fund the virtual transaction.

At this point the transactions are created but aren't funded yet. The user has seen the transactions and knows that unilateral exit path exist. The user can safely sign and broadcast the transaction. The user has lifted their funds and has a `vtxo` that can be used.

However, it is not exactly like a `vtxo` yet. The ASP will only allow the user to spend the `vtxo` once the on-chain lifting transaction is confirmed. The ASP doesn't want to be the victim of a double-spend attack.

The double-spend attack is also exactly why the pool transaction must be fully funded by the ASP. If users would fund the pool transactions directly. An evil user could double-spend and prevent the pool-transaction from making it on chain.

> **Comments:**
> **username_2**: so lifting transactions are the pool transactions ? and they need to be signed by the users joining the Ark?  
> **username_1**: No, they are two different kind of transactions. Both go on chain though  
> **username_3**: To summarize, you can lift your own on-chain utxo directly into a vtxo and then you can use this vtxo just like any other vtxo that was the result of an Ark round: you can spend it in an Ark round in return for other vtxos  
> **username_0**: > The ASP will only allow the user to spend the vtxo once the on-chain lifting transaction is confirmed.    How is this enforced?  
> **username_1**: Spending a vtxo is like an atomic swap between an old and a new vtxo.   The ASP can just decide to not provide the new vtxo  
> **username_0**: AFAIU, the lifting tx cannot be broadcasted before the pool tx where the vtxo is created because the pool tx's connector output is used as input of the lifting one.   Therefore, the pool tx must be broadcasted first in this scenario. And once a pool tx is broadcasted, vtxos are created and can be redeemed at any time, so how could the ASP enforce what you said? Did I misunderstand something?  
> **username_1**: The order you described isn't correct.  The pool tx and vtxo's are created first. Then, the pool transaction  is broadcasted.  

---

