Apr 30•30 min read

Bitcoin, CTV Covenants, and Enigma

In Bitcoin today, if you need to perform a transaction, you acquire the recipient’s address, create a transaction paying them and then sign it. The Enigma Network will allow you to multi-thread your actions. Instead of sending transactions to be directly mined inside a block, you send an anchor transaction representing all of your transactions. If you want to open a channel to Bob, don’t make just a single channel, split the channel into ten separate channels and reveal them when necessary. What does reveal mean? Right now, you must coordinate with your partner to open a channel, using an anchor, you can create channels non-interactively so you can make them without your partner and they aren’t aware of its existence until you show them the details to the channel. Everything should look as expected, there’s a cooperative and uncooperative close methods with time-outs needed to safeguard both parties, nothing has changed except the anchor allows for the actual network activity to be weightless and not burdening the chain. This isn’t a Layer 2 upgrade but a Layer 1 upgrade. From this framework, you will use your Layer 2’s such as Lightning and RGB, blurring the lines between the two layers, making atomic actions across both Layer 1 and multiple Layer 2’s together, potentially only having a single input and output.

Before we begin, I would like to provide an example so you can conceptualize the mechanics of a CTV transaction. I intend to perform three transactions. To do this, I will SHA256 hash the three transactions and place the hash result inside another transaction that we will call an “anchor transaction” that uses CTV at its root. Think of it like an index and certification for the three transactions. They are on-chain, but aren’t maintained on-chain. Once the anchor is on-chain, I cannot modify them. I submit the anchor transaction to the Mempool and once it is confirmed inside a block, all three of my hashed transactions are also confirmed. If I designated a payment to someone, I am now able to pay them with one of these transactions, they do not need to send it to the Mempool and they can create their own transactions from mine without trust issues. As for the remaining transactions, I have two options: My first option, I could “unroll” or embed the transactions and place them in a future block, this would be just like a normal transaction that we are familiar with today, but this is inefficient, these transactions are already confirmed, there’s no need to re-confirm them. My second option is to “re-roll” the transactions to make new transactions. I could place these new transactions inside their own anchor, just like last time and send it directly to the Mempool. Once they are confirmed, I can toss away the first set of confirmed transactions away. For my new transactions, I wasn’t concerned about space requirements or the number of transactions, these floating transactions all share the same on-chain cost, the single anchor.

BIP-119 or CheckTemplateVerify (CTV), introduces the capability to pre-commit transactions through pre-signed hashed transactions. But what does this mean exactly? To put it in perspective, if Taproot enables signature aggregation, CTV takes it a step further by enabling transaction aggregation. If channels allow you to go up and off-chain, covenants, specifically Equality Covenants, allow you to go down and in-chain. Channels are an agreement between parties and are nondeterministic in nature. Covenants are an agreement between transactions and are deterministic, this allows for a much more stable platform to build on. From here, we can add Lightning, making it a Layer 3 without ever noticing except that it’s better and faster. When someone sends you a transaction, why can't you also initiate and confirm transactions? Payers no longer have the sole advantage of committing transactions to the chain, now receivers can commit transactions as well. As the recipient of a payment, you can effortlessly create transactions within your personal scriptPubKey without imposing any additional costs on the sender, and what's interesting is that they are not even aware of your actions. Whether it's opening channels, closing channels, building vaults, or any other necessary action, you can carry out these tasks while receiving payment. Free of cost. All you do in lieu of providing a signature is provide a small hash representing your intended transactions and signatures. Why can’t I do this now? Place the hash of the transactions inside, say, OP_RETURN? You could attempt to create a second-layer protocol doing this but you have to trust that whoever sent that transaction deleted the private keys to it, otherwise they can steal the funds.

https://rusty.ozlabs.org/2023/07/09/covenant-taxonomy.html

Currently, in order to perform any action with your Bitcoin, it is necessary to have a valid Unspent Transaction Output (UTXO) already committed within the blockchain. However, this requirement can be challenging for newcomers who do not possess a pre-existing UTXO. Fortunately, CTV offers a solution to streamline this process and turns this conventional process on its head. With CTV, you can create a set of non-recursive transactions that signifies your intention to open a channel, allocate funds into a vault, and settle a payment to Bob. This approach significantly alleviates the on-chain burden, improves transaction efficiency, and guarantees privacy, as the contents concealed within the hash remain known only to you. An intriguing consequence of this is the emergence of Non-Interactive Channels (NIC’s), where a channel remains "cold" until you decide to reveal it to your partner, thereby making it "hot". This could allow you to close your channels and re-open them privately at night so that you can go the evening without a watchtower, re-establishing the channel in the morning without having to perform another transaction since it was actually opened the night before.

https://utxos.org/uses/non-interactive-channels/

https://rubin.io/bitcoin/2021/12/11/advent-14/

While this is just the first step, the benefits of using covenants and pre-signed commitments are significant. By consistently employing these techniques, you can reduce on-chain transactions by a lot, as transactions are committed whenever you receive payment and remember, this was all free for you. I could create as many transactions as I desired. If I had the need for it, I could’ve created fifty channels instead of just one. The goal is to remove trust from the system, for instance, tasks like inheritance and managing vaults shouldn’t require the deletion of private keys to create complex systems.The design space of Bitcoin doesn't change, but it does add the concept of zero into the UTXO set. Every transaction and UTXO on the blockchain no longer is owned by one person, it belongs to everyone inside it. Each transaction is now just an anchor for the actual activity occurring inside the hashes.

https://rubin.io/bitcoin/2021/12/08/advent-11/

So all we get are NIC's? Not even close. Let's consider a straightforward batch transaction from an exchange. Normally, this transaction would involve several inputs and potentially thousands of UTXO’s being distributed to different individuals. However, the exchange now has the option to create a compact transaction with just a few inputs and a single UTXO. This significantly reduces the transaction's overall size, resulting in cost savings for the exchange in terms of fees. When an individual spends their UTXO from this batch, the UTXO "unrolls." As time passes and everyone gradually spends their UTXOs, the batched pool will gradually diminish until no one is sharing the original UTXO anymore.

The old Batch could have a heavy fee and footprint as it contains a lot of data. The new Batch will create the anchor transaction to finalize the payments to individuals. They could then unroll it at their leisure or if congestion control was added, it could automatically unroll over time for them.

But what if I could avoid paying fees to unroll my UTXO and transaction and instead just re-roll my UTXO and transactions? Welcome to The Enigma Network. This new Network is deterministic, on-chain, has automatic UTXO pooling with asynchronous payments, and as collaboration increases, both scaling and privacy increases. Instead of thinking of terms of performing single transactions, think in terms of tasks to perform. Need to pay someone? Ask a channel partner if they need to as well, you can charge them a slight fee if you wanted to include their transactions with yours. Let’s set out some terms first. Anchor UTXO’s will be called ATXO’s. Bitcoin held in Lightning channels are LTXO’s. Your normal transactions, such as opening or closing channels, paying Bob, anything that doesn’t need to go on-chain and are held by anchors (ATXO’s), we will call them Settlement UTXO’s, STXO’s. UTXOs that are short-lived, private with e-cash-like properties are Virtual UTXO’s, VTXO’s. The idea is that only ATXO’s go on-chain, STXO’s and VTXO’s are freely traded between users, without needing the Mempool and can be done non-interactively with privacy. STXO’s are incorruptible when they are committed so they are only good as in input for making a PSBT for an ATXO. Losing your STXO’s can result in a loss of funds. If you elect to convert your LTXO’s, STXO’s or VTXO’s back to normal UTXO’s, in your transaction, you would see your UTXO’s being ejected from the pool’s ATXO. A second transaction with an ATXO would place them back into the network.

In this diagram, I am taking a normal input and I am making an ATXO anchor that commits 3 new transactions.

In this instance, I am using 3 inputs to make a single anchor with 3 output STXO’s. These STXO’s could be to make a dozen channels, paying Bob or even pushing your money to cold storage.

In this diagram, I took STXO 1 and STXO 2, made 3 new pre-signed transactions and committed them inside ATXO 2, but I couldn’t touch STXO 3 (maybe it is owned by someone or a group that is offline?). The transaction will have a single input, the ATXO, and for its outputs, it’ll have the new ATXO and the ejected STXO.

If we did own STXO 3, to fix this, we would re-roll STXO 3 inside the new ATXO 1 anchor instead of allowing it to eject.

STXO 1B belonged to Bob. I gave Bob his transaction showing I paid him. If he needs to spend the money I gave him, he would need to prepare a new anchor. If Bob and I parted ways by the time he creates a new anchor and transaction, our ATXO’s will split. Because I didn’t properly structure my transactions well, when Bob makes his anchor, his footprint will actually be larger because of me. It would have been smarter to make STXO 2A for Bob so that there would only be a single ejection for Bob. Another possible scenario as to why i couldn’t use STXO 2A is that it could have been a pool owned by others and my money was only in STXO 1A, making this type of ejection the only option.

Thankfully Bob stuck around and we decided to use a common anchor and collaborate a little. Bob had some transactions that he didn’t want to reveal to me so they’re in their own separate hash while Bob and I create a Lightning channel together, represented by LTXO AB. Because my STXO 1A was already inside the same ATXO as Bob’s payment, I didn’t need to bring in another input to fund the channel. I could have used STXO 2A to fund it as well, instead, I made some more transactions inside STXO 3A.

Here’s some analogies that people have made to try and help explain:

Owen’s Postboxes

Kuriitaasuki’s TARDIS.

I see it like the Bank of Bitcoin, where upon receipt of payment, you are able to pull out your checkbook and write an endless number of checks equal to the amount of cash you’re receiving. Once they’re signed in a block, you can give their owners their checks, those owners can now write new checks based off of your check, continuing the cycle.

So what layer is this Settlement Layer? I’d like to call it Layer 1.0*, 1 with an asterisk to show it’s slightly different. We could call it Layer 2 and we move Lightning to Layer 3. As all of the data that has to be retained is Settlement data, I’m calling it the Settlement Layer. If I commit a transaction that has one GB worth of data inside its transaction, I’ve made the Settlement Layer one GB bigger and if I unroll these STXO’s onto the main chain, the Settlement Layer would shrink while the main chain would grow, but I would have to pay the fees to unroll all of that data. All transactions in the Settlement Layer are committed, cannot be modified and are as trustworthy as being inside a block on the main chain, that’s the entire intent. This Settlement Layer could grow to trillions of bytes of data and that wouldn’t be an issue as the data is safe, ready to be used, held by the owners of that data. In fact, the more we push things to the Settlement Layer and not on the main chain, the more efficient we can consolidate onto the main chain. In terms of security, you now have not only the ability to keep your keys in cold storage, but your actual transactions as well. Even if your keys are compromised, without the transaction data, no money can be stolen except for any bare UTXO’s still on-chain.

Consider a scenario where Alice needs to pay Bob in the future but is also expecting to receive another payment soon. Instead of creating her own anchor and submitting it to the Mempool, along with associated fees, Alice can incorporate an STXO for Bob within her next payment she is receiving. By doing so, Alice commits the payment to Bob and can provide the signed STXO to him directly, without ever needing to make a transaction on the base layer. Similarly, Bob can follow the same approach when he receives a payment on-chain and creates a PSBT STXO from Alice's STXO to pay Carol. When Bob received payment from someone’s ATXO₁, both his ATXO₀ and the new ATXO₁ will be the inputs to the transaction, Carol’s payment will be hidden inside the new output ATXO₂ without any evidence that Bob’s payment went to Carol. And anyone who was not part of the collaboration in the transaction, will be ejected as output UTXO’s. These could be entire pools or single individuals, depending on the circumstances. Perhaps Carol ejects her UTXO in the next transaction. It is important to highlight that all these transactions are processed outside the regular transaction flow, allowing participants to commit them without adding to the blockspace. STXO’s never need to go on-chain unless they’re needed for visibility or perhaps as an inscription. As a result, additional fees are avoided, and block capacity is optimized. An interesting implication is that any channel openings, channel closings, or other transactions can be discarded once they have been spent, eliminating the need for them to be included on the blockchain ever.

Once the ATXO is committed on-chain, all of my STXO’s (Tx1, Tx2, Tx3) are now fully certified and I can give them to my counter-parties. I can now also throw away any old STXO’s that became invalid and outdated with the new ATXO. There are situations that you could bake into your STXO’s such as TimeLocks and alternative spend paths, this is the basis of Ark, the receiver can spend it for the first two weeks, if the receiver did not spend it, it goes back to the originator. If they don’t spend it, the ASP can be the one to redeem it after week 4. This is all viewable in the transaction, there’s no means for someone to trick you unless they make the offer over complicated. One neat feature of using anchors for certain types of transactions such as Relative Timelocks, the anchor acts as a sponsor and you can fee bump the anchor, not worrying about trying to fee bump any Relative Timelocks.

Let's take collaboration to the next level and introduce the concept of Payment Pools. In a payment pool, a group of individuals collaborates to share a single ATXO, and with each spend, they merge their funds into a new ATXO to prevent the pool from decaying. Within this ATXO, each participant holds a stake in the collective UTXO. Here's where it gets even more fascinating: when you make a payment to someone who also has their own payment pool, the two pools can temporarily merge, consolidating into a single ATXO. However, after the next spend from either pool, they may split back out again as the participants are not collaborating all the time. This dynamic merging and splitting of payment pools add another layer of complexity and flexibility. Users of a payment pool can collectively share the transaction fees, ensuring that individuals don't bear a significant burden while enabling the pool to remain competitive in the market. This fee-sharing mechanism allows participants to pool their resources efficiently, providing a more cost-effective and competitive solution for transactions. Internal transactions are invisible so the redistribution and resizing of internal UTXOs cannot be detected. The creation of a payment pool could have lots of inputs with a single ATXO output. Any on-chain updates where new ATXO’s and STXO’s are made, if only internal shuffles occur, the transaction should just have the old ATXO and the new ATXO, no ejections. Collaboration falls apart or if new members join, the anchor transaction will have these extra inputs and ejected ATXO’s.

Here is an example of a pool unrolling on-chain. Just performing an unroll makes it easier to commit all the transactions in Block N, but if you commit the leaf transactions to the blockchain directly, you’ll end up with extra transactions than if they were all committed in the original Block N in a normal batching scenario. To make this a more realistic and efficient system, instead of committing your vanilla UTXO’s in the leaf transaction, create STXO’s by rolling them into a new ATXO that spends the transaction, that way it never consumes space on-chain and only anchor transactions occur on the main chain. Each UTXO on this graph could represent hundreds or thousands of transactions occurring over a period of weeks or months.

https://rubin.io/bitcoin/2021/12/10/advent-13/

Let’s build a basic pool. It won’t even be a pool really, just five individuals combining their UTXO’s together and no further collaboration.

The reason we don’t want this is because as soon as anyone spends, everyone else is immediately ejected out especially if no one else is online at the time. Alice can give Fred his STXO, but we could’ve done this a lot better.

To be continued on building a payment pool with a single output. Once a new anchor is committed on-chain, all pool members should create pre-signed transactions that will maintain them within the pool but not perform a spend. This will allow the pool to perform one more hop before decaying, ejecting the offline members. They can always rejoin a pool if they are ejected so it’s not too bad if this happens.

Let's build some more features, we can pre-commit any valid transaction we want! Another exciting aspect is congestion control for on-chain activity. On-chain payments without anchors will be less common so Congestion Control isn’t really for the main Enigma Network, but more for writing things on-chain such as Inscriptions or other data commitments. Imagine I want to allocate fees for both Alice and Bob's transactions, with a payment range of 1 to 3 sat/vbyte. Now, here's the thing: if I underestimated the fee rate for an STXO that I wish to write on the main chain, I'd have to resort to using Child Pays for Parent (CPFP) to ensure my transaction gets included. I could also have an anchor imbed an Inscription, the inscription can pay for the fees through the anchor, making a new type of payment called Parent Pays Through Child (PPTC). But hold on, there's more to it! Miners have their tricks too. They can compact transactions together, optimizing fee collection while minimizing blockspace usage. We'll dive into this topic in more detail soon. To streamline the process, it's better to create multiple branches that pay Bob, allowing us to select the most suitable fee rate transaction instead of CPFP constantly, but this requires planning and designing,

https://rubin.io/bitcoin/2021/12/09/advent-12/

Lightning immediately becomes much more flexible but also not as needed, Enigma’s deterministic platform allows for much more creativity to occur without consuming blockspace. You can perform both L1 and L2 actions together inside a single ATXO. No need to make a design decision based on space concerns anymore, use as many STXO’s as you need. One form of jamming in Lightning is when you stack too many Time-Locked Contracts (HTLCs) together, the protocol currently has a hard limitation of 483 with a soft limit of 12, and this is all due to footprint concerns. ATXO’s have no limit and you can consolidate in your STXO’s however you need to. It’s possible to consolidate everything into a single STXO and embed this in witness data as a means of backing up your current status. This transaction wouldn’t be within the normal location so nodes would not verify it, but that’s not needed as it’s an STXO anchored by its ATXO. In another ATXO, you can expand back out to your original STXO configuration. With Lightning, I don’t need to concern myself with how large I want my channels to be. Instead of making a single 1 BTC channel, I can make 100 0.01 BTC channels and reveal them as needed to my partner. If I realize I need to reallocate funds elsewhere, I can close some of these channels with Bob with a quick reveal, then reallocate the funds to channels for Carol, all within the same ATXO and block. If I don’t want to have a watchtower over night, I can make an anchor to close my channels with everyone, reopen them in an unrevealed state so that in the morning, I can start business again without needing an opening transaction. Dust is no longer an issue as ATXO’s don’t need to leak dust and STXO’s don’t require fees so there’s no dust there either.

https://blog.bitmex.com/lightning-payments-when-are-they-too-small-to-secure/

https://unchained.com/blog/dust-thermodynamics/

Another issue is the security budget and the time it takes to onboard new users. Currently, on-boarding everyone in the world onto the Bitcoin network would take approximately 8 years. However, with CTV, it becomes possible to onboard everyone in a possibly only a few days. Over the following 8 years, their UTXOs would gradually unroll on-chain, securing fees for the miners. Let’s instead use The Enigma Network, they can work within their own blockspace requirements, anchoring themselves to the chain occasionally. They can hold funds securely however they desire to, be it bare UTXO’s, STXO’s, VTXO’s or LTXO’s, there’s probably more flavors to come that behave in their own particular ways.

Recently, the popularity of Ordinals, Stamps, BRC-20 and other data embedding protocols have emerged. This has caused many issues for the community as fees have gone up 500%. Well, we can’t exactly get rid of them, Stamps cannot be censored and they have the worst impact on the ecosystem since they bloat the UTXO set, causing every node to consume more RAM over time like a memory leak on the system. Ideally, OP_RETURN can be used for this and perhaps there’s discussion to expand the data available for it, but that’s for another discussion. The problem is, what do we do about it? UTXO pooling. Since a group of us can share space and transactions, if there’s 50 of us in a pool, the fee is only 1/50th of the cost. a 150 sats/vbyte would cost each member 3 sats/vbyte. This does a few things for us, it keeps fees low for individuals, it provides more fees for the miners and inscribers can’t pool their data embedding so they are at an economic disadvantage. Compared to a 50-member pool, an ordinal would cost around 1200% more than a normal transaction. One perk for inscribers is that they can commit and batch their data now, so they don’t have to compete against the market, they can just become the buyers of last resort of available free space. At night, blocks are typically more empty as there’s less economic activity, this is when inscriptions could unroll onto the chain.

Let’s discover Hal Finney’s Banks, but done properly. Instead of these banks being money custodians, they’re data custodians. The money is owned by the end-users, the banks have no means of stealing the funds, and they’re providing either data management or data anchoring or both, depending on your needs. Alice needs to send money to Bob, she’ll make her own ATXO that has all of her housekeeping needs, including the payment to Bob and she’ll provide this ATXO to an Anchor Operator (AO). The AO will place her ATXO within their own ATXO and commit it to chain, informing Alice of its status. To ensure the AO doesn’t grief Alice, we’ll pay the AO fees, but how do we ensure that the AO both performs the data anchoring for Alice and Alice doesn’t grief the AO without paying? To entice the AO to ensure that they provide optimal service, we’ll start out with a down payment, 2 sats to the AO from Alice for first time service, 1 sat for the current anchor, 1 sat for the next anchor in a week. The following week when Alice does her next anchor, she’ll commit another 1 sat for the following week, continuing the service payment. There’s probably better ways of performing this with ensuring both parties are not relying on trust for the service. Also, don’t forget to harness Enigma. When Alice was doing her housekeeping, if she has 50 channels open with other people, she can ask them if they have any transactions committed to the chain, Alice can do state updates for her and her friends all within the ATXO that’s intended for the AO. If all of her friends and Alice share the same ATXO on the base layer, the ATXO given to the AO would look like it’s just Alice with no additional inputs from her friends.

With Anchor Operators, we can create a second Mempool, the Anchorpool. Instead of relying to the primary Mempool, you can send your ATXO (to the AO, your ATXO is just another STXO) to the Anchorpool. AO’s can negotiate with each other who’s ATXO’s they wish to bid on or trade with. If one AO has an input that another AO is also using, they could collaborate to perform a better swap, making a single ATXO between the two of them. The idea behind Ark is to constantly use two blinded key swaps, if AO’s can effectively perform on-chain anchors that are consistently 2 inputs with 2 outputs (2 ATXO’s, one being the primary ATXO, the second being an ejection of someone not collaborating), then we can effectively make STXO’s as private as VTXO’s and might not even need VTXO’s anymore.

Let's explore the concept of Decentralized Mining Pools (dpools), which bring forth numerous advantages, albeit with a few drawbacks. While you still have the option to participate in a traditional mining pool operating within a dpool, the dpool itself operates in a decentralized manner. No individual or entity exercises control over the funds within the dpool, and the need for communication mechanisms like DNS is eliminated as everything operates directly through the blocks themselves. The template of the dpool is established and remains immutable from its first mined block, ensuring that no single entity can exert dominance over it. The significant advantage of dpools is that the fees collected are distributed across multiple blocks by the pool, resulting in a smoothing effect. Even if a particular block has low fees, miners can still expect a decent reward for their contributions to the block.

Operating within a dpool also unlocks fascinating features, such as the concept of Compaction. Picture a scenario where Alice is making a payment to Bob simultaneously while Carol is also making a payment to Bob. Wouldn't it be convenient if we could effectively combine these transactions, performing something similar to a CPFP type operation, and have only one transaction committed on-chain? That's where Compaction comes into play. By merging the UTXOs from Alice and Carol into a single UTXO paying to Bob, we achieve a compacted representation of their transactions. Now, imagine if Alice, Bob, and Carol were each in their own payment pools. In that case, all three pools could be seamlessly merged into a single pool. And the best part? These operations take place directly on layer one, allowing more transaction to be settled per block.

But what if we shift our focus to channel-based transactions? Here's where Cross Channel Tree Swaps come into play. With channels, we have the flexibility to consolidate UTXOs and pools at our leisure. By utilizing Cross Channel Tree Swaps, we can further optimize the utilization of resources, consolidating UTXOs and pools across multiple channels and only the commitments would need to be settled.

https://rubin.io/bitcoin/2021/12/12/advent-15/

Hierarchical Channels are nested HTLC channels within each other, allowing for Service Providers or Factory Operators to be the first channel layer and users the second channel layer, there’s some complexity to them and questions on how to make them work as is, today. I haven’t had a chance to deep dive into how CTV could improve Hierarchical Channels but there’s definitely room for improvement.

https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html

Ark and Darkpool are two protocols that fit within the Enigma framework. They both presents\ an innovative approach to achieving Chaumian e-cash-like behavior without relying on a trusted mint. The current proposal for Ark uses APO, while APO can be used to synthesize CTV, CTV is more concise, it’s a 32 byte hash vs a signature, and it’s faster due to sha2 vs ecc operations. Using APO for Ark, you send money to an ingest pub-key, which places you within the factory channel on L2. APO allows for "replaying transactions" by entering the system through sending funds to the designated key, this helps L2 scale really well, but it doesn’t do much for L1 scaling which is what Enigma aims to achieve. Users register notes of equal value and submit them to the Factory Operator. The Factory Operator runs new rounds at regular intervals, with verification based solely on the amount as everything remains blinded. These notes have a validity period of 4 weeks, after which the Factory Operator can redeem them. If the notes are not redeemed within the first two weeks, they are returned to the original creator. Integrating CTV with Ark could scale the ingestion process by creating a NIC to the Factory Operator, users can bypass fees while improving scalability by stacking multiple transactions together. Darkpool makes a few different assumptions from Ark and has some benefits and downfalls when compared to Ark.

https://www.arkpill.me/

https://gist.github.com/moonsettler/6a214f5d01148ea204e9131b86a35382

So what are these Templates in CheckTemplateVerify? If I create a single STXO that holds a payment to Bob, the template for this ATXO would be just the single STXO transaction. If I did 10 payments, its template would be the 10 payments. CTV just verifies that the transactions you wish to perform are valid and produces the hash that represents those transactions.

This is Covenant A with cov(B) and cov(C). These two covenants each have two possible output transactions, cov(B) OR cov(C) can be spent, not both. I can present this to a channel partner of mine, cov[B] could be to update our pool, cov(C) could be an ejection from the pool or some other option.

This is represented in TXGL, Transaction Graphical Language. The thought is to move the semantics of the logic up a level. Attempting to audit this opcode by opcode would be a nightmare, but having another means of representing what’s occurring simplifies auditability and reproducibility. You could even compile the transaction directly from these diagrams. It’s like miniscript for miniscript.

My partner, knowing that both cov(B) and cov(C) cannot be altered and only one outcome is possible, can create his own proposal in return. In this example, M0 and M1 are gas inputs. Covenant A has two possible outcomes, cov(B) and cov(C). In order for me to receive Tx(G), I must provably show that cov(C) cannot perform tx(F), I do this by spending tx(C), thereby preventing Tx(F) from existing. I can then spend cov(G), with the proof that tx(F) can’t be performed.

For more information on TXGL, read here.

https://rubin.io/projects/txgl/

By taking a step back and looking at your commitments as schematics instead of just a simple transaction, you can build almost any simple or complex system imaginable, secured by your anchor transactions. Anyone becomes empowered to create their own systems, to collaborate and coin-join with others to help reduce your own fees, and provide more privacy for everyone involved.

Transaction Aggregation is the significant development that changes the way transactions are handled. Instead of one transaction per person or group, there's now a bundle of transactions. These bundles can vary in size and complexity, making it difficult to understand the interactions between transactions, thereby increasing network efficiency and improving user privacy. Every time you make a transaction, you're not just making one transaction, but all of them. So go ahead and take care of all your needs. You can also collaborate with others, similar to using the Lightning network, to pool transactions together on-chain to save on fees.

Sapio is a front-end for Bitcoin Core allowing you to build payment pools, coinjoins, vaults, escrow accounts and anything else you figure out how to build. No more need for third party services for you to do anything. When you build a contract, you won’t perform “transactions”. You’ll create it in a single transaction. Its deployment is also asynchronous, as you can deploy it while receiving or sending a transaction. The thought used to be that we would all live on Layer 2 due to high fees, what will happen is we’ll all become points on the map using anchor transaction to perform your housekeeping. You now perform hops on the chain. Each time you need to hop, you produce hundreds of new STXO’s and dumping hundreds of old STXO’s, erasing small portions of your map, updating it when you land in the next block. In a sense, blocksize is now infinite, we can make as many transactions as we want, and we now have a Block Index Limit of 4 MB’s.

Enjoy.

https://rubin.io/bitcoin/2021/12/15/advent-18/