Nostr Web Client

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

waxwing 1y ago

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

Reply to this note

Please Login to reply.

Discussion

Rusty Russell 1y ago

Agreed. SIGHASH_NOINPUT has a clear use case, but got mired in the fact that it opens covenants.

None of these proposals offer compelling use cases (ie beyond, basically, refining lightning) because they are all incremental. They cater to users who *don't want to* use a UTXO, not those who *can't afford to*. And that's likely to be a narrow band of users, in the long term.

The only protocol I can conceive of which *does* give something to sub-UTXO users is a group structure where all the funds can be burned if any user proves the coordinator misbehaved (Christian Decker named this a "Nero protocol", which I like). But proving every kind of misbehavior, including failure to respond, is a very big, maybe impossible, ask. TBH, I haven't tried...

waxwing 1y ago

On noinput/APO, that's interesting, perhaps even a good counter to my point. Do you think that its potential use for covenants is actually the reason it hasn't reached a concrete soft fork proposal (hence muddying the waters or smth)?

It always felt like a very powerful change, and to the extent any of these things could be dangerous, it is so more than say ctv. Or is it that eltoo *also* is not reaching the threshold of "10x" (colloq. speaking).

/dev/fd0 1y ago

Pools are a killer app and Ark (L2) will use them.

They already built a prototype on liquid. CTV works for them which could be upgraded to TXHASH later.

waxwing 1y ago

You're right to bring up Ark. But I have trouble with it, first because I don't understand it well (where is it documented properly, in detail?) and also it having "operators"/service providers is a big concern of mine - you're free to disagree on that, though. I really need to understand it but I hate it when there isn't a spec, or paper to read.

With respect to the pools concept generally, I am not so optimistic as you, but I 100% agree it's a tantalizing area. Unless it works with *very* large numbers (I don't think 100 cuts it, for example) I suspect it won't ever go anywhere, and it's critical that it doesn't effectively require onlineness of all participants etc. I find most designs are fragile, or, they have centralization.

/dev/fd0 1y ago

Docs: https://arkdev.info/docs/learn/concepts

Even I don't like the use of ASPs. However, I beleive a better version of Ark can be built using maker-taker model as used in joinmarket.

In coinjoin it can make transactions less likely to be identified on-chain as cj, more freedom to exit at any time and reduce interactivity.

waxwing 1y ago

Re the docs, I was looking at that page earlier today, perhaps unfairly dismissing it as "high level guide" when i want a detailed protocol description. If that's the most detailed description that exists maybe it works.

jungly 1y ago

> 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.

A Federated L2 could be interesting where the federation is not limited to Liquid where the federation is limited to regulated parties.

Instead, what if we have a federation managed by a threshold signature that could grow to 50-100 parties to help execute state changes for coinpool.

Such an federation is possible using a Schnorr Threshold Signature. I am building one for a mining pool, where the federation membership is backed by PoW. How such a federation can minimise trust without PoW is a question I am thinking about these days.

Meanwhile - unashamed link share to my repo: https://github.com/pool2win/frost-federation

waxwing 1y ago

Nice, seems like a good general concept for federation.

For a coinpool, I'm wondering how you fold in a threshold. For exit, unilateral exit has to exist of course. But for state updates generally, I guess *maybe* thresholds help for an optimistic path that therefore doesn't require everyone online? (Whether 1 of N or t of N is different.. i guess it just depends?).

jungly 1y ago

tbh, I am using the federation for a mining pool design, where the payout is a DLC contract. The federation acts as an oracle, and voila, the miner gets a unilateral exit, with DLC backed payout guaranteed as long as 1) miner produces hashrate and 2) federation remains honest and signs the attestation.

I have been wracking my brains to see if we can do anything with the federation for an L2 payment mechanism.

I see two problems, a) without PoW how do you keep federation honest and not start sybil attacking b) does it really do anything useful at all, as you asked the question too. I have this uncanny feeling someone somewhere will figure this out. Threshold signatures are way too cool to not give us an interesting future.