Crypto News
Readers Responses To The Cult Of The Covenant
Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.
_________________________________________________________________
Last week I published a short prompt looking to hear some readers thinking on different covenant proposals. The design space of covenants has rapidly evolved in the last two years or so, going from a mere two proposals (CTV and APO) to almost a dozen different proposals for very basic functionality that can offer large optimizations to existing use cases such as cold storage schemes or off-chain protocols like the Lightning network. It’s quite a lot to reason through on the part of the communities in this space trying to assess what proposals they should or should not support. Especially when the reasons for supporting or not supporting any specific proposal could be anything from not wanting or viewing as dangerous things it enables, to efficiency differences between one proposal and another that implement the same functionality.
I think while the developer and more technical user communities are moving closer to consensus on what is or is not desirable, or which proposals enable specific use cases more efficiently, the larger communities of active users are much more uncertain or undecided. Taking that into account I am going to break up the first response here to address in pieces
REARDEN
Rearden, proposer of Template Key, sent this in over Twitter:
BIP119/CTV/OP_CHECKTEMPLATEVERIFY is far and away the most thoroughly explored, well reasoned, ready for activation covenant proposal. It alone enables a category of scaling enhancements to bitcoin (of which Ark is an example). What makes CTV a blindingly obvious addition to bitcoin is that it composes beautifully with other proposed changes, as seen in OP_VAULT. CTV is a building block for bitcoin like OP_CHECKSIG, probably more fundamental than CLTV or CSV.
OP_VAULT also includes 2 covenant opcodes beyond CTV: one that restricts spends to carrying through the same taptree with only the selected leaf modified in a specific way (OP_UNVAULT); and another which restricts spends to a specific output script (address) (OP_VAULT_RECOVER). While these are introduced in the OP_VAULT proposal, they are also designed to be composable and may enable a broader ecosystem of self-custody improvements than OP_VAULT.
OP_VAULT has actually evolved quite a bit since the original proposal. Originally it was a very basic two part proposal, OP_VAULT and OP_UNVAULT. Each would accept three pieces of data as input for validation, with OP_UNVAULT requiring two of those pieces of data be the same as an OP_VAULT input being spent. OP_VAULT, when creating a vault, requires the hash of a recovery key in cold storage, a time lock delay length, and the hash of a key used to sign the transaction spending from the vault. The resulting UTXO locked to OP_UNVAULT that would be created would require having the same time lock value as the OP_VAULT input, the same hash of the recovery key, and then a hash requiring the eventual withdrawal transaction to match that exact hash (this part is essentially CTV baked into the OP_UNVAULT). So this proposal very simply accomplished supporting vaults, but also kind of implemented CTV, just with the requirement that you create an OP_VAULT output, and have to spend from it into an OP_UNVAULT output to be able to use it for CTV purposes. This would always be stoppable by sweeping it to a recovery address before the timelock expired and the “CTV” path was spendable.
The most recent version of OP_VAULT has been changed pretty heavily, and actually in some ways looks wholly different in accomplishing the same thing. Firstly, there is no OP_UNVAULT. That is replaced with a separate OP_VAULT_RECOVER opcode. Secondly, OP_VAULT is now entirely done in tapscript. This means every OP_VAULT restriction on spending from the vault, instead of being its own bare script in a UTXO, is now done as a taptree path. There are a lot of data values it takes as arguments, but the three things it is ultimately enforcing is this: data describing a new script to replace the taptree path being spent with, which is the first output being spent to, and the amount that has to go back into the vault, which is the second output being spent to. The script of the first output, the funds being set up to withdraw from the vault, must be the exact same taptree in its entirety, except for the one leaf being spent (which is replaced). This new leaf uses CTV itself to commit to a time locked transaction restricting where the withdrawal will eventually go. Every other path except the one spent that exists in the vault tree still exists in this output. Including a path using OP_VAULT_RECOVER, which literally just specifies the recovery cold storage path, and which output in the spending transaction has to match that script. It also enforces that the entire input amount has to go to that output. The second output in the transaction under discussion just exactly replicates the taptree being spent from, and requires the defined amount to put back into the vault.
Not only does this refactored version of OP_VAULT take advantage of CTV itself, so that it can be used on its own without unneeded inefficiency, but the use of taproot for OP_VAULT allows for more flexibility in vault construction. Different paths can allow less and less to be re-vaulted, but with longer time locks, for example. Using CTV instead of baking that into OP_UNVAULT in the previous proposal also opens the door to using something other than CTV to fill that role in a vault scheme if it becomes available in future.
I think Rearden is entirely right that both of these proposals have very clear and obvious use cases with little or no downside, and the current state of each proposal has gotten to a point that there is no needless redundancy between them, and both complement each other quite well.
BIP118/APO/SIGHASH_ANYPREVOUT is a very path dependent solution to the problem of reducing the burden of running lightning nodes and watchtowers. It started with the simple idea of letting an input not commit to its prevout point; but you can’t add a new sighash flag without a new key version, so we get a new key version; you can’t skip only this input’s prevout because that could lead to quadratic hashing work in validation, so we get implied ANYONECANPAY; the resulting tx size is large, unless we add a magic key for the taproot internal key; possibly &c. The result is a change that is _sold_ as “just adding a sighash flag” but actually adds a new key version, then reuses most of the existing sighash, and unintentionally adds a brand of inefficient covenant through pre-signed output scripts.
My Template Key draft aims to resolve most of APO’s path dependent choices by taking a step back and looking at what can be done once a new key version is required. Template Key takes a fresh look at signature hashing modes, and abandons the existing ones in favor of a new set with greater flexibility and specifically intended to be usable with either signature opcodes or CTV (most of them any way). I’m 100% positive that I missed some important considerations in the design of Template Key, but I think it’s directionally more correct than APO.
All that said, I would not stand in the way of a community effort to activate APO; it’s not evil, just could be better.
Again, I’m pretty much in agreement with Rearden here. The entire issue of APO creating a new sighash flag with different semantics is it is not something you can do in a backwards compatible way if you just try to apply it to everything, so only a new key version would be able to actually use it. There have been quite a few different tweaks and design changes/realizations over the years, and ultimately all of it has been aimed at the single new use of sighash flags: having a signature that can be reattached to any input versioned right using the same script and holding the same value amount.
If we are going to be extending the sighash flag system, there is more useful things that could be done aside from just APO. I haven’t really digested his Template Key proposal in depth, but one good benefit of having more flexibility in what inputs and outputs a signature does or doesn’t commit to is making it easier to change output amounts later in multiparty protocols to increase fees. Some protocols could do this with more sighash options without everyone having to coordinate to do it.
Ultimately I think APO is definitely a desired functionality, but there is still room in my opinion to look at more efficient and/or more flexible ways to accomplish more than just APO in one go.
Other 2 sats: Similar to you, I initially had a gut negative reaction to covenants, and especially recursive ones; but at the end of the day each _recipient_ of bitcoin chooses their receiving output script (address) and can choose to permanently lock them in some stupid way if they want. This is already possible, covenants just make it possible in new and creative ways that also enable useful/smart things. Even if we _are_ concerned about recursion, the only proposal currently close to ready to activate that enables it is APO. Much has been made about the potential for APO to enable recursion and Spookchains. As I said in my Template Key draft somewhere however, these are an academic curiosity only; as they require trusted setup with deleted keys, and can still only recurse within a fully pre-mapped set of states.
My only concern at this point with recursive covenants isn’t the potential for government blacklists, or censoring control, but enabling things that distort the overall system incentives by introducing too much complex functionality. For the charm that is the third time, I again agree with Rearden. None of the concrete covenant proposals published to date enable enough complexity to convincingly open the door to any serious incentive distortions.
ANON
An anon on Telegram sent this:
Sup Shinobi,
A few years ago when Jeremy was proposing OP_CTV activation, the majority of the louder voices on Bitcoin Twitter came together to shout idioms of ossification and in general prevent any sort of positive discourse from progressing the activation attempts. As far as I can tell, the majority of negative feelings towards covenants were mainly based on two factors; the fear of restriction on future coin spends by large regulating bodies, and the use of speedy trial. I never really understood the first part, as covenants are opt-in by nature, and any spends out of a covenant remove any forward facing restrictions on transactions. The fear of a government somehow enforcing and requiring everyone to join a covenant and restrict future payments seems unfounded, not to mention this same situation could more or less be replicated in a clever multisignature scheme. As for the speedy trial concerns, I suppose I understand that slightly, but only from a meta-stance, and not in particular to any elements present in OP_CTV itself.
Now that the dust has settled, do you have any sympathy for the fears of the covenant deniers of yesterday? Is there any merit to their social rejection? Why did OP_CTV achieve such a level of technical consensus but fail to achieve the same level of social acceptance?
Best,
Confused Covenant Cultist
To a degree of course I do, it’s a very healthy sign for active Bitcoiners to be by default skeptical of proposals or changes that they do not fully understand, either in how they work or what they are for. I think a good part of the reaction when Jeremy was discussing activation went far beyond that, with numerous people actively in bad faith continuing to “voice concerns” after they had been explained and definitively demonstrated to be baseless. A lot of that though, like you said, intertwines with concerns and issues over using Speedy Trial as an activation mechanism again.
To put it bluntly, I just think in a large part it was simply people not liking Jeremy on a personal level, or at least the way that he engaged on the topic of CTV and its activation publicly. It’s sad, and definitely undeserved, but I see the whole incident as a case of people not having a problem with the message (if they understood it), just the messenger.
Until next week, ciao.
Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.
Crypto News
Great Scott! If Only We Could Go Back to 2009 to Buy Bitcoin!
It’s 2024. Donald Trump has just clinched the election again, Bitcoin’s hit a new all-time high, inflation’s running hotter than the DeLorean’s flux capacitor, and everyone’s wondering, “What’s next?” As we all wrestle with the wild pace of history, there’s a flash in the sky, a crackle of lightning, and who should appear but Doc Brown himself. He hops out of the DeLorean, eyes wild and hair wilder, and says, “Forget sports almanacs, Marty! We’re going back – not to 1985, but to 2009, before anyone knew what a Bitcoin even was!”
Yes, we’d all love to jump into that time machine and zip back to January 3, 2009 – the day Bitcoin’s genesis block was mined. Get it cheap, stockpile our wallets, and maybe even tuck a few under the couch cushions. But here’s the catch: Bitcoin doesn’t work that way. Its greatest strength? “Everyone gets the price they deserve.” No one gets a free ride, and Bitcoin doesn’t have a rewind button – only a road forward.
Doc Brown was onto something when he said, “Roads? Where we’re going, we don’t need roads!” The path Bitcoin forges isn’t one of shortcuts or regrets. It’s a one-way journey to the future, with a price tag that keeps moving forward. It doesn’t care if we wish we’d started at $1 or $100 – it’s relentless, and that’s the point.
Today, people freeze at the current price, haunted by unit bias, plagued by a “missed opportunity” that exists only in hindsight. But Bitcoin’s value doesn’t lie in a magical price point of the past; it lies in the present – in its steady march into the future. And standing on the sidelines, waiting for some impossible dip or trying to summon 2009 prices, is like being Biff: always scheming, always missing the point.
If Marty learned anything, it’s that you can’t stand on the fence and hope things will work out. Biff, forever clueless and out of touch, is the perfect example of what happens when you miss the future staring you in the face. Imagine Biff in 2009 – he’d be mocking Bitcoin, laughing it off, and then spending decades regretting every lost satoshi. Don’t be a Biff. Don’t let hindsight or wishful thinking stop you from joining the future.
We all wish we’d snagged Bitcoin at the price of a coffee, but that DeLorean opportunity is long gone. Doc Brown would tell us the same thing he told Marty: “The future is what you make of it, so make it a good one.”
So, next time you’re looking at Bitcoin’s price today, heart pounding like you’re about to hit 88 mph, remember: there’s no going back to 2009. There’s just the next block, the next satoshi, and the next step forward. Where Bitcoin’s going, we don’t need time travel – we just need the courage to act. And like Doc would say, when it comes to Bitcoin, where we’re going, we don’t need regrets.
This article is a Take. Opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
As we barrel through 2024, the dream of hopping in a DeLorean and rewinding to 2009 to buy Bitcoin at pennies per coin tempts us all.
Crypto News
Bitcoin Businesses Feel Safe In The U.S. In Wake Of Trump Victory
This morning MARA, the largest publicly-traded Bitcoin mining company, shared that it will be rolling out three new data centers in the U.S.
Would it have made such an announcement had Harris won the election? Probably. (It’s not like they whisked up these data centers overnight.)
But would they have made the announcement with such gusto, highlighting the fact that the bitcoin the company mines will be “Made In USA”? Probably not.
American compute power is accelerating. Today, we’re announcing:
-Three new data centers.
-Owned and operated in Ohio.
-372 megawatts of capacity.#Bitcoin – Made in USA. pic.twitter.com/ltDbhKrCHJ— MARA (@MARAHoldings) November 11, 2024
The “Made In USA” line is likely a nod to President-elect Donald Trump, who’s said he wants all future bitcoin mined in the United States.
Since Trump won the election, the stocks for bitcoin mining companies across the board have skyrocketed, with CleanSpark (CLSK) even being halted due to such breakneck upward price action, indicating that not only miners but also investors believe that Bitcoin mining is welcome in the U.S. and that the industry will thrive as a result.
And it isn’t only Bitcoin miners who feel that Bitcoin companies are safe to operate in the U.S. Alex Leishman, CEO and CTO of Bitcoin exchange River, also believes that the Trump administration will be kind to Bitcoin businesses (and Bitcoin holders).
Major risks to Bitcoin have been removed or made substantially less likely this year:
– Federal Ban / Chokepoint (with Trump this is much less likely)
– Gox coins dumping (coins have already been distributed)
– Self custody ban (less likely with Trump)— Alexander Leishman 🇺🇸 (@Leishman) November 11, 2024
In this tweet, Leishman seemingly refers to the promise Trump made in his keynote speech at Bitcoin 2024 to protect the right to self-custody and to stop the Federal bureaucracy from unlawfully cracking down on the Bitcoin and crypto industry.
Will Trump follow through on all of his promises? Hard to tell.
It seems likely that he will, though, as money talks and the Bitcoin/crypto lobby raised millions for Trump’s campaign.
For now, though, optimism abounds, which is refreshing after four years of the Biden administration, which made Bitcoin and crypto companies feel uneasy about their status in the U.S.
The Bitcoin industry breathes a collective exhale as Trump’s Bitcoin-related rhetoric and policy proposals should be a boon for the industry.
Crypto News
The Race Is On To Frontrun The U.S. Government
With the 2024 election all but final, it’s clear Donald Trump, the soon-to-be 47th President of the United States, will be the most pro-Bitcoin leader in U.S. history
The big question remains, however: How effective will he be in operationalizing his strategy?
At Bitcoin 2024, Trump – as well as Robert F. Kennedy Jr. and Republican Senator Cynthia Lummis – made clear that they want the United States government to buy Bitcoin. All would seem to be in a better position to enact this following the election, as the Republican Party increased its representation in government considerably.
Yet, as for how quickly the U.S. could become active in the market, that’s more murky. Since announcing the bill, Bitcoin has surged from $60,000 to a high of $86,000, and with the U.S. government soon to be buying, there’s even more incentive for the price to escalate.
Herein lies the problem: The United States has essentially telegraphed to the world that it intends to buy an asset that’s in scarce supply, without the concrete ability to do so.
Even with a majority in the House of Representatives and Senate, passing the Strategic Bitcoin Reserve Legislation 2024 will still require an act of Congress, and the agreement of lawmakers. It would seem foolish to expect this won’t be complex or time-consuming.
For example, the bill proposes revaluing the Federal Reserve’s gold holdings, as well as integrating Bitcoin into government financial systems. Questions will likely abound, as will operational challenges. Let’s remember it took all of three years for SEC Staff Bulletins to be adjusted just to value Michael Saylor’s public markets Bitcoin buying spree correctly.
This is the nature of government — slow and bureaucratic. Even with Trump, RFK, and other Bitcoin backers in positions of power, the chances that the U.S. government begins to acquire Bitcoin on January 20, 2025 seem infinitesimal. This is not saying that it won’t happen at all, just that it won’t be timely.
This is even to omit that there could be a prioritization challenge. Maybe the crypto lobby wants to move quickly on the long delayed market infrastructure bill. If so, Congress could become more consumed with the guardrails for exchanges, and redefining securities laws than the question of the strategic reserve. After all, they helped bankroll Trump’s win.
How much could Bitcoin rise in the meantime? With the bull market in full force, I’d argue that institutions and governments have every reason to become active in the market. There are many regimes around the world where the executive branch has enough power to begin accumulating Bitcoin today. They’d be foolish not to frontrun the U.S. government.
El Salvador started this process in 2021, and it has amassed over 5,900 Bitcoin. Yet, it faced 2-3 years of market headwinds, as traders countered its entries. Lest we forget El Salvador bought hundreds of Bitcoin at $60,000, a move that for years was fuel for its enemies.
Trump may yet do his part to boost Bitcoin. Yet, in telegraphing his intentions, he’s almost certainly created conditions that can be exploited by savvy traders.
Time will tell them if, among them, we’ll see other nation states.
Today, I received confirmation that another nation state is currently discussing
– a Bitcoin strategic reserve
– drafting Bitcoin mining regulations so they can improve their electrical grid and better monetize stranded energyIt’s happening
— Daniel Batten (@DSBatten) November 11, 2024
The US wants to buy bitcoin. Will other countries do it first?
-
Awakening Video1 year ago
This is What Happens When You Try to Report Dirty Cops
-
Substacks8 months ago
THE IRON-CLAD PIÑATA Seymour Hersh
-
Substacks1 year ago
The Russell Brand Rorschach Test Kathleen Stock
-
Substacks1 year ago
Letter to the Children of Gaza – Read by Eunice Wong Chris Hedges
-
Substacks1 year ago
A real fact-check of Trump’s appearance on Meet the Press Judd Legum