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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D%40sprovoost.nl.
