> 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.
This is incorrect. I am excited about potential extensions to Bitcoin's scripting capabilities. I know at least Greg Sanders and Anthony Towns have shown interest, given their substantial contributions in this area. You are showing interest too, and i know others are interested. This is plenty of individuals that are both interested in "feature" soft forks and contributing to the Bitcoin Core project. I won't take the bait into responding to people breaking Chatham House rule to steer political drama. But the reason for the lack of progress of these proposals and others is not to be found with Core contributors. On Tuesday, June 10th, 2025 at 1:03 PM, Sjors Provoost <sj...@sprovoost.nl> wrote: > > > 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+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D%40sprovoost.nl. -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/lwLiMkO_bCFho9M5zNi78X3C8pspK83ovYKzel7LPn2XLVKYmkjY5iwpQouCHOfTGlG6r85BlNn9xbJtwDPG3yd69BhnmeohMXmYOl1ZKD0%3D%40protonmail.com.
