Replying to Avatar waxwing

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

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.

Reply to this note

Please Login to reply.

Discussion

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.

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.

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.