It might be eltoo, but recently there was a proposal for hierarchical channels on Bitcoin that could be done without eltoo. So it's possible we could skip eltoo entirely and have channel factories where liquidity can be rebalanced off-chain now. I posted about this a little while ago: #160061

Me personally, I'm hoping to see Cross-Input Signature Aggregation for base layer

OP_VAULT would be best

Hoping for BIP 118. SIGHASH_ANYPREVOUT should enable Eltoo and make Lightning even more scalable and secure.

Eltoo, OP_vault

ban jpegs

ossification

Not everyone supports the taproot update after so much time, and you are already talking about the next update ...

I used to anticipate BIP-118, APO being the next upgrade but it still has complications, the fee market still isn't figured out for it and the complexity keeps increasing so I'm starting to have my doubts.

What I have been looking at now is BIP-119, CTV. What is it? What does it do? CheckTemplateVerify allows for users to pre-commit transactions via pre-signed hashed transactions. What does that mean? Today if you want to acquire some bitcoin and open a lightning channel, you first have to recieve payment and once that's settled on-chain, you can broadcast a second transaction to create your channel.

So what about CTV? Instead, when you request payment the first time, you will preprogram your intent into the public key address that you provide to the exchange or whomever is paying you, and when they do pay you, their tx and commitment on-chain is the proof you need to open your channel. This was a Non-Interactive Channel. My channel partner can be completely unaware that this channel was made, and I could do a uncooperative close on the channel and my partner would never know it existed. They would only find out once I provided the transaction details for it, aka the pre-commited transaction.

Now that's a very basic feature but it's only step one. At a minimum, if you always use covenants and pre-signed commitments, you reduce on-chain transactions by half (not completely true, there is some blockspace consumption when unrolling transactions) as you're always creating transactions when you're receiving payment, this could go towards making a channel, sending it to a vault, making another payment to someone else and so on.

The design space of Bitcoin doesn't change, there's no new features that are enabled, but what it does do is remove trust from the system, for example, inheritence and vaults no longer need you to delete a private key.

So all we get are NIC's? Not even close. Let's build some more features, we can pre-commit any tx we want! Next, I want to add in some congestion control. I had wanted to open a channel with Alice, but I also needed to pay Bob. So I'll need to pre-commit some fees for Bob's transaction, I'll specify it to pay in a range of 1 to 3 sat/vbyte. the neat part about this is that the transaction doesnt need to be unrolled today, it isn't a 0-conf tx, it's been commited already by the exchange so it could sit for years before I even tell Bob about his payment (if it were to unroll thanks to the congestion control, bob's wallet would scan the chain and see the vanilla utxo).

Alright, let's collaborate on a larger level, let's make some Payment Pools. I'm getting paid from the exchange and I've programmed my payment to make a channel. But so did 200 other people getting paid from the exchange. Typically this goes out in a batch transaction with lots of outputs, one for each customer. But now, its batched transaction will have only a couple utxo's. where did everyone's money go? You formed a utxo pool. Everyone owns a part of that utxo. When you do eventually spend or close your channel, that utxo pool will begin to unroll. Your closing transaction will include the utxo pool as an input and on the output side, you'll have your payment being ejected from the pool and the another utxo for the remainder of the pool participants. Your utxo might even unroll from that pool and roll into another pool. both pools could even merge into a single pool to save space, depending on the circumstances.

What else can we do? Decentralized Mining Pools (I'll call them dpools). Lots of perks, some downsides. You can only solo-mine it as is, you can always join a normal pool that mines in the dpool, but the dpool itself is quite decentralized, no operators control the funds to the dpool, communication means such as dns is not needed as everything is done via the blocks themselves. the dpool's template is set in stone with the first block it mines so no one controls it. Operating within a dpool also allows for some fun features such as Compaction. What if Alice is paying Bob at the same time that Carol is paying Bob? Wouldnt it be nice if you could effectively CPFP the two tx's and only have one tx commited on-chain? That's a Compaction! now there's a utxo coming from alice and carol paying to bob. If Alice, Bob and Carol were each in their own payment pools, all 3 pools could be merged into a single pool. Now this is being all done on layer one. What if we were doing channels instead? We could do Cross Channel Tree Swaps. We could at our leisure consolidate utxo's and pooks.

So what problems does CTV really fix? one off the top of my head is channel jamming, a limitation of lightning is the number of htlc's. If you have too many, your closing tx becomes too big. With CTV, htlc limits are removed as everything gets rolled up into the pre-commitment. Another issue it solves is dust. If you always defer to creating channels with your dust, it is always spendable and can be consolidated by the next owner. Another is the security budget. So today, if we wanted to onboard everyone in the world, it would take 8 years to do so. With CTV, you could onboard everyone in one day and then over the next 8 years, their utxo's would unroll on-chain and if they opened channels instead of being on layer 1, their money would be immediately spendable, they didnt have to pay opening channel fees and if theyre lucky, someone else they had paid can cover their expenses to update their channel as that person performed their own channel update. So over that 8 year period, miners can see that there's millions of transactions using congestion control, waiting to be unrolled. the transactions dont need to compete for fees as they arent 0-conf, they were onboarded on the day of the great flood. so the tx's can sit indefinitely until someone decides its time to update. This does raise some interestinf questions about the mempool. Do we have one for 0-conf and one for commited transactions that have additional unrolling to do? Since miners can create channels in their basecoin transaction, they can technically spend their money before the 100 block cooldown, they just cant close it.

Some more references in my thread

Cross Input Signature Aggregation would get bitcoin more fungible and cheaper to use on-chain