3 ms·

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

> 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-now-controls-51-of-total-mining-power-threatening-entire-currencys-safety 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 4y ago
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 4y ago
  > 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 4y ago
    > 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.

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

midmagico 4y ago

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 4y ago
> 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 4y ago
  > 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.