JeremyRubin
Discuss CTV+CSFS+CAT
Similar to my comment on CTV+CSFS then CAT+Math+EcMath, enabling CAT without more ergonomic access to its capabilities risks the development of contracts that do not fully express the intentions of their participants due to the costs or complexities involved in fully expressing those with CAT. I'd prefer CTV+CSFS then CAT+introspection+Math+EcMath.
I like this combination and consider the best possible option at this moment.
I am in favor of this (with or without CCV, "C3PO" or "C4" I don't care).
C3PO is CTV, CSFS, CAT.
I like this combination and consider the best possible option at this moment.
I used to like it too. But now i think this is how you get "native" tokens and AMMs on bitcoin.
CAT will be helpful to assemble the message for CSFS (even, for example, OP_SHA256 OP_CAT OP_SHA256 would need CAT), otherwise the functionality of CSFS may be somewhat limited.
Can't you make much more efficient leafs with CSFS alone for BitVM? e.g., an addiiton gate would be something like:
<sigX> <x> <sigY> <y> <sigZ> <z>
DUP TOALT <pk> CSFSV
DUP TOALT <pk2> CSFSV DUP TOALT <pk2> CSFSV
FROMALT FROMALT
ADD
FROMALT
EQUAL
IF
OP_RETURN
ELSE
<verifier_pk> CHECKSIG
ENDIF
CAT will be helpful to assemble the message for CSFS (even, for example, OP_SHA256 OP_CAT OP_SHA256 would need CAT), otherwise the functionality of CSFS may be somewhat limited.
PAIRCOMMIT does this in a single op per item, and without the weird side effects of CAT (e.g. Schnorr tricks, hash deconstruction).
Ah we are getting at... never get covenants. I am cool with that as well.
No, but anticipating controversial behaviors and points of hard ideological resistance can be useful.
edit: Also worth noting that recent trends since ordinals show that degens can really drive up the fees with anything that they can get hyped about, they don't really care about efficiency either. There is a huge difference between tokens that are client side validated only (literal hallucinations as far as the protocol is concerned), and tokens you can identify and interact with in script in a way that is enforced by consensus. Something worth keep in mind!
Ah we are getting at... never get covenants. I am cool with that as well.
No, but anticipating controversial behaviors and points of hard ideological resistance can be useful.
edit: Also worth noting that recent trends since ordinals show that degens can really drive up the fees with anything that they can get hyped about, they don't really care about efficiency either. There is a huge difference between tokens that are client side validated only (literal hallucinations as far as the protocol is concerned), and tokens you can identify and interact with in script in a way that is enforced by consensus. Something worth keep in mind!
You're right— Ordinals have demonstrated that hype-driven activity can significantly impact Bitcoin's fee market, regardless of efficiency concerns.
The distinction between client-side validated tokens (e.g., Ordinals, BRC-20s) and protocol-enforced tokens (e.g., potential covenant-based assets or OP_CAT-enabled tokens) is key. Client-side tokens are ephemeral—they exist as conventions outside of consensus, whereas script-enforced assets integrate directly into Bitcoin's validation rules, making them more predictable and reliable but also subject to protocol-level constraints.
This raises an important question: If Bitcoin introduces more expressive covenant-based opcodes (CTV, OP_CAT, CSFS, etc.), will hype-driven users exploit these features to congest the chain in ways that are harder to mitigate than client-side tokens?Fee impact modeling should be a top priority when considering activation path
Ordinals community is using taproot, sighash flags, nlocktime, several opcodes etc. at this moment. They will use everything that will exist in the future.
This raises an important question: If Bitcoin introduces more expressive covenant-based opcodes (CTV, OP_CAT, CSFS, etc.), will hype-driven users exploit these features to congest the chain in ways that are harder to mitigate than client-side tokens?
My guess is yes. It's all speculation ofc, but we would likely see at least one hype cycle. LNhance (CTV+CSFS+INTERNALKEY+PAIRCOMMIT) has been constructed to not enable enough expressiveness for such tokens. Specifically inspecting the input scripts is a significant technological threshold.
The basic primitives for bolt-on "native" tokens are script quining (also referred to as recursive covenants) and state carrying (stuff like amount for fungible tokens). CAT and CCV enable these behaviors. I just want to make it clear, so that people can't say later this surprised them or something!
This raises an important question: If Bitcoin introduces more expressive covenant-based opcodes (CTV, OP_CAT, CSFS, etc.), will hype-driven users exploit these features to congest the chain in ways that are harder to mitigate than client-side tokens?
My guess is yes. It's all speculation ofc, but we would likely see at least one hype cycle. LNhance (CTV+CSFS+INTERNALKEY+PAIRCOMMIT) has been constructed to not enable enough expressiveness for such tokens. Specifically inspecting the input scripts is a significant technological threshold.
The basic primitives for bolt-on "native" tokens are script quining (also referred to as recursive covenants) and state carrying (stuff like amount for fungible tokens). CAT and CCV enable these behaviors. I just want to make it clear, so that people can't say later this surprised them or something!
A strong counter-question would focus on why LNhance’s restrictive approach is preferable to OP_CAT’s increased flexibility while also clarifying the long-term implications they want acknowledged. Here's a structured response:
agree re hype cycle. It's inevitable—likely a few weeks of intense activity before interest declines —but how do we prevent inefficient congestion from causing lasting harm to Bitcoin’s fee market?
I see the argument that LNhance intentionally limits expressiveness to prevent on-chain tokenization, while OP_CAT + CCV enable recursive and state-carrying behaviors that could make such use cases easier. But I’d like to clarify—do you believe LNhance’s trade-off (limiting expressiveness) is categorically better for Bitcoin, or is it simply a more cautious, incremental approach to covenants?
When you say you want people to understand the implications are you referring specifically to the risk of Bitcoin becoming a Layer 1 token platform, or do you mean something broader
But I’d like to clarify—do you believe LNhance’s trade-off (limiting expressiveness) is categorically better for Bitcoin, or is it simply a more cautious, incremental approach to covenants?
I would say more cautious approach. By sidestepping the most controversial new behaviors we can make a very useful step forward and keep being deliberate about the features we enable. If that is desired by the community...
When you say you want people to understand the implications are you referring specifically to the risk of Bitcoin becoming a Layer 1 token platform, or do you mean something broader
Generally I want people to have a rough understanding of what is enabled by the various opcodes. I don't know which is worse for bitcoin, devs being reckless about social consequences or being overly conservative.
But I’d like to clarify—do you believe LNhance’s trade-off (limiting expressiveness) is categorically better for Bitcoin, or is it simply a more cautious, incremental approach to covenants?
I would say more cautious approach. By sidestepping the most controversial new behaviors we can make a very useful step forward and keep being deliberate about the features we enable. If that is desired by the community...
When you say you want people to understand the implications are you referring specifically to the risk of Bitcoin becoming a Layer 1 token platform, or do you mean something broader
Generally I want people to have a rough understanding of what is enabled by the various opcodes. I don't know which is worse for bitcoin, devs being reckless about social consequences or being overly conservative.
Can't really disagree with anything you said, everyone has a different approach to these things.
Reposting a few points from my soft fork support rationale doc:
Many of the objections to recent proposals look at the "unintended consequences" of the activation of taproot, namely how it allowed spamming the blockchain with monkey jpegs and other questionable use cases. They make the argument that these proposals could bring another generation of questionable use cases like this and crowd out "legitimate" use cases for bitcoin, like payments. I agree with the intention of supporting the use of bitcoin for real economic activity instead of speculation. These monkey jpeg use cases are actually just arbitraging the cost of block space against the market value of monkey jpeg vibes. It's more profitable to use bitcoin for monkey jpegs than the marginal utility of using it for payments or other mainstrea use cases. The parties involved will continue to do this as long as either the demand for block space increases (and so, min fee per byte), or the demand for monkey jpeg vibes decreases. As developers in the bitcoin ecosystem, we have very little influence over the demand for of monkey jpeg vibes. However, we do have some ability to influence the demand for block space. We also want to do this in some way that doesn't increase the experienced end-user costs, as just increasing the demand would. We can do this by finding some way to "fit" more economic activity into the same "amount" of block space. You could say we want to encourage something like Jevons paradox to trigger. There are many concrete ways to do this, like extensions of Lightning, Ark, validity rollups, or any of the other proposals. There are inefficient ways to do some of these right now, but to properly achieve the goals of outcompeting monkey jpegs, there should be a goal of reducing the footprint that these constructions have (and in a way that's less likely to have security vulnerabilities).
So yes, some proposals might enable more kinds of overlay protocols / colored coins / whathaveyou to be implemented, but it also enables a bunch of other systems that would outcompete them for block space and make them untenable.
@moonsettler can you build 2 clients for CTV+CSFS+CAT? BIP 8 and BIP 9
I will support it and help with the IRC meetings, table for economic nodes, twitter discussion etc.
By the way, one reason that we don't want CAT prematurely is because of the memecoins/altcoins culture that could negatively impact Bitcoin's regular functionality.
Per today's Solana token price and its hit on Bitcoin, I hereby declare that the memecoin season has ended, and probably we don't need to worry about JPEG etc anymore...
By the way, one reason that we don't want CAT prematurely is because of the memecoins/altcoins culture that could negatively impact Bitcoin's regular functionality.
Per today's Solana token price and its hit on Bitcoin, I hereby declare that the memecoin season has ended, and probably we don't need to worry about JPEG etc anymore...
You can do all this with CTV alone and CSFS will help it further. We dont need CAT for memcoins or scams.
@moonsettler can you build 2 clients for CTV+CSFS+CAT?
I kinda started doing a concurrent activation client for LNhance and C3PO and C4. Then PostCapone spooked me out of it. There were technical issues as well, maybe I will change my mind again. For now I want to separate the LNhance consensus changes from the fluff like tests for better reviewability.
For BIP-9 support I guess you can just set LOT to false, should work, full BIP-8 support is not implemented yet, but close enough.
branch: https://github.com/lnhance/bitcoin/tree/ccc-26.x-deploy compare: https://github.com/lnhance/bitcoin/compare/lnhance-26.x...lnhance:bitcoin:ccc-26.x-deploy?expand=1
@1440000bytes If you want to help with this, we can talk. But for that you would have to unblock me on twitter. 🤨
@moonsettler can you build 2 clients for CTV+CSFS+CAT? BIP 8 and BIP 9
I will support it and help with the IRC meetings, table for economic nodes, twitter discussion etc.
I will also help with community discussion and any project management aspects, if needed
Yeah - what we need is more young devs working. I feel as though every core dev I meet has been working w/ BTC for a decade. I think we would benefit from some new devs eager to learn, some sort of apprenticeship program. I do feel we are a bit insular and unwelcoming at times