[wizzwizz4]

> Things like the Bitcoin Cash fork & DAO fork arguably set the precedent that the developers control the funds.

Perhaps it made people more aware of that fact, but this was always true. Bitcoin has never been "trustless"; that's always been a mirage. (Not even the original Bitcoin whitepaper makes that claim, and it claims some pretty dubious things!)

[midmagico]

Pfft. Its existence solely and only persists through the mass of nodes run by people who utilize the network. The only control that developers exert is over their own actions and willingness to write code. The overall community consensus to run that code is cooperative, *not* coercive.

You have absolutely no idea what you're talking about.

(edit) And you clearly never read the whitepaper: "What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party."

^^ Literally trustless right there.

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