I suppose we will now all talk about covenants...again.
Here is a nice lite compendium of covenants info. The sit didn't show up too well on mobile, so consider checking it out on desktop.
Might be a good place to start if you want to get up to speed on what's out there.
I wouldn't call myself an ossifier, but I'd prefer to err on the side of being conservative.
My reason, Bitcoiners shouldn't ever compromise on freedom, and as long as nothing is breaking, then I'd say the only acceptable change is one that blazes forward from that principle, ideological, freedom-maxxing intolerance. Obviously, the foRkTarDS didn't -- they were ideologically intolerant, but from another camp, the wrong one. From my 30000ft view, a good proposal has to somehow create the narrative that it enables more freedoms in the future, and not less, get the ideologically intolerant freedom maxis on board and the rest will follow.
Again 30000 ft.... Covenants defined as,
Isn't very reassuring. But what do I know?
Now I wonder, can we undersrand the Knotzi as a semelparous bitcoiner, that essentially proved the opposite of their main thesis, i.e. that a small subset can control bitcoin?
I wonder.
The point of covenants is to make bitcoin better money. They let you put conditions on how your bitcoin is spent. Not anybody else's. I think that's where your resistance comes from.
Covenants can let you protect your bitcoin from theft, hand it on to others, or collaborate in how your bitcoin is spent in a group, but they can't let you control someone else's bitcoin or anyone else control yours (unless you specifically join a group covenant for the purpose of collaborating in spending).
Thank you for reading my comment and taking the time to explain. The word "whitelist" came up in one of your previous (linked) posts. It's a new word for me, so it wasn't necessarily how I thought about it, although, is concentric with the anxiety I had, which is that (my reflex thought, based on how it was worded, see above, was) somehow covenants could be used to undermine the permissionlessness of using Bitcoin. I'll be honest though, I don't fully follow the idea of a "permanently KYC'd coin," and I don't maintain that view.
It sounds aspirational, and a bit like a how nanny-state strives to function. Claw-backs, especially, very fiat.
Protecting bitcoin from theft requires cajones, not covenants.
In Bitcoin, the recipient picks the address (i.e., the output script) that they expect to be paid to. Usage of a covenant construction would be self-selected, it generally cannot be imposed by the sender. If the sender unilaterally decides to send funds to a different output script than indicated by the receiver, the receiver would likely not even notice the payment, and has grounds to not honor the payment.
My comment may have come off as tone deaf, I'm realizing. I do understand the basics of bitcoin transactions, but a covenant script is unfamiliar to me.
I'm trying to think about what it would be used for, about which I can see there have been huge efforts to explain, but I encounter heaps of technical jargon that I don't understand when I try to engage. Not from you, though. It is really interesting that the people who do understand, and whose opinion actually matters seem to have their own preferences based on the techanical merits and pitfalls of each proposal.
Fwiw, I hadn't ever read up on these nor paid attention to any commentary before reading this webpage and I was just pointing out that the language sounds CBDC-esque, put in that way. Maybe it isnt just me, since you and nerd2 sought to clarify the point as well. Is it a common FUD?
Covenants being used to create a whitelist-coin was a big concern when the covenant debate restarted a few years ago. After it was debated for months, the general sentiment settled on the concern being unsubstantiated. About to go to bed, I’m gonna try to write up an example for a covenant tomorrow after the Optech Recap.
The main thing to consider when thinking about whether covenants can or will be used to make a government whitelist or whatever is whether any given covenant construction is superior for that function than the existing 2-of-2 multisig that bitcoin already supports.
To date, assuming that I'm an evil government wanting to restrict the usage of bitcoin, the BEST way to do so is to require custodians to only allow withdrawals to 2-of-2 multisigs with my cosigner as the 2nd party. Now no user can spend without my permission and I can check every transaction for whatever conditions I want. Every covenant idea from CTV to TXHASH to CCV is inferior to a multisig for me the evil government.
Also keep in mind when thinking about the above that any covenant related whitelist would have the same problem as the above which is that I the recipient would have to include the condition (whether additional signer or covenant) in my receive address. Bitcoin, no matter how modified, does not have any concept of sender-added-conditions for receive addresses. For more on that, see here: https://x.com/reardencode/status/1757481697460072808
https://twiiit.com/reardencode/status/1757481697460072808
I realized that I was struggling with coming up with something reasonably quickly, and should also be trying to catch up on BIPs, so I asked a friend to tag in for support.
Just checking, you have already read this thread by Robin Linus? https://delvingbitcoin.org/t/perpetually-kycd-coins-using-evil-covenants/556
Looking forward to that!
Multi-sig can be defined as "Restricting a UTXO to only be spent after a number of wallets has signed" or timelocks as "Restricting a UTXO such that it can only be spent after time is passed"
You have to create a wallet with the CTV script for this to be a thing. As we only expose addresses, and not xpubs, no one can lock your Bitcoin to a CTV script (using a seed phrase you created) in the same way that no one can lock your Bitcoin into a multi-sig with keys that they control. This is FUD.
This is once again a demonstration of why I am calling for anyone serious about CTV to write demonstration software
Anything you can do with CTV you can already do with presigned transactions + deleted keys. The purpose of the CTV consensus change is to make it so users don't have to perform this bullshit ceremony just to use that functionality.
No because like one of the things they're trying to do is like coin pools. Like your lightning transaction is actually a 2-of-2 multi-sig. So its kinda like "just use deleted keys" and so you're relying on the other party you're in this covenant with (which just like multi-sig only works by exposing xpubs) to delete their keys in order for your security guarantees to be real.
Also lets be honest with ourselves, a psbt (or a bunch of them) is like going back to 2009 wallet.dat files for Bitcoin key backups.
Saying some things are "kinda like" other things is not an argument against covenants. Try again.
I'm sorry I'm trying to make it relatable to something you've experienced before, but again, that's why I call for demonstration software.
Hey, recreate a vault that protects an mk3 generated seed using presigned transactions. See how well it goes for you.
So I thought about it right? You would generate the seed on the mk3, presign a transaction to a holding address. The holding address uses the timelock script. After the timelock, the mk3 can spend from the funds again, no no wait...because the key wasn't generated securely the presigned transaction never gets mined ah fuck and we don't have a "wait until I sign to start the timelock" op_code in Bitcoin script. Man, but Kruw you're so sure about this pre-signed transaction thing why don't you demonstrate for the class?
Look, if you know me, you know I like to hold back from being an asshole like this, but I don't know maybe this is what it takes to make a point?
I love being an asshole, no problem.
Irrelevant. Bitcoin is built on the assumption that users generate random secrets. Nothing matters if you discard this premise.
Okay. We'll see how relevant it is on the larger forum. I think its actually very relevant. "CTV vaults save you when your cold card fails you".
I think there's a bunch of node runners that are going to be very happy that this risk mitigation can be a possibility.
The logic makes sense, but not the story. Why is it needed?
Multusig mitigated single points of failure risks. Simple.
Simplicity speaks volumes.
Don't worry, I'm going to be taking the "code or shut up" approach for the next few months. I'll come back with a GUI so you can see what I'm talking about, although CLI demo software is currently available if you would like to get ahead of the curve.
seeing those proposals I can't stop thinking of them as shenanigans for trap clueless people.
Ill take a look and read more about it to clarify what it is.
There are no traps in covenants. Just tools to help people better secure bitcoin in various contexts.
OP_TXHASH authors are Steven Roose and Brandon Black, not Russell O'Connor and Brandon Black.
You can verify it in https://bips.dev/346/
Also, for some reason in the left index TXHASH looses the prefix "OP_".
I don't mind AI slop, but you need to double check it.
The original ideas were Russel O'Connor's though :)
Is this an old page? It doesn't mention BIP-448 or OP_TEMPLATEHASH. IMO that proposal currently has the most momentum and odds of actually getting activated.
I believe it is maintained by Brian Hirschfield, and it is possible that he is using it as a learning exercise.
I always thought Dathon sounded rather like Dathan, who led a rebellion against Moses and got smoked in the Book of Numbers.
People think it's weird when I pay attention to names, but it's worked out for me so far.
Interesting connection
Good link, comments filled with all the usual FUD.
I think reading and talking about it is not enough. We need to build demonstration software so that regular users who were psyoped into being scared of it can instead of talking about outrageous hypotheticals, talk about their lived experience instead.
On that note, I would start with vaults as the first demonstration using the coldcard mk3 example as background for the demonstration
The funniest part is both sides think they're the freedom camp. One side says don't touch the rules, the other says covenants are how your keys survive your own hardware failing. Same fear, different cure. The fork circus just proved the loudest narrative wins, not the best technical case. That's the actual lesson this thread keeps dodging.
110 was always about dismantling resistance to covenants and Bithereum non-sense generally
deleted by author