| I totally may be misunderstanding. I see that developers and miners work with and for each other because of their mutual stake in the network (there is some "trustless." :)) I think if even 1 developer has a court order for them to push to master, it will happen whether anyone wants it to, since GitHub is already known to mindlessly abide by government requests. (see popcorntime dmca) The people who merge or pull the code have the ultimate decision. But it's a problem. Who is accepting the code and who isn't? The developer can be disallowed from contributing to the code if this change isn't accepted. (Explicitly not "compelled speech" to "not say" something - this would be a gagball.) So the next patch comes. The question of who is forking and is who isn't raises from 50%/50% to 25%/75% until the numerator approaches zero. For the sake of networking the question isn't "whether I want to accept this patch" but "whether I think most people will accept this patch." So the miners have a endless chain of developers who are asking for this patch or no more patches. For the miners to have leverage with developers they need to be able to take over the code themselves. The next set of developers will have this issue, ad infinitum, unless the cycle is broken somehow. IMO the solution has to involve zero knowledge proofs which is the closest we can get to preventing rubber-hose legal attacks. Since XMR probably won't gain the traction to become a competitor to BTC, BTC will probably have to integrate it or continue to suffer from problems like this. edited to add addendum: The incoming/departing core developers & the open source nature of the BTC codebase also presents an issue. Unless the miners are reviewing each pull indiscriminately, they are trusting the code developers to have merged PRs that they want. How does an open source contribution, blessed by a core developer, become trustless? Anonymity is necessary to prevent core developers from being compelled, but names are necessary for trust of core developers. |