More generally, I agree with James' observation that Bitcoin Core devs are paying much less attention to soft forks than they used to.

I can only speak for myself here. Part of the problem is that the current proposals don't excite me, yet. That's even after spending time at the op_next conference.

SegWit (which happened before I was involved) brought the promise of Lightning. Taproot lets you build cold storage with hidden fallback options.

I'm still waiting for MuSig2 to finally have broad adoption, something that's higher on my review list than new soft forks, and I barely get to it.

In that light, talk of a vault soft fork seems premature. The tool development is too far behind even for forks that already activated.

Similarly congestion control doesn't excite me. I'm general I'm skeptical of claims that the masses are suddenly going to self-custody because of a dramatic event in US politics. Especially given that plenty of other countries are in worse shape and we don't see self custody blossom at a scale where it causes congestion. The US is 5% of the world population.

That's not to say that I'm against these ideas. If I see other people work on and activate them in a competent and careful manner I might be fine with it. It's sad that their main proponents and developers burned out, and that certainly won't speed things up. Maybe grants tailored for potential soft fork devs can help here, as long as the right expectations are set.

But not being opposed does not reach the bar of me actively reviewing it, which is part of what pushes things forward.

If I see a more fleshed out design for a (BitVM powered?) sidechain with unilateral (no 1 of N nonsense) exit that gives me full privacy (Shielded CSV?), that would get me more excited. Especially if it's clear which specific opcodes are best to get there.

Other devs will have other things and other thresholds that get them out of their soft-fork winter sleep. There's a "I know it when I see it" aspect to this too.

All that said, it might be the case that one day every single core dev is excited about a soft fork proposal, or would be if they read enough about it, yet is too distracted by their day to day focus. But I'm not sure if that is really what's happening. nostr:note1579fauj8nwl38mvzle5fkupswjw6fkzqv4syupav8ckshujy24tsks9y3h

Reply to this note

Please Login to reply.

Discussion

Good to see this discussion on nostr!

Well, I guess it'll be screenshotting between twenty social media platform and forums... :-)

Agreed, especially on the false urgency. I do think vaults are cool as a final get-out-of-jail card to prevent my stack from getting stolen. But we can spend a few more years hashing out covenant proposals IMO.

Vaults are useful to prevent your hot (or luke warm) coins from being stolen. They give you a button to send money to cold storage.

Using them toto protect your cold storage is trickier, because then where do you send the coins? What if you fallback cold storage actually has worse security?

There are more subtle ways in which you can use vaults as a dead man switch, which current requires moving your UTXO's on a regular interval.

Vault to a custodian makes sense. In an emergency, you use that dormant Coinbase acct. They don't even know that's why you have it!

But in general, I see OP_VAULT and go "why can't Script do that?". Explicit opcodes for uses strike me as premature optimization or a throwing up of hands on Script as a programming language. I want to fix that, even though I'm unlikely to use vaults.

Re world population: keep in mind that although the US is very rich, they don't have more UTXOs. For congestion only the number of transactions matter, not the amounts.

When there *is* congestion then the rich will push out the poor.

But my point is that adding a few million Americans to the pool of people-with-a-government-that-actively-hates-Bitcoin is not going to make a dent in the number of transactions.

That requires a global shift towards self custody. I'd love to see that of course.

Expecting global shift without improving UX makes no difference.

It's a two way street. We make non-custodial Bitcoin UX better, governments make fiat and custodial Bitcoin suck more.

This is an interesting response to the debate, and further firms up my sense that the real problem with enacting a covenant soft fork is the lack of a *genuinely compelling* protocol proposal using it.

Don't get me wrong, there are lots of proposals, some of which are useful: vaults seems like the strongest candidate there, but they are not critical to bitcoin's survival/success (important, yes, critical, i suspect no), and congestion control is valuable but neither of these are *genuinely compelling*. Lightning was, and segwit was propelled by its existence.

To illustrate my point, if you go to utxos.org, another proposal it highlights as an example is "Bitcoin Clique". I read the paper yesterday, and the TLDR is a kind of coinpool construct that requires covenants to allow exchange of funds within the pool. It has some neat tricks (repeated trees with double spend prevention through adaptors), but imo it doesn't reach the "compelling" level because: a) it needs an operator, who needs to put up linear collateral b) exit is unilateral, of course, but is very disruptive (so large groups might never work), c) exit onchain footprint is log_2(n) in pool size which sounds great but that is another size restriction. d) fixed denomination coins!

This protocol is cool but "meh" in terms of it ever getting usage.

We need something that feels very 10x (business/marketing speak). I don't think vaults have that feeling, and congestion control definitely doesn't. That's why I believe Sjors is right to mention sidechains/ShieldedCSV (though I think the latter doesn't actually go in this direction).

You might read this and reasonably ask me: "Well, but if you don't know any super-duper compelling usage of covenants yet, why are you so keen on finding them?" It's not easy to explain, but it's an intuition I've developed, that constraining destination might be the last piece of the puzzle (after malleability fix for presigning, then schnorr for musig, mast for script size) that allows offchain contracting to work to its full extent, which I don't care about to do fancy programming in bitcoin, I care about it because I think it's needed for 50x to 500x more *users* of Bitcoin.

TLDR someone needs to find a kickass off chain (L2 if you like) protocol that could 50x the usage of bitcoin using covenants, *without centralization *, then needs to write code and deploy it on say Liquid and signet. Then the conversation changes. Before then, we're probably not going to get vaults etc. (I could be wrong!).

nostr:nevent1qqsthqlm2dkha0meqvhqx6n3suh3f0s2jx9vs4634hj965vgxn0swagpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygyxsh477ejn8rwkjv0zen0ncxwe7rj6zpnujx8j9ecgrsj43786lqpsgqqqqqqsdaag06

James’s observation uses cognitive dissonance. He’s saying everyone needs to self custody at high fees and at the same time that we should switch to receiver-pays-for-shipping soft fork. The two thoughts are at odds with each other. Datapoint for this is Rusty’s points on Nostr.

what is massive adoption? why is so important?

Yep that’s per much where my head is at too. So much yet to be explored from prior soft forks that the only current proposal that I’d like to see move forward is Matt’s Great consensus cleanup .. build work on that still ongoing i believe

I'm getting rather excited about great script restoration, it enables numerous next level protocols, and can probably be restrained securely.

A zk verifier onchain would be amazing.

I agree regarding the urgency, or lack thereof. I expect a 6102 type event in the future but this will most likely precede the sense of urgency rather than the other way around.

> Maybe grants tailored for potential soft fork devs can help here, as long as the right expectations are set.

I think Reardencode said on twitter he asked and was told no. Are the current proposals just not compelling? Or does the controversy scare away donors?

Nice article