Welcome to Covenants 101, with a focus on CTV.
What are they? Is this an attack on bitcoin? Can the government lock up all our coins?
Without an accurate mental model of what's actually going on, it's hard to reason on what they can and can't do.
So let's walk through it. š©š
Addresses are built from the spending conditions YOU want for YOUR coins. You have a key, you define a lock that it opens, that IS your address.
Coins (UTXOs) sent to the address must be unlocked to be spent. You defined the lock, you decide what opens it, nobody else.
#m=image%2Fjpeg&dim=1193x670&blurhash=iB9Z%7D%5BR4MwV%40R%2B_401E2bwxaV%40j%5BayWCogNGogay00p0x%5Dozsm8_%7EV-oi%5EE1tRa%23oes.V%3F-pRij%3F%7EWr%3BMxWBkCx%5EE1E2g3&x=0074ba584c939245de6642f0af58fb03a58caa071c164670b1edbee8f2a5deff
There are other things we can use to make our locks: extra keys, relative or fixed timelocks, & logic to combine them. The address encodes it all.
(Technically, theyāre all actually scripts - the different functions used inside: OP_CheckSig, OP_Multisig, OP_CheckLocktimeVerifyā¦)
#m=image%2Fjpeg&dim=1194x671&blurhash=iICZU%7BfP9Ys%3AD*xu009Z%7EqMvWBbXjFt9ofxvXSRjs*ayWUoKj_t7bJNGWA%3FbofV%40WBNHWBD%25kC%25L4mjv%252WBkWRj%25g%253IT&x=560797a2678a79e78834b14a9e958e2256fca7d5d99a492bf8645efa771af48c
You build a transaction with the To addresses, attach your UTXOs, and show whateverās needed to unlock them. Then broadcast.
Before itās included in a block, Bob canāt be SURE heāll get the coins. EVERY ownership change MUST touch the chain to become immutable.
#m=image%2Fjpeg&dim=1191x670&blurhash=iADS%25P_059nmwuXn009bM%7C%7D%5EMgN%7BtQagf94mj%3BWB6%7Cl8%24LMzOai%5E%3DtxBkD00rt%2C%2CWTOGIU_4W%3DR.4TxVf%2BM%7CxBS4k%5BS6xs&x=88f9bcb0507eadb4359a919f44ced66be1f2ddf1056a5bda5e36636e8970111b
OP_CTV, Check Template Verify, proposes a new primitive added to the family: check that the SPENDING transaction, hashed, matches one we defined.
Itās kind of like using Tx data as the key for the lock, instead of a private key. And if YOU build the address, YOU decide the terms.
#m=image%2Fjpeg&dim=1192x672&blurhash=iBBWY*8%5EM%7Bxv4ox%5E00Rk_2%3FbD%24ozt7aeoLayofR*00Ip-%3Bs%2CxZRO%7Ept74oWBV%40t7j%5BWXRj%25MRjRi%7EVemITbbkXkXD*NG-p&x=d26abb0dd8bb9c4b41f29adb2b9205c603d82bde91a0338f31f6eb22e7f2a66b
If CTV was live, Bob can make his address key be a signed but unbroadcast Tx sending to Charlieās address. Nodes will reject any other spend as invalid.
If Bob hands that Tx to Charlie, he can SEE Bob canāt spend them differently. And pay himself out any time, without asking Bob.
#m=image%2Fjpeg&dim=1192x669&blurhash=iDD0AP%7ES4%3AI%5EMxxa%25LNL00%7EErZIWtRR%24t8t8NG9FFZcE-.rqRnNeNLVsxC00NN-Ui%5DtRNGIVjE%3Fa8%5En%23xuNHa%24nhs7ozks&x=87fb386b20b37aa79c7066ff1b00c4cb7da3de3e8e7456b81827a21a9bb9a770
If you choose to ACCEPT payment via CTV, the payer needs to pass you the Template for every step between your coins and the mined Tx.
Thatās what you need to fully exit if you want. We always have to store data: private keys, channel states for LN, now spend paths for CTV.
#m=image%2Fjpeg&dim=958x670&blurhash=r5B3%24gL30A%5EN00r%2CIs4p%25g*f4ZEl%3FWIBrpOWXSxu1X.0%3D%5D9H%3Fd%25hRQxbIU00Mc%24_S%25%3FvtTxZ%25LIUbxowjYa*WTV%40oga%5EV%5D%3Fw-%3AxZRSD%24E1WFV%3Dxu&x=368e9f7ce313fab67d6af1690bbb7169708c83ee74119c9a655bbbd077538e81
We burden the chain with only 1 transaction, yet get more than 1 ownership change, or said differently: irreversible commitments.
What if Charlie did the same thing in creating HIS address, with someone HE needs to pay?
What if they did it too?
#m=image%2Fjpeg&dim=1193x669&blurhash=iDD9q%3B_09ZIvRQs8-%3BNH00%7EDnAIWozbXofxvM%7B9YAXpb-owIRkNyNIVsw%5B00WG%251s7ozR.IUjE%3FH4mxBt7NIWXs8ngozp0&x=17ba9658e51d6b21db07c5af96eff67e8f5dc2107a7d18d01d2d5da510978810
What if each layer paid many people, not just one?
We can go as deep as we can coordinate in advance.
When Alice makes that ONE payment on chain, EVERYONE in the tree is paid:
The guy before them CANāT take coins back, and keyholders can all exit whenever they want.
#m=image%2Fjpeg&dim=1192x669&blurhash=iHEo*%2BV%3BX9E3RQxWxuR-4n%7EWR7RkozWnoft8NGD%259%5ByDxZw%5DafNLSOV%3Fs802M%7D%252aJt7R.IUsm%25MDingt7R-R*s%2CjDozkr&x=12493c317e26b3f4a521ca6b8aa397d505f8b0da47e20e9b127862271d7b90aa
Instead of each L1 Tx being one ownership change, we can plant a whole tree full of many users, all sovereign, but only using 1 UTXO of block space.
If the leaves were lightning channels, you can even be spending sats freely - only updating the tree rarely for channel closures.
#m=image%2Fjpeg&dim=1106x671&blurhash=iD9asXxaRRoyMzx%40MyW.RkD8Vvx%40V%5BoxozaxbFay%3F%5BtQV%5DkBV%5Boze%3AWBaeMhbaoMWBoxnmW-WBa_i%25btjbaykUjIX5e%3Aoe&x=e0dde6b60451a24531945c751fc8a5a8b97a9e9c19b1977e724c94b467225953
Wait: Donāt we have to mine this huge pile of Tx eventually, for everyone to REALLY get their coins?
If we collaborate, NO! We can build alternate spend paths. But thatās a whole thread.
You now understand covenants 101: commitments made *without always touching the chain*.
#m=image%2Fjpeg&dim=1118x668&blurhash=i8BzB%7D%3F%5B00DPVt9ZIA%3FH%25N%24%3AQ%3FDiNYScMyRQ%25M%25fEbti-pt8s%3Bs%3Ax%5DWCMx00DjWB%3Fb%3Fvt8spM%7BE0IURjsoxu%25MxuRjIUMx&x=63b4dcf0ac4f4e43b44c443a7fd3746da00b765dbc08b483ab0bdd78446f32c7
This is awesome! Thank you!
I wish I had more visibility on nostr. I get pretty much nothing on here when I post content
Can you consolidate into one long note next time? Nostr doesn't have arbitrary character limits like Xitter.
Nostr is a lot smaller than twitter. It is more focused on bitcoin, though. I think there is good potential to educate plebs on here. Thank you for migrating these threads. I have wanted to dig into how CTV enables these higher level constructs. š š
man, same
zero interaction whatsoever on my occasional development posts. I get that it's technical, but isn't most of nostr?
followed
Being a reply guy seems to be a decent way to get followers. It worked today! Otherwise, I think, just post consistently and be patient. Nostr is very small still and there's no algorithm to game so you shouldn't expect the same engagement numbers as other networks.
A ton of good info here. I've only heard about CTV argued about by folks way above my technical understanding (for what seems like a really long time now) but haven't seen so neat and logically put together. Will study further & ask questions, seems worthy of a full length article imo
You can make this a regular note, you don't need a thread
Ser I have heard from other technicals that TXHASH is a better and more functional upgrade vs CTV. Do you have an opinion?
As far as I'm concerned CTV and TXHASH are functionally equivalent. The difference is really TXHASH is trying to specify all possible behavior ahead of time but disables it for now, and CTV specifies one very specific, well understood behavior right now, but allows upgrades over time.
Preferring TXHASH over CTV basically means pushing back covenants at least 2 years, for no benefit that I can see, since CTV can always be upgraded to support new features.
Thank you for the insights! If you setup zaps youāre due a couple.
Iām looking forward to this eventual upgrade and subsequent functionality. UTXO sharing and vaults especially.
Will CTV enable Lightning symmetry?
CTV alone doesn't enable lightning symmetry (as far as I know) but the proposed LNHANCE upgrade combines CTV, CSFS (checksigfromstack) and IK (innerkey) to enable lightning symmetry.
CTV as proposed, as far as I'm concerned carries essentially no risk. It's functionally equivalent to presigned transactions, slightly more space efficient, and without the risk of mishandling keys or key leakage.
Of these, I understand the implications of CSFS the least, so I'm not sure if there are any risks, people I trust somewhat say there's no risk. Still, I prefer to understand as much as my pea brain allows. Regardless, I believe it's necessary to enable ln-symmetry with CTV.
IK is nothing but a very neat little space optimization for taproot, so it has no risks that I'm aware of.
Txhash is CTVv2. It would allow you to have more flexible fees and control what happens with the committed tx's. The problem is it can be designed a hundred different ways, and I've lost confidence in the developers who are pushing it for multiple reasons. The first being, they don't actually understand CTV, they see it as "limited" because it doesn't deal with sighash flags and sets everything in stone, so they're trying to fix a problem they don't understand. They try and say that CTV is flawed because it uses CPFP more often than RBF but they don't realize (because they don't understand CTV trees) that you can't RBF in those situations or it breaks the trees because the TXID must be immutable. Another big red flag for me (besides the fact that theyve been nacking CTV for years and not producing any code to replace CTV) is that they see zero risk concerns for behaviors that txhash can do such as TXHASH+CSFS gives you drivechains and MEV. The MEV can occur because of the exact flexibility that they desire from txhash. They're also not even aware that CTV has its own upgrade path, Rearden has made one called Template Key. The difference between txhash and TK is TK is a single byte mode operator while txhash relies on multibyte sighash flags. They have zero self awareness and honesty my patience has run out with them, I am finding them to be intellectually dishonest at this point.
Great information, thank you. As a non technical but also operating a node I am trying to get as much info as I can on covenant upgrades so I can make an informed vote by choosing which version of the protocol to upgrade to (if any).
Do you recommend running something other than bitcoin core or is that the only reliable place to get the best version of the protocol? I was thinking about this the other day and wondering if there are other sources for software outside of core.
Core is your best bet, I'm tempted to spin up Knots to see what GUI changes Luke has done, I just don't agree with the default relay settings so I'd change them. Sparrow is a nice tool as well. I'll be honest, I rarely run my node, it's typically off months at a time. Peter Todd has also started his own distro called Libre Relay which has a more relaxed op_return and a new RBF called One-Shot but it's still super beta.
The thing that has really helped me learn the innards to all this was Jeremy's advent calendar that he made for CTV. I spent a good year trying to decipher it all and I'm still learning.
I've written two of my own essays to try and help teach what I've learned.
Iām interested in knots too. I just wish it had more devs and more eyes on it. Would be cool if a more nimble competitor (to Core) arose where they could implement soft forks and push the envelope so ppl like you and me could run them to try it out.
I actually donāt use my node for txās lol I know thatās corny but I wasnāt able to set it up privately and itās on a windows machine. As a non technical Iām not confident enough in the setup to custody my life savings on it. I use sparrow via someone elseās node on a different machine and hodl my keys in a secure schematic.
I see it similarly to Linux Distros, use Core (compare it to Debian) and from there, various flavors are made. Most security related patches should always go upstream to Core and disseminate from there. Soft forks are bit of a pain points atm, Core has said they're not dealing with soft forks anymore, consensus has to be found elsewhere. So we've been trying to figure that out for the last few years
Interesting, I didnāt know Core wasnāt messing with soft forks anymore.
So there is an opening for a group of devs to implement new consensus changes post-core. Could be called Bitcoin-mantle!
Is anyone working on filling this market need other than nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk ? Maybe nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m nostr:npub10pensatlcfwktnvjjw2dtem38n6rvw8g6fv73h84cuacxn4c28eqyfn34f and others could work on setting something up?
Itād be righteous to see some of these upgrades get off the ground and into main net so #Bitcoin can work towards scaling further. Iāll update my node. #CTV #APO #TXHASH #CSFS #OP_VAULT
It's not about the software itself. If the market was ready for it, it'd be ready in a week. The problem is the market needs to learn what it desires.
Well this lil conversation is a tiny signal that the market is starting to demand something like a post-core repository where new scaling (and anti-spam) upgrades can be found and experimented with.
OK so question... if you can "plant the whole tree" with only using up 1 utxo... in the process of building that tree offline so to speak, what is preventing the double spend? Since the transaction is unbroadcasted, what is preventing someone in that chain from signing twice?
