pull down to refresh
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
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!
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.
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
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.
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
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.
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.
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.
Hey, recreate a vault that protects an mk3 generated seed using presigned transactions. See how well it goes for you.
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.
I think its actually very relevant. "CTV vaults save you when your cold card fails you".
It would be relevant if I made the claim that CTV would have stopped the COLDCARD attacker, but I didn't.
However, I will steelman that argument for you to fight it: The option of covenant enabled vaults could have mitigated some of the losses from the CC vulnerability. This is not because CTV protects coins directly, it is because users are more likely to use multisig/passphrase/dice rolls on their "final stand" vault wallet than they would for a daily spending wallet.
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.
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.