Bitcoin Forum
October 10, 2025, 06:49:38 PM *
News: Latest Bitcoin Core release: 29.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Covenant Script: Modern upgrade or new vulnerability?  (Read 108 times)
Liocen (OP)
Member
**
Offline Offline

Activity: 71
Merit: 25


View Profile
October 09, 2025, 09:24:57 AM
 #1

In an effort to control and make Bitcoin transactions more secure, developers have created a script called Covenant Script. Covenant Script is a scripting concept that can restrict the future use of Bitcoin’s UTXO (Unspent Transaction Output).
Normally, when you send Bitcoin, that output can be spent by anyone in a future transaction — if they provide the correct signature.
But with Covenant, you can say:
“This output can only be spent in the future on this specific script, or this specific type of output.”
Thus, Covenant imposes a “rule” or “condition” that controls the natural free flow of Bitcoin.

Although Covenant scripts (such as the OP_CHECKTEMPLATEVERIFY, OP_CAT, or OP_TXHASH proposed codes) enable a new generation of scaling and privacy tools such as Ark, Vault, and Channel Factory,
some people are still hesitant to use them due to their risks or controversial aspects.

They explain the following conclusions about its risks_
▫️ Since Covenant allows anyone to create scripts that force transactions to be sent to specific addresses or conditions.
This allows governments or large organizations to create policy-enforced address lists and apply “whitelists/blacklists”.
If Covenant is used incorrectly, the fungibility and independence of Bitcoin can be damaged.
▫️ If Covenant is designed incorrectly, “recursive” or repetitive covenants can be created —
that is, a Covenant will continue to impose the Covenant on subsequent UTXOs, acting as a kind of self-propagating script.
Unexpected script loops can be created in the network,
node verification can become complicated,
even “locked output” (stale coins) can be created on the blockchain.
▫️ Using Covenants makes some transaction patterns “predictable” —
such as Ark or Vault transactions having to be in a specific format.
Although this increases privacy, analysts will be able to identify Covenant-type outputs.
▫️Every new Opcode or Covenant type change means adding new rules to the consensus layer.
If all nodes or miners do not agree, then a chain split (soft fork contention) can occur.

So is Covenant dangerous?
Not at all, Covenant itself is not dangerous,
But it is dangerous if the user uses it dangerously. Moreover, it is powerful.
Just as caution is required when using powerful tools, proper security design and setting limits are essential in the case of Covenant.

Developers working on Covenant have proposed different versions to see if this capability can be added without breaking the consensus rules of Bitcoin Core. For example-
Jeremy Rubin proposed “OP_CHECKTEMPLATEVERIFY (CTV)”
Gleb Naumenko proposed “OP_TXHASH or TXHASH”

Covenant Script Modern Upgrade or New Vulnerability Door? We would like your valuable opinion on this.
Satofan44
Full Member
***
Offline Offline

Activity: 168
Merit: 407


Don't blame me for your own shortcomings.


View Profile
October 09, 2025, 03:34:25 PM
Merited by d5000 (2), ABCbits (1)
 #2

They explain the following conclusions about its risks_
▫️ Since Covenant allows anyone to create scripts that force transactions to be sent to specific addresses or conditions.
This allows governments or large organizations to create policy-enforced address lists and apply “whitelists/blacklists”.
If Covenant is used incorrectly, the fungibility and independence of Bitcoin can be damaged.
This is nonsense and not a valid concern. The government and organizations already do this. Private companies can also do this. The way it is done is by centralized methods. All covenants would do is improve all of these existing methods, that are already used, and make them decentralized.

▫️ If Covenant is designed incorrectly, “recursive” or repetitive covenants can be created —
that is, a Covenant will continue to impose the Covenant on subsequent UTXOs, acting as a kind of self-propagating script.
If any upgrade is designed incorrectly it can cause small to catastrophic issues, this is not something that is convenant specific.

Covenant Script Modern Upgrade or New Vulnerability Door? We would like your valuable opinion on this.
Don't ask LLMs like ChatGPT about advanced subjects like this. They respond with generic concerns with have many flaws if analyzed well, they hallucinate all the time. Stop relying on them.

Xun hu
Jr. Member
*
Offline Offline

Activity: 37
Merit: 3


View Profile
October 09, 2025, 04:48:25 PM
 #3

I get that you’re saying ‘Governments already do all this, covenants just decentralize it. sure, partially true but you’re missing some key points

first off centralized control and covenant-driven control are not the same thing in centralized systems if someone changes policy it’s outside community oversight. but with covenants if they’re misdesigned, you could get recursive covenants or locked outputs and that’s decentralized risk, no one can directly control it. that’s a new kind of systemic risk.

second, predictability. you’re saying centralized systems already exist so covenants aren’t bringing anything new. reality check: Ark, Vault, or CTV type covenants create new transaction patterns. they help with privacy tools, sure, but they also bring new fingerprinting risks for blockchain analytics that wasn’t really a thing with centralized KYC or exchange blacklisting.

third, i kinda agree with you on ChatGPT and AI they do spit out generic or sometimes hallucinated stuff. but dismissing LLMs entirely means you miss out on a broader innovation discussion, we need both technical risk and potential utility in the picture.

Covenants themselves aren’t dangerous but without precise design+community awareness+audit, they’re a powerful double edged sword, we want to unlock their potential without compromising chain safety.
if we prevent recursive behavior and shield predictable patterns, covenants could be the building block for privacy first, decentralized smart vaults. that’s something most people overlook.

So yeah, centralized control exists, but covenants bring programmable, decentralized capabilities and that’s not just the same old thing in a new wrapper.
Satofan44
Full Member
***
Offline Offline

Activity: 168
Merit: 407


Don't blame me for your own shortcomings.


View Profile
October 09, 2025, 06:37:48 PM
 #4

Did you just respond with your alt account?  Roll Eyes Tagged both accounts.



first off centralized control and covenant-driven control are not the same thing in centralized systems if someone changes policy it’s outside community oversight. but with covenants if they’re misdesigned, you could get recursive covenants or locked outputs and that’s decentralized risk, no one can directly control it. that’s a new kind of systemic risk.
It is not. Stop exaggerating everything. This "systemic risk" is not anything specific to covenants it is present in all feature additions and further it is always present due to the very nature of Bitcoin itself. Anyway many outputs are "locked", either by technical error or by key loss. Stop spreading misinformation.

Ambatman
Hero Member
*****
Online Online

Activity: 784
Merit: 926


Don't tell anyone


View Profile WWW
October 09, 2025, 08:53:08 PM
 #5

Smart contract on layer one is a No to me. But I understand it's utility and find it as a good direction if properly implemented
Maybe on separate layer say Layer two.

Quote
Covenants themselves aren’t dangerous but without precise design+community awareness+audit, they’re a powerful double edged sword, we want to unlock their potential without compromising chain safety.
In my opinion, There's always a price. The simplicity of Bitcoin is one it's strength.

Quote
We would like your valuable opinion on this
You can check out this thread.
https://bitcointalk.org/index.php?topic=5220520.0

d5000
Legendary
*
Offline Offline

Activity: 4424
Merit: 9599


Decentralization Maximalist


View Profile
Today at 02:33:18 AM
 #6

Maybe on separate layer say Layer two.
The "problem" here is that we don't have perfect Layer 2's still, and covenants could enable better ones.

Still hoping for hashrate escrows / Drivechain but this proposal is almost 10 years old now. With a limited set of covenants we could get finally Ark taking off (e.g. with OP_CTV) and also some new sidechain and rollup ideas would benefit from it.

I understand however the concerns regarding recursive covenants. This could lead slowly to a separate Bitcoin universe with some coins only being able to transferred with other rules which could never be changed again. So I would prefer a very restricted proposal. Some rollup ideas like this one rely on recursive covenants, so other alternatives should be researched.



It would be interesting as a thought experiment what would happen if we had such a "walled garden" of "restricted covenant coins for life" ("covenantBTC") and they compete with regular BTC: would they diverge into different currencies with different prices, transforming the covenantBTC effectively into an altcoin?

One could argue for example that a covenantBTC is less flexible than a "vanilla BTC" and thus should have a lower value. If less people accept the "covenantBTC", that would reduce the incentive for Bitcoin users to create recursive covenants with these characteristics.

Perhaps this would mean that the fear of recursive covenants is exaggerated? I have still not found an answer for that.

The government example doesn't really convince me. If people are so scared about governments banning an "unseizable" Bitcoin, they must acknowledge that these governments could also ban generally all coins which don't offer blacklisting, so for example only ERC-20 tokens could be permitted.

Xun hu
Jr. Member
*
Offline Offline

Activity: 37
Merit: 3


View Profile
Today at 06:00:42 AM
 #7

Maybe on separate layer say Layer two.
The "problem" here is that we don't have perfect Layer 2's still, and covenants could enable better ones.

you’re absolutely right that L2s aren’t perfect yet but covenants shouldn’t just “fix” that gap they can redefine how L2 and L1 communicate, the real edge isn’t in restricting covenants but in containing them through verifiable limits like expiry heights or state-bounded scopes that prevent recursion without killing flexibility.


I understand however the concerns regarding recursive covenants. This could lead slowly to a separate Bitcoin universe with some coins only being able to transferred with other rules which could never be changed again. So I would prefer a very restricted proposal. Some rollup ideas like this one rely on recursive covenants, so other alternatives should be researched.

that’s a fair concern but recursion fear shouldn’t lead to over restriction, instead of banning flexibility we should design containment logic covenants that expire, or can only operate within bounded block heights.
that preserves decentralization while keeping self-propagation under control.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!