It still feels like clarity is what's missing the most here. As always we, bitcoiners, all seem to be in general agreement, but we over-focus on the small differences that are often caused by just misunderstanding each other.
So we seem to be in a situation where there are multiple competing proposals that try (slightly) expanding the expressiveness of bitcoin Script and there are multiple usecases that people are hoping for that require this expressiveness. Of course when expanding expressiveness of programming language, it's not possible to foresee how it's going to be used in future, but at the same time having couple actual needs and usecases in mind helps.
Is there a table that would do a good job summarizing what are all the proposals and what usecases would be enabled by any of those? (formatting wise something like this) Hopefully that would at least yield clarity into what proposals should be clearly subsumed by others and only leave small number of actually competing ones.
For each of the proposals it would be amazing if we can get
  • How many lines of code it changes (e.g. using draft/example implementation)
  • Which other proposals can be used to simulate the same behavior (and what would be the extra cost)
  • What are the incentive changes for Miners, Node Runners, Users, Exchanges...
  • Who are the main proponents/drivers
  • Who are the main customers
Is there such a table?
And further on my wishlist - it would be amazing to have someone great like Elle Mouton write the deep-dives, explanations and comparisons in easy to digest way.
100% this. I am sw dev so i am technical. I am Bitcoin user for about 10y yet i never took the time to get deep into Bitcoin codebase. To me goals of DCs make sense because those are general good sw design practices (layering, isolating the risk, extensibility). I am very open to arguments against yet i have not seen any presented in a form that would make sense to me. Unknown unknowns in not an argument for me. I was hoping for good write up from Peter Todd (i am so sucker for this guy) so i can finally make my decission. I feel like most of pro-DC crowd is exactly like this so someone like OP (which i am also big fan of) taking time to write good summary could actually help to resolve this situatuon.
reply
Peter Todd is such a valuable voice in the space. Concerning drivechains, if you look at his last comment on SN you might get an idea on his stance, but I would also appreciate his input here. If a personal bounty would be required for his valuable time and effort, I'd be happy to help fund it.
reply
"Approach NACK: given that drivechains has fundamental flaws unrelated to the exact implementation, there's no reason to distract Bitcoin Core development with this pull-req, even in draft form. What's holding Drivechains back is the idea itself, not the code.
You haven't even bothered to write or link a high-level BIP-style overview of this take on the idea. Writing a bunch of detailed code is a waste of time."
And some fanatics below are impertinent enough to scream: "You need to see a psychiatrist" - while he is talking about tail emission or demurrage as solution to other threat for Bitcoin, i.e. so painfully obvious lack of free market in post-subsidy era.
reply