From: Sjors Provoost <sjors@sprovoost•nl>
To: James O'Beirne <james.obeirne@gmail•com>,
Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: "David A. Harding" <dave@dtrt•org>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Tue, 10 Jun 2025 18:56:54 +0200 [thread overview]
Message-ID: <0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl> (raw)
In-Reply-To: <CAPfvXf+0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA@mail.gmail.com>
Hi James,
From both your and Andrew's mail we can distill a relevant factor: pretty much everyone who is excited about (feature) soft forks is not working on Bitcoin Core.
A few, such as yourself and Jeremy, were in the past but stopped doing so.
Although trying to persuade more people inside the project to review and further develop these proposals is useful - methods and tone tbd - also consider the opposite: convince more people who want these changes to start contributing to Bitcoin Core.
Perhaps there should be grants specifically for people working on this, because as you point out it's quite the uphill battle and rebase hell. That's even true for proposals with broad support inside the project, just ask Antoine Poinsot what experience led him to (temporarily) rage-close BIP54 [0].
There are of course two downsides to that approach:
1. It takes years to ramp up. The best time to plant a tree is ten years ago. But it's been six years and multiple developers could have been ramped up by now. To be fair, grant budgets were pretty tight until only two years ago.[1]
2. As a new developer becomes familiar with the project, they develop their own list of priorities which may no longer include the soft fork they were originally excited about.
Both can be overcome and if the industry is serious about these proposals they should allocate such resources. This sounds like a cop-out:
> Many of the signers are builders capable of evaluating the proposals,
but don't necessarily have the time to opine on Delving threads or write
prototypes because they are, well, building things for actual end use.
With grants one does have to careful to not create an incentive where the new developer has to achieve soft fork activation at all cost. Too much of that will lead to massive friction and burn them out very quickly, as Mike Hearn, Gavin Andresen and Jeff Garzik can probably attest. I don't how to best encode "don't put too much ego in your proposal, it will be your undoing" in a grant contract.
---
Let me also speak a bit to my own motivation. Vaults appear to be the only feature enabled by the proposal that I personally find important enough to work on.
Bear in mind that my main priority in these six months is getting Stratum v2 readiness in v30 [2], in order to end the situation Poelstra described, and to ensure Bitcoin Core is no longer a bottleneck:
> and yet if you want to mine from your local node on a local miner
today you need to run Sjors' personal fork of the project plus two
other daemons.
Congestion control seems highly premature, Lightning works well enough for me, which makes me less motivated to look into LN-Symmetry - though I'm happy to test a working demo. I don't see an urgent need for alternative L2 systems.
Up until quite recently it seemed to me that the momentum for vaults was in OP_VAULT, which in turn would require OP_CTV. But a single purpose op code is not ideal, so this project didn't seem to be going anywhere.
I only realised yesterday that the vaults enabled by just CTV are much more ergonomic than I assumed, so I'll (continue to) look into CTV from that perspective [4].
A fully fleshed out shielded CSV demo is another thing that would motivate me to review things. That actually helps with a very serious problem: privacy.
That's why I would prefer a more powerful soft fork, conditional on people doing a proper analysis on the MeVil issue - instead of the current strategy of avoiding it. I'd get my vaults, and the BitVM folks can have at it, hopefully with less crazy transactions.
Or is CTV + CSFS enough for that? My naive impression is that CCV + CAT + 64 bit arithmetic would be much more useful there, allowing a bridge without BitVM. But maybe it's a good enough start? I suppose Poelstra co-signed for a reason :-)
Conversely, I don't oppose CTV + CSFS; I haven't seen an argument that they're harmful. Since there's little MeVil potential, I could also imagine other developers carefully developing and rolling out these changes. I would just keep an eye on the process.
What I _would_ oppose is a Python based alternative implementation and activation client like co-signer Paul Sztorc proposed.[3]
Cheers,
Sjors
[0] https://github.com/bitcoin/bips/pull/1800#issuecomment-2836126414
[1] https://opensats.org/blog/opensats-receives-additional-funding-of-dollar10m-from-startsmall
[2] https://github.com/bitcoin/bitcoin/issues/31098
[3] https://www.youtube.com/watch?v=ImUCulfr1cE
[4] https://delvingbitcoin.org/t/ctv-vault-output-descriptor/1766
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D%40sprovoost.nl.
next prev parent reply other threads:[~2025-06-10 17:03 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 11:40 James O'Beirne
2025-06-09 12:51 ` Michael Folkson
2025-06-09 14:41 ` James O'Beirne
2025-06-09 15:56 ` Michael Folkson
2025-06-09 13:51 ` Matt Corallo
2025-06-09 14:43 ` James O'Beirne
2025-06-09 17:51 ` Matt Corallo
2025-06-09 19:27 ` /dev /fd0
2025-06-09 21:12 ` Matt Corallo
2025-06-09 18:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 2:02 ` Paul Sztorc
2025-06-09 23:02 ` Andrew Poelstra
2025-06-10 2:08 ` David A. Harding
2025-06-10 13:23 ` Andrew Poelstra
2025-06-10 17:17 ` Matt Corallo
2025-06-10 23:42 ` Antoine Riard
2025-06-12 3:34 ` James O'Beirne
2025-06-10 23:42 ` Antoine Riard
2025-06-11 13:52 ` Peter Todd
2025-06-10 14:03 ` James O'Beirne
2025-06-10 16:56 ` Sjors Provoost [this message]
2025-06-10 17:15 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 19:04 ` Paul Sztorc
2025-06-11 18:09 ` Brandon Black
2025-06-10 2:28 ` Melvin Carvalho
2025-06-10 13:19 ` Greg Sanders
2025-06-11 14:12 ` James O'Beirne
[not found] ` <CAB3F3Dsf8=rbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw@mail.gmail.com>
2025-06-11 16:50 ` James O'Beirne
2025-06-11 18:34 ` James O'Beirne
2025-06-11 20:30 ` Matt Corallo
2025-06-12 0:59 ` Harsha Goli
2025-06-12 2:06 ` Greg Maxwell
2025-06-12 3:23 ` James O'Beirne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt$(echo .)org \
--cc=james.obeirne@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox