Author: Anony
"Sharing UTXO" (hereinafter referred to as "sharing UTXO"), as the name implies, allows multiple users to share the ownership of a UTXO and allow their funds to be deposited in the same UTXO. The focus of this concept is not on the management of permissions, but on the expression and control of internal status - allowing multiple users' funds to be stored in one UTXO, but still ensuring autonomous custody without being infringed by other users.
The concept of "shared UTXO" has been under discussion and development for a long time. In the broadest sense, any design that controls UTXO by more than one party can be considered as such. This broadest definition would also include two-party shared UTXO such as "lightning channels". Even if we intentionally exclude such two-party shared UTXO and only include cases where three or more parties share UTXO, then the concept of "channel factory" [1] proposed in 2018 is undoubtedly a subset of shared UTXO. In addition, the concept of "coin pool" [2] proposed in 2020, as well as some designs proposed "incidentally" when discussing the "covenant" proposal [3] , have added content to this topic.
In fact, the designs proposed are so diverse that they are prone to confusion and confusion (at least for me). These obstacles to understanding require us to summarize the commonalities of these designs, identify a basic concept, and explain these designs based on this basic concept and the corresponding terminology.
It is worth mentioning that some authors have already started to do this explicitly (treating seemingly different concepts as different designs of the same concept) [4] ; Optech's theme interface also merged the similarly meaning "payment pool" and "Coinpool" into the name of "Joinpool" [5] (but still did not propose the basic concepts of "Joinpool" and "channel factory").
Inspired by these efforts, this article attempts to use "shared UTXO" as a basic concept, discuss the basic problems faced by this concept, and explain the forms and characteristics of some common designs (such as: channel factory, Statechain, ARK).
Before that, we need to explain some more basic concepts.
Basic Concepts
Commitment Transaction
In a contractual protocol, a "commitment transaction" refers to a transaction that has been signed by the counterparty (thus valid and available) but is not broadcasted by default. These transactions can be regarded as a "trusted commitment" given by the counterparty, and are also a guarantee for participants to ensure that they can unilaterally retrieve the funds they deserve.
For example, in a lightning channel, both parties must give the other party a commitment transaction when the channel is initialized and each time the channel status is updated; these commitment transactions record the latest status (balance) of the two parties in the channel, and once they are sent to the chain for confirmation, the channel funds will be split between the two parties.
What needs to be emphasized here is the ability of commitment transactions to express the internal state of a contract. A lightning channel is only represented as a UTXO on the chain, but it can accommodate the funds of two users, relying on this ability of commitment transactions.
vTXO
In the context of "shared UTXO", "vTXO (virtual UTXO)" refers to the most basic unit of user funds in UTXO. This term is proposed for the convenience of analysis and expression. But at the same time, such a name also has a strict factual basis: given that we express user funds in the output of commitment transactions (TXO), the movement of these funds is no different from UTXO.
Here, I divide vTXO into two types: (1) Exclusively owned funds (like common single-signature UTXO), which can be called "coins"; (2) Lightning channels . The reason for dividing them into two types here (rather than treating Lightning channels as a shared UTXO and treating them as only the former type) is that: (1) The transaction outputs of Lightning channels all have devices specially designed to implement the "off-chain update mechanism" mentioned below, which cannot be counted as coins; (2) Exclusively owned funds and Lightning channels have very different user experiences: Lightning channels allow instant payments (at the same time, Lightning Network can amplify this payment capability), and the size of payments can be adjusted; but in exclusively owned funds, neither of these can be done; (3) We have accumulated a lot of knowledge about the characteristics of Lightning channels, and we also have terms to describe these characteristics. There is no need to describe it as a shared UTXO and then restate these characteristics in terms of shared UTXO; treating it as a basic analyzable unit will provide great convenience in understanding.
This classification is of course imperfect in the literal sense, but it is useful. We will see later that some designs (such as one-way channels with service providers) seem to meet the classification reasons for lightning channels in terms of form, but their actual usage is closer to coins; in this case, I still classify them as coins.
Off-chain update mechanism
Just having a "commitment transaction" is not enough to construct a lightning channel. Imagine if we can only allow two users' funds to live in the same UTXO, but every time they want to pay each other, they still need to initiate an on-chain transaction, then the practicality of this construction is very questionable. The success of lightning channels lies in designing a usable mechanism ("LN-Panelty") to update commitment transactions off-chain, allowing two parties to pay each other without initiating an on-chain transaction.
In the context of shared UTXOs, an off-chain update mechanism refers to a mechanism that can transfer funds between vTXOs without requiring on-chain confirmation.
Shared UTXO
In the CoinPool article [2] , the two authors summarized an important feature: "non-interactive arbitrary order withdrawal", which means that no matter when the user withdraws, he can always get back the funds he deserves, and the withdrawal process does not require the help of others. I believe that this property is the fundamental property of shared UTXO. Without this property, it will become a custody solution; no matter what design is inside this custody solution, it cannot be called "shared UTXO".
Technically, this means that we need to allow each party (each vTXO holder) to veto the state change of the shared UTXO, otherwise, it is possible that the majority of participants will infringe on the ownership of funds of a certain participant. In other words, all possible state changes must be agreed to by each participant (in advance or immediately).
For example, if three users share a UTXO, then no matter A uses the funds to pay out, or A wants to pay B, as long as the transaction uses the shared UTXO as input, it must be guaranteed that without the signature of C, these transactions cannot take effect. Otherwise, A and B may conspire to embezzle C's funds.
However, this poses a practical challenge: once a user goes offline, the ability of other users to update the state is affected (although the ability to withdraw funds is not affected). (Similar to in a lightning channel, if the counterparty goes offline, you will not be able to operate the funds in the channel).
It can be said that all shared UTXO designs are designed to address this challenge.
Next, we will use a series of examples to introduce the form of expressing the state within the shared UTXO and the type of vTXO, how to determine the impact of offline users on the shared UTXO, and how to affect the practicality and usage experience of the shared UTXO accordingly.
Congestion Control
Let's first consider the simplest multi-person shared UTXO: n parties all have funds (vTXO) in one UTXO, and these vTXOs are all exclusively controlled; these vTXOs are all committed by the same commitment transaction (each party holds the same commitment transaction and has been signed by everyone else); once such a commitment transaction is broadcast and confirmed by the block, the shared UTXO will be completely decomposed, that is, the internal state is completely exposed, and everyone takes back the funds originally stored in the shared UTXO. As shown in the following figure:
This is the simplest design: vTXO uses the simplest type, there is no off-chain update mechanism (so the three people cannot initiate internal payments off-chain), and any one person's unilateral withdrawal will lead to the withdrawal of all. What is the use of such a structure?
Jeremy Rubin named this structure "congestion control" according to its usage scenario. Its purpose is: when the handling fee is high, many payments that need to be made are "stored" in a UTXO, and these payments are launched on the chain when the handling fee drops to an acceptable level. For example, when the handling fee is high, Alice and her two friends want to withdraw money from a custodial exchange. Then the exchange can coordinate the three parties to initialize a shared UTXO and transfer the funds of the three people to this shared UTXO first; when the handling fee ebbs, the three people will cooperate or use the committed transactions in their hands to withdraw the funds.
If the three parties can be guaranteed to be online at all times, the usefulness of this construction will be greatly improved: the three parties can further coordinate the fees; they can also pay directly to one another instead of using the payment address used in their own re-commitment transaction. However, this cannot be guaranteed in the case of random users. In the case of non-cooperative exit, since the commitment transaction has already locked the fees in advance, users who wish to speed up confirmation can only use sub-transactions to add fees (i.e., "CPFP" [6] ), but cannot use "replacement fee (RBF)".
Relatedly, another point that may be criticized is its collective exit mechanism: in a non-cooperative situation, if a user is more eager to exit than others, and the preset fee rate of the committed transaction cannot be achieved, then TA will need to bear the additional fee for all these UTXOs to be confirmed on the chain. This means that if the users in the congestion control UTXO do not all have the same time preference and usage pattern, the user experience will be discounted or even become a disaster.
Is there a way to pop just one vTXO, instead of expanding all of them? Apparently there is - it's just a matter of leveraging the congestion control construct more deeply.
Improved congestion control
As shown in the figure below, we can initialize a congestion control UTXO like this: when Alice wants to withdraw money unilaterally, the commitment transaction she can use will only pop up her vTXO, and return the remaining funds to another congestion control UTXO belonging to the remaining participants (such as "Congestion Control UTXO-2" in the figure below), which is also pre-signed with a commitment transaction, allowing Bob and Carol to withdraw unilaterally. The same is true for other situations, so the "Commitment Transaction B" and "Commitment Transaction C" in the figure below are not further refined.
This structure can greatly alleviate the problem of additional transaction fees mentioned above, because whenever a user withdraws money, he only needs to confirm one more UTXO.
Moreover, assuming that Alice will also share her signature on the commitment transaction A with everyone, then this transaction can also be used by other users as an "exclusion transaction" - when Alice is unresponsive for a long time, she will be ejected from this shared UTXO, so that the remaining users can enjoy the benefits that a normal shared UTXO can bring to them. This can also limit the impact of Alice's offline on other users.
The only drawback is that this construction only allows users to exit one by one in a queue; if multiple users try to exit at the same time, the so-called "race condition " problem will occur: these users will initiate a fee competition to compete for the order of queuing (the qualification to exit first). Because we have not arranged a commitment transaction that allows multiple users to exit at the same time - if there is such a commitment transaction, there is no need for contention. For example, when observing that Alice is about to exit, Bob can use the prepared commitment transaction that allows three people to exit at the same time, and use the RBF method to make this transaction obtain a higher confirmation priority than Alice's transaction (this is a good thing for Bob, it is cheaper than waiting for Alice to exit first and then initiating a transaction himself); when Bob's transaction is confirmed, the three people can exit simultaneously.
At first glance, it seems that there is no doubt that such commitment transactions that allow multiple people to exit at the same time should be added. But at the same time, the concept of "shared UTXO" will begin to show us its brilliance: compared with the simple congestion control construction mentioned above, the improved construction requires a much larger number of commitment transactions signed by users at initialization, which means that the demand for interaction between users has increased significantly; moreover, it does not increase linearly with the number of users, but will result in a so-called "combinatorial explosion"; if such commitment transactions that allow multiple people to exit at the same time are added, the possibility of exit will further explode (if this is not obvious because the number of 3 people is too small, the reader can try to draw a shared UTXO for 5 people).
What means of communication will users use to complete so many interactions? (The Internet, of course, but how do these users find each other?) Given the possibility that a user will be lost during the initialization process, the initialization will fail completely and must be started from scratch, should some anti-sybil mechanism be used? These are all issues that need to be considered.
So, is there some kind of middle way?
Tree structure
Consider the shared UTXO in the figure below: When Alice wants to exit (or someone else wants to exclude Alice), Alice cannot pop out of the shared UTXO directly, but needs to broadcast "Commitment Transaction 01" first, which will split the original shared UTXO in half into two shared UTXOs; then, Alice broadcasts the next commitment transaction to continue splitting her own shared UTXO; ... and so on, until her vTXO is completely exited.
(Readers familiar with this field will no doubt blurt out: "This is a tree structure!" Yes, it is.)
In terms of exit fairness, this construction is not as good as the construction described in the previous section: depending on the order in which Alice exits, she almost always needs to confirm more than 1 UTXO. In our example, if she exits first, she needs to confirm 2 additional UTXOs. If it is a shared UTXO among 8 people, she needs to confirm 3 additional UTXOs.
However, if you look closely at the above figure, you can see its huge advantages, especially when the number of parameters is large:
(1) The number of commitment transactions that need to be signed is greatly reduced (this construction requires less commitment transactions than the previous construction even if there is one more user); this is because multiple users can use the same commitment transaction to exit;
(2) It also partially alleviates the aforementioned state contention problem, because every time a shared UTXO is split, there is one more UTXO that is allowed to be accessed, which means that one more user originally located on a different branch is allowed to operate; assuming that Alice and Carol both want to exit, then after "Commitment Transaction 01" is confirmed, they can operate in parallel without affecting each other;
(3) It also makes it easier to run off-chain update mechanisms (if any). Assuming Alice is offline, in the simple blocking control construction we described earlier, the off-chain update mechanism will also be suspended; in the above improved construction, although others can update the commitment transactions that do not originally include Alice, the number of updates required is large, which will also bring difficulties to the design and increase the complexity of analysis; in this construction, since the number of commitment transactions is greatly reduced and the commitment transactions that do not include Alice are easy to locate and analyze, it is naturally easier to design an off-chain update mechanism.
In summary, in these sections, we analyzed the impact of the state expression methods within the shared UTXO on its practicality and user experience. These three expressions can be tentatively called "beaded structure", "star-moon structure" and "tree structure". It is impossible to test how these three structures were first proposed, but I think many developers must have thought about them.
We also learned from these analyses about the many challenges that a shared UTXO may encounter during its lifecycle.
Next, we further analyze the impact of the vTXO type.
Coin vs. Flash Channels
Take a look at the following form of shared UTXO. How does it differ from the "congestion control" structure in terms of characteristics?
Yes, it uses the exact same state representation structure as congestion control, but because these vTXOs are not exclusively controlled coins, but lightning channels, even if this shared UTXO does not implement an off-chain update mechanism (cannot allow funds to be transferred between vTXOs), it does not affect these users being able to pay each other, because they have lightning channels opened between each other! They can pay each other, and they can also use counterparties in the shared channel to initiate and receive lightning payments. The only thing they can't do is resize their channel in this shared UTXO - this requires initiating an on-chain transaction, more like this shared UTXO.
This example illustrates the impact of the type of vTXO on the user experience of shared UTXOs, and also shows that even without changing the state representation structure, it is possible to improve the user experience in other ways. Of course, this also requires increasing the number of commitment transactions that users need to sign during the initialization phase.
In fact, the above diagram is inspired by a famous shared UTXO design - Channel Factory. Unlike the Channel Factory, I assume here that it does not have an off-chain update mechanism (while the Channel Factory does, at least it is assumed). If there is such a mechanism, then these three users can adjust the size of each other's channels without initiating on-chain transactions - there are obvious uses.
Off-chain update mechanism for multiple parties
Off-chain update mechanisms can greatly increase the utility of shared UTXOs: when vTXOs are exclusively controlled funds, off-chain update mechanisms allow these users to pay each other; when vTXOs are lightning channels, off-chain update mechanisms allow these channels to adjust size.
However, even for off-chain updates, all participants affected by the changed state must be present before they can be used (otherwise it is unsafe). Therefore, a suitable state expression structure will facilitate its operation.
Finally, although the off-chain update mechanism can play the same role as the lightning channel vTXO under certain conditions, it does not mean that it is redundant to classify the types of vTXO, nor does it mean that it is redundant to treat the off-chain update mechanism as an independent element. From the perspective of convenience and completeness of analysis, we are required to identify them as two independent elements.
Next, we will introduce several multi-party off-chain update mechanisms. (If you are not interested in the technical details, you can skip to the next section.)
In the lightning channel, the off-chain state update mechanism is implemented by installing a special device in the output of the commitment transaction: whenever the state is updated and a new commitment transaction is exchanged, both parties give each other a secret value used in the previous commitment transaction. If one party broadcasts such an outdated commitment transaction, the other party will be able to use the corresponding secret value to preemptively seize the value in the output belonging to the fraudulent (or careless) party. This implements a penalty mechanism that prevents both parties from broadcasting outdated commitment transactions.
Such a mechanism is extremely difficult to extend into a multi-party off-chain update mechanism. Specifically, when a party submits an outdated state, the party can indeed be punished, but the other parties are also rolled back to an old state and cannot immediately divide the funds according to the latest state. The solution is to allow each commitment transaction representing the old state to be spent by the commitment transaction representing the updated state within a window period to ensure that the funds can always be divided according to the latest state and penalties applied. The problem is that this will cause the number of commitment transactions that need to be signed for a single update to increase with the number of state updates that have occurred, and the number of commitment transactions that need to be saved will increase in a step-by-step manner. As shown in the following figure:
在第2 次更新状态时：共享UTXO --> 承诺交易#0 --> 承诺交易#01 --> 承诺交易#012共享UTXO --> 承诺交易#1 --> 承诺交易#12共享UTXO --> 承诺交易#2注1：承诺交易#0 表达的是初始状态。注2：纵向同一位置的承诺交易表达的是相同的状态。In this way, although the security of state updates is guaranteed, the interaction and storage burden of the participants are very large. Moreover, once a user broadcasts an old commitment transaction on the chain, in order to use the latest state settlement channel, it may be necessary to confirm the entire transaction chain on the chain (for example, Alice puts commitment transaction #0 on the chain, then others have to continue to broadcast #01 and #012 on the chain), which makes it not scalable at all.
This is why we want "eltoo". This idea was proposed in 2018 [7] , which proposed a new SIGHASH tag (namely ANYPREVOUT, now defined by BIP-118 [8] ); using this tag, the signature can only specify the output of the transaction, not the input, so it can always be used to spend the same script; combined with the value of the nLocktime field of the incremental commitment transaction, this can achieve the following effect [9] : transactions later in the transaction chain can directly spend any of their ancestor transactions, regardless of how many transactions separated the two when they were signed, and vice versa. That is, when Alice puts #0 on the chain, others can directly broadcast #012, skipping the middle #01 (in fact, #012 is no longer needed at this time, only #2 is needed). This greatly eases the interaction and storage burden of participants and saves scalability.
However, eltoo requires us to activate SIGHASH_ANYPREVOUT with a soft fork, so this mechanism is currently unavailable.
In 2022, John Law proposed another off-chain update mechanism called the Tunable-Panelty Protocol [10] .
In this mechanism, the commitment transaction (CT) representing the state (with a relative time lock) not only takes the shared UTXO as input, but also has an additional small input (Dust), which comes from another fund of a participant outside the shared UTXO. When a participant, such as Alice, tries to issue a commitment transaction, this small input must be confirmed first, that is, ST ("state transaction") must be issued. ST also has another output, which is actually a deposit (Stake), because when updating the state, the participant must provide the private key of the deposit.
The end result is that if a participant attempts to publish an old commitment transaction, they must first put an old ST on the chain, which will cause their deposit to be taken away - at this time, the shared UTXO has not been spent, so it does not affect the ability of all users to use the latest state. In other words, TPP designs a preparation phase for splitting shared UTXO, so that users who attempt to defraud (or are just careless) cannot directly operate shared UTXO, thus avoiding the problem of needing to replay the transaction chain mentioned above.
A major advantage of TPP is that it can be implemented now without changing the underlying structure of Bitcoin.
In fact, there is a very simple multi-party update mechanism based on time-locked commitment transactions. It is derived from the research on two-party channels [11] .
In this mechanism, the commitment transaction itself carries a transaction-level time lock, and each time the state is updated, the participants sign a commitment transaction with a shorter time lock (so it can be published and confirmed faster). The time lock itself prevents the problem of commitment transaction conflicts, so there is no need to further design a mechanism to deal with the possibility of such conflicts (a user publishes a commitment transaction representing an old state).
This mechanism is so simple and easy to implement that the discussion of the above two mechanisms seems meaningless. But this is not the case. A fatal flaw of this mechanism is that it has a clear lifespan - after a certain number of updates, it can only be settled and a new shared UTXO can be re-established. Although it can be alleviated (for example, one of the mitigation methods is to insert multiple intermediate transactions between the shared UTXO and the commitment transaction that finally expresses the state to multiply the relative time lock), it cannot be fundamentally solved.
Aside: Proposed restrictions on shared UTXO
Although shared UTXO is often discussed in conjunction with various soft fork proposals that can implement restrictions, I have barely mentioned them so far. The reason is that although these restriction proposals can be used to assist the operation of shared UTXO, they do not determine the fundamental characteristics of shared UTXO - and only by understanding the fundamental characteristics of shared UTXO can we understand how these restrictions are used in this scenario.
We briefly analyze three proposals here: OP_TLUV [12] , OP_CTV [13] , and OP_EVICT [14] .
As mentioned earlier, when constructing a shared UTXO, a lot of interactions are required (signing a large number of commitment transactions to ensure security), which will hinder its practicality and user experience. In this regard, OP_TLUV's solution is to use Taproot's Merkle script tree structure to commit the user's status to the leaves of the script tree. When the user needs to exit unilaterally, he can reveal this leaf and exit with the amount of funds recorded in it; TLUV will verify the amount of funds and ensure that the remaining funds are transferred to a new taproot output, and the output no longer allows the exiting user to participate - its public key has been deleted from the taproot internal public key, and its script has been removed from the Merkle tree.
Since the Merkle script tree itself can commit to the user's fund status, the user does not need to sign the commitment transaction. During the initialization and interaction process, it is only necessary to fully verify the internal public key and script tree structure of the taproot output. This greatly reduces the need for interaction.
Readers familiar with other protocol designs in this field may say: Isn't this the common "state tree" design under the state model? Yes, that's right. But from our previous structural classification, this design should be classified as a star-moon structure, not a tree structure - it allows a single user to exit directly and leave other users unaffected, rather than splitting the shared UTXO in half every time. Accordingly, we can also imagine a tree structure using OP_TLUV - what is promised by the script tree is the funds and aggregated public keys of half of the participants.
Coincidentally, OP_CTV can also be used to support this design. Because OP_CTV allows us to make a script spendable only by transactions with certain features, including the output amount and the script. Therefore, we can also commit the user's withdrawal transaction to the leaves of the Merkle script tree, allowing the user to unilaterally use it - anyway, the result of the use is the withdrawal of its funds, and the remaining funds enter a UTXO, which has also been locked by us with the appropriate internal public key and Merkle script tree, allowing the remaining users to withdraw unilaterally.
Compared to OP_TLUV, in this usage of OP_CTV, the user needs to verify more things (need to verify that each withdrawal step will hand over the remaining funds to the correct script tree), but also does not need to sign a commitment transaction (the number of verifications is the same as when using only commitment transactions).
The idea of OP_EVICT is to take a different approach. The author of OP_EVICT, ZmnSCPxj, noticed that in the star-moon structure using OP_TLUV, the exit transaction needs to reveal the Merkle tree path of its own leaves; and using the tree structure also requires revealing multiple transactions similar to the Merkle tree path. Is there a way to avoid this overhead?
The idea of OP_EVICT is to allow users to directly sign an output (public key and amount), and to make such a signature understandable by the OP_EVICT opcode and used to verify whether the current transaction output is consistent with the signed output. After verifying the signature and the corresponding output, OP_EVICT will subtract the signature public key from the taproot internal public key and require the remaining public key to sign the transaction. In this way, the taproot internal public key itself commits to the composition of the participants, and the participants' funds do not need to be committed by the Merkle tree, but only need to be protected by the public key's own signature (and the output signatures of other users).
OP_EVICT has another major advantage: it allows multiple users to exit at the same time. Therefore, it can implement a star-moon structure without the problem of competitive entry. (More precisely, the mindset of OP_EVICT is different. It assumes that users rarely need to exit unilaterally. On the contrary, the difficult problem is that one (some) users are offline and other users cannot use the shared UTXO function normally. Therefore, what is needed is a tool that can effectively exclude offline users. After excluding offline users, the remaining users can update the status through cooperation. Therefore, users exiting by themselves is not the "normal" usage of this opcode.)
Compared to the previous two, since there is no way to explicitly commit to state, it will require more user interaction, but it will also be significantly less than the case of using only commitment transactions.
In summary, the main use of the restriction clause opcode in the shared UTXO scenario is to reduce the need for interaction. It can reduce the operating overhead of certain state expression structures, but it does not determine which structure we can use. The research on the structure will not lose its meaning due to the emergence of restriction clauses.
Shared UTXO Design Example
Multi-party channel
As shown in the figure above, this is a congestion-controlled UTXO with an off-chain update mechanism (vTXO is a coin, a beaded structure with an off-chain update mechanism).
Sometimes, the structure shown below is also considered a multi-party channel.
Compared with decentralized lightning channels (and the layered channels described below), the advantage of multi-party channels is that they are less likely to face the problem of "receipt limit (incoming liquidity)". The disadvantage is that it is more difficult to resist the impact of offline users.
Layered Channels
“Hierarchical channel” is an idea proposed by John Law in 2023 [15] . It uses a tree structure, and vTXO is a lightning channel. At the same time, the author proposed to use TPP as its off-chain update mechanism.
Channel Factory
The channel factory uses a beaded structure, vTXO is a lightning channel (there is a lightning channel between every two users who share UTXO), and a time-locked decreasing commitment transaction is used as the off-chain update mechanism.
Statechain
The basic idea of “Statechain” [16] is that by transferring the private key that controls a UTXO, the UTXO can be completely transferred without any on-chain transactions. To facilitate such a transfer, two parties (user and service provider) need to jointly construct a public key (each party only has half of the private key behind the public key) and deposit funds into this public key (in order to ensure trustless withdrawals, a commitment transaction with a time lock must be signed in advance); when making a payment, the payer and/or service provider first shows the recipient the transfer history of the UTXO's off-chain ownership to prove the authenticity of the funds; then, the payer submits his or her signature to indicate his or her willingness to pay; the receiver works with the service provider to generate a new private key fragment and signs a new commitment transaction with a shorter time lock, and the payment is completed.
If expressed in terms of shared UTXO, it is a beaded structure that uses time-locked decreasing commitment transactions to update the state; however, this shared UTXO has only one vTXO, and the holder of vTXO cannot split his own vTXO. Once payment is made, the entire vTXO must be transferred over - at any time, there is only one legitimate holder of vTXO; in addition, in order to be able to introduce new users without using on-chain transactions, users must trust that the service provider will not collude with any previous user of the vTXO (if they collude, they can generate a valid signature for the shared UTXO private key and transfer the money away) - this is its biggest drawback, and why users need to perform additional verification when receiving payments.
If a user wants to enable more granular payments, rather than just being able to transfer all funds at once, then it is possible to transfer vTXOs to a lightning channel and send payments within that lightning channel [17] .
ARK and ARK v2
"ARK" [18] is a flat structure without an off-chain update mechanism. So, what is the difference between it and "congestion control"? The reason is that its vTXO is not a pure coin (but it is not a lightning channel either). From the script content, it is more like a "one-way channel". This one-way channel has two spending paths, one is the multi-signature of two participants; the other is a single signature of a user with a time lock. The latter can be used to indicate the final ownership of the funds in this one-way channel, and can also be used to urge a participant to take action. The former can enable the functions that can be supported by the multi-signature device before the time lock expires. When describing the one-way channel below, I will write the participants who can use the time lock branch first.
The user's vTXO in ARK is a one-way channel between the ARK service provider and the user. The user's vTXO injects funds into the one-way channel between the user and the ARK service provider through a special commitment transaction (Redeem TX).
This design is used to support a "non-interactive atomic coinjoin payment": when Alice tries to pay David, she can use her one-way channel with the service provider (Alice-Server Coin) to express a credible commitment: if and only if you pay David, my money belongs to you; but if you don't do it within a certain period of time, I will take my money. This is indeed possible because, as a shared UTXO, ARK cannot be spent without Alice's consent. Therefore, if the service provider does not provide the service, Alice can always issue the CT and Redeem TX#A, and then take the money in the Alice-Server coin.
Correspondingly, the service provider does not worry that Alice will default on her payment, because once she pays David, she can always confirm it with the Alice-Server coin and then use the commitment transaction given by Alice to take the money away.
Ultimately, the ideal situation is that both parties will cooperate: the service provider cooperates with David, and Alice agrees to change the state of the ARK on the chain with the service provider. In this process, Alice does not pay David directly; if David receives payment on the chain, then for external observers, it is unknown who in this ARK paid him (only Alice's peers know); and if David also uses another ARK to receive payment, then even Alice's peers in this ARK do not know who the money was given to (as long as these peers are not involved in both ARKs).
In addition, although the one-way channel here theoretically supports fine-grained payments, ARK does not support this feature. Like the statechain, funds are transferred as a whole.
ARK v2 basically uses the same structure [19] , but enables some designs that allow service providers to recover funds more efficiently (also relying on the Merkle script tree of taproot). However, in terms of the structure of shared UTXO, the two versions are basically the same. In addition, ARK can be independent of restrictions, but ARK v2 explicitly relies on restrictions.
Praise and criticism of shared UTXO
The CoinPool article nicely outlines two motivations for studying shared UTXO, which are also the benefits that shared UTXO is expected to bring to people:
- Privacy. When many people share a UTXO, the initiator of the payment can be hidden on the chain; and if the recipient also uses the shared UTXO, the recipient can also be hidden. ARK is a representative who embraces this direction.
- Scalability. It can reduce the number of on-chain UTXOs (on-chain states) and the need for block space (for example, off-chain update mechanisms can be used to pay each other in shared UTXOs). The representative of this aspect should be the channel factory.
The criticism of this concept is mainly from the perspective of practicality, arguing that it is very rare for all users to be online when the number of users increases, which means that its status may often get stuck and cannot be updated, so it is a fragile mechanism with poor usability. Another criticism is more pointed, from Peter Todd: We assume that this mechanism is used to expand Bitcoin's processing capacity, that is, to accommodate users with poor economic conditions who cannot afford to have their own UTXO on the chain and use it; however, we also assume that when something really happens, users will actively exit or passively pop up on the chain - how can they suddenly afford it?
This criticism obviously requires a deeper analysis to find a reasonable response. At least, for now, people will not stop researching shared UTXO for some benefits. And these studies have already produced value, both in theory (such as TPP) and in practice (such as the implementation of statechain).
Summarize
This article analyzes the basic elements of shared UTXO and uses this to explain the specific designs of various current shared UTXOs, attributing their characteristics to the use of specific basic elements.
This article mainly focuses on the structural features, and omits many technical details (such as the design of related scripts and the supporting user interaction process). Further research in this direction can help us further evaluate the pros and cons of different designs.
(End of text)
footnote
1. https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks.pdf ↩
2. https://www.btcstudy.org/2022/06/15/coinpool-exploring-generic-payment-pools-for-fun-and-privacy/ ↩
3. https://utxos.org/uses/scaling/ ↩
4. https://www.btcstudy.org/2023/11/28/op-evict-an-alternative-to-op-tapleafupdaverify-by-zmnscpxj/ ↩
5. https://bitcoinops.org/en/topics/joinpools/ ↩
6. https://www.btcstudy.org/2022/03/17/introduction-to-fee-bumping-by-Bitcoin-Optech/#CPFP-%E7%AE%80%E4%BB%8B ↩
7. https://blockstream.com/eltoo.pdf ↩
8. https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki ↩
9. https://www.btcstudy.org/2020/09/01/en-eltoo-next-lightning/ ↩
10. https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories ↩
11. https://www.btcstudy.org/2022/11/14/understanding-payment-channels/ ↩
12. https://www.btcstudy.org/2023/06/29/tapleaf-update-verify-covenant-opcode-introduction/ ↩
13. https://www.btcstudy.org/2022/02/07/what-is-bitcoin-checktemplateverify/ ↩
14. https://www.btcstudy.org/2023/11/28/op-evict-an-alternative-to-op-tapleafupdaverify-by-zmnscpxj/ ↩
15. https://www.btcstudy.org/2023/04/17/resizing-lightning-channels-off-chain-with-hierarchical-channels/ ↩
16. https://www.btcstudy.org/2021/10/12/statechains-non-custodial-off-chain-bitcoin-transfer/ ↩
17. https://www.btcstudy.org/2023/01/12/statechain-lightning-combined-in-bitcoin/ ↩
18. https://www.btcstudy.org/2023/07/21/simplest-ark-explanation-by-ruben-somsen/ ↩
19. https://www.btcstudy.org/2024/06/12/introducing-ark-v2/ ↩
