This is a continuation to my first paper on CTV and Enigma.

I cover a lot of material in my second paper from my concerns with Lightning, a better explanation of how covenants work, the problems I see with Drivechains and what's a good direction to aim towards.

I've written a second essay which would help understand this one. It's still dense but much more approachable

Yeah, it's definitely dysfunctional at the moment but I show how we can vastly improve it 😉

Deterministic so safer than lightning, you only need to hold your own data commitments so less of a headache than lightning, everything is non-interactive unless you decide to collaborate. Enigma will be much larger than Lightning, after discovering this and comparing it to Lightning, I think we're way over relying on Lightning.

the upgrade itself is relatively simple, 200 lines of code plus tests. it is massively less complex than both segwit and taproot. the issue has always been, what's the reward?

No, STXO is not a "redeem" for my UTXO. It's my money just as much as my private key. The STXO is IN the blockchain, it just doesn't have global presence. if you lose your transaction info, you lose your money.

You can directly write STXO's onto the chain and I'm going to add a way of making the CTV transaction a sponsor for special transactions that are STXO but should be on the base layer. what will disappear are silly things like channel openings and closings. payments to bob. i also want to add what i'd do to whirlpool.

CTV is just a placeholder for transactions.

I want to pay Bob (Tx1) Open a LN channel (Tx2) Cold Storage (Tx3)

SHA256(Tx1+Tx2+Tx3).

ATXO is the tx with CTV(HASH of Tx's)

STXO is Tx1, Tx2, Tx3.

if STXOs arent Bitcoin than neither is lightning. we could designate lightning as LTXO's.

Proper link

I made an update :).

The Enigma Network

How about we fix the scaling issues instead of this

here ya go

you can't fork Stamps out unless you want to remove multi-sig. That is their stick against censorship. Stamps pollute the UTXO set, causing an effective RAM leak on the entire network. Best we can do have them have their fun in the least destructive way possible.

Twitter's discussion and questions

covenants!

the internet relies on the datagram as a standard.

RGB can replicate any blockchain. there won't be 20k chains in the future 🤷‍♂️

The Hodl culture and meme is easier to explain than the Hodl+Spend so it's easier for one to be more popular, especially since the Hodl is a lot older of a meme. Having Lightning definitely helps the Hodl+Spend crew.

One problem I've had with the culture is the inability to admit the scaling problem. We say that Bitcoin needs nothing else but even when segwit was made, we knew that it couldn't scale perfectly. If we wanted it to work on a global scale, Lightning's whitepaper cites 133 MB blocks for 8 billion people. Taproot and Schnorr Sig's ability to aggregate will definitely help but it'll only get us so far. I think the best next upgrade would be CTV, CheckTemplateVerify, to explain its behavior, if Taproot and Schnorr can aggregate signatures, CTV allows you to aggregate transactions. A next perk to this is that anytime you create a covenant, you aren't the individual paying the fee to commit your transaction [unless you're spending to yourself of course]. When you're wanting to receive payment, you create the pubkey address that they will spend it to, but what they don't know is the details of that Script key. You could program in it a few channels, some going to cold storage and some going to George, the guy next door. No one will know until you inform that person of your secret covenant transaction. I've done a few write-ups so far and am always welcoming feedback, so no one hesitate to comment!

#161679_

OP_Vault has been reworked to not touch any of the transaction components but work only at the tapleaf level. James now wants to include OP_CTV with OP_Vault

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