Jul 25•33 min read

Where Do We Go From Here?

In the last few months, there has been a shift in the air. I don’t want to say it was due to Ordinals, but they helped show the concern that many people have been feeling, as a lot of this work has been in progress for years by various groups. We’ve seen a convergent evolution of ideas all arriving together to nearly the same concepts while respecting the core principles and ethos to Bitcoin. There are a great many nuanced points to address that is hard to convey in one conversation, let alone in a tweet so I decided to publish an article for everyone.

My biggest concern and the one I should address first is that people don’t take criticism well when it comes to Lightning. Any critique is immediately felt as FUD, that the years of work that we’ve made has been a waste and our vision of Bitcoin with Lightning is wrong. I’m not going to hold back, I can’t stand the thought of running a lightning node. That I need a hot wallet online 24/7 and if I lose connectivity, I’ll most likely come back to a forced closed channel from either myself or my partner. There are mitigations to this, ACINQ just released their “third-generation” lightning wallet called Phoenix and is a great example of a lightning wallet that makes the user experience great and stands a chance against everything becoming custodial. It’s the lightning wallet I use and prefer and recommend to others, but let’s see how we can make a “fourth-generation” wallet. I see two things that we must overcome to compete with custodians, convenience and price, I don’t want it to be difficult and I don’t want to pay for it, how hard is that? cue laughter. Phoenix does a great job with convenience, it has a sleek UX that really can’t be beat, the only difference between it and a certain popular custodial wallet is the requirement to remember 12 words.

Their recent splicing update has also seen their fees rate go down. So what’s the bad? Some of them are due to the design decisions of the wallet to create a better experience and reduce fees, some of them are due to the Lightning Network itself. First and foremost, if ACINQ wanted to double spend the channel balance, what exactly is stopping them from using an old channel state? You have no watchtower configured to detect them and your wallet could be offline for potentially days or weeks at a time. The only thing keeping ACINQ in check is that they don’t know if and when you’re accessing your wallet, but hey, we all connect our Phoenix wallet to our own nodes and don’t leak anything back to them, right? The double-spend isn’t exactly a fear but it does raise questions about the nature of the relationship you have with channels. Something else that isn’t frequently discussed is that the liquidity that ACINQ has with you in your channel is locked for them, they can’t do anything with it except let it sit there. Liquidity Management is a concern and over time, you may see them lowering receiving capacity or even them force closing the channel with you due to inactivity. With Phoenix’s new splicing update, you might notice that you don’t have much receiving capacity, this isn’t a coincidence, they need the freed capital. This isn’t something directed at ACINQ but the nature of Lightning and our shift towards LSP’s, how long can they afford to keep a channel open with you, it doing nothing? They can’t even route through you.

The other issue we discussed were fees. Lightning itself suffers from fees in a few different ways, the issue that I don’t know if it can be truly resolved is the fee rate, it’s typically proportional rather than a flat rate and that has a lot to do with the liquidity management issues, if you consume my entire channel, i need proper reimbursement so I can rotate channels and stay in this business, this isn’t a charity. Lightning also suffers when the main-chain is suffering from congestion, this isn’t necessarily so bad if you’ve already established channels and they don’t close on you. During the high fee season, quite a few people suffered from forced closed channels, sometimes paying up to forty or sixty dollars for closing the channel. What’s worse is that an unexpected force close isn’t just an unexpected expense to you because you’ll mostly need to perform a second transaction to reestablish the channel, but the closing transaction was twice as big so it cost twice as much! This also precludes those who haven’t yet joined the network and they’re forced to pay outrageous fees just to enter. The fees having to open and close channels will force a lot of people to find means of avoiding those fees which, unfortunately, involves custodians the majority of the time. Even Phoenix can easily be priced out for most individuals in the future, both for us the end users and ACINQ the service provider. They may end up having to focus on solutions that doesn’t stagnate so much capital.

Custodians. The necessary evil. Or so we thought until Satoshi gave us Bitcoin. Some arcane knowledge that seems to have been lost is that Satoshi’s Bitcoin had both channels and covenants. Channels came via nSequence, which was later discovered to be unsafe as all unconfirmed transactions are second-rate citizens. Covenants were technically possible via OP_CAT, but it was disabled when Satoshi removed 15 Opcodes. We’ve properly restored channels via segwit, but we’ve been stuck for over a decade on how to properly restore covenants.

Most of this is due to the mysterious nature of covenants, what exactly can they do? I would like to answer that today. There’s so many different properties and flavors to them. The most known component to covenants is non-recursion and recursion. Now I’ve been told up and down, there’s no practical difference between the two and it doesn’t really matter because people can be dumb and lock their coins in permanent ways already, and I’ve accepted that answer for a long time because I’ve had nothing to counter it, there’s been no practical differences. During our research in comparing the different proposals, we’ve discovered that there are, in fact, differences. One concern for recursion transactions is that they become sandwich-able and an attack surface can appear, depending on how the contract is coded, think AMM’s and DeFi that can use spreads. This is where re-ordering of transactions can occur and introduce potential MEV. Recursion makes developers lives much easier, but also makes it all the much simpler to analyze and potentially extract value. Another behavior is Spook-chains and Evil Mints. They are only possible via recursion. Evil Mints have been brought up quite a few times and they’re mostly disregarded because you can be entrapped with a whitelist multi-sig as well. One key difference though is once the evil government is out of power and a less evil government is in charge, before, they could dissolve the multi-sig and everyone would go free. But with recursion, the mint might be permanent! Now this government has to choose between burning 500k coins, maintaining the mint or we discuss a hard fork to fix the abnormality. Another way to make it seamless would be if the private key to the mint was leaked and every wallet provider integrated the key into their wallet. Now, I’m not sure if Spook-chains would see adoption or have any sort of safety concerns, but it makes me ask the question of what other differences exist and where? I’m leaving that question open for everyone. I cannot ACK on a proposal until I know these differences and so, until then, I must withdraw my ACK for APO. I would like to show a better way without recursion in the next section.

Equality Covenants, also called Deterministic Outpoint Flow Covenants [DOF], ensure there’s no malleability of the TXID’s for the outputs while fixing the number of inputs to preserve the TXID of each transaction, this is enabled by proposals such as CHECKTEMPLATEVERIFY [CTV]. This allows for some novel behavior. It allows you to sustainably build new states more efficiently, with things such as DLC’s, channel factories, vaults, inheritance schemes, payment pools [also called coin pools], while not having the same space concerns that on-chain transactions have.

Just within the last month, one of the most senior developers, Rusty Russell, just learned about Equality Covenants. Because we’ve never understood the concept of Equality Covenants, covenants that can be implemented by signatures in the output, we’ve always tried to create the perfect off-chain L2 solution. One where we can launch from a single transaction on-chain and maintain perfectly off-chain and allow for graceful ejections back to on-chain. The perfect unicorn. So far, the two proposals that could achieve this type of behavior would be MATT and Drivechains which would provide it for proper two-way side-chains efficiently. MATT’s behavior would essentially be a combination of CTV+CSFS+Recursion wrapped into two Opcodes. Because MATT is recursive and would allow for much powerful expressive behavior, I am hesitant about its future even though it is an elegant solution.

Another way of achieving Equality Covenants is using Deleted-Key Covenants, which are used today. These are possible today by using pre-signed transactions with secure key deletion, but that’s another form of trust or interactivity that can’t really be used practically in a lot of cases such as hardware wallet functionality which equality covenants aim to solve. The last type of covenant is Noinput Covenants or Deterministic Script Flow Covenants [DSF]. The intended behavior of noinput covenants is nearly the opposite to equality covenants, the TXID’s are malleable since the number of inputs aren’t fixed, but the spending script is preserved, this behavior is enabled by the proposal ANYPREVOUT [APO]. Using recursion, this allows for better state up-keeping and enables Eltoo [also known as LN-Symmetry or Lightning++], but are inefficient on-chain unlike equality covenants.

With a bare solution such as CTV, at each transaction you have to dynamically re-compute the state to maintain it in homeostasis and not eject your UTXO’s onto the main chain while Eltoo is designed to be efficient at the off-chain side. There have been attempts to emulate each type of covenant with the other, but it’s apparent there are fundamental differences between the two styles. Another method to check for keys and provide efficient off-chain usage like with Eltoo is to use CheckStackForSig [CSFS] with CTV. This allows for proper state updating or “deferred distribution of the outputs” to enable LN-Symmetry with CTV+CSFS similar to APO except without the ability for recursion.

DOF Covenants are always non-recursive. These are determinate states that would allow you to create bundles of transactions. It is this feature that we will use to provide a cash level experience to the off-chain world. When CTV has a single input, it is a DOF covenant, whereas when it has more than a single input, it is non-recursive DSF. APO/AS can perform both recursive and non-recursive DSF covenants, but is incapable of emulating the properties of DOF covenants. Due to the work on Equality/DOF covenants, a pull request was done for APO to demonstrate the differences in how they behave. All references are currently at the bottom.

So how do we keep the custodians at bay and how do we allow Phoenix to maintain their elegant wallet solution once they can’t maintain stagnant channels with everyone? Phoenix’s new wallet model uses splicing and a single UTXO and each time you perform a transaction on-chain, it will close the old channel and establish a new one. This reduces your inbound liquidity as you might not have empty channels anymore and can increase the occurrence of on-chain transactions slightly for end-users as you might need to resize your channel. This frees up dead capital for ACINQ because they no longer need to maintain 11 channels with you with half of them empty on your side, but it also makes it easier to trace you and your single UTXO on-chain whereas before, your channels could stay open for months or years and never close. If someone wanted to catch any details about you, they would need to check via the Lightning Network side. Now they can watch you on-chain.

Let’s clean up some of these privacy issues. Have you ever seen the movie Primer?

In BIP78, the idea is to perform “Payment Output Substitutions” and “Payment Forwarding” to help combine payments so that the flow of payments can’t be understood. Let’s incorporate this behavior into every transaction except without the interactivity drawbacks, provide even more options and your sending party or receiving party doesn’t even need to be aware that you’re performing these actions. The sending party also no longer needs to make two transactions that double-spend each other which allows for safer hardware wallet use. So how can we bring BIP78’s desired behavior natively and then allowing individuals to create a new interactivity layer? BIP119 and CTV! We do things like before in BIP78, whenever we are sending or receiving, the other party may include their own UTXO’s and the destination payments may be going to an entirely different party but we can stop using PSBT’s for a poor man’s covenants and use proper covenants then we can abstract a new layer on top of it again.

Let’s explore what it would look like to upgrade the Phoenix wallet. I no longer need to maintain all my liquidity with my LSP, I can maintain the majority of my liquidity on-chain such as in Vaults or DLC’s, and only a small portion is safely allocated to LSP channels all while maintaining a single UTXO. If I collaborate with others on-chain, my UTXO may end up ejected or sharded as others may consume the original UTXO and I am not available to collaborate with them to maintain a singular UTXO. This is where CSFS would be helpful to maintain an updated state as other parties can more easily roll me back up into the shared UTXO instead of needing a service provider to help maintain state. Because the first layer of signing is abstracted away, collaboration to perform new actions becomes much easier. Most actions you perform today using PSBT’s, you would do with CTV, and then you can establish a new layer of behavior when you create your new PSBT’s.

If you wished to onboard your entire family, you could do it in a single transaction with a single input and output UTXO. Have each family member create a bundle of transactions, for each person, the funds will go into two vaults, one colder than the other. You can adjust the vault so that large values may take more days and smaller values take shorter time. You could also have them add a path where in 5 years time, you, yourself, can sweep the funds back to yourself, just in case they never touch their funds. We also need some warmer funds. Let’s prepare some channels. Twenty channels, ten connected back to you, ten connected to a hub. Now for these channels, your family member shouldn’t show them to you yet, we want to keep them hidden so they’re in a cold state. They should only show you the vaults so that you can recover the funds just in case. One last thing, let’s make a bet on that sports game that’s happening on Sunday, we can use a DLC for this and the oracle isn’t even aware of our little bet. DLC’s become much easier to perform because you no longer need pre-signed transactions, think seconds instead of minutes. A lot of DLC’s today are not practical because of the delay times.

Once everyone has everything set up, you’ll create your own transaction that pays to the ten keys, now if the paths expect a specific amount of Bitcoin, if you under-fund the transaction, you could burn all the funds. If you over-fund the transactions, you could burn the excess funds. Once we understand these new behaviors, we could discuss Opcodes such as OP_AMOUNT where it would give us more flexible addresses with how we receive funds. Once you create your transactions paying everyone, you’ll pass them through OP_CTV and produce a transaction that’s funded from your input UTXO holding your vaults and channels, with one output UTXO holding all of the payments to your family members as well as your original funds. Once someone decides to spend, if we’re in contact, we could reestablish a new UTXO pool, ejecting anyone who wasn’t available. If we planned ahead, we could’ve made paths for each situation where Alice or Bob or both are offline and we can maintain them into at least the next transaction before we eject them. If we added CSFS, we can maintain these states much easier and not necessarily need to eject them. Once the transaction is in the next block, your family can at anytime, send you the details to one of the channels, along with a payment to whom they’re sending money to in the invoice, probably a drink at the store, your node will pass this off to whomever needs it among your other channels, you might need to reveal a cold channel to Eve if you had nothing hot already. Now that you’ve made a channel hot, you might need to make sure your watchtower is in order. This Friday when you get paid, you can settle all of the accounts and refresh the channel with Eve so that it’s cold again. If Bob had instead bought a TV, you might’ve needed to reveal three channels to Eve to provide enough funds. No new transaction needs to occur on the blockchain until that Friday.

Now where did we store all of our data? One simple solution I like is to use the same private keys for nostr and use that as a nostr-chain for our pool and any private channels with each other for channel updates and a private channel with yourself for all of your various funds. Overall data management is easier than Lightning due to no global state and DOF covenants don’t need a counter-party. All of these transactions are deterministic in nature so we don’t have to worry about protecting them so much like in Lightning. If you were to reveal your private channel that held all of your funds, unless they also have your key, it does them no good except ruin your privacy. And vice versa, if someone has your key, unless they have the details to your transactions, they cannot spend them. It might be smart to protect your channel with a secondary key so if your primary key is stolen, they can’t find your transactions channel. It’s an interesting situation, your funds are secured by a single [or multiple!] key and yet they’re also being protected by the secondary key to your channel containing your data, as long as that second key isn’t compromised, your funds can’t be moved. I’m sure people will find all sorts of different data management systems, Lightning’s has vastly improved as it’s matured over the years.

That was a wild ride! Can we do it? The more interactivity you perform, the bigger these states you can build and any breaking in interactivity can cause the states to decay and lead to UTXO ejections, the better you build your ejection paths in your states, the cleaner the ejections will be, it’s smart to eject five idle individuals in a single UTXO rather than five UTXO’s. CTV isn’t meant to be the L2 unicorn that everyone has sought after, but instead, a means of incorporating the behavior that we’re familiar of acquiring via interactivity but make it a non-interactive requirement and then allow you to integrate a new layer of interactivity further than you could before. It is an improvement of Layer 1, the deterministic layer, with some new requirements such as data retainment. But we turn these weaknesses into strengths by using the data availability problem as a privacy and security upgrade. Since Phoenix’s new splicing wallet suffers from heuristic concerns on-chain, by integrating the properties of BIP78 where no one is sure if a UTXO belongs to a sender or receiver, it breaks the assumptions baked into surveillance schemes and providers stronger privacy for the entire network.

So what started this discussion? The flavor of drama on twitter this week has been about Drivechains, MEV and does it really affect Layer 1 and the relationship we have with miners. Before I could even begin, I realized I had to catch everyone up to the picture I envision in my head because these questions and answers are nuanced and require a lot context to answer and it’s no wonder we’ve been having these debates for years with no clear resolution. Drivechains are a one-to-one trust minimized two-way peg securing one or many side-chains, up to 256, to Bitcoin using a hashrate-escrow that is akin to a 13150-of-26300 multi-sig spread across three months of blocks with each block acting as a signature. The full 26,300 signatures is actually six months, but worse case is three months. The security risk to your funds is that instead of a normal 51% attack where someone can double-spend only their own funds, now a 51% attack can steal any side-chain funds. But this is why the slow withdrawal is required, it would need to be a sustained 51% for months.

There’s a few new messages that would appear in an OP_RETURN for the coinbase of each block to facilitate the different functions and to ensure segregation from the main-chain and the drivechains. D1 lists all current chains, D2 lists all current withdrawal, M1 is a new side-chain proposal, M2 is ACK for M1 if you support the new M1. This process is similar to a BIP9 soft-fork where 90% miner approval is needed to create the new side-chain proposed in M1. If the new side-chain is approved, it is added to its appropriate D1 slot. The rest of the codes are for bundle proposals to withdraw, approving those bundles and finally withdrawing those bundles. All of this is neatly isolated from the rest of the network, consumes almost no space, provides additional revenue to miners and there should be no impact to the main-chain. The only drawback I would say is that the withdrawals are limited to 20,000 outputs so you’ll have to use specialists to perform the withdrawals, ordinary users wouldn’t perform this action. So what’s the issue? Where’s the drama? It all comes down to incentives and motivations.

Most of the time, the conversation steers towards the withdrawal bundles, miners will steal people’s coins! If this was a concern, we could just extend the time for withdrawal, at some point, there’s just no practical reason or ability to perform the theft. The withdrawal time is fine, we don’t need to extend it further and I think the long delay time actually causes economic concerns. What service provider wants to wait 3 months that could possible turn into 6 months or even be rejected altogether. The Nominal Value of any side-chain coin will be hurt by the Time Value of waiting for such a long withdrawal. The other incentive is the fees earned in each block from the side-chains and this is where I realized I needed to provide additional context. For what matters is how they’re earned.

As it stands today, fees don’t really matter, we are currently sustained by the coinbase subsidy and have a few decades before it becomes a concern. A lot of people like to point out the year 2140 as the year when the subsidy is finally gone, but this is a bit of a misnomer, the subsidy will already effectively be long gone by that time. Halving 6, roughly in the year 2032, we will see the subsidy go below one bitcoin. Halving 13, in the year 2060, we will see the subsidy go below 1 million sats. At this point, our primary means of security is no longer based on the subsidy, but on the fees. By halving 19, 2084, the reward is below 10k sats. It’s effectively gone 60 years sooner! On a good day for miners, they get about 75 bitcoin a day from users. A good day for users, we pay about 25 bitcoin a day. With the subsidy currently providing an additional 900 bitcoin a day in Halving 3. That places 90% of the incentives focusing on the subsidy still, fees still don’t matter. Miners will happily push an empty block just to get the subsidy with no fees, it would be a waste of work to throw away that block. This will start to change around Halving 8, 2040, when the reward is roughly 0.2 bitcoin per coinbase. At this point, baseline fees should start to overcome the subsidy and the importance of fees will become apparent.

There’s a few issues that may be seen once fees are the primary source of supply. Re-org’s are a common concern discussed. One concern of mine is the variance of fees paid per block. On average, the miners are paid 25 bitcoin per day, but what about per block? What if one block has 3 bitcoin while the next three blocks has only 0.05 bitcoin in fees? Some miners might feel incentivized to perform a re-org to capture that 3 bitcoin. Miners that are only able to mine one block a month might get really unlucky and mine a low subsidy block, get a string of bad blocks and they’re out of business or forced to join a larger pool that gets blocks more often and isn’t so sensitive to luck. So block reward variance is important to maintain low as to not encourage centralization of miners.

Drivechains aims to partly fix this dilemma by restoring the baseline subsidy, but not the variance itself. The main-chain and its fees will do their thing and the side-chains will do their thing and provide their fees via individual BMM transactions mined in each block. If there were five side-chains in steady-state and achieved similar transaction revenues to the main-chain as today, that would bring in 150 bitcoin daily, 25 bitcoin from the main-chain and 25 from each side-chain. This is good! The fee variance I was concerned about should be mostly reduced in the Poisson distribution between all of the chains as we’ve effectively brought back the reward subsidy during the early years. Even if one chain or the main chain has a low fees block, the others should try and average you out. The fee subsidy is already understood and agreed upon except few discuss the variance issue in fees and its effects on miners.

What isn’t agreed upon is the effects that the new subsidy will have. The fees are skewed away from the main-chain and the fees of the side-chains become more important. This is where the discussion of MEV, Re-orgs, miner centralization start to join the discussion. Do they occur or not? We’re all mostly familiar with the Prisoner’s Delimma, where two individuals that can’t communicate can either choose to cooperate or not. If they decide to cooperate, they both win, but if either one of them backs out, the one who decided to trust could be severely punished. One that many aren’t familiar with is the Diner’s Delimma, instead of it being a two player game, it is an N player game and relates to tragedy of the commons and the free rider problem.

The Diner’s Delimma is based on how we decide to pay. If we each buy our individual meals, we would most likely be frugal and get the cheaper option. If we split the bill blindly, some or all, will buy more expensive meals since it doesn’t impact them as much. If everyone buys the luxury meal, everyone ends up paying more than if they just paid individually. MEV works on a similar principal, we’re using a common service or function and due to that, we may end up paying higher fees such as larger spreads or prices even though our individual behavior might’ve priced it differently. Can this happen on L1? Not currently and I think recursion may be specific to enabling this type of behavior. They make the perfect Diners. Can this happen on L2? Most definitely. A side-chain could probably be designed to mitigate the effects but it might not be a very fun chain. People will build their Diner’s and people will enjoy them. Sometimes they’ll be smart and know to pay separately, sometimes they won’t.

But this isn’t the end to the story. Let’s tame the beast. There can be a new form of miner revenue with CTV. Miner Compaction Value, MCV. Instead of an extraction game that’s a race to the bottom, it’s a collaborative game to cooperate and earn more fees. Miners can consolidate transactions that will allow them to save space, earn additional fees by including more market activity than one would expect inside a block. People participating in channel factories and coin pools can allow groups of people to pay low fees but be competitive for miner space. I discuss this more in my Enigma paper.

What about Re-org’s for Drivechains? While the side-chains will provide a new subsidy, it isn’t perfect. The Mining Gap still exists and variance of fees can still be high because the main-chain has low throughput so L1 re-org’s may still occur. Depending on how you design your L2 would tell you what vulnerabilities and attacks it is open to, I won’t really get into this can of worms as it’s all side-chain specific. Alright, last one, miner centralization. The key issue with miners is the block template production, while a singular entity has control of that, issues will occur. This is known as the Principal–Agent Problem. It goes beyond just Drivechains, the recent released Mempool Accelerator could one day be a concern if it sees excessive adoption. One potential way to resolve this is to implement StratumV2 to allow the individual miners to control their own templates. Pools can cross-check a miner’s templates to ensure there aren’t too many questionable transactions alongside the miner’s best partial work. Partial work just means that if you need to get 20 zero’s to create the block, your best partial work may only have 17 zero’s. Providing these partial works is how pool’s estimate your hash-rate and reward you accordingly.

So what’s the problem? Looks like they’re all manageable or solvable. The Pareto distribution of funds is backwards. The majority of the fees are from the side-chains, everybody is using the side-chains, and as far as anyone is concerned, the side-chains are Bitcoin. That’s why we implemented the BIP’s in first place! But it was a Faustian bargain. Because deep down we all know they’re not Bitcoin, otherwise we wouldn’t be calling it a side-chain. The majority of users would never really interact with Bitcoin Proper. Why would they? The fees are insane, the security model of my side-coin is basically guaranteed, I would know months in advance of any attempts of thief. So would any user actually care what happens with the politics of Bitcoin? The moment main-chain fees became unbearable, we just moved to the side-chain and life is great again. I stopped caring about Bitcoin because I have my bitcoin in my little bubble of a side network.

There’s two parts to Bitcoin, Bitcoin The Network and bitcoins, the UTXO sets. What we did was make access to the UTXO sets extremely easy but did nothing to improve the Bitcoin Network. It still can’t handle a lot of traffic, fees easily spike at the drop of a dime, lightning is still hard to on-board individuals, all of the troubles of the Bitcoin Network don’t impact the users of the side-chain, that’s always been the intent and selling point. But what did we really do? If your goal is NgU, the easiest way to achieve that is increasing the blocksize, you’ll immediately see more adoption. Second easiest way? Adopt Drivechains. Now I’ve never associated the word easy with Bitcoin and for good reason. I don’t think it would be so easy to just adopt Drivechains and all of our problems go away. We either pay the price now or we pay later. There are a lot of good people out there who haven’t found Bitcoin yet and I think we would price them out. I came late to the game, I spent years being stubborn, but I’m finally here. If we had adopted Drivechains sooner, by the time I realized my foolishness, I would have a fraction of what I have today. I don’t say that in a manner of me bag holding, but that we would end up attracting a lot of people who wouldn’t respect Bitcoin’s ethos, they would never really care and may push for decisions that we might not want and they would hold much more undue influence for we would be outnumbered.

Let’s take the M1 proposals for example. I’ve said that M1 proposals are soft-forks and I was accused of not reading the BIP’s. Yet if 80% of the population lives on these side-chains and only truly interact with the side-chains, then how is it not soft-fork? A new proposal comes in to make a Stake-chain to earn interest. Can you or can you not say that you can now stake your bitcoin? It would seem to be a very valid claim to say yes, I can now stake my bitcoin and earn a small ROI. So how was this not a soft-fork? The problem is consensus shifted from the main-chain to all of these side-chains and we forgot about the main-chain, it became irrelevant to us. All of the value became exogenous to the chain. Those who held onto the Bitcoin ethos stay a fringe minority on the main-chain who might always grow smaller, while the masses and society live their lives on these side-chains.

There’s two things I’ve had Drivechain proponents claim which I must push back on. The first that a privacy chain would be sufficient to help Bitcoin’s privacy, let’s just recreate zcash on a side-chain! I feel that Litecoin’s mimblewimble getting blocked helped show that privacy upgrades must be to the core system and attempting to create an add-on for it isn’t sufficient. The other is that only Drivechains provide sufficient fees once the subsidy runs out. I feel that I’ve shown that is clearly not true, there are new and better ways of acquiring fees to secure the chain. Another, as Drivechains are designed today, they could be better designed for tomorrow. One example is the 20k UTXO limit, this can be expanded beyond that limit with CTV to allow instant payouts over Non-Interactive Channels [NIC’s] that aren’t claimable until the 3 month mark. Because the payouts are immediate, perhaps it would be smart to re-evaluate the time lock on the funds, a shorter period could be appropriate. Because the funds can be shuffled around, we could find that the funds re-enter the side-chains and leave no footprint after the time lock is over.

So what do we do? Just nothing? First we must fix the Pareto distribution of fees earned. 80% of the fees should to be sourced via the main-chain and 20% from side-chains. This means that we have to build the Network’s strength and earn more MCV. There is an order to these things and before we discuss more advanced upgrades, we need to come to an agreement on a DOF covenants upgrade. We got a little excitement from some Ordinal folks and it brought the usability of the market to its knees. That’s not money of the future. Having Equality Covenants would allow us to create layers within potentially endless layers and accrue additional fees via the main-chain. CTV alone enables at least 2 different side-chain models discovered so far for people to use to experiment. On those side-chains, you can stake or create further side-chains. Other off-chain solutions such as Ark, Darkpool, two new blinded non-custodial e-cash schemes. Ark is meant for convenience and speed while Darkpool is meant for more long-term solutions. Along with Lightning, these new layers can always be extended off of these chains. And each of these layers can now share space together to save on fees on the main-chain. There will be no difference between Layer 1 and Layer 2 except when you desire your finality.

We could see how much adoption these side-chains and protocols adopt before we decide to optimize any processes such as discussing proper Drivechains. There’s more features that come with Equality Covenants covered in my paper Enigma such as dpools that would help modulate the fee variance even better than Drivechains could ever dream, even going as far as fixing the Mining Gap. Even though I feel CSFS is safe and would give us Eltoo along with CTV, I would be happy with only CTV as it would allow us to explore these new domains before choosing on how to proceed further. The community should be part of the discussion. We might find we don’t need anything else, but if a need grows, the market will want and then find a solution. To do that, it means we must keep building. Cypherpunks build. The problem with that is that Consensus is broken. This didn’t happen recently, but since the very first e-mail. I hope this helps to heal that wound.

A single act of carelessness leads to the eternal loss of beauty.

Enigma: https://app.sigle.io/polydeuces.id.stx/bo-iHio5_4iTlvWwXwZ9l

Burak’s Ark: https://www.arkpill.me/

Moon’s Darkpool: https://gist.github.com/moonsettler/6a214f5d01148ea204e9131b86a35382

Moon’s Surfchain Side-chain: https://gist.github.com/moonsettler/e0c24863fda418a2fb504a307fda8a19

Linus’s Stakechain Side-chain: https://coins.github.io/stakechains.pdf

Reardon’s Comparison of Covenants: https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/

Lloyd on CTV+DLC’s: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html

Zen’s CTV+DLC’s: https://zensored.substack.com/p/supercharging-dlcs-with-ctv

Review of Smart Contracts: https://rubin.io/bitcoin/2021/12/04/advent-7/

Primitives and Upgrades: https://rubin.io/bitcoin/2021/12/05/advent-8/

Covenants: https://rubin.io/blog/2021/07/02/covenants/