[wizzwizz4]

> The overall community consensus to run that code is cooperative, *not* coercive.

We don't disagree. Many people act like the consensus algorithm is somehow magically obviating the need for a consensus among humans. One must inherently trust that, if one is to use something like Bitcoin.

Functionally, as long as the consensus is to install the latest version of Bitcoin Core, Bitcoin Core's maintainers control Bitcoin.

The whitepaper claims that Bitcoin removes the need for a trusted third-party to transactions. If you consider mining pools to be "a party", that claim isn't strictly true: on several occasions, one mining pool has held 51% hash power (e.g. https://www.extremetech.com/extreme/184427-one-bitcoin-group... is a notable example; before that, pools normally kept their hashing power below 30% voluntarily), so in reality, you're trusting all sufficiently-wealthy parties not to do that. However, the whitepaper doesn't make the widely-believed stronger claim about magical trustlessness.

[midmagico]

No, that's incorrect. There is no fundamental trust; you were describing control in a coercive sense among the developers by directly asserting that developers have specific control over the funds in the system.

This is obviously not true, has never been true, and I have no trouble predicting that it will never be true.

What I took exception to was the fact that you were asserting developers themselves control funds, and that they specifically were trusted parties. Overall, Bitcoin depends on no trusted third parties, since in your example, mining pools with 50% hashrate do not arbitrarily control funds either.

And no, writing software does not imply control over the network, since there were plenty of other node implementations which existed (and exist) and which users choose to run for X or Y reasons. Writing software out of consensus which arbitrarily controls funds, in your assertion and in consistency with your string of logic (context across multiple messages,) "devs writing code" is not what consensus is. Even the github repository where Bitcoin is currently published is not current consensus. Current consensus is the current behaviour of the network right now. That is current consensus.

So, no, you're still wrong.

[evilspammer]

> No, that's incorrect. There is no fundamental trust; you were describing control in a coercive sense among the developers by directly asserting that developers have specific control over the funds in the system.

> This is obviously not true, has never been true, and I have no trouble predicting that it will never be true.

IANAL, especially considering the number of jurisdictions involved.

It seems totally possible to me that a BTC developer could be rubber-hose compelled by the legal system to publish a patch, just as they might compel a bank to refund someone's stolen funds. Governments sometimes protect from "compelled speech." But what if the speech is publishing "from=acct1 to=acct2 value=100" to a blockchain? How is that different from a banker being compelled to click a button in their own UI, thats value is the same thing?

Secondly, you are right that people would probably fork and not update if the developers became compromised... then the new developers would have the same thing happen to them and become compromised. As long as the developers aren't anonymous they will be a SPOF. (This is why my initial comment said KYC killed bitcoin - its entire premise fails when it is nonymous.)

Finally, cryptocurrencies as a whole are just BTC, ETH, and a bunch of nothing. Repeated forks of BTC because of legal drama, departing/jailed developers, will rapidly move the BTC forks into the nothing category. Without consensus on a path forward (to fork or not to fork) both sides of the network are diminished. It isn't even clear if Wright's goal is to get 4b, or just to destroy BTC far enough to collect the ashes.

[smoldesu]

> a BTC developer could be rubber-hose compelled by the legal system to publish a patch

> you are right that people would probably fork and not update

One of us is misunderstanding how the Bitcoin core works. You're correct that a BTC developer could be compelled to publish a "bad patch", but nobody is obligated to accept it. If it's sufficiently controversial (eg. "accept my new ledger!"), there wouldn't even need to be a fork in the first place. It would die as a PR, and if it was forced through then miners would almost certainly protest since it undermines their authority.

You're right in the strictest possible purview of "this is possible", but Bitcoin's community would be left bereft. Anyone who tries modifying the ledger knows the weight of what they're suggesting, that's why it just doesn't happen.

[wizzwizz4]

> It would die as a PR, and if it was forced through then miners would almost certainly protest since it undermines their authority.

Since we're talking about trust… what would happen if it were waved through the PR process, bypassing those checks entirely? (Do miners normally conduct code reviews?) What if it were obfuscated, disguised as something else – perhaps complete with tests "proving" that it was, in fact, that something else. It's been done before: http://underhanded-c.org/.

> Anyone who tries modifying the ledger knows the weight of what they're suggesting, that's why it just doesn't happen.

In other words… you're trusting that everyone in "Bitcoin's community" wants Bitcoin to continue to exist, and won't do things like this?

[evilspammer]

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.

[nullc]

Why do you think miners matter? Why do you think github matters?

[midmagico]

> 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)

No, it will not happen since a majority of the devs are US-based and developers in the US can't be compelled to produce speech in the USA. Neither will it matter even if someone with push commits pushes a theft-branch to the github repository, since nobody would run it.

> 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."

This is false, no. There are literally tens of thousands nodes worldwide and achieving a worldwide-jurisdiction hostile patch push when compelled speech is illegal in many developed nations would be essentially impossible, and I would be glad to bet you impossible unless Bitcoin were already dead. In any event you're presuming nobody would be able to mount a legal defence in the first place against illegal court orders.

A hardfork change of this nature literally requires global, immediate, coordinated roll-out, or it will simply fail. There's a reason why there have been no contentious hard forks in the entire history of Bitcoin.

> 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.

This is a fantasist scenario, completely at odds with reality. There are literally hundreds of billions of dollars wrapped up in Bitcoin. That block of wealth and capability won't just sit there and be pushed to run something that would literally wipe them all out overnight. It's fantasist nonsense.

The scenario of one bloc or another demanding some change or other is similarly nonsensical due very specifically to the carefully-curated decentralization of Bitcoin and the nature of its consensus—again, the hard forks you are envisioning have a zero chance of being committed as locally-compelled speech, let alone by some legal jurisdiction attempting to compel tens of thousands of people worldwide into running backdoored software which literally none of them would consensually run. Like it's nonsense.

Similarly, miners who produce blocks which reassign any money without cryptographic signatures behind the money will be very simply, producing blocks which are the exact same thing as not producing blocks at all.

At this point, with the newness of your account and your odd half-blind awareness of how Bitcoin works, I'm going to presume you're not actually discussing this in good faith.